Since a bunch of people are setting up a straw-man to criticize this post for "not just serving plain HTML" I'll share my opinions on this.
Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, they are going to use it to build a monolith application to get content from a database, or a service, then generate server-rendered pages, and also host an API from the same codebase, or something similar.
Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views.
If you haven't experienced this already, you will come away with one of two conclusions.
1. Wow, this is so much fun, as long as I stay on the happy path of ... Rails ... Django ... ASP.net.
2. Wow, setting up all these moving parts really sucks' I'm mostly writing configuration files, and then Googling the error messages when I inevitably screw something up.
What I think Deno is trying to do is make the process of getting a server side rendered application with modern tooling running with minimal ceremony, while still enabling the developer to customize the system and build things that are not covered by the documentation guides. In addition, their solution is one that can be more easily hosted on edge servers than most other options out there.
I'm glad they are doing it, because it's a sorely lacking area of modern web development. They only other people who are taking this on in a meaningful way that I am aware of are Remix. I would be happy for there to be more entrants into this field.
Your focus on things being "modern", which is no indicator of value except for hipsters and recruiters, made you forget about the third conclusion with which you might come away from setting up a monolith application:
3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not
It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations.
If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.
There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it.
The novel thing, for this, in my mind, is the edge hosting.
> Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views.
You can use a service worker proxy to cache and serve files to an application, which keeps things both fast and also with raw uncompiled html and JS file.
I don't think most of the people commenting here realize that the entire site loads just fine with Javascript disabled. Essentially this is HTML getting generated on the server.
The fact that it is in Deno rather than PHP, Ruby or Python is the point of the article.
Thank you. Being unfamiliar with Deno, I was trying to figure out what was loading the libraries when there was only one request/response over the wire. I of course was making the assumption that the single JS file was being run in the browser, not on the server.
I mean, this is a "single file website" in the sense that `<iframe src="https://google.com"></iframe>` is a "search engine implementation in one line of code".
The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step. It's really not that different than doing regular Node.js development with a committed node_modules (hi, Google), except that if node.land or crux.land go down, you've lost your reproducibility.
The thing about "familiar/modern techonologies" seem like superficial vanity. A vanilla Node.js equivalent might look something like this
import {createServer} from 'http'
import {parse} from 'url'
const route = path => {
switch (path) {
case '/': return home()
case '/about': return about()
default: return error()
}
}
const home = () => `Hello world`
// etc...
createServer((req, res) => {
res.write(route(parse(req.url)))
res.end()
}).listen(80)
Which is really not anything to write home about, nor an intimidating monstrosity by any measure. Serving cacheable HTML is really not rocket science, it simply does not require "the latest and greatest" anything.
I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website.
> except that if node.land or crux.land go down, you've lost your reproducibility.
Dependencies are cached. This is no different from if npm would go down.
> The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step
Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime.
In regards to your node example, this is fairly different:
the dependency pulled in from deno.land is a wrapper around the built-in http server, which does various error handling for you and simplifies the usage.
The router isnt a simple switch statement either; its a URLPattern (the web's version of path-to-regexp) based minimal router. Campring these to the node built-ins isnt exactly a fair comparison I would say.
Also on top of this, with node you need a configuration to get typescript working, then you need a package.json, etc etc.
This is great, I'm not sure why this is being misinterpreted so much. Serving generated HTML from Node using Express many years ago was also great at the time. You can still do that, but in my experience the tooling is quite dated/fragmented and the ecosystem+language has evolved significantly since then. Nowadays, SSR+Node generally refers to front-end frameworks with SSR capabilities (Next, Nuxt, SvelteKit, etc.) or generation of static files. Building a dynamically server side rendered site using TypeScript+JSX but without the issues of client side frameworks, hydration, SPA routing, etc. sounds revolutionary, even though it shouldn't(?)
This starts to make sense when you consider the self-flagellation of a full server-side-rendering production setup that has existed over the past decade, to the point many SPA products completely give up on SSR - or nowadays throw themselves at the walled garden of Vercel/Next.js etc to solve it for them.
There's plenty of non-Vercel attempts at this and it's kind of table stakes for frameworks hoping to get popular. There is a push for server-first/MPA app development where SSR is assumed to be the baseline. Remix [1], Qwik [2], and Marko [3] are in that camp. I'm not sure about Remix but the other two have a goal of authoring the entire app components but only sending the JS needed for the parts that can change on the client.
Aaron from Deno here. Of course it's producing HTML as an output, but the point is that you can use JSX and familiar technologies like tailwind to dynamically generate that HTML at edge vs client side.
And unlike a pure static site, you can add API or form routes
> /// <reference no-default-lib="true"/>: Deno comes with various TypeScript libraries enabled by default; with this comment, we tell it to not use those, but instead only the ones we specify manually.
Interesting. I checked the docs on this and it’s not quite clear to me why this is needed in this case, or what the benefit is in taking this approach. Is this strictly a build time optimization, or is it necessary in this example?
Tons of big websites use something quite similar to this for their maintenance pages - pop a page of HTML in a JS function, upload it to a Cloudflare worker, and attach that worker to a wildcard route to catch everything on your domain temporarily when you want users to see your maintenance page. It's a common strategy that works well.
I've been dabbling in Deno for a while now. Standard lib is there. Testing is there. All the packages I'd ever want are there. Linting, a strong style guide, and a documentation generator too.
And unlike other beasts, it feels so minimal and out of the way.
Is there a particular advantage to how this is done here with Deno or is this just an example of server side rendering being possible in Deno? The latter is fine as I'm a fan of Deno :) just missing why it's such a popular post (maybe more Deno fans?)
If the the deno executable is roughly the same size as a popular "web browser"1 why not just distribute Javscript files and let users run them in deno. Or let users "import" them into their own scripts.
1 The one I downloaded weighs in at 85MB. That is smaller than some popular smartphone apps.
As I understand it, deno is designed to be somewhat safer than nodejs.
I can edit and compile deno much easier than I can compile a popular web browser. Some popular web browsers are not meant to be edited or compiled by users. If there are things that users dislike about these programs they are powerless to change them.
The "web browser" is created and controlled by companies in the business of user data/metadata collection and advertising. AFAIK, the people behind deno are not engaged in such practices.
The "modern" web browser has become a Trojan Horse of sorts. Instead of a program for displaying and reading HTML, it has become a vehicle by which users indiscriminantly/involuntarily run other peoples' programs, often written in Javascript, in a context where a third party, the commercially-oriented browser vendor, can quietly collect user data/metadata, mediate and manipulate user interaction.
Deno takes the Javascript interpreter out of the browser.
I've been looking at Deno very briefly recently (overall a good impression) and I was very much surprised that just getting the visitor's IP address took like a dozen lines of code.
My test case was, basically reproducing something like
<?php echo $_REQUEST . "\n" . $_SERVER; ?>
and I was a little surprised how much convenience was baked into it and how you wouldn't have access to all that in other libs. That someone created an issue[1] makes me think I am not just not looking good enough and it's actually tedious.
I keep seeing comments about static html vs generated html. So I have a question (please respond):
Why can’t we just run the example Deno program to generate snapshots of html?
It seems like some of us think pure static html is a good goal for some things, so why not use this Deno program to create the same html responses in generated files?
It’s probably the same amount of code because instead of writing a http response you write a file.
Of course you lose some functionality this way, but your app you rules imo
Alas, I wanted to believe, but I pretty much immediately uncovered a bug with the way my browser’s back button works.
In iOS Safari, click the “CLI” link at the top, then swipe the page to the right to go back. If you do it slowly it works, but the first time I tried I did a regular flick-swipe from about the height of the page where the version number is. I was trapped in deno.land and couldn’t go back.
(Maybe that’s a bug in deno.land though, not deno.com?)
[+] [-] Dangeranger|3 years ago|reply
Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, they are going to use it to build a monolith application to get content from a database, or a service, then generate server-rendered pages, and also host an API from the same codebase, or something similar.
Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views.
If you haven't experienced this already, you will come away with one of two conclusions.
1. Wow, this is so much fun, as long as I stay on the happy path of ... Rails ... Django ... ASP.net.
2. Wow, setting up all these moving parts really sucks' I'm mostly writing configuration files, and then Googling the error messages when I inevitably screw something up.
What I think Deno is trying to do is make the process of getting a server side rendered application with modern tooling running with minimal ceremony, while still enabling the developer to customize the system and build things that are not covered by the documentation guides. In addition, their solution is one that can be more easily hosted on edge servers than most other options out there.
I'm glad they are doing it, because it's a sorely lacking area of modern web development. They only other people who are taking this on in a meaningful way that I am aware of are Remix. I would be happy for there to be more entrants into this field.
Best of luck to everyone out there.
[+] [-] masa331|3 years ago|reply
3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not
It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations.
If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.
[+] [-] chrisco255|3 years ago|reply
The novel thing, for this, in my mind, is the edge hosting.
[+] [-] dodyg|3 years ago|reply
https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...
[+] [-] giantrobot|3 years ago|reply
Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
[+] [-] rglover|3 years ago|reply
https://github.com/cheatcode/joystick
[+] [-] colordrops|3 years ago|reply
[+] [-] thunderbong|3 years ago|reply
The fact that it is in Deno rather than PHP, Ruby or Python is the point of the article.
[+] [-] abracadaniel|3 years ago|reply
[+] [-] bachmeier|3 years ago|reply
Not a web developer. How is this different from CGI or a regular web server? This an honest question - I don't understand the significance.
[+] [-] lhorie|3 years ago|reply
The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step. It's really not that different than doing regular Node.js development with a committed node_modules (hi, Google), except that if node.land or crux.land go down, you've lost your reproducibility.
The thing about "familiar/modern techonologies" seem like superficial vanity. A vanilla Node.js equivalent might look something like this
Which is really not anything to write home about, nor an intimidating monstrosity by any measure. Serving cacheable HTML is really not rocket science, it simply does not require "the latest and greatest" anything.[+] [-] crowlKats|3 years ago|reply
> except that if node.land or crux.land go down, you've lost your reproducibility.
Dependencies are cached. This is no different from if npm would go down.
> The only semi-interesting thing here is that this demo pulls dependencies from 3rd party registries via HTTP without an explicit install step
Given that this seems interesting to you, it seems you haven't heard of Deno (https://deno.land). It is not related to node in terms of environment, its a new completely separate runtime.
In regards to your node example, this is fairly different: the dependency pulled in from deno.land is a wrapper around the built-in http server, which does various error handling for you and simplifies the usage. The router isnt a simple switch statement either; its a URLPattern (the web's version of path-to-regexp) based minimal router. Campring these to the node built-ins isnt exactly a fair comparison I would say.
Also on top of this, with node you need a configuration to get typescript working, then you need a package.json, etc etc.
[+] [-] CreepGin|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] krapp|3 years ago|reply
We used to call those script tags back in the olden days...
[+] [-] hamandcheese|3 years ago|reply
I wouldn’t say you lost it, I’d say you never had it in the first place.
[+] [-] mavbo|3 years ago|reply
[+] [-] tmp_anon_22|3 years ago|reply
[+] [-] n42|3 years ago|reply
[+] [-] grayrest|3 years ago|reply
[1] https://remix.run/ [2] https://github.com/BuilderIO/qwik [3] https://markojs.com/
[+] [-] rglover|3 years ago|reply
1. Get some data from a database/source.
2. Pass that data to a template/component.
3. Convert that template/component to HTML (using the given framework's version of renderToHTML()).
4. Return the HTML to your HTTP request.
For example, here's the SSR for my framework: https://github.com/cheatcode/joystick/blob/development/node/.... It blew my mind when I wrote it because I was under the impression it would be more difficult.
[+] [-] edent|3 years ago|reply
HTML. You're serving HTML.
Doesn't really matter that the server-side language is JS, PHP, or BASIC.
[+] [-] AaronO|3 years ago|reply
And unlike a pure static site, you can add API or form routes
[+] [-] chrisshroba|3 years ago|reply
[+] [-] ovao|3 years ago|reply
Interesting. I checked the docs on this and it’s not quite clear to me why this is needed in this case, or what the benefit is in taking this approach. Is this strictly a build time optimization, or is it necessary in this example?
[+] [-] lucacasonato|3 years ago|reply
[+] [-] onion2k|3 years ago|reply
[+] [-] gherkinnn|3 years ago|reply
I've been dabbling in Deno for a while now. Standard lib is there. Testing is there. All the packages I'd ever want are there. Linting, a strong style guide, and a documentation generator too.
And unlike other beasts, it feels so minimal and out of the way.
[+] [-] didip|3 years ago|reply
Deno is making JS development fun again. Major props. I hope Deno Deploy is a commercial success for the team.
[+] [-] zamadatix|3 years ago|reply
[+] [-] AaronO|3 years ago|reply
Technically if you were doing this in Node, you would need at least a package.json and would have to configure your TS/JSX transpile, etc...
[+] [-] dustymcp|3 years ago|reply
[+] [-] abdellah123|3 years ago|reply
[+] [-] lucacasonato|3 years ago|reply
[+] [-] jack_riminton|3 years ago|reply
[+] [-] 1vuio0pswjnm7|3 years ago|reply
1 The one I downloaded weighs in at 85MB. That is smaller than some popular smartphone apps.
As I understand it, deno is designed to be somewhat safer than nodejs.
I can edit and compile deno much easier than I can compile a popular web browser. Some popular web browsers are not meant to be edited or compiled by users. If there are things that users dislike about these programs they are powerless to change them.
The "web browser" is created and controlled by companies in the business of user data/metadata collection and advertising. AFAIK, the people behind deno are not engaged in such practices.
The "modern" web browser has become a Trojan Horse of sorts. Instead of a program for displaying and reading HTML, it has become a vehicle by which users indiscriminantly/involuntarily run other peoples' programs, often written in Javascript, in a context where a third party, the commercially-oriented browser vendor, can quietly collect user data/metadata, mediate and manipulate user interaction.
Deno takes the Javascript interpreter out of the browser.
[+] [-] wink|3 years ago|reply
My test case was, basically reproducing something like
and I was a little surprised how much convenience was baked into it and how you wouldn't have access to all that in other libs. That someone created an issue[1] makes me think I am not just not looking good enough and it's actually tedious.[1]: https://github.com/denoland/deno_std/issues/1884
[+] [-] yawnxyz|3 years ago|reply
Also wondering if this can be done serverless-ly or requires something always on?
[+] [-] lucacasonato|3 years ago|reply
[+] [-] zzbn00|3 years ago|reply
https://tiddlywiki.com/
[+] [-] seanstrom|3 years ago|reply
Why can’t we just run the example Deno program to generate snapshots of html?
It seems like some of us think pure static html is a good goal for some things, so why not use this Deno program to create the same html responses in generated files?
It’s probably the same amount of code because instead of writing a http response you write a file.
Of course you lose some functionality this way, but your app you rules imo
[+] [-] egberts1|3 years ago|reply
Meanwhile, I just created a JavaScript-free website.
Never have to worry about broken NPM, cookies, trackings, API, or JS-based malware.
And I use my iPhone/Android to edit/create web pages in Markdown, then my CI will build it and post it for me.
Look at the snazzy 3-D CSS, also JS-free.
Did I mention that I have a no-nonsense Privacy Policy?
3-D web page. https://egbert.net/blog/index.html
[+] [-] Gravyness|3 years ago|reply
[+] [-] gorgoiler|3 years ago|reply
In iOS Safari, click the “CLI” link at the top, then swipe the page to the right to go back. If you do it slowly it works, but the first time I tried I did a regular flick-swipe from about the height of the page where the version number is. I was trapped in deno.land and couldn’t go back.
(Maybe that’s a bug in deno.land though, not deno.com?)