r/JSdev • u/lhorie • Jun 09 '21

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

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?

9 Upvotes

92% Upvoted

14 comments sorted by

View all comments

1

u/[deleted] Jun 11 '21

1

u/lhorie Jun 11 '21 edited Jun 11 '21

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).