Why? Just so you can tell another developer that there's a compiler transpiling non-standard syntax into function calls that concatenate strings at runtime? While the output HTML that the user sees is exactly the same? That's exactly why I'm calling out to be library vanity. My example is SSR, that's literally the default baseline. It doesn't make a very strong argument to imply my 5 min thing will somehow be worse if only you get to decide what random garbage to add to it to make the alternative look better. E.g. Make hegel types work in the original and then let's talk loss of productivity from arbitrary decisions.
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.
I'm with lhorie. SSR literally is about serving strings... you're the one equating it with server-side JSX. JSX is syntactical sugar that abstracts vanilla JS which in turn renders strings.
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.
My point is that it doesn't matter, serving strings or rendering react comps. For folks who has to work with jsx + ssr for one reason or another, they will appreciate what deno's team has done here.
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.
What I was trying to get at is that whether you have to work with JSX or whatever, that doesn't really have much correlation with Deno per se. CRA/Next/Remix give you decent JSX setups out of the box too (for scopes where JSX is actually justifiable), and so on for all the popular framework flavors, so it kinda doesn't do Deno any justice to say what amounts to "hey look, it can do the most basic of things when you pull in a bunch of libs".
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.
Agree 100%. The first time I heard the term "Server side rendering" I wondered what the hell it meant! Must have been coined by the new-fangled DOM-manipulator army. Modern web development is a big, clunky, slow mess, and for no good reason.
SSR means server-side rendering. String-ness is irrelevant (everything is a string as far as HTTP is concerned). The difference is between serving HTML vs JS for the purposes of generating a DOM tree. The article is using nanossr specifically to server HTML, MPA-style. My thing is using template string, which is what systems like lit-html use for their flavor of "declarative components"
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.
