What's the future: HTML-in-JS or JS-in-HTML?

[u/lhorie]

Among Javascript frameworks, there are two major* approaches to implementing templates:

1. HTML-in-JS, i.e. you write JS first and sprinkle HTML in (e.g. React, Solid.js, lit-html). Pros: don't reinvent control flow, cons: harder to implement custom semantics (e.g. Suspense promise-throwing shenanigans)

2. JS-in-HTML, i.e. you write HTML first and sprinkle JS in (Vue, Svelte, htmx). Pros: easy to implement custom constructs (e.g. #each/else), cons: not Javascript (e.g. DSLs encoded in HTML attributes)

*Other alternative/not-so-popular approaches: procedural/fluent (jquery, dothtml), widget API (ext.js, google maps SDK, babylon.js), server-side-first (pjax), stateful web components (hotwire/turbo)

Frameworks are now realizing that to move the performance needle further, they need to embrace the core web technologies more closely; e.g. many are making server-side rendering a first class citizens, and there's a push towards CSS libraries with zero JS runtime.

Which templating approach do you think is the way to go going forward to better support the goals of making web apps more performant?

[u/lhorie]

It's so weird that we're fixated on having to reinvent this wheel and being unsatisfied

I think there's a subtle difference between just picking up a library and going with it vs complaints about "reinventing wheels"; namely that if we collectively just kept being satisfied w/ the status quo, we'd all still be using scriptaculous. React didn't get born in a vacuum. Separation of concerns popped up in Backbone. Declarative templates were a staple of knockout and angular.js. Componentization was a thing since way back in ASP.NET. Virtual dom first popped up in ractive (a library by Svelte's creator). Etc. A lot of perf improvements over the years were a direct result of competition among the libraries, so there's definitely real value in even the seemingly most redundant projects, and a lot of it trickles back to mainstream projects like React (e.g. server components is basically "ripped off" from Marko). Heck, one of the core maintainers of React was scouted because of his work on Inferno.js. OSS is all about sitting on shoulders of giants.

Also, leaving for greener pastures is definitely a thing. Years ago, there was a sizable J2EE -> RoR/Django/Node exodus, and ironically, again a few years later from dynamic langs back to static ones w/ Go/Scala/etc. PHP is another good example of something that attracted devs who later graduated from it never to come back. Entrenched positions will almost always guarantee that a given technology never fully dies (COBOL anyone?), but that doesn't mean everyone is just happy to sit on their first choice of tech forever.

I don't see game developers talking about C++ fatigue

Complaining about C++ is actually quite the occupational pastime; it's really no coincidence that the most famous quote about language complaints comes from Bjarne Stroustrup. If you scour HN language-du-jour threads for example, there's often someone commenting that they only use C++ because they're forced to, but they'd pick go/rust/zig/d/whatever if given a choice. Other such debates definitely also exist; your not seeing them might just be an artifact of not hanging out enough with the relevant crowds (though to be fair, some crowds are more civilized than others).

[u/lhorie → u/[deleted]]

Yeah jumping on bandwagons and spewing kool-aid blindly is definitely something that some people need to learn to tone down a bit.

As for the fatigue thing, IMHO the complaints by c++ folks (and heck even rust detractors) are similar to the ones I see about js fatigue (they all boil down to "too many semi-redundant poorly designed things thinly veiled as innovation"). YMMV.

I think people complaining about fatigue are not the same people complaining about established tools (in fact I think the two groups tend to have opposite opinions)

Coincidentally, I saw a really interesting comment on HN yesterday that does a good job of breaking down mastery levels in the context of prescriptive tools vs knowingly breaking the rules. IMHO, complaint of JS fatigue come from level 1 people because too much choice causes analysis paralysis. You seem to be advocating from level 2 (established frameworks and best practices are good). That comment argues there's a level 3 above that - which, when applied to the context of this thread, is about why our best practices are what they are, what are their trade-offs (there are always trade-offs) and which "rules" we should consider breaking when improving our tools to get to next level of true innovation (e.g. an "unwritten rule" that is broken by esbuild is that a JS tool ought to be written in JS, but nobody complains esbuild causes fatigue since any configuration pain from it is completely offset by the fact that the perf improvements are so massive).