_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI The time is right for a DOM templating API
llcooliovice wrote 5 hours 12 min ago:
> We've explored the reactivity landscape. While early DOM templating
proposals didn't include updating, userland systems have thoroughly
explored the landscape by now, and discovered good mental models and
better and worse implementation approaches. I think we can now zero-in
on a system that combines the best features from the different
approaches.
AFAIK Ryan Carniato/Solid JS is still exploring whatâs possible with
signals. I donât think userland exploration of this space has
entirely finished, and further innovation may be possible.
codedokode wrote 6 hours 1 min ago:
The web platform is over bloated. The proper solution would be a
minimum set of APIs and set of reusable by many sites JS/Wasm
libraries.
For example, most of Web Audio (thing like filters and oscillators
except for actually sending audio to audio card) could be implemented
in Wasm making a browser simpler and not allowing to use it for
fingerprinting. Also, base64 encoding/decoding, URL handling function,
most of canvas code etc. Imagine how less work for browser developer it
would be.
yoz-y wrote 3 hours 41 min ago:
I think web needs an âactually standardâ library. Something that
vendors could ship with browsers but could be also updated to higher
version of a site requires it (and cached forever).
That would allow us to not download a bunch of code every time.
vlucas wrote 9 hours 39 min ago:
I like the spirit here, but I would argue we need a few lower level
APIs built into browsers first instead.
It will be near impossible to get everyone to agree on a standard
template system. What the browser CAN do, however, is provide some
lower level APIs on how to apply diffs to the DOM in a performant
native way.
I would LOVE for something like this to exist in browsers natively:
element.applyDiff(DocumentFragment | string, { method: 'innerHTML' |
'outerHTML' })
This could apply the diff in a way that would be non-disruptive, i.e.
it would keep element focus, input values, states in audio and video
players, mutate attributes, etc. There are JavaScript libraries that do
this like Idiomorph, but a native solution has the potential to be much
more performant.
MrJohz wrote 8 hours 24 min ago:
The article does link to the DOM part proposal, which would be one
useful low-level API. It wouldn't work so well for VDOM-based
frameworks, but for other frameworks it could simplify how they work
and provide additional room for optimisations. It would also be
useful for projects without a framework, particularly if the signals
proposal was also adopted.
TheRealPomax wrote 10 hours 1 min ago:
> This kind of templating is the cornerstone of all modern web
frameworks and rendering libraries these days, all of which let you
declaratively combine markup with data
Okay but just because fighting the river has become popular doesn't
mean wanting to pave over the river is a good idea. It might be the
logical _conclusion_ to fighting the river, but you could also just...
stop fighting the river and use it the way it was intended to be used
again.
ulrischa wrote 10 hours 25 min ago:
The answer is here on the HN Start-page: XSLT
llcooliovice wrote 13 hours 21 min ago:
> If the Records and Tuples proposal were progressing, JSX could maybe
create Records with boxes, but that proposal has been stalled,
especially on the record identity and box parts that would make it
suitable for a JSX semantics.
That proposal hasnât just stalled, itâs been withdrawn. [1] It has
been replaced by
URI [1]: https://github.com/tc39/proposal-record-tuple/issues/394
URI [2]: https://github.com/tc39/proposal-composites
llcooliovice wrote 13 hours 27 min ago:
> There are in-flight proposals for very low-level DOM update
primitives, like DOM Parts, which target framework implementations, but
I think higher-level APIs like full declarative templating can take
even more load off, help prove out and complete the lower-level API
proposals, and be really impactful for developers and users.
There is an alternative suggestion to DOM parts which might be a better
bet:
URI [1]: https://github.com/whatwg/dom/issues/736
notnullorvoid wrote 15 hours 0 min ago:
This is exactly the kind of high-level feature we need to stop putting
standardisation efforts towards, and focus instead on low-level
features that provide value for high-level user land abstractions.
There is no value this provides over making a tagged template function
and exposing it as a library. If that library is stable with ubiquitous
adoption for 5-10 years then maybe there's something to talk about.
hackrmn wrote 15 hours 20 min ago:
I disagree on the general principle of adding APIs -- the platform
suffers not from lack of APIs, when you really think about it, but from
"another API to rule them all". It's frankly a similar fallacy that
struck Microsoft where they were for a long time stuck having to
support every API their seniors and interns ever invented -- none of
which seem to be sufficient, apparently.
The solution to the "bro, just one more API, please" is to design a
_transparent_ platform that is well able to "delegate" programming of
new features (e.g. one implementing your favourite templating API) to
third-parties in a manner that maintains their "first class citizen"
status. WebAssembly was a move in that direction because it's a generic
platform that in part supercedes and otherwise supplants the mess that
JavaScript has to manage bridging the originally "kiddie script"
application software domain, with the native functionality the browser
may be encapsulating (also for performance).
Case in point: FFMpeg may be compiled to a WebAssembly module, which
gives you arbitrary video/audio encoding/decoding -- pending correct
design of bit-blitting so the decoded output can be efficiently
transferred to the screen/speakers (which, for much of the reasons I am
trying to outline, _is_ the bottleneck of the entire solution).
We need more of the same kind of thinking. Stop begging Web browser
vendors / w3C / WHATWG for more features that are just lipstick on a
pig -- sit down, think about what kind of feature(s) would allow the
Web platform to finally escape the death spiral it's been in since its
inception -- albeit one with a large enough radius it's meant to never
actually resemble a spiral.
I don't know if I am making myself clear here, but in much simpler
terms: why should there be another piece of code that caters to "most"
(because you happen to be a FP/React zealot, for better or for worse)
when these people can ostensibly write such templating system
themselves, publish it on e.g. NPM and/or pull it and use it from
there?
aatd86 wrote 16 hours 24 min ago:
I don't quite understand.
The DOM is/needs a functional API.
Why bolt another DSL on top?
Now you have to find a way for javascript to interact with your
template language.
While functions are sufficient.
That doesn't look like orthogonal language design.
troupo wrote 13 hours 57 min ago:
> I don't quite understand. The DOM is/needs a functional API. Why
bolt another DSL on top?
There are no parts of DOM APIs that are functional. It's all 90s-era
Java OOP-style.
aatd86 wrote 12 hours 56 min ago:
functional in the sense that it uses method calls on objects and
javascript has higher order functions.
It is a spectrum.
I know DOM nodes are objects that use inheritance but I also know
javascript is not deemed a "traditional" functional PL of course.
troupo wrote 10 hours 52 min ago:
Javascript being a decent functional language does not make DOM
API functional.
DOM API is 90-s era OOP
austin-cheney wrote 14 hours 18 min ago:
People want this because JSX is all they are capable of.
One reason why things like this have never happened before is because
the people who need this are only barely capable of working with
HTML. The DOM supports a wide variety of technologies far outside and
unrelated to HTML.
ukuina wrote 17 hours 42 min ago:
Nit: The post keeps referring to "standard JSX" as though trying to
will such a thing into existence.
jmull wrote 6 hours 22 min ago:
I thought one of the main points the article is making about JSX is
that it currently isnât standardized.
llcooliovice wrote 18 hours 5 min ago:
> There's no fundamental templating knowledge that's portable between
stacks, and native DOM creation APIs like innerHTML are unsafe by
default.
setHTML() is already implemented in Chrome/Edge and Firefox so this
point is a bit outdated - there is a safe alternative to innerHTML.
infensus wrote 14 hours 17 min ago:
MDN and caniuse say otherwise. I think there might've been an older
specification that got implemented, but it's been revised since
llcooliovice wrote 13 hours 31 min ago:
Chrome implemented a prototype, then the spec changed and they
removed it, then they implemented the new version. I should have
been clearer and said Chrome Canary and Firefox Nightly. Not sure
when it will reach stable but probably some point this year,
theyâve been working on it for ages and Safari is onboard.
llcooliovice wrote 18 hours 21 min ago:
There is still innovation happening in frameworks. I do wonder if it is
too early to start adding things like this to the browser. Web
components landed way too early and now weâre stuck with them.
jlukic wrote 19 hours 15 min ago:
Itâs worth noting this was written by maybe the person with the most
experience in the space i can think ofâ-the primary author of Lit /
Polymer working at web components on Google and contributing on many
core DOM specs that have become part of the web platform.
troupo wrote 17 hours 17 min ago:
> Itâs worth noting this was written by
by one of the people wrecklessly barging forward with half-baked
specs that introduced significantly more problems than they solved,
pushed a "solution" that requires 20+ new web specs to barely do all
the things user-space is already doing while completely ignoring and
gaslighting anyone who wasn't 100% on board with what they were
doing.
Safari argued that there should be a declarative ways for this 15
years ago
gwd wrote 13 hours 11 min ago:
> wrecklessly
It's "recklessly". "reck" is a very old word meaning "to care,
heed, have a mind, be concerned about"; so "reckless" means
"without taking heed".
I actually thought it was directly related to "reckon" (meaning "to
think or calculate"), but when I looked it up it turned out not to
be the case (except much further back in the etymological tree).
troupo wrote 10 hours 47 min ago:
As I get older my brain and my fingers get more and more divorced
from each other :)
My brain knows it "reckless", my fingers type "wreckless". Same
happens to a few other words, too.
JimDabell wrote 14 hours 22 min ago:
Web components were such a big disappointment. 200% the complexity
for 20% of the functionality. Everything coming out of that area
seems to be hideously over-engineered while failing to solve the
problems people wanted them to.
My feeling is that they were focused on designing something that is
aimed at building form controls, not the kinds of components web
developers use in practice. They are designed to make browser
vendorsâ lives easier, not web developers. Thatâs often excused
with âweb components excel at âleafâ componentsâ when what
is actually meant is âweb components are bad at everything
elseâ.
I would expect an actually good solution that fits in with the
webâs architecture to come from the direction of HTMX, not web
components.
> Safari argued that there should be a declarative ways for this 15
years ago
True, but they were equally able to propose and deploy alternative
solutions and mostly just went along with web components (with
exceptions of course).
troupo wrote 14 hours 1 min ago:
> True, but they were equally able to propose and deploy
alternative solutions and mostly just went along with web
components (with exceptions of course).
Safari doesn't have as many engineers (a shame) and definitely
doesn't have as many people whose apparent job is just to sit on
standards committees and generate specs (like Alex Russel, Justin
Fangnani etc.).
They did end up proposing declarative template instantiation in
2017: [1] but that mostly went nowhere
URI [1]: https://github.com/WICG/webcomponents/blob/gh-pages/prop...
JimDabell wrote 13 hours 53 min ago:
That looks interesting â certainly a lot simpler and closer
to web developersâ needs than what ended up getting
standardised.
It really is a shame Apple donât invest more in WebKit and
the web standards process. Although theyâve been doing a lot
better over the past few years.
austin-cheney wrote 19 hours 21 min ago:
DOM templating is just like JavaScript classes. Classes in JavaScript
were requested since the earliest of times and always rejected until
ES6 (2014), because they are/were:
* always unnecessary
* always artificial
* only vanity
* only desired by insecure persons not familiar in the technology
* only qualified as bad idea but necessary because people were just
going to do it anyways
So far the DOM has managed to escape this stupidity only because it is
not a part of JavaScript. Java people ignorant of JavaScript desirous
of features to make JavaScript feel more like Java has no bearing on
the DOM, for example, because they are separate technologies managed by
unrelated organizations.
None of the ergonomic reasoning mentioned in the article are qualified.
Just because many people lack confidence in the technology and
knowingly make poor design decisions doesnât mean a familiar vanity
layer will fix anything. Declarative comfort, for example, is not a
resolution to performance and security problems just because other
knowingly bad design decisions are worse. Two wrongs donât make a
right.
Furthermore the DOM already has a slow unnecessary declarative
abstraction layer insecure people cannot live without called
querySelectors. In other words this proposal is to React as
querySelectors are to jquery, and classes are to Java. These are/were
trends and trends die over time. We really should move past vanity as
an alternative to an absence of training.
yoz-y wrote 3 hours 34 min ago:
Iâm curious. What is actually wrong with querySelector?
austin-cheney wrote 1 hour 26 min ago:
String interpolation is so ridiculously slow. Epic slow.
Perhaps just as importantly is that is a crutch for many to avoid
accessing the DOM in steps. You can read from the DOM with
querySelectors but you cannot modify the DOM with them. If
querySelectors is all you can do then you must use some third party
template system because you have no idea how any of this works even
though it provides maximal expressive freedom.
9rx wrote 9 hours 43 min ago:
It is slightly different. Classes ended up being worse than what they
were trying to supplement. Templating, if done right at least (a big
if, granted), can bring small improvement. If classes were better, we
wouldn't see them the same way now.
b0a04gl wrote 19 hours 41 min ago:
no point pushing declarative sugar again into a system that's already
kinda moved on. native templating not fixing real pain = state sync,
fine grained reactivity, perf edge cases. we might need a browser level
primitives that let lib authors build better abstractions without the
payload tax. we maynot need another xsl reboot
stevage wrote 20 hours 26 min ago:
What exactly is the problem with having the higher levels of web
development supported through libraries (React, Vue etc) rather than
directly in the browser? Why does this need to happen?
mock-possum wrote 19 hours 10 min ago:
FTA, which I agree with:
> Developers need to reach for a library, and thus tools like npm or
a CDN, to do many basic things. This adds to the overhead of getting
started. It makes simple static files and devtools less useful than
they could be. There's no fundamental templating knowledge that's
portable between stacks, and native DOM creation APIs like innerHTML
are unsafe by default.
Remember when you could just drag an html file into your browser, and
it would work? No build step, no package install, no web server, just
vanilla html+css+javascript?
It would be nice to get to do that again, and the more we move things
like .querySelector out of libraries like jQuery and into native
browser APIs the better, imo.
That should ideally be the highest calling of frameworks like Lit and
packages like Lodash - to be so good that they prove indispensable,
and ultimately go native.
bapak wrote 12 hours 39 min ago:
> It would be nice to get to do that again
The answer to this is both "never gonna happen" and "you already
can."
You already can ship a React app in pure JS and even import modules
via ESM in the browser from CDN. Performance will suck but you can.
You'll never be able to actually have a complex web app that you
can just drag into the browser. As the base API expands, so do the
ambitions.
Heck we've had PHP 4 years after HTML just to fill in some blanks,
people will always want more than static code.
upghost wrote 21 hours 3 min ago:
Is there anyone else who feels kinda like declarative templating is
actually kind of worse than jQuery? Don't get me wrong, I've been using
React for nearly a decade. But the more complex my SPAs become, the
more I wish I had imperative control of the DOM.
I think the reason is because the DOM is a leaky abstraction and at
some level I would just prefer last write wins.
I realize declarative templating is supposed to handle that, but this
starts to break down really quickly when you share mutable state
between components.
bapak wrote 12 hours 35 min ago:
I donât like React but I disagree with this sentiment. First of all
you can already opt out of declarative DOM and knock yourself out
with innerHTML and ref.
Second, what can you do with imperative control of the DOM that is
less practical with the declarative one? I can only think of certain
methods (attachShadow(), showModal()) but even then you're a 10-line
component away from making it declarative.
parhamn wrote 20 hours 45 min ago:
I think part of this is React folks think its a cardinal sin to
invoke the dom apis directly. Sometimes it's just fine to capture a
ref (and dare I say, query a component by a id) and do the work
directly. In fact this is what most libraries that are "fast" and
low-rerenders do (like the form ones).
tcoff91 wrote 21 hours 11 min ago:
Stop adding more complexity to the browser and making it even more
impossible to build a new browser from scratch.
wavemode wrote 21 hours 34 min ago:
I would argue that the proliferation of frontend frameworks is evidence
is that we -don't- know what the optimal abstraction is for building
frontend applications. We're all still trying to figure that out.
Just look at what happened with Web Components. It didn't take over or
become the foundation of everyone's software. It just became yet
another competitor [0].
I wish the standards committees would focus their efforts on improving
JavaScript the language. That has a much greater and more lasting
return on investment.
[0]:
URI [1]: https://xkcd.com/927/
branko_d wrote 18 hours 1 min ago:
I would love to see Web platform become more similar to JVM or .NET
CLR - just a bytecode JIT with access to rich layout/rendering
engine. Then build whatever you want on top of it.
nine_k wrote 17 hours 50 min ago:
DOM + CSS is a hugely rich layout / rendering engine. The problem
is that it's heavyweight.
jdkoeck wrote 18 hours 39 min ago:
Is there really a proliferation? At this point itâs 90% React.
d--b wrote 22 hours 44 min ago:
The part about Signals is telling and illustrates well why the idea
while laudable is practically unfeasible.
I get why OP likes signals. In every large enough project there is a
half baked implementation of a DAG calc tree and it makes sense that a
language could standardize one.
But these abstractions have a huge mental / implementation cost.
The problem, as with most engineering things is a tradeoff problem. The
react model - where you just update the global state and re-render
everything - is slower but easier on the brain. The signals model is
faster, but so much effort.
Most apps out there donât need to be crazy fast, and people will
choose react because itâs just simpler.
But signals donât really have anything to do with templating, do
they? So why do we have to choose, could we have templating and signals
as separate things?
Well OP thought about templating and realized you do need a way to tell
the dom how to fit your templated node where it belongs and update it
when things change.
And this is where these proposals fail. There needs to be a choice
here. The API must pick a side (well technically it could allow for
both, but ugh), and developers wonât ever agree which side it should
go.
The big problem of UIs has always been how they update, not how
theyâre defined. Microsoft tried (and failed) at defining a ton of
models, MVC, MVP, MVVM, and what not, all of them were painful AF. Then
imgui come and say, well what if UIs didnât have state at all. Ooh
this is nice, but kind of hard on the cpu, so what do we do?
Well, perhaps one of the biggest reason for the success of web apps is
in fact that the dom didnât impose a way to bind data to its view.
And so we may be doomed to framework hell.
jraph wrote 18 hours 31 min ago:
> The react model - where you just update the global state and
re-render everything - is slower but easier on the brain.
I would gladly take easier on our hardware, bandwidth and planet even
if a bit harder on the developers' brains. (as a developer).
> Most apps out there donât need to be crazy fast
I wish we recognized that we need apps to be lean.
> and people will choose react because itâs just simpler.
I think you are right, and I dislike React for this.
leeoniya wrote 21 hours 45 min ago:
> The react model - where you just update the global state and
re-render everything - is slower but easier on the brain. The signals
model is faster, but so much effort.
there are multiple frameworks now that do fine-grained diffing
without relying on signals, proxies, or any other reactive
primitives. they basically have the top-down react model but much
faster and without the weird concepts like hooks and manual/wasteful
dependency arrays.
my favorite one is ivi-js: [1] it's just 8% slower than the fastest /
ugliest / imperative / unmaintainable vanilla js you can eventually
arrive at if all you care about is winning benchmarks.
URI [1]: https://github.com/localvoid/ivi
URI [2]: https://krausest.github.io/js-framework-benchmark/2025/table...
localvoid wrote 18 hours 53 min ago:
Just want to add that even though ivi is using tagged templates, I
am strongly against using tagged templates to describe UIs as a Web
Standard.
One of the most useful features that could make a lot of
incremental computation problems easier is "value types"[1], but
unfortunately it seems that isn't going to happen anytime soon. The
biggest constraint when developing an efficient UI framework with
good DX is JavaScript. Also, it would be nice to have
`Node.prototype.insertAfter()` :)
1.
URI [1]: https://github.com/tc39/proposal-record-tuple
leeoniya wrote 14 hours 50 min ago:
> The biggest constraint when developing an efficient UI
framework with good DX is JavaScript.
for perf, s/JavaScript/DOM, i think.
good DX comes from ecosystem and amount of time invested in
making good tooling. JSX would be a non-starter without IDEs
helping autocomplete, linting/format, syntax coloring, and
webpack/babel to do the compilation.
tagged templates could reach at least the same level of DX as JSX
if the community invested the resources to make that better. i'm
not saying it's the right solution for a standard, but it would
be way better than jsx, since tagged templates are already a
standard.
localvoid wrote 10 hours 58 min ago:
I would prefer a more expressive language like Kotlin[1] that
makes it easier to work with many different domains instead of
JSX hacks :)
1.
URI [1]: https://developer.android.com/develop/ui/compose/kotli...
troupo wrote 13 hours 52 min ago:
> JSX would be a non-starter without IDEs helping autocomplete,
linting/format, syntax coloring, and webpack/babel to do the
compilation.
and then you immediately go on to say this:
> tagged templates could reach at least the same level of DX as
JSX if the community invested the resources to make that
better.
So, tagged templates are also non-starters without IDEs helping
autocomplete, linting/format, syntax coloring.
> i'm not saying it's the right solution for a standard, but
it would be way better than jsx, since tagged templates are
already a standard.
They are strings. There's no magic in tagged templates that
somehow make them immediately better for some custom
non-standard syntax compared to JSX.
You can't just plop a string containing lit's custom
non-standard syntax into an IDE (or a browser) and expect it to
just work because "it's tagged templates are standard".
For the purpose of templating in the browser there's literally
no difference between standardizing a custom syntax based with
JSX or tagged templates.
leeoniya wrote 13 hours 3 min ago:
> There's no magic in tagged templates that somehow make them
immediately better for some custom non-standard syntax
compared to JSX.
they're marginally better since they have a platform-defined
way to deliniate static from dynamic parts. ivi _can_ work
without a runtime or build-time JS parser, while JSX cannot
(because jsx has to be parsed out of full blobs of js)
on the dx/ide side, sure there's not a huge amount of
difference if both had the same effort invested.
troupo wrote 10 hours 48 min ago:
In the context of "let's create a native templating syntax
for the browser" those differences between JSX and tagged
templates don't matter. You still need something that the
browser needs to parse and understand, you still need
something for libs/frameworks to handle/understand/compile
to.
My feeling is that tagged templates would actually be a
worse fit in this scenario because now you would have to
distinguish between "regular" tagged templates and
"templating" tag templates.
localvoid wrote 10 hours 21 min ago:
If I understand it correctly, the main argument in favor
of tagged templates is that it doesn't require any
changes to the js engine and that is why it will be way
much easier to push forward. Browser implementation
should be quite straightforward and it will be possible
to implement a semi-efficient polyfill.
Personally, I don't think that it will have any
significant impact, everyone will continue using
React,Vue,Svelte and it is highly unlikely that they are
going to adapt this new API.
leeoniya wrote 8 hours 29 min ago:
that's a better distillation :)
dragonwriter wrote 22 hours 38 min ago:
> Microsoft tried (and failed) at defining a ton of models, MVC, MVP,
MVVM, and what not,
Microsoft used those at various times, but the only one it defined
was MVVM.
MVC was Xerox PARC, MVP was Taligent.
keepamovin wrote 22 hours 58 min ago:
The time has been right for Yonkers -
nitwit005 wrote 1 day ago:
If you built React into the web platform, what I'd expect is everyone
would stop using it the moment a big new version of React came out, and
it'd eventually get deprecated and removed.
There has been long running complaints about how many UI frameworks
there are, and how often they change. It's settled down some, but I
don't expect that situation to change for a long while.
Sophistifunk wrote 1 day ago:
When are we done adding everything into the browser API?
lylejantzi3rd wrote 10 hours 6 min ago:
When somebody creates something better.
wewewedxfgdf wrote 1 day ago:
Hopefully never.
Unless you loved IE6 of course, which was when Microsoft declared the
web browser to be 'complete'.
taeric wrote 1 day ago:
Hard not to laugh out loud at "We know what good syntax for templating
looks like." We don't. Not even close. Because I'd hazard a good
template is almost certainly more of a visual thing than it is a
symbolic one. Is why dreamweaver and such was so successful back in
the day. And why so many designers learn with tools like photoshop.
Also hard not to feel like this is reaching hard to try and recreate
xslt. :( It is inevitable that someone will want to template
something that isn't well formed, but can combine into a well formed
thing. And then you are stuck trying to find how to do it. (Or
correlated entities on a page that are linked, but not on the same
tree, as it were. Think "label" and "for" as an easy example in plain
markup.)
If I could wave my magic wand, what we need is fewer attempts to make
templates all fit in with the rube goldberg that is the standard
document layout for markup. People will go through obscene lengths to
recreate what judicious use of absolute positioning can achieve fairly
well. Sure, you might have to do math to get things to fit, but why do
we feel that is something that we have to force the machine to do again
and again and again on the same data?
tshaddox wrote 2 hours 52 min ago:
I'd also argue that there are only superficial similarities between,
say, React and Svelte. Yes, they both have a syntax based heavily on
HTML, but they work very differently. React is the only major
framework that works by having (mostly) normal JavaScript functions
return lazy representations of markup (in the form of JSX). React has
no template-level notion of looping or conditional rendering, because
you use normal JavaScript for that.
9rx wrote 12 hours 15 min ago:
We do know what is good. We may not know what is perfect, but perfect
need not be the enemy of good.
taeric wrote 10 hours 49 min ago:
What is good, then? Because I'm really not seeing it. Just peek
at substack and bluesky to see how the templating ideas in web dev
have turned out. (I'm assuming they are decent modern examples.
If not, I'm game to see one.)
9rx wrote 9 hours 55 min ago:
That which improves upon previous solutions.
I have no idea what substack and bluesky are, but I'll take that
to suggest that someone used templating to create a mess. While
that is no doubt true â someone can create a mess out of
anything â would the same person have avoided the mess if the
templating wasn't there? It is just ergonomics, after all, not
some fundamentally different idea.
taeric wrote 9 hours 29 min ago:
substack and bluesky are just newer sites. I don't even think
they are bad. Just I question the volume of markup that they
use to layout stuff. Knowing that that is the standard.
Do you have examples that are good?
9rx wrote 9 hours 25 min ago:
At the time, this was good:
printf("%d", 10);
It might not hold up to today's standards, but "good" isn't a
constant.
taeric wrote 9 hours 9 min ago:
So, no? You don't have any examples by which to
demonstrate what a good templating language is?
You seem to have gone on a tangent that "good" is a general
topic in my question. I meant do we have specifically good
examples of templates. Surely if we know what good
templating syntax is, we can share examples of it? Even if
you can't describe it directly.
9rx wrote 9 hours 5 min ago:
I provided a good template language, at least given what
was good at the time it was introduced. As good is
necessarily a moving target, one can never really satisfy
your request as by the time the submission has
round-tripped it is quite possible that what is good has
already been redefined.
So, yes, I understand you are trying to call attention to
my 'loosey-goosey' usage earlier. But I am saying that
when I said "good", it was relative to the temporal
position it found itself in.
taeric wrote 8 hours 56 min ago:
Then take my question as, "then what is a good
templating example today?"
Dodging the obvious question in favor of discussing if
we can make progress... feels less than good faith.
9rx wrote 8 hours 48 min ago:
I still consider the templating language I shared
before, even at the time of this comment, to be good.
But, as recognized earlier, others may find it
doesn't hold up to today's standards. "Good" is not
only not a constant, but is also subjective. Do I
really have to explain the entire universe here? Man.
taeric wrote 8 hours 35 min ago:
You didn't share a templating language, though?
You shared an example of a formatting/templating
string, but didn't even indicate what level of
format string it supported. Such that I don't know
if you are sharing C's printf, bash's printf,
PHP's... I can presume you don't intend to include
CL's FORMAT. Even if I do have a softspot for it,
myself.
9rx wrote 8 hours 27 min ago:
> You shared an example of a
formatting/templating string
Which is, you guessed it, a language! Okay, yeah,
I didn't dive in so deep as to provide a formal
specification for the language, or whatever it is
you were hoping for, but if you really want to
take this to silly town, I'm going to tell you
that what you saw is the only valid input for
this language and only specify that, so, maybe,
unless you are having fun with this comedy
routine (in which case, carry on; I'm certainly
still entertained!), you can read between the
lines? The question asking if I need to explain
the universe was rhetorical, implying that I am
not going to do that.
taeric wrote 6 hours 28 min ago:
My question to you, then, is if you think you
contributed anything at all to this? Because,
yeah, nothing there.
9rx wrote 5 hours 45 min ago:
Yes, it contributed to my enjoyment. I mean,
that is all that can be contributed,
fundamentally, so...
jdkoeck wrote 12 hours 18 min ago:
> Hard not to laugh out loud at "We know what good syntax for
templating looks like."
First of all, it's not very nice to laugh in the face of someone
advocating for progress on the web platform, which benefits everyone.
Second of all, yes we do now know what good syntax for templating is,
it's basically jsx (and I'm saying this as someone who's really not a
fan of React). It took the whole web by storm, it's been adapted for
all kinds of frameworks, and it's undeniable that all js templating
systems converged towards common attributes:
templates-as-expressions, composition via nesting and control flow
with just javascript (instead of specific template syntax).
MrJohz wrote 10 hours 39 min ago:
It's good when someone advocates for what they believe to be
progress on the web platform, but it's not necessarily clear that
this would be progress. And that line in particularly is amusing
because we absolutely don't know what good syntax for templating
looks like â that's why there's so many different options.
JSX is certainly the most popular because it's used in the most
popular framework, but it has some very clear weaknesses. In
particular, it has very clear semantics for a React-like,
VDOM-based framework, but those semantics do not work as well for
other kinds of framework.
For example, you mention control flow via ternaries/`.map`. This
works great in React, where the entire template will be reevaluated
every time any input changes. However, frameworks like SolidJS or
Vue in Vapor mode work very differently, and typically evaluate JSX
only once at component mount (or at least, as seldom as possible).
To support these, these frameworks need to use either special
components like `For`/`Show`, or directives like `v-if`.
There's also the issue of how to evaluate JSX. In theory, JSX is
flexible, in that `` can be converted to any call of the form
`h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or
Vapor mode Vue â in both of these frameworks, `expr` cannot be
eagerly evaluated, so the traditional transforms just don't work.
Both of these frameworks therefore have to include their own custom
plugins for handling JSX correctly.
The author's suggestion to also use signals as a state mechanism
suggests they're imagining something more along the lines of
SolidJS. That's an odd choice (it's my personal go-to framework,
but it's also very niche), but it also implies, as discussed, that
JSX-in-the-browser wouldn't behave like JSX-in-React. From
experience, that will cause problems! I've worked with React
developers before who've really struggled to use SolidJS because of
precisely this issue.
taeric wrote 10 hours 58 min ago:
I'm laughing because it just hits so hard. Started playing some
role playing with friends again recently and we were looking for a
template for the character sheets. You know what they have? A
PDF. That is their template. Why? Because they design things
that way.
And it is funny, because I can already feel the ideas that would go
into templating this symbolically. Characters have 6 and 20
numeric attributes. But, I can already guess most would consider
it a fault to manually place either of those on the page. Yes, the
sheet has a limitation on how big your name can be. No, you can't
really avoid that.
JSX is what happens when you no longer have a design and a dev
team. It is great at that, even. But if you have a workflow where
a designer makes a template and sends it over to a dev, it no
longer really helps. You are much better off making something that
can pick at artifacts that are handed off.
Instead, we seem to be aiming for an idea that will have to replace
learning of everyone involved.
chii wrote 15 hours 49 min ago:
> People will go through obscene lengths to recreate what judicious
use of absolute positioning can achieve fairly well
the web has the requirement that the 'document' look good no matter
what device size/dimension, orientation, and/or capability.
In regular apps (say, a windows app), you don't have this
requirement. In mobile apps, there's a standardized set of sizes.
Only on web do we have both!
taeric wrote 11 hours 13 min ago:
Not really? People impose the idea that they can make this work.
Yet no sites looked good on the Nintendo DS browser, and people
were largely ok with that. Few sites look genuinely good on
phones. People are largely ok with that.
DangitBobby wrote 6 hours 9 min ago:
The Nintendo DS browser was not good enough to use as a daily
driver. My phone, on the other hand, I spend more time browsing
on that than I do my computer. Some sites aren't great on it, but
the vast majority are fine (reader mode will get you through 99%
of the rest). I'd argue most sites don't "look good" on any
device. It's really not that hard these days to make a site work
on mobile, the navbar often is the most challenging part of it.
moritzwarhier wrote 15 hours 49 min ago:
> Hard not to laugh out loud at "We know what good syntax for
templating looks like." We don't. Not even close. Because I'd hazard
a good template is almost certainly more of a visual thing than it is
a symbolic one.
How do you come to this conclusion? It seems to me that what you mean
is a general gripe with HTML+CSS, not with how it's generated.
And why do you bring up absolute positioning?
I hear this take on HN again and again and sure, absolute positioning
has its place, and is needed for many things.
But when it's used for page/app layout, most of the time I came
across this it was an absolute nightmare, falling apart at the
slightest content (even text!) or screen size changes.
Even print newspaper layout can't work like this, because typography
is involved, although it's probably a lot closer to what I imagine
you are describing.
Maybe I'm misunderstanding you.
But when I was doing more CSS-intensive work (I still do a fair bit),
developing something on a basis when someone created a layout based
on absolute positioning that looked like it was "almost ready", it
was a terrible time sink to try to fix it and recreating it using
flex, flow et al for layout (I'm not that fond of grid outside of
some scenarios, and at the time I didn't use it due to browser
support) was always faster because the problems with absolute
positioning as the main layout tool were basically unfixable.
Maybe there are techniques using calc() and viewport units where it
makes sense, but absolute positioning is not suitable for any layout
outside of completely static content and viewport dimensions, in my
experience.
taeric wrote 11 hours 15 min ago:
I've been in the opposite, where people will go through lengths to
try and make it so that the defaultish dom layout makes things
"fall into place" so that they had a very specific layout of
elements. When a fairly simple set of elements with somewhat
minimal styling would get what you wanted surprisingly easy.
Provided you did a lot of up front calculation on your own.
Basically, my assertion used to be to draw out what you have in
mind on grid paper. Then start creating the elements. I don't see
how that flow could land you with the 100ish divs that you wind up
with on something like a single blue sky post.
Is it a panacea? No. Of course not. Can a constraint language
help? I think so.
I'll add that the flex layouts seem like an improvement over what
used to be there. Even if I find it rather amusing that we seem to
have settled back on tables for layout. :D (I suppose it is more
like some of the layout managers from Java days, truthfully.)
But, fundamentally, the problem appears to be that the drop to
symbolic text is just not something that everyone does the same
way. As such, it is very easy to get into a lot of trouble with
the number of cooks in the kitchen, as it were.
moritzwarhier wrote 7 hours 36 min ago:
But flex layout is fundamentally different from tables, I guess
you meant grid with that reference?
It's not that every website uses CSS grid for layout.
Coincidentally, I took a look at the DOM+CSS of a bluesky post
just a few days ago (very weird coincidence, since that was the
first time I opned bluesky for months), and it did use old-school
tricks like centering using CSS transforms, presumably because
renders a tiny bit faster than flex centering, or avoids layout
calculations when elements are added in a virtualized list.
Virtualized lists are also a good example for falling back to
specifying exact pixel positions and dimensions for performance
reasons, but these are usually determined with help of JS. I
think the transform I saw was a translateX(-50%) one, so
centering.
I totally get the canvas-like approach, but in a way the
constraint-based flex layouts fall into the same line of thinking
for me.
The issue with absolute positioning is the need to manually
specify positions and dimensions for elements, which makes it
useless unless you are working within a fixed box or only
relating to the corners of one rectangle.
It is explicitly meant to remove elements from the normal layout
flow so they overlap each other by default.
taeric wrote 6 hours 30 min ago:
I did mean grid, there.
And don't get me wrong, I don't necessarily want everything
absolute positioned. I just find it amusing when people try to
get a badge or some such on something and then herculean
efforts they will go through to get that badge exactly where
they want it.
So, with bluesky, the amount of markup that goes into the
footer menu of each post would be what I'm looking at. Tools
were clearly used to get styles such as "css-g5y9jx" and this
isn't the worst examples I've seen. But I am curious on why so
many nested divs seem to be needed all of the time.
I am not clear what you mean by canvas-like approach? I think
folks should still use elements. Just fewer of them, all told.
Direct to my claim, though; my argument is just that
templates/designs are visual things. I don't think people are
thinking in terms of nested div elements. They largely don't
even think of sections of their template as parent/child
relationships. They have a visual thing and want it filled in
with whatever data.
dominicrose wrote 16 hours 39 min ago:
We don't know what good syntax for templating looks like because HTML
is complex enough and many have tried making it more complex with
things like Blade for PHP or HTMX for example.
For some reason I've always preferred JS to HTML. React components
with JSX is a good balance. Not everyone agrees but that's OK.
austin-cheney wrote 18 hours 57 min ago:
> Hard not to laugh out loud at "We know what good syntax for
templating looks like." We don't.
The article fails to accept that performance and security arenât
addressed by vanity layers. This is a mistake repeated by web
technologies when popular demand eventually crushes common sense,
because hiring is more important than training/maintenance when the
lowest levels of the work force canât tell the difference and
drives all design decisions.
If you want better performance or security you have to measure
things, not wear a pretty dress and look the other way.
wahern wrote 1 day ago:
> Also hard not to feel like this is reaching hard to try and
recreate xslt.
I was never a fan of XML, but XSLT was (is!) a killer redeeming
feature of the ecosystem. And it's still widely supported in
browsers! It was such a shame that XML caught on where it
sucked--configuration, IPC, etc--but languished where it shined, as a
markup language with an amazing transformation capability in XSLT.
I think where XSLT fell over was that it's a real DSL, and a
declarative, pure, functional DSL at that. People like to talk a big
game about DSLs, but inevitably they're simplistic syntactic
exercises that don't actually abstract the underlying procedural
semantics of popular host languages. When faced with a well-designed
DSL that makes difficult tasks trivial... people can't be bothered to
learn.
PaulHoule wrote 7 hours 0 min ago:
The thing most people never got about XSLT is that it is really
about production rules -- and production rules (e.g. the major path
to "expert systems") are one of the most solidly rejected
technologies in software engineering.
I didn't understand this until I spent a few years going down a
rabbit hole asking questions like "why don't people like production
rules?" In the case of templating people expect to make a template
with a top-down organization that looks like the output, whereas
XSLT really wants you build transformations from the bottom-up. On
some level the bottom-up part is clear, particularly if you want
to code-generate your rules (towards the end I was writing
production rules that write production rules) but what is not clear
is how the parts all fit together: you can't visually tell between
an XSLT that builds the structure you want vs one that doesn't.
I think the most fun I ever had with XSLT was when I used an XSLT
engine with user-defined procedures and had them create side
effects, such as matching certain patterns in an XML document and
making SQL inserts, though that was a long time ago when we were
still using terrible XML parsing libraries.
froh wrote 10 hours 7 min ago:
here on HN I dare to out myself as a DSSSL lover, the scheme based
predecessor of xslt.
I still can't wrap my head around how the neat and clean dsssl
syntax, a real programming language, was replaced by an xml
notation for the same: for cuntional code and a framework.
because semantically, that's what xslt is: a functional language
with a framework, geared at transforming xml instances.
but that syntax... and of course a much inferior and more obscure
language than scheme underneath dsssl.
striking wrote 7 hours 10 min ago:
Why not implement a DSSSL-to-XSLT compiler?
Mikhail_Edoshin wrote 10 hours 27 min ago:
XSLT is not bad, but XML, unfortunately, is normally misused, so
XSLT is tainted as it has to be a part of that misuse.
The true role of XML are grammar-based notations. These occur in
two places: when a human gives data to a machine and when a machine
produces data for a human. This is where XML is used despite its
often mentioned shortcomings; for example, many notations to
describe the user interface are based on XML. This is convenient,
because user interfaces are created manually. (I am not mentioning
text markup, it is well known.)
Yet XML was often used as a notation for machine-to-machine
exchange. For example, the ONIX book description standard. Here
data are moved between two computers, yet for some reason they have
to form grammatically correct phrases according to a set of grammar
rules. Computers do not need grammar. They do just fine with
non-grammatical data, like a set of tables. It is way simpler for
them; parsing or generating grammar, even explicit, is pure
overhead for data exchange and is only necessary when data enters
or leaves the computed pipeline.
So, to your examples: configuration in XML is actually fine, but
IPC is not. Configuration is written by hand, IPC happens between
machines. IPC specification, on the other hand, is also a good fit
for XML.
That said, XML and thus XSLT has another flaw: it is way too
verbose and has no good way to format it. Conciseness was an
explicit no-goal but now we can say it was a mistake.
PaulHoule wrote 6 hours 41 min ago:
I thought Tim Bray's XML spec was one of the most beautiful tech
documents I'd every seen when I saw it for the first time.
Adding namespaces at that point in history though was a disaster.
Back then developers just weren't used to that kind of rigor
(when I first started coding Java I had to go to a website run by
frickin' NASA to get a clear explanation of how namespaces
worked.)
It didn't help that Microsoft dropped a stick of over-complicated
standards that tried to bring RPC into XML. RPC has always been
a cursed concept because between (1) trying to be intellectually
coherent and (2) caring about performance RPC systems become
incomprehensible and it doesn't matter if it is Sun RPC, DCOM,
CORBA, "Web Services", Protocol Buffers, etc.
The fact that the "REST economy" is intellectually incoherent and
could care less about performance seems to have helped it
succeed. Right now I just wrote a javascript function that looks
like
const get_item = async (item_id) => {...}
and it does
GET /item/{item_id}
and I have a Java function on the server that looks like
Item getItem(String item_id)
and is tagged with some annotations that make it get called when
that GET request. Jackson lets me write an Item as an "anemic
domain object" that gets turned into the exact JSON I want and
the only real complaint I have is that the primitive types are
anemic so representing dates is a hassle.
connicpu wrote 9 hours 43 min ago:
The XML abuse I've seen at work is truly horrifying. We use
protobuf for most of our inter-service IPC, but for one
particular team one of their customers demands the use of XML so
that it can be run through some XSLT "security" filters, so they
have to transform a fairly large protobuf object into XML, run it
through said filters, and then convert it back to protobuf :( I
weep every time I think about it.
taeric wrote 9 hours 30 min ago:
It is probably impossible to find a tech stack that has not
seen horrible abuse somewhere. :D
Granted, it did seem that XML got more heavily abused than some
other options for a while. I am curious if that is just a by
product of when it was introduced. That or just the general
proliferation of how many front end developers we have. (I
hate that I am pushing that to almost be a complaint. I
certainly don't mean it that way.)
echelon wrote 11 hours 26 min ago:
XSLT was cool.
XML needs another syntax that isn't so verbose. Sort of like how
OWL has XML, Manchester, Functional, and Turtle syntaxes for the
same data structures.
XSLT needs a Turtle-style syntax.
XML in general (the data structure, not the syntax) needs a
Turtle-style syntax.
geocar wrote 18 hours 26 min ago:
> but languished where it shined, as a markup language with an
amazing transformation capability in XSLT
I choose to look at this a little differently.
An XML application using XSLT is so much better (faster load times,
faster to write, easier to make correct) than a JavaScript
application with a JSON api, that XML is basically a secret weapon.
I only care enough that it stays in browsers, but otherwise I'd
prefer nobody know about it because it means less competition on
things that matter (faster load times, faster to write, fewer bugs,
etc). And I've got a half-baked JavaScript-based "renderer" I can
finish in case some Google VP asshat goes looking for things to
delete...
marcosdumay wrote 21 hours 3 min ago:
XSLT is just not a good language. Every single attempt of making
XML executables (and there were many) failed badly, always for this
one good reason.
notpushkin wrote 21 hours 15 min ago:
Iâm a big fan of XHTML (strictness is good) and feel like XSLT
could be a great addition, but I hate the syntax. Iâd love to
build a Jinja to XSLT compiler one day.
I also have a simple playground for XSLT:
URI [1]: https://xsltbin.ale.sh/
nine_k wrote 18 hours 10 min ago:
XSLT's weaknesses are the extension of its strengths. It's the
first homoiconic, purely functional language that enjoyed
widespread adoption among "normal" developers, not type theory
wonks.
But XML's syntax sucks, and so inevitably does XSLT's, because
XSLT is just XML. Were it s-expressions, the syntax could suck
slightly less. It was (is!) a small price to generate XSLT using
XSLT, which makes XSLT very powerful and expressive if you hold
it right, almost like a Lisp. This saved me a few times around
year 2000 or so.
PaulHoule wrote 6 hours 55 min ago:
Homiconicity can get you into trouble.
CSS and HTML have a dual relationship. You could certainly
write CSS with an XML-like syntax but people would always get
confused at whether they are looking at style or markup.
Because HTML and CSS look completely different you never have
that problem.
XSLT shares the same problem with the RDF specs coming out at
the same time that it hid the production rules/logical nature
of the system, had it looked more like
-> $x
it could have been quite different. But production rules never
really sold (got told that by the marketing chief of vendor at
a hotel bar after a conference they sponsored) and it's an
interesting question why. They can do all kind of neat things
like manage asynchronous processes that happen over a long
period of time (like having a loan officer approve a loan) but
nobody ever tried to use them to deal with the async comm
problem in Javascript as far as I can tell.
notpushkin wrote 13 hours 40 min ago:
Can you generate XSLT from s-expressions though? :thinking:
mattmanser wrote 14 hours 29 min ago:
I wouldn't say it had widespread adoption. We used XSLT in my
day job at the time to do client-side updates, even had a
special SQL API that turned sql queries into XML automatically
by naming the columns with a special syntax and it was
virtually unheard of (2007?).
It was actually great when you got it, but the learning curve
was so steep many developers couldn't use it effectively to
begin with. For complex pages only certain developers could
make changes or fix the bugs. Precisely because it was
functional and most developers at the time really only
understood imperative.
In fact, I remember the DailyWTF had a WTF about using XSLT as
client-side transforms a few years later: [1] But doing
something like that was in fact so much faster than doing it in
js, and when you groked it (deliberate throwback), it was so
much simpler. I actually wrote a pivot table control in XSLT
which completely blew away the performance of the pre-v8
javascript one. Pre-V8 javascript was so slow most developers
wouldn't believe you now. A 10,000 iteration loop of even basic
operations was often enough to cause IE6 to show a pop-up
saying the page wasn't responding.
The pivot table in javascript would crash with just a few
hundred lines of data, in XSLT it was instant with even
10,000s.
A really interesting use of XSLT on the web at the time was the
WoW character viewer. You could view (and share) your character
on Blizzard's website, with all their gear, skills, etc. It was
blazingly fast for the time and it was all written in XSLT.
URI [1]: https://thedailywtf.com/articles/Sketchy-Skecherscom
agumonkey wrote 17 hours 50 min ago:
I barely used xslt, but as a fp head I wanted to try, the most
confusing part to me were terminology / semantics / decoupling.
Seemed like matching templates could be anywhere making
difficult to understand the meaning of a script.
PaulHoule wrote 6 hours 49 min ago:
In some sense that's a strength. When things can happen in
any order you can mash together two things and they work
together.
When I was looking for my own revolution in software
engineering I saw one part of the low code/no code puzzle was
that conventional tools force you to determine what order
events happen which was something laymen shouldn't be
bothered to do. Some counters are: spreadsheets (they
figure out what order to calculate it), make (does a
topological sort), dependency injection tools like Spring
(writing a FactoryFactoryFactory isn't so bad, but
maintaining it is a disaster when a "small" change means you
have to reorder the order in which you construct everything)
There is a "freedom is slavery" problem here. People saw the
semantic web as "you're going to exhaust yourself arguing
with people about standards and ontologies before you even
start coding" and not "if my data is properly namespace I can
throw data from 10 different sources together into my RDF
database and start writing queries".
nine_k wrote 17 hours 39 min ago:
It's sort of similar to regular pattern-matching, but sadly
not built for ergonomics :(
agumonkey wrote 17 hours 35 min ago:
The node pattern matching was ok, but as far as i can
recall, there could be multiple matching patterns scattered
in lots of places (a 180deg turn compared to most FP
pattern matching that aim for exhaustiveness ?)
HelloNurse wrote 12 hours 43 min ago:
Exhaustiveness is only relevant for the compiler-managed
pattern matching of a traditional FP type system, where
you need to write an implementation (patterns that will
be used at matching usage sites) for everything that your
types promise.
XSLT pattern matching is the plain kind: here is a
pattern, look for it in the input and process every
match. If some part of the input document is ignored,
it's just not useful; if some part of the input document
is processed several times, it's perfectly well defined.
friendzis wrote 10 hours 16 min ago:
The problem here is runtime includes, especially the
"drop source in place" style includes, coupled with
dynamic dispatch at runtime. These two things in
combination make static analysis of execution flow
anywhere from really hard to impossible
agumonkey wrote 10 hours 51 min ago:
I get it, but it's hard to track
HelloNurse wrote 10 hours 17 min ago:
If by "hard to track" you mean not knowing what
template is producing an observed bad output, the
modularity of self-contained templates and XPath
expression is likely to help with debugging.
eclipticplane wrote 21 hours 31 min ago:
It's been a long number of years, but XUL (Mozilla/Firefox's UI
layer) combined with XSLT was an incredible stack to build entire
applications.
wpm wrote 1 day ago:
I regularly work with APIs in shell that return XML and XSLT is a
goddamn super power. I adore it.
hsn915 wrote 1 day ago:
What we need is not templating. What we need is a native implementation
of a virtual dom.
More specifically, a native implementation of the "patch" function:
patch(target_dom_node, virtual_dom)
Where `virtual_dom` is just a plain-data description of the DOM.
Most of the "slowness" of the DOM come from its requirement to be a
90's era Java style object hierarchy.
Don't call it "templating". Just call it "virtual dom". Everyone knows
what that means.
silverwind wrote 18 hours 7 min ago:
Virtual DOM is a useless abstraction, there are numerous libs that
perform fine without it.
nine_k wrote 17 hours 46 min ago:
It's a useful abstraction: you just build the full DOM with every
change, a bit like a game engine. It makes so many things simpler.
It's not a free abstraction though.
ethan_smith wrote 21 hours 23 min ago:
A native virtual DOM implementation would also drastically reduce
memory overhead since browser engines could optimize diffing
algorithms at the C++ level instead of requiring megabytes of
JavaScript framework code to be downloaded, parsed and executed on
every page load.
sethaurus wrote 22 hours 0 min ago:
Other than quibbling over the word "template", how does that differ
from what TFA is describing?
hsn915 wrote 16 hours 4 min ago:
The linked proposal has many "features" that would be "needed" if
you frame the problem in terms of a "template api", centered around
"binding" variables, and what not. [1] My proposal only adds one
native function with nothing else: no new data types, no new apis.
URI [1]: https://github.com/WICG/webcomponents/issues/1069
WickyNilliams wrote 15 hours 30 min ago:
Doesn't your proposal implicitly introduce the concept of a
virtual DOM, which the browser does not have?
You'd need to spec out what that looks like. It adds one new API
from the users perspective but much more from the browsers
perspective.
Additionally the next generation of Frameworks do not use virtual
DOM. Solid and svelte do not. Vue is moving away from it. Signals
are directionally where they're all heading.
djfivyvusn wrote 1 day ago:
Where's the code?
exclipy wrote 1 day ago:
URI [1]: https://github.com/WICG/webcomponents/issues/1069
jongjong wrote 1 day ago:
Yes, it's weird that Browsers were so fast to ship CSP rules to prevent
XSS attacks by limiting the use of inline scripts but so slow to ship a
templating mechanism which would largely solve the problem.
It's like creating regulations which require a specific solution before
that solution exists.
shermantanktop wrote 1 day ago:
A basic lesson we've learned over and over is that API/ABIs aren't
final. Application needs are never permanently fulfilled by a stable
API, with all future problems considered to be app-level issues.
This proposal is a good example of how common issues with the platform
are solved on top (React etc.) until we recognize them as a problem and
then push them down. Polyfills are another example.
If a proposal like this succeeds, it lives a time in the sun, but then
spends most of its useful life being the old thing that people are
trying to work around, just like the DOM API, just like ECMA versions,
just like old browsers, just like every other useful bit of tech that
is part of the system but can't be touched.
Is it possible to think about entropy, extension and backcompat as
primary use cases?
EasyMark wrote 12 hours 9 min ago:
Isn't that why you have versions and maintains backward compatibility
with older versions, and don't change the "old" interfaces?
troupo wrote 13 hours 59 min ago:
> A basic lesson we've learned over and over is that API/ABIs aren't
final.
On the web they are. Once something is out in the open on the web,
there will be people depending on this, in this exact form, forever.
That's why there are still APIs that end up in "smooshgate" because
of decisions from 20 years ago:
URI [1]: https://developer.chrome.com/blog/smooshgate
btown wrote 21 hours 35 min ago:
It's also the case that every feature in web standards means extra
code that needs to be painstakingly maintained, and extra code that
anyone trying to create a standards-compliant browser must implement.
I want to see projects like [1] actually have a chance to catch up
over time, not always be chasing an expanding scope.
I want the web platform to have every possible capability that native
platforms have (subject to privacy and sandboxing constraints, of
course). And I want the developer experience of web developers to be
incredible.
But these need to be balanced against the consequences of added
complexity. And in this case, does native templating really improve
developer experience? I'm not convinced the benefits outweigh the
costs.
URI [1]: https://servo.org/
dleeftink wrote 21 hours 43 min ago:
> spends most of its useful life being the old thing that people are
trying to work around
But in the process, the base functionality has been propped up
another level.
Incremental updates aren't worthwhile just because of userland
requirements that will always discover new gaps, use-cases and
blindspots.
quotemstr wrote 21 hours 46 min ago:
> A basic lesson we've learned over and over is that API/ABIs aren't
final
I dunno --- getElementById has been stable for, what, 25 years?
"There's no such thing as a stable API" is something said by people
unable or unwilling to create interfaces that last. It's a statement
of personal resignation, not cosmic impossibility. There are tons of
counterexamples.
Application needs, like other needs, are infinite. You satisfy these
needs by adding new APIs, not breaking working ones.
bryanrasmussen wrote 16 hours 34 min ago:
I think you'll find that even the most unstable APIs have extremely
stable parts to them.
At the same time I don't think there is actually anything that most
people would consider an API that is open to public usage that has
maintained that kind of stability that getElementById has, which
after all is something most people would describe as a method of an
API.
ericyd wrote 1 day ago:
> React doesn't provide a way to explicitly bind to properties and
events of DOM elements, or provide directives that apply to an element.
I didn't understand this part, can anyone shed light? What is different
between what's being described here and what React does with event
listeners, etc?
bevr1337 wrote 1 day ago:
> React doesn't provide a way to explicitly bind to properties and
events of DOM elements
We can nitpick this point because react has had a ref API for at
least 5 years now. Given a ref, all DOM API are available. For
events, SyntheticEvent will refer to a native event if it exists.
The SyntheticEvent abstracts vendor discrepancy. Under the hood,
react can apply some optimization too. [1]
URI [1]: https://legacy.reactjs.org/docs/events.html
URI [2]: https://react.dev/reference/react-dom/components/common#reac...
MrJohz wrote 1 day ago:
The synthetic event also adds its own abstractions though. For
example, the `onChange` handler in React behaves very differently
to the native DOM `change` event.
bevr1337 wrote 21 hours 10 min ago:
And then some. Switching to react-native or other render targets
can also be a doozy. Hopefully the references clarify all the
features.
krebby wrote 1 day ago:
I think this is referring to the fact that React uses synthetic event
listeners - it's cheaper to bind an event listener once at the root
and do your own element matching than it is to continuously bind and
unbind listeners.
URI [1]: https://react.dev/reference/react-dom/components/common#reac...
bravesoul2 wrote 1 day ago:
Depends where the platform boundary is for Web. As much as we hate JS
fatigues and so many frameworks, choice is good. Maybe if the browser
can make it easy for these frameworks to be performant and integrate
more deeply (not part of the JS bundle but more like a deeper JS
'plugin' with bonus of sometimes having a cache hit from another site)
we could just carry on using React et. al.
pier25 wrote 1 day ago:
The web really needs native templating, reactivity, and data binding.
I can't even begin to imagine how much CPU and bandwidth is wasted with
billions of users downloading, parsing, and executing something like
React.
ivape wrote 3 hours 42 min ago:
Two way data binding and a jsx clone is kind of all anyone really
needs.
hyfgfh wrote 21 hours 56 min ago:
That's alright now LLM and crypto make this waste seem minuscule
strix_varius wrote 23 hours 9 min ago:
With the TC39 signals proposal, part of that is making progress.
CharlieDigital wrote 22 hours 51 min ago:
Except React.....
agos wrote 13 hours 50 min ago:
if (when?) Signals become a standard, React will be in a tight
corner if they decide to ignore them
WorldMaker wrote 9 hours 23 min ago:
Not really? `useSignal` is just another hook React needs as a
replacement/augment for `useState` and maybe `useEffect`.
Signals aren't that special. Arguably that's part of why a lot
of people like Signals as a proposal.
(I'm still of the sort that thinks Signals are just worse
Observables, so it's not a proposal I'm particularly thrilled
about, but were it to be adopted Signals are easy to use in
Observable contexts as well, they are just uglier
half-implemented BehaviorSubjects, though maybe with a few
extra lint rules to prefer Observable behaviors over Signal
ones.)
tacticus wrote 21 hours 31 min ago:
Was react ever about progress?
nine_k wrote 18 hours 1 min ago:
If you valued your sanity when developing complex Web UIs,
React was a lifesaver.
DOM sucks though, it's slow, it's heavyweight, it lacks
transactions. We're stuck with it, and frameworks like React
have to do the DOM diffing + patching thing, explicitly, in JS.
nchmy wrote 12 hours 24 min ago:
Nah. [1]
URI [1]: https://svelte.dev/blog/virtual-dom-is-pure-overhead
URI [2]: https://news.ycombinator.com/item?id=43971164
nine_k wrote 9 hours 0 min ago:
React appeared in 2013, Svelte, in 2016. Three years is a
lot. What comes next can see and avoid some pitfalls of
earlier designs.
nchmy wrote 5 hours 3 min ago:
1. I'm referring to the comment that the DOM is slow/bad.
It is not. Moreover, VDOM is ON TOP OF the DOM.
2. We're currently living in 2025. React (and SPAs) is
not even slightly necessary.
youngtaff wrote 17 hours 33 min ago:
React was a solution to a ten years ago problem
youngtaff wrote 13 hours 20 min ago:
You can downvote it but it doesnât make it any less true
Alex Russell has written swathes of arguments about Reacts
performance issues [1] The DOM has become much faster since
React started over a decade ago, the VDOM really isnât
needed anymore even for app like experiences
React is about developer preference over user experience
URI [1]: https://infrequently.org/2024/11/if-not-react-then...
ch_sm wrote 12 hours 22 min ago:
Agree that react isnât the best implementation of the
concept, both in terms of ergonomics and efficiency. But
a react-like framework is still very much needed to
create complex apps in the browser. So IMHO react is a
solution to a very current problem, only not an ideal
one.
nwienert wrote 1 day ago:
React isnât templating though.
ivape wrote 3 hours 41 min ago:
That's kind of like saying React isn't just a bunch of a functions
(it is). What do the JSX templates compile down to?
ASalazarMX wrote 6 hours 39 min ago:
Respect for focusing on semantics but not contesting the CPU and
bandwidth waste. That takes honesty.
lofaszvanitt wrote 1 day ago:
Fisrt include jQuery as a whole into the base standard. That would help
a lot.
bravesoul2 wrote 1 day ago:
Out of FE for a whole but isn't that done to a great extent.
lofaszvanitt wrote 18 hours 20 min ago:
done, how?
bravesoul2 wrote 11 hours 45 min ago:
URI [1]: https://developer.mozilla.org/en-US/docs/Web/API/Element...
edoceo wrote 1 day ago:
I <3 jQuery but, no.
lofaszvanitt wrote 1 day ago:
What no? Why can't we have nice things, like concise, easy to
remember, not overly elaborate syntax?
ameliaquining wrote 1 day ago:
jQuery is large and contains a lot of things. Which specific
features do you think the DOM needs?
lofaszvanitt wrote 18 hours 20 min ago:
What do you think is alrite in the current spec?
eszed wrote 1 day ago:
From bevr1337's comment, above:
> its API was a reflection of the domain. As a developer, I
want to query for a node (CSS selector, xpath, etc.) to affect
change and traverse to other nodes
That's what I miss about it.
jraph wrote 18 hours 16 min ago:
Doesn't querySelector(All) provide this?
troupo wrote 17 hours 10 min ago:
Not entirely. There's a reason people do
Array.from(querySelectorAll) to do more than just `forEach`
jraph wrote 16 hours 23 min ago:
So you are saying that Array.from(querySelectorAll) gets
you there? What are you missing then?
Genuinely asking, I have no clue what's being alluded to
without being clearly mentioned in this thread.
troupo wrote 14 hours 11 min ago:
> So you are saying that Array.from(querySelectorAll)
gets you there? What are you missing then?
Array.from adds friction. The need to wrap
querySelector in null checks adds friction. The fact
that they are not composable in any way, shape, or
form, with any DOM methods (and that DOM methods are
not composable) adds friction.
jQuery was the fore-runner of fluid interface design.
Nothing in the DOM before, then, or since ever thought
about it. Even the new APIs are all the same 90s
Java-style method calls with awkward conversions and
workarounds to do anything useful.
That's why sites like "You don't need jQuery" read like
bad parody: [1] E.g. what happens when it's not just
one element?
$(el).addClass(className);
// vs.
el.classList.add(className);
Or: why doesn't NodeList expose an array-like object,
but provides an extremely anaemic interface that you
always need to convert to array? [1]
$(selector).filter(filterFn);
// vs.
[...document.querySelectorAll(selector)].filter(filterF
n);
There's a reason most people avoid DOM APIs like the
plague.
--- [1] This is the entirety of methods exposed on
NodeList [2] Instance properties
- length
Instance methods
- entries() // returns an iterator
- forEach()
- item()
- keys()
- values()
URI [1]: https://youmightnotneedjquery.com
URI [2]: https://developer.mozilla.org/en-US/docs/Web/A...
WorldMaker wrote 8 hours 54 min ago:
You don't need Array.from if you are using `for
(const x of document.querySelectorAll(selector) { }`
loops anyway or have a library like IxJS handy.
ES2025 added map, filter, flatMap, reduce, forEach,
and several other methods to all iterators (including
NodeList directly, I believe, but definitely its
entries(), keys(), values(), if not) [1]. It'll be a
year or two at current pace before that is "widely
accepted baseline" in browsers, but it's great
progress on these sorts of complaints.
URI [1]: https://2ality.com/2025/06/ecmascript-2025.h...
troupo wrote 6 hours 42 min ago:
> including NodeList directly, I believe,
I listed all public methods and properties of
NodeList. It does have a forEach, so there's not
much need for `for of`
As for iterator methods, I completely forgot about
that :) Yeah, you can/will be able to use them on
.entries()
WorldMaker wrote 5 hours 52 min ago:
You missed [Symbol.iterator] as a public method.
I prefer the aesthetics of for/of over forEach in
most cases, but it's as much personal preference
as anything.
I did briefly forget the distinction between
Iterable (has [Symbol.iterator]) and Iterator
(the thing [Symbol.iterator]() returns). You can
use the Iterator helpers "directly" on the
NodeList with
`someNodeList[Symbol.iterator]().map(â¦)` or
`Iterator.from(someNodeList).map(â¦)`. There are
advantages to that over `Array.from` but not many
advantages over
`someNodeList.entries().map(â¦)`.
(I partly forgot because I assumed MDN hadn't
been updated with the new Iterator helpers, but
of course it has [1], they are marked as
"Baseline March 2025" [all browsers updated since
March 2025 support them] and there is a lot of
green in the browser compatibility tables.
caniuse suggests Iterator.prototype.map is ~84%
globally available.)
URI [1]: https://developer.mozilla.org/en-US/docs...
troupo wrote 5 hours 45 min ago:
> with
`someNodeList[Symbol.iterator]().map(â¦)` or
`Iterator.from(someNodeList).map(â¦)`
I always feel like clawing my eyes out with
most of the DOM APIs, or workarounds for them
:)
WorldMaker wrote 4 hours 53 min ago:
[Symbol.iterator] is more the for/of API
(protocol, more accurately) than a DOM API.
It's an improvement today that the DOM APIs
pick up niceties like direct
[Symbol.iterator] in addition to Iterator
methods like entries().
It's nice that there is syntax sugar for
[Symbol.iterator] in both for/of and also the
spread operator/deconstruction/rest operator
(things like [...someNodeList] and const
[item1, item2, ...rest] = nodeList).
In theory, the only missing piece is syntax
sugar for Iterator.from() if you wanted to
direct chain any iterable to the iterator
helperrs. But in practice, that's also part
of why the explicit iterator methods like
entries() already exist and those are
surprisingly well implemented (and have been
for a while), including on NodeList.
jraph wrote 12 hours 11 min ago:
I agree that DOM lists not being real arrays is a
pita. I can understand why for getElementBy* methods
which return live lists, but it's less clear for
those methods returning fixed lists.
But to me, these are minor inconveniences and habits.
A thin wrapper can get you there easily if you care
enough. I personally dislike this array/element
confusion that jQuery adds.
troupo wrote 10 hours 51 min ago:
> A thin wrapper can get you there easily if you
care enough
But that's more and more friction. A wrapper here,
a wrapper there, and if here, a try/catch there. At
one point you are reinventing significant chunks of
jQuery
jraph wrote 9 hours 45 min ago:
jQuery's scope is broad¹. It has at least:
- a plugin system
- its custom selector parser (because it had it
before querySelector and is not totally
compatible with it)
- its abstraction to iron out browser differences
(old IE vs standard, notably) that's not relevant
anymore
- its own custom (DOM) event management
- its implementation of methods that are now
standard (ajax & trim for instance)
I recognize that the DOM API could be better, and
comes with friction. Back then, ironing out the
browser differences and its selector feature were
killer features of jQuery. Today, I do not think
the quirks of the DOM API warrant importing a
library like jQuery.
¹ but indeed, very lightweight compared to
modern frameworks like Angular, React and Vue,
with all the ecosystem which comes with each of
them (react-router, redux, etc).
bevr1337 wrote 1 day ago:
As mentioned, the DOM API is a stinker. Does this address that root
issue?
I'd love to see something that builds on the work of hyperscript and
HAST. They are great models of the DOM. It would be exciting if a
template language were syntax sugar.
JSX is easy to reason about because its elements are 1:1 with a single,
uniform function call. That feature means JSX is always optional.
Sometimes it is even more verbose or less-performant to use JSX than a
hyperscript API like specifying optional properties. I think errors and
call stacks are clearer than during string interpolation, but that's
possibly BS.
Web components offer limited data binding and the hyperscript approach
has clear control flow. The templates seem to be a source of confusion
in the GH discussions.
There is still something special and pleasant about jquery because its
API was a reflection of the domain. As a developer, I want to query for
a node (CSS selector, xpath, etc.) to affect change and traverse to
other nodes. After a beer or two I'm convinced emacs and org mode
approaches are worth emulating in the web.
Great article and linked discussions. Thanks for sharing.
rs186 wrote 1 day ago:
The author was a core contributor of Google's Lit project:
URI [1]: https://github.com/lit/lit
mock-possum wrote 19 hours 24 min ago:
Lit my beloved
God I love lithtmlâs tagged template literals so much more than
reactâs JSX or Vueâs 3-in-one thing. Itâs just html, in
strings, in JavaScript. Lit is just a way to make custom elements
easier. Man itâs gonna suck when I have to move on from my current
gig and get my hands dirty with react again.
troupo wrote 17 hours 16 min ago:
> Itâs just html, in strings, in JavaScript.
It's not. It's a custom HTML-like syntax with lots of custom and
weird rules.
yoz-y wrote 3 hours 36 min ago:
Itâs similar enough to html that anybody familiar with html and
JS can pick it up. Quirks it has, but I like that using it mostly
just feels like building a huge html string.
troupo wrote 3 hours 17 min ago:
> Itâs similar enough to html that
"Similar enough" is a far cry from "Itâs just html, in
strings, in JavaScript"
> anybody familiar with html and JS can pick it up
Just like JSX. But no one calls JSX "just HTML" (and in React,
with rules of hooks, it's no longer "just JS"). In Solid JSX
returns actual DOM nodes btw.
> it mostly just feels like building a huge html string.
Because that's what you essentially do. lit runtime parses your
custom string, converts it to proper HTML, concatenates that
into a string, and then dumps into the document with innerHTML
(it does set up data bindings etc. , so it's more than just
thay of course)
unlog wrote 11 hours 22 min ago:
Yep, `lit` is contaminating the browser API with their ideas just
because their group of people writes the code for the browsers.
They should be competing from the outside. Instead of pushing
this kind of apis that only fit their mental models.
mosdl wrote 1 day ago:
I miss mozilla's XUL language (and XBL!), those were awesome.
sabellito wrote 1 day ago:
My company, me as a solo dev, back in 2003-04 built a "single page
app" using XUL and iframes.
Still has some 200 monthly users, the poor bastards. They have to
download Firefox 3.6 iirc, and it only works in an 800x600 window.
XUL was beastly back then though.
Nextgrid wrote 1 day ago:
> Still has some 200 monthly users, the poor bastards. They have to
download Firefox 3.6 iirc, and it only works in an 800x600 window.
Out of curiosity, what does that app do to convince people to jump
through such hoops? Would you mind sending a link to it?
mosdl wrote 21 hours 46 min ago:
Quite common, lots of old software that is custom written lives
on, be it java apps, old vb stuff, etc
sabellito wrote 1 day ago:
It's a full management app for recruiting companies.
There are still 3 companies that use it (since 2008), so their
employees don't have a choice really. The app does a lot, so to
stop using it the companies would need to hire and migrate to 3-4
other services. I reckon SAP and the kind could do everything as
well, but these companies are too small for that.
There isn't a website or anything anymore for me to show, and I
haven't been involved in it for over 10 years.
watersb wrote 1 day ago:
there-is-only-XUL
paulrouget wrote 19 hours 33 min ago:
There is no data! [1] Good old time.
URI [1]: https://www.mozilla.org/keymaster/gatekeeper/there.is.only...
latortuga wrote 1 day ago:
Seems like a comment comes up about XUL every few years and I can't
help but be sniped by it. A xulrunner app was my first job out of
college in '08, good memories, fun dev environment!
segphault wrote 1 day ago:
Instead of adopting JSX, I would really like the syntax for this to be
more like the way Kotlin uses receivers and builders to provide a
generalized syntax for DSLs that happens to be good for describing
component hierarchies. It would be broadly useful far beyond just HTML
templating, it would also be great for expressing configurations and
all kinds of other things.
The actual semantics for templating and data binding could just be a
set of standard functions that use those syntactic feature, much like
what you see in Jetpack Compose.
BiteCode_dev wrote 1 day ago:
You don't even need much: loops, conditionals on attributes, and
conditionals on nodes.
In fact, we could have that cross-language.
quantadev wrote 1 day ago:
Templates are great until they need to be dynamic. Then you're right
back to the current situation where frameworks like React are just the
better way.
In fact, you could call JSX a "Dynamic Templating System" and that's a
reasonable summary of what it is (in addition to other things of
course).
There might be some ways that React itself could, internally, notice
the special cases and special times where it _could_ be slightly more
performant from using a lower level of templating, as an optimization,
but I'd certainly prefer that to be abstracted away and buried deep
inside React, rather than ever having to think about it myself, at the
JSX layer.
Someone can let me know if React is already leveraging this for
browsers that support it, I didn't research that.
rictic wrote 1 day ago:
The system described in the article is very React-like, and could be
used by future versions of React. In both, functions return a
description of HTML to render, which can be applied either to create
new HTML or to update previously rendered HTML.
nwienert wrote 1 day ago:
I skimmed part of it, but unless I missed some huge caveat I think
youâre backwards and GP is definitely right. The article mentions
React, then sort of dismisses it later saying the other two
strategies are better to implement instead of diffing.
I donât see any reason a browser level âhereâs new DOM you
diff and apply itâ couldn't exist and be a huge win for React and
other libraries, with React so much more popular than every other
framework combined, and that being a pretty low level API, it makes
sense to start there.
Building the overly abstracted thing first is a mistake web API
authors have made too many times (see web components).
quantadev wrote 1 day ago:
I still have hope for Web Components to take off in the figure.
I'm a React dev so I don't "need" them, but they may end up being
some kind of capability that React can secretly, quietly embed
into React core as some kind of optimization if that ever makes
sense. Web Components is a great idea, but like I said it's just
not quite as convenient as React, so it's currently somewhat
irrelevant at least for me.
Gualdrapo wrote 1 day ago:
"If I could wave my magic wand..." at least 2 of 3 of the changes I'd
made about the way frontend web is developed, would be about ``s:
1. Making it possible to do something like and being able to load
them from an external source
2. Making them "dynamic"
3 (and the most controversial one) that all CSS, HTML and Javascript
(if you don't hate it) could be written natively like QML - one
syntax to rule them all.
lelanthran wrote 10 hours 54 min ago:
> 1. Making it possible to do something like and being able to
load them from an external source
I've done that, requires no build step/npm/whatever. It was posted
on HN for discussion a week ago:
URI [1]: https://github.com/lelanthran/ZjsComponent
quantadev wrote 1 day ago:
As a web dev you probably already know but #1 is slightly similar
to `Web Components` but you're right we cannot load a web component
right in the HTML where we use it. It makes sense though because if
you use an Element in multiple places it wouldn't make sense to
have 'src' in multiple places, so ultimately some kind of 'loading'
at the top of the page is needed, and that's how WebComponents
work, but I still like how you think.
#3 is a tricky one syntactically because HTML needs to be used by
mere mortals and JS is a programming language used by us gods, so
unifying all three would br tricky, but again I agree with you that
would be awesome. Maybe some flavor of LISP would be both "powerful
like a language" and "easy like a document".
insin wrote 1 day ago:
We'd need a good API for UI components to go with it
wg0 wrote 1 day ago:
Need a DOM snapshot API too.
PaulHoule wrote 1 day ago:
What about [1] ?
The next two documents are part of a set that I made which did
DOM-based templating on the back end in Java [2] [3] one trouble is
that systems that work at the DOM tree level are an order or two
magnitudes slower than string-based templating systems. Hypothetically
you could do some interesting things like hygenic macros and merge
together arbitrary documents, rewriting the CSS classes and such. But
by and large people find string-based templates to be good enough and
don't way to pay the price for something more expensive.
URI [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/El...
URI [2]: https://ontology2.com/the-book/html5-the-official-document-lan...
URI [3]: https://ontology2.com/the-book/source-code-transclusion-in-htm...
WorldMaker wrote 1 day ago:
Currently s only have automatic behavior when attaching a to the
Shadow DOM to a node with existing "Light" DOM children, which mostly
only happens with Web Components (and for now Web Components require
JS).
So it is not yet a full, generic templating solution.
Also, this article goes on at length about how the templating needs
to be "reactive" and not just "builds a DOM tree", and doesn't do
that yet at all, even in the automatic behavior scenarios, it's a one
time "merge".
Kicking the can along the road of the complexity of "reactive"
components is a large part of how we've got the (quite basic) and
tags that we got, and I think why the article is still currently
impractical. There needs to be more agreement on what "reactive"
means. The article mentions the signals proposal, and that's one
possibility that a lot of frameworks are pushing for right now, but
it's still a process before browsers agree to support something like
that, and something like that is a dependency before agreeing on what
a "reactive" template language can be/how it would work out of the
box.
DIR <- back to front page