3 ms·
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
by ajcp 5y ago
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 this would be when you want to do JS-y things in HTML (auth, API, hand state, etc), but they don't show any of that on their showcase site...so...yeah.
0. https://website-in-a-single-js.deno.dev/ https://website-in-a-single-js.deno.dev/
- AaronO 5y agoI 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
- ajcp 5y agoI get that after reading your blog post, so that's fair. Maybe it's just a case of the magic trick that's missing that third act. Clicking around with the Dev Console open and watching the pages in Sources was enjoyable.
- e12e 5y agoI 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).