Wow that's cool. Would love to see a more "interactive" to-do or "guestbook" site that shows how that side of things work.
Also wondering if this can be done serverless-ly or requires something always on?
A whole website in a single JavaScript file
51–60 of 170 posts
Re: A whole website in a single JavaScript file
#52> /// : 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?
Re: A whole website in a single JavaScript file
#53Earlier quoted context omitted.
I understand the blog post, and the capability itself is neat, but I'm having a hard time understanding the utility in what they are showcasing from the actual example site[0]. As other posters have pointed out, why not do it in HTML from the start? It's more simple and efficient than this -or any- framework. Just drop the ol HTML file on your server and away you go! I understand that the supposed "real" utility in t…
I agree we could have elaborated on auth, API endpoints or parametric routes (maybe a follow up !). But this example does showcase a few things you don't typically get with a single vanilla HTML file: - JSX + reusable/shared components - Multiple URLs / pages - Tailwind
I actually think this is quite neat, but I am a bit worried about caching.
Someone mentioned rails, and rails have a lot of facilities to set correct cache headers for assets (css, js, images etc) and for dynamic content (for logged user in and/or for pages that are dynamic but public).
If you're deploying static files via a vanilla web server, you also get a lot of that for free, via the file meta-data.
I would expect a framework for publishing sites to showcase a minimum of good caching (client cache, ability to interact with a caching reverse proxy like varnish - and/or a cdn).
Re: A whole website in a single JavaScript file
#54Earlier quoted context omitted.
I think it's actually much worse than that - it's a little tricky to tell on mobile, but going from "stats" to "bagle" and back again - looks like this mucks up the client side cache? While one whole second is "90s slow" for a first render for a static site - it's truly ludicrous for navigating back to an already cached page? How are the cache control headers with this set-up - is there a varnish or similar cdn/cache…
The request headers have no-cache set. I assume this is because it's in a live developer playground page instead of a production deployment.
> I assume this is because it's in a live developer playground page instead of a production deployment.
Not how I read it - the first link is to a site deployed via "deno deploy", the last one is a link to the same content in a playground.
>> Hosted on Deno Deploy, this little website is able to acheive a perfect pagespeed score. Serviced from an anycast IP address over encrypted HTTP from 29 data centers around the world, the site is fully managed and will be available indefinitely at zero cost.
>> Everything mentioned here can be viewed on a playground.
For what it's worth, the deployed site seems a little snappier to me now on mobile - maybe I'm just less grumpy after dinner...
Re: A whole website in a single JavaScript file
#55Since 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…
> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages,
Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
Re: A whole website in a single JavaScript file
#56I mean, this is a "single file website" in the sense that ` " rel="nofollow">https://google.com"> ` 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…
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 t…
Yes, I know what Deno is, and when I say "semi-interesting", I mean I'm trying to find a silver lining to praise Deno for. To clarify, the similarity is that this claims to be a "single file" thing by importing the meat of the functionality from elsewhere. Which is not really interesting at all, because using batteries to make websites was already a thing with PHP in the 90s. Or, as I mentioned, it's not that different from just using express or path-to-regexp or lodash or whatever in a typical Node.js setup.
Caching dependencies is very different from general reproducibility. Committing node_modules guarantees that the app works even if the NPM registry were to implode. Try to deploy your deno thing from a cold state (e.g. maybe you're moving to a different AWS region or a different provider or whatever) while there's a deno.land outage and it will blow up. I'm actually curious what this caching story looks like for large cloud fleet deployments. Hopefully you don't have every single machine individually and simultaneously trying to warm up their own caches by calling out to domains on the internet, because that's a recipe for network flake outs. At least w/ something like yarn PNP, you can control exactly how dep caches get shuttled in and out of tightly controlled storage systems in e.g. a cloud CI/CD setup using AWS spot instances to save money.
These deno discussions frankly feel like trying too hard to justify themselves. It's always like, hey look Typescript out of the box. Um, sure, CRA does that too, and it does HMR out of the box to boot. But so what? There's a bunch of streamlined devexp setups out there, from Svelte to Next.js to vite-* boilerplates. To me, deno is just another option in that sea of streamlined DX options, but it isn't (yet) compatible with much of the larger JS ecosystem.
Re: A whole website in a single JavaScript file
#57No post body was provided.
Re: A whole website in a single JavaScript file
#58I mean, this is a "single file website" in the sense that ` " rel="nofollow">https://google.com"> ` 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…
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 t…
> I wouldnt say an iframe and this are in any way shape or form comparable. this is a "full-fledged" website.
This is what's called an "analogy".
But your other points are valid.
Re: A whole website in a single JavaScript file
#59> These are served using the serve function from the standard library. I guess Node.js could learn a lesson here.
Demo was started by the original author of Node, and they took lessons learned to this new platform.
Also note that Deno is an anagram of node :)
Re: A whole website in a single JavaScript file
#60I 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.
> Essentially this is HTML getting generated on the server.
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.