I guess Node.js could learn a lesson here.
Also note that Deno is an anagram of node :)
My man, let me introduce you to ... HTML. It has "time to interactive" at 0.0 seconds and content paints instantly!
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.
I'm not sure Deno(the service, not Deno the language) are actualy proposing a model - similar to Cloudflare, for example - where you have your infra somewhere and they only host the "edge", in a CDN, or spread around the world.
The browser still has to fetch and render the HTML. JS-heavy sites do tend to be slower, but no site has a 0s TTI/FCP.
How are the cache control headers with this set-up - is there a varnish or similar cdn/cache doing useful work (I'm assuming not, more importantly I'm worried pointing something like fastly at this will fail in caching static pages?).
http://mkws.sh/ uses the standard UNIX tools to generate `HTML` pages featuring a powerful sh based templating engine https://adi.onl/pp.html. Dependencies and complexity are kept to a minimum. It does the minimum required, generate HTML pages and keep duplication low using aprox 400 SLOC.
"Many [devs] are more familiar with the Chrome DevTools console than they are with a Unix command-line prompt. More familiar with WebSockets than BSD sockets, MDN than man pages. (...) Many developers, we think, prefer web-first abstraction layers." -- https://deno.com/blog/the-deno-company
I've been doing JavaScript myself for about 15 year, unfamiliar with the UNIX philosophy (to be doubted as any doctrine). Started doing web development using plain HTML the "old school" way, I personally dare to say the _normal_ way.
Before the rise of SPAs I very much agreed with the idea of progressive enhancement which is coming again into attention with the likes of https://turbo.hotwired.dev/.
While doing SPAs I always felt that stuff constantly didn't fit, that we were constantly using unfit tech, doing hacks for benefits of using a single (unfit?) language both on the server and the client, partial loads (faster loading times) and having a single codebase for all OSes. Stuff felt hacky most of the times and we were hiding those complex hacks under what _seemed_ as elegant and simple abstractions. But I believe most experienced JavaScript developers agree that the elegance and simplicity is mostly on the surface. I constantly felt dissatisfied with the code I wrote. I refuse to go on a full rant regarding SPAs and JavaScript but that's the gist of it.
While configuring my dev environment I stumbled up the https://suckless.org/ guys. Their code embodies the UNIX philosophy well although some people, including me, might say that some stuff is too simple. Simplicity for the sake of simplicity is not a good idea (nothing for the sake of anything is a good idea to be honest) but rather as a consequence of you understanding of what's not really needed.
While investigating more more the UNIX world, discovering OpenBSD and using it as a daily driver things started to fit and make sense.
Now, regarding how mkws fits generating static sites, it mimics building a small C project except the Makefile is replaced by a shell script, so all the principles fit and are well established. pp is the compiler, .upphtml files are the sources, html files are the output binaries. Everything integrates and fits well. I feel satisfied about how everything works.
Code is small and simple, abstractions are kept to a minimum. I, as a single person, am able to investigate, understand and change every part of the generating process. Can't say the same thing about a JavaScript static site generator, you don't really need the v8 engine to generate a few HTML files, that's complex, most of use agree simple is relatively good, complex relatively bad as an industry best practice.
Regarding SPAs, I believe they were a quick solution until we properly solve the problems they solve via progressive enhancement.
You're using practices from a language unrelated to webdev, scripting language unrelated to webdev and what looks to be a closed source generator built and (un)maintained by a single person. There probably is a context where this setup makes sense, but to me it's anything but simple or intuitive.
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
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).
Clicking around with the Dev Console open and watching the pages in Sources was enjoyable.
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...
If you can elaborate on how statically-served HTML would render orders of magnitude faster than server-sider-rendered HTML with a similar response time, I'd love to hear it.
This application is generating HTML on the server, but so does PHP. A Web site backed by a PHP application is the antithesis of a static site.
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.
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.
The reasons I have for justifying use of React, JSX, GraphQL, etc. have nothing to do with being "hip and cool" and everything to do with happiness and productivity. Using modern tools is both more enjoyable and more productive in my experience, as someone who used Ruby-on-Rails with templated pages for four years.
The accounting software I use, written in 2004, evolved over the decades starting from 1980s software. It all works (hence, I’m using it now), but comparing the user experience and source code of various features developed at various times reveals a lot about what “modern” means.
Here’s a few things:
Standardisation: Modern software tends to use proven designs, such as SQL over a bespoke query language.
Performance: The strictness of ABIs and APIs makes it difficult to restructure for the sake of optimisation without introducing undesirable breaking changes. Old codebases may be essentially “frozen” and stuck on old versions of libraries. Fresh software can use the latest versions of libraries, with their new APIs & ABIs and whatever optimisations come along.
Fundamental coding improvements: Old languages don’t have ergonomic, performant closures (see lambda functions in Python). New languages do (see arrow functions in ES6). Replace “closures” with any core language feature, like null coalescing, match statements, object & array destructing (or even better: pattern matching assignment), or hygienic macros. (Let’s not discuss async/await as that doesn’t lie in the “unquestionably better” column.)
Better error messages & debugging: Over time, we collectively as developers have figured out what helps and what hinders when trying to track down troubles.
——
I also build stuff that solves real world problems. I once used Python and Django for everything. Now, I’ve moved to Node.js, TypeScript, React, and generally that ecosystem. It works far better than Python+Django. My development speed is blazingly fast in comparison, and the results stand up — they’re shippable.
Once I was familiar with Python & Django, they got the job done.
Now, I’m familiar with TypeScript & Node, they get the job done better.
Familiarity is that invisible force that, in its absence, prevents us from distinguishing things that don’t work from things that do work but are just different from what we know.
i seek out new technologies because i want to be _more_ productive than the average engineer. i don't believe there are hundreds of thousands of developers who are more productive than someone who makes an effort to learn stuff like deno, vite, unjs, fauna, etc. as soon as possible
The novel thing, for this, in my mind, is the edge hosting.
Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well.
Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.
https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...
Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
why do you have to sprinkle that snark + negativity in there? it implies a toxic role of "you are superior" and "people who use JavaScript to serve static blog content" are inferior.
why can't we all just get along? especially in this tight-knit programming community that is supposed to be full of love and collaboration. in today's modern day of inclusion and emphasis on mental health, you're spreading hate towards people who use JavaScript to serve static blog content and talking down to them. not every 2022 of you, in my opinion.
let's work to get rid of the culture where you imply somebody else's code project doesn't meet your standards, and that since they wrote it, they are dumber than you for making poor design decisions in your opinion.
I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users.
I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.
The fact that it is in Deno rather than PHP, Ruby or Python is the point of the article.
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.
CGI is replaced by JS
Apache/nginx is replaced by CDN
web server is replaced by edge nodes (aka, glorified runtimes automagically spread across many endpoints)
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)
[1] https://remix.run/ [2] https://github.com/BuilderIO/qwik [3] https://markojs.com/
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.
HTML. You're serving HTML.
Doesn't really matter that the server-side language is JS, PHP, or BASIC.
And unlike a pure static site, you can add API or form routes
I'm a huge fan of runtimes that reduce boilerplate and configuration, so that's what makes me most interested in Deno. What I'm most concerned about is that we're pushing the idea that Deno's approach to third party imports solves all the problems of npm et al. If we teach developers to think of third party and native libraries as equivalent, I think we're hiding a lot of problems rather than solving them, which could be even worse.
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?
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.
Deno is making JS development fun again. Major props. I hope Deno Deploy is a commercial success for the team.
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...
The goal was to showcase simple yet intuitive JSX + tailwind at edge, we didn't elaborate on more advanced use-cases like authenticated pages, API endpoints/forms, dynamic pages (location, etc...) or parametric routes.
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.
My test case was, basically reproducing something like
<?php echo $_REQUEST . "\n" . $_SERVER; ?>
Also wondering if this can be done serverless-ly or requires something always on?
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
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
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?)
> 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.
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. </two-cents>
This is what's called an "analogy".
But your other points are valid.
Deployment for a vanilla node.js thing is as simple as adding `node index` as the entry point in your favorite provider (because they all have node.js images these days), I've had such a thing humming along for years. Again, it's really not rocket science.
We used to call those script tags back in the olden days...
I wouldn’t say you lost it, I’d say you never had it in the first place.
also not new, but you know that already :)
It really comes about from my frustration. So much effort pushing into new tech and the result (at least as I and others in the comments here noted) is something reflective of pre-existing technology that has been around for decades.
I get that though enough of these exercises true innovation does emerge. However there is a whole lot of "re-inventing the wheel" in-between that which is frustrating as it seems to be prevalent.
Imperative vanilla code vs Declarative components. Both should have their place.
Rendering HTML on the server has always been the standard way of doing it, so the whole concept of SSR is funny to me. We've been creating new abstractions that trade old problems for new problems, and then newer abstractions that trade out problems again, since the dawn of time.
And yeah sure, you can always take a simple demo app with Declarative components and turn it into a few lines of imperative vanilla code and say it's simpler this way. But then what? How are you tackling scaling, organization, composability, and deployment? (these are the real things the deno team is trying to show here, are they not?) By the time you design everything out and put all these in place for your vanilla code, you'll end up spending just as much resources (if not more) as you'd have for using Declarative components with deno.
Whether one wants to squint at this and think of React is neither here nor there, IMHO. Svelte, for example, cannot implement this website in this MPA format with only one `.svelte` file, but I don't think it's necessarily more verbose or slower to develop with than, say, Gatsby.
On the other hand, https://docs.ycombinator.lol/ has been running for years without me ever having to worry once, so there's that. Maybe it's time to give them another try.
Try it out: https://hi-there.vercel.app
▲ /tmp/ mkdir hi-there
▲ /tmp/ cd hi-there
▲ hi-there/ echo '<h1>hi sillysaurusx</h1>' > index.html
▲ hi-there/ vc
[…]
Inspect: https://vercel.com/rauchg/hi-there [690ms]
Production: https://hi-there.vercel.app [copied to clipboard] [9s]
Happy to hear more feedback on pricing. Please reach out to rauchg@vercel.com
I think it was in the transition between now and vercel. Back then, `now` had some sort of requirement where it only worked automatically if the folder had a package.json file. A plain index.html file required configuration. Delighted to see that this is no longer the case.
I'll give `vc` a shot.
The pricing issues stemmed from the fact that I use updown.io to monitor my domains. Since it pings them every 15 minutes or so, and since vercel spins up servers on demand, that means I was paying for essentially 24/7 service, which was an unwelcome bill over what I signed up for. Customer support gave a 50% refund, which I appreciated, and I've downgraded to a free account ever since.
Everytime I give myself some free project experiments (have a local PI for tinkering) I always feel it’s unnecessarily complicated or feeling that hill I have to climb, at which point I can dream the solution in PHP frontend JS/HTML.
I think if you want to pick a pragmatic toolkit to work with long term and kick the churn to the curb, PHP is a great choice for web applications and will continue to be for a long time thanks to it's diaspora.
That said, React makes building even more interactive, complicated things simple, and is easy to hire for, so thats what we use at work.
I do think the world is still ripe for a PHP-like language. The template-style webserver-aware way of doing things, with modern features. Maybe one day.
Channeling my inner Cicero, Fuck Rust.
If you haven’t experienced any pain authoring isomorphic JS with Node, that’s great! My experience has been the opposite of that. But with Deno, everything feels completely web native. You never need to worry about modules, syntax, platform features (even localStorage!), or packages… it just works.
On top of that, all the built-in tooling is high quality and I’ve never felt the need to replace them. A formatter, test runner, bundler, type checker, doc generator, benchmarker, and even the built in deployment platform. In fact, I’ve never experienced a more smooth deployment experience anywhere. There is nothing this cohesive in Node.
If you need one more reason, Deno is arguably the most secure runtime in the world. I would not be surprised to see more corporations start to use Deno for user submitted programs as we’ve seen recently with Supabase and Slack, for this reason.
At the risk of diving too deep into opinion territory, I'm not all that enthusiastic about isomorphic JS (and I say this as a someone who's worked on a isomorphic framework). The promise of low learning curve is certainly appealing, especially for those still in the learning phase, but at least in my experience I find that isomorphism falls a bit short in practice because server and client semantics are just... different.
When I talk about compatibility, I'm specifically talking about non-platform compatibility, i.e. library authors need to consciously target Deno if they want to support it, and the way to do so may be entirely non-trivial (e.g. the lengths that postgres.js goes to, compared to slonik, comes to mind). But most of the JS ecosystem lives on NPM and imports things willy-nilly with no regard for whether their thing will work in Deno because that's the path of least resistance. This is not Deno's fault of course, just an unfortunate reality.
You are right about incompatibility being a major issue; Deno recognizes that as well, hence, they are working on a compatibility mode that allows using Node specific libraries in Deno[2].
> migrating to Deno is, charitably, likely a monumental task that nobody would ever undertake, even considering the upsides.
This is, of course, contingent on the architecture used: for code tightly coupled to frameworks/runtimes it is indeed a monumental task. I have two small to mid size SaaS apps happily running on Node.js, but I'm looking forward to replacing it with Deno solely for the streamlined DX. The apps follow DDD architecture, thus, framework specific stuff is decoupled into a service/adapter and changing it is a day's work. The major technical road-block for now is indeed incompatibility of third-party libraries/SDKs written for Node.js (google sdk, mongdbo driver, etc.).
[1] https://itnext.io/moving-libraries-to-deno-the-whys-and-hows...
You can just move your DENO_DIR (cache) along with the rest of your code the same way you can move your node_modules folder.
You must be new here.
Don’t get me wrong, I absolutely think you should consider your tools, but I recently had to get a screw out of a bookcase. It was stuck in free air and was just going round and round, so I ended up using a hammer to push it in the right direction. This is far from the only time I’ve used my hammer for something it wasn’t intended for, and it got some new scratches on the side, but at the end of the day, the screw got out.
Which is important to remember here on HN, because this isn’t really a “programming community”, it is (or was perhaps) a platform for investors to sneak peak on interesting opportunities masked as social media for hackers. And the ”monstrosity” was launched after all, which is the most important aspect of any product.
Aside from that, I think it’s reasonable to assume that a lot of smaller and personal websites are used as learning experiences. So naturally a lot of them are going to be build “suboptimal” because the reason the tool was chosen was the tool itself.
Why do you have to sprinkle that positivity in there? It implies a toxic role of “I am naive”.
Ah, I’m just jerking your chain. For the most part I agree with you. Calling the way other people do things a “monstrosity” really is uncalled for.
Now you owe me a coffee and a monitor.
> 2-3mb of JS download (that will be cached aggressively)
It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
I don't think we should simply accept that's how things are done now.
> I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy.
A web developer like the one you mention that can't even conceive of server side rendering makes them a bad web developer. That lack of core understanding means they have no idea how a web browser works and only view the world through JavaScript. They have no concept of progressive enhancement.
So this means they'll likely spend the next five years poorly implementing features a web browser already has. They're going to make websites, er "apps", that won't work properly in micro browsers. Hyperlinks won't work or will be flakey enough to might as well not work. And best of all their stuff won't work on entry level devices that are extremely popular.
> But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users.
You say this but it's not the common case. A lot of people have shitty devices because they're cheap. Whether they're entry level phones or shitty bullpen office systems people everywhere are stuck with them.
No matter how fast Chrome might execute some JITed inner loop is immaterial when the next line adds the DOM's billionth div pretending to be a button.
Thanks to cargo culting CI/CD there's little guarantee some app is going to reference the same JavaScript file on different days so the cached version will be tossed and yet another copy of Doom will be downloaded.
There are plenty of uses for JacaScript and cool web technologies. There's also lots of places where JavaScript is indispensable and enables awesome things. But requiring 3MB of JavaScript to read a static blog post is just poor craftsmanship. It's not even interesting as a project because you've signed the reader up to execute some unsolicited code to do who knows what. If you love JavaScript, render all your markdown with it on your device and just send me the static output. Don't make me download Doom and the markdown just to turn it into a few paragraphs of text I can't actually read. Web developers should respect their audience enough not to make them spend unnecessary resources to use their stuff.
Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers.
Similar strategies are used in Phoenix Live View apps.
Load static markup and data -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.
Yeah, this is primarily what I'd expect would hold back migrations, both in actual technical terms (e.g. Deno-flavored libraries for some tasks may not exist at all) and buy-in from engineers. Don't get me wrong, I'd love to seriously consider Deno for our (very large) codebase (a 1000+ package monorepo with 400+ engineers committing), and I say this as someone who's successfully lead a number of massive migrations for this monorepo. But Node -> Deno at even 1/100 of this scale is, in my mind, potentially orders of magnitude more difficult than even a monorepo-wide Flow -> Typescript conversion, which is already fairly daunting migration.
If the point of the article was to highlight a super simple, no-fuss edge computing deployment thing, maybe it would have been better to lead with that? Because if you lead w/ "A whole static website in a single JS file", then let's not blame me for pointing out that that's a relatively trivial task to accomplish with other technologies.
If you have a reason to believe the reality is different, though, happy to hear about more details beyond "this sounds made up."