[HN Gopher] The time is right for a DOM templating API
___________________________________________________________________
The time is right for a DOM templating API
Author : mdhb
Score : 199 points
Date : 2025-06-26 19:23 UTC (1 days ago)
(HTM) web link (justinfagnani.com)
(TXT) w3m dump (justinfagnani.com)
| PaulHoule wrote:
| What about
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
|
| ?
|
| The next two documents are part of a set that I made which did
| DOM-based templating on the back end in Java
|
| https://ontology2.com/the-book/html5-the-official-document-l...
|
| https://ontology2.com/the-book/source-code-transclusion-in-h...
|
| 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.
| WorldMaker wrote:
| Currently <slot>s only have automatic behavior when attaching a
| <template> 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
| <slot> 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)
| <template> and <slot> 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.
| wg0 wrote:
| Need a DOM snapshot API too.
| insin wrote:
| We'd need a good API for UI components to go with it
| quantadev wrote:
| 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.
| Gualdrapo wrote:
| "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 `<template>`s:
|
| 1. Making it possible to do something like <template src="...">
| 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.
| quantadev wrote:
| 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".
| lelanthran wrote:
| > 1. Making it possible to do something like <template
| src="..."> 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:
| https://github.com/lelanthran/ZjsComponent
| rictic wrote:
| 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:
| 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:
| 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.
| segphault wrote:
| 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:
| You don't even need much: loops, conditionals on attributes,
| and conditionals on nodes.
|
| In fact, we could have that cross-language.
| mosdl wrote:
| I miss mozilla's XUL language (and XBL!), those were awesome.
| latortuga wrote:
| 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!
| watersb wrote:
| there-is-only-XUL
| paulrouget wrote:
| There is no data!
|
| https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x.
| ..
|
| Good old time.
| sabellito wrote:
| 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:
| > 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?
| sabellito wrote:
| 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.
| mosdl wrote:
| Quite common, lots of old software that is custom written
| lives on, be it java apps, old vb stuff, etc
| rs186 wrote:
| The author was a core contributor of Google's Lit project:
| https://github.com/lit/lit
| mock-possum wrote:
| 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:
| > 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.
| unlog wrote:
| 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.
| yoz-y wrote:
| 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:
| > 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)
| bevr1337 wrote:
| 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.
| lofaszvanitt wrote:
| Fisrt include jQuery as a whole into the base standard. That
| would help a lot.
| edoceo wrote:
| I <3 jQuery but, no.
| lofaszvanitt wrote:
| What no? Why can't we have nice things, like concise, easy to
| remember, not overly elaborate syntax?
| ameliaquining wrote:
| jQuery is large and contains a lot of things. Which
| specific features do you think the DOM needs?
| eszed wrote:
| 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:
| Doesn't querySelector(All) provide this?
| troupo wrote:
| Not entirely. There's a reason people do
| Array.from(querySelectorAll) to do more than just
| `forEach`
| jraph wrote:
| 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:
| > 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: https://youmightnotneedjquery.com
|
| 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(filterFn)
| ;
|
| There's a reason most people avoid DOM APIs like the
| plague.
|
| ---
|
| [1] This is the _entirety_ of methods exposed on NodeList
| https://developer.mozilla.org/en-US/docs/Web/API/NodeList
|
| Instance properties
|
| - length
|
| Instance methods
|
| - entries() // returns an iterator
|
| - forEach()
|
| - item()
|
| - keys()
|
| - values()
| jraph wrote:
| 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:
| > 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:
| jQuery's scope is broad1. 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.
|
| 1 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).
| WorldMaker wrote:
| 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.
|
| [1]
| https://2ality.com/2025/06/ecmascript-2025.html#iterator-
| hel...
| troupo wrote:
| > 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:
| 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.)
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| troupo wrote:
| > 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:
| [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.
| lofaszvanitt wrote:
| What do you think is alrite in the current spec?
| bravesoul2 wrote:
| Out of FE for a whole but isn't that done to a great extent.
| lofaszvanitt wrote:
| done, how?
| bravesoul2 wrote:
| https://developer.mozilla.org/en-
| US/docs/Web/API/Element/que...
| pier25 wrote:
| 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.
| nwienert wrote:
| React isn't templating though.
| ASalazarMX wrote:
| Respect for focusing on semantics but not contesting the CPU
| and bandwidth waste. That takes honesty.
| ivape wrote:
| 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?
| strix_varius wrote:
| With the TC39 signals proposal, part of that is making
| progress.
| CharlieDigital wrote:
| Except React.....
| tacticus wrote:
| Was react ever about progress?
| nine_k wrote:
| 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.
| youngtaff wrote:
| React was a solution to a ten years ago problem
| youngtaff wrote:
| You can downvote it but it doesn't make it any less true
|
| Alex Russell has written swathes of arguments about
| Reacts performance issues
| https://infrequently.org/2024/11/if-not-react-then-what/
|
| 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
| ch_sm wrote:
| 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.
| nchmy wrote:
| Nah.
|
| https://svelte.dev/blog/virtual-dom-is-pure-overhead
|
| https://news.ycombinator.com/item?id=43971164
| nine_k wrote:
| 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:
| 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.
| agos wrote:
| if (when?) Signals become a standard, React will be in a
| tight corner if they decide to ignore them
| WorldMaker wrote:
| 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.)
| hyfgfh wrote:
| That's alright now LLM and crypto make this waste seem
| minuscule
| ivape wrote:
| Two way data binding and a jsx clone is kind of all anyone
| really needs.
| bravesoul2 wrote:
| 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.
| ericyd wrote:
| > 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?
| krebby wrote:
| 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.
|
| https://react.dev/reference/react-dom/components/common#reac...
| bevr1337 wrote:
| > 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.
|
| https://legacy.reactjs.org/docs/events.html
| https://react.dev/reference/react-dom/components/common#reac...
| MrJohz wrote:
| 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:
| And then some. Switching to react-native or other render
| targets can also be a doozy. Hopefully the references
| clarify all the features.
| shermantanktop wrote:
| 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?
| quotemstr wrote:
| > 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:
| 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.
| dleeftink wrote:
| > 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.
| btown wrote:
| 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
| https://servo.org/ 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.
| troupo wrote:
| > 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:
| https://developer.chrome.com/blog/smooshgate
| EasyMark wrote:
| Isn't that why you have versions and maintains backward
| compatibility with older versions, and don't change the "old"
| interfaces?
| jongjong wrote:
| 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.
| djfivyvusn wrote:
| Where's the code?
| exclipy wrote:
| https://github.com/WICG/webcomponents/issues/1069
| hsn915 wrote:
| 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.
| sethaurus wrote:
| Other than quibbling over the word "template", how does that
| differ from what TFA is describing?
| hsn915 wrote:
| 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.
|
| https://github.com/WICG/webcomponents/issues/1069
|
| My proposal only adds one native function with nothing else:
| no new data types, no new apis.
| WickyNilliams wrote:
| 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.
| ethan_smith wrote:
| 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.
| silverwind wrote:
| Virtual DOM is a useless abstraction, there are numerous libs
| that perform fine without it.
| nine_k wrote:
| 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.
| taeric wrote:
| 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?
| wahern wrote:
| > 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.
| wpm wrote:
| I regularly work with APIs in shell that return XML and XSLT
| is a goddamn super power. I adore it.
| eclipticplane wrote:
| 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.
| notpushkin wrote:
| 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:
| https://xsltbin.ale.sh/
| nine_k wrote:
| 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.
| agumonkey wrote:
| 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.
| nine_k wrote:
| It's sort of similar to regular pattern-matching, but
| sadly not built for ergonomics :(
| agumonkey wrote:
| 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:
| 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.
| agumonkey wrote:
| I get it, but it's hard to track
| HelloNurse wrote:
| 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.
| friendzis wrote:
| 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
| PaulHoule wrote:
| 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".
| mattmanser wrote:
| 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:
|
| https://thedailywtf.com/articles/Sketchy-Skecherscom
|
| 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.
| notpushkin wrote:
| Can you generate XSLT from s-expressions though?
| :thinking:
| PaulHoule wrote:
| 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 <someElement
| someAttributeattribute=$x/> ->
| <anotherElement>$x</anotherElement>
|
| 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.
| marcosdumay wrote:
| 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.
| geocar wrote:
| > 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...
| echelon wrote:
| 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.
| Mikhail_Edoshin wrote:
| 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.
| connicpu wrote:
| 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:
| 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.)
| PaulHoule wrote:
| 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.
| froh wrote:
| 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:
| Why not implement a DSSSL-to-XSLT compiler?
| PaulHoule wrote:
| 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.
| austin-cheney wrote:
| > 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.
| dominicrose wrote:
| 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.
| moritzwarhier wrote:
| > 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:
| 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:
| 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:
| 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.
| chii wrote:
| > 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:
| 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:
| 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.
| jdkoeck wrote:
| > 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).
| taeric wrote:
| 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.
| MrJohz wrote:
| 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 `<Cpt prop={expr} />` 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.
| 9rx wrote:
| We do know what is good. We may not know what is perfect, but
| perfect need not be the enemy of good.
| taeric wrote:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| 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:
| _> 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:
| My question to you, then, is if you think you contributed
| anything at all to this? Because, yeah, nothing there.
| 9rx wrote:
| Yes, it contributed to my enjoyment. I mean, that is all
| that can be contributed, fundamentally, so...
| tshaddox wrote:
| 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.
| Sophistifunk wrote:
| When are we done adding everything into the browser API?
| wewewedxfgdf wrote:
| Hopefully never.
|
| Unless you loved IE6 of course, which was when Microsoft
| declared the web browser to be 'complete'.
| lylejantzi3rd wrote:
| When somebody creates something better.
| nitwit005 wrote:
| 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.
| keepamovin wrote:
| The time has been right for Yonkers -
| d--b wrote:
| 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.
| dragonwriter wrote:
| > 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.
| leeoniya wrote:
| > 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: https://github.com/localvoid/ivi
|
| 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.
|
| https://krausest.github.io/js-framework-benchmark/2025/table...
| localvoid wrote:
| 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. https://github.com/tc39/proposal-record-tuple
| leeoniya wrote:
| > 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.
| troupo wrote:
| > 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:
| > 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:
| 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:
| 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:
| that's a better distillation :)
| localvoid wrote:
| 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.
| https://developer.android.com/develop/ui/compose/kotlin
| jraph wrote:
| > 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.
| wavemode wrote:
| 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]: https://xkcd.com/927/
| jdkoeck wrote:
| Is there really a proliferation? At this point it's 90% React.
| branko_d wrote:
| 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:
| DOM + CSS _is_ a hugely rich layout / rendering engine. The
| problem is that it's heavyweight.
| tcoff91 wrote:
| Stop adding more complexity to the browser and making it even
| more impossible to build a new browser from scratch.
| upghost wrote:
| 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.
| parhamn wrote:
| 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).
| bapak wrote:
| 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.
| stevage wrote:
| 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:
| 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:
| > 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.
| b0a04gl wrote:
| 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
| austin-cheney wrote:
| 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.
| 9rx wrote:
| 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.
| yoz-y wrote:
| I'm curious. What is actually wrong with querySelector?
| jlukic wrote:
| 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:
| > 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_
| JimDabell wrote:
| 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:
| > 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:
| https://github.com/WICG/webcomponents/blob/gh-
| pages/proposal... but that mostly went nowhere
| JimDabell wrote:
| 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.
| gwd wrote:
| > wrecklessly
|
| <pedantic>
|
| 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).
|
| </pedantic>
| troupo wrote:
| 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.
| llcooliovice wrote:
| 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.
| llcooliovice wrote:
| > 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:
| 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:
| 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.
| ukuina wrote:
| Nit: The post keeps referring to "standard JSX" as though trying
| to will such a thing into existence.
| jmull wrote:
| I thought one of the main points the article is making about
| JSX is that it currently _isn't_ standardized.
| aatd86 wrote:
| 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.
| austin-cheney wrote:
| 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.
| troupo wrote:
| > 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:
| 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:
| Javascript being a decent functional language does not make
| DOM API functional.
|
| DOM API is 90-s era OOP
| hackrmn wrote:
| 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?
| notnullorvoid wrote:
| 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.
| llcooliovice wrote:
| > 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: https://github.com/whatwg/dom/issues/736
| llcooliovice wrote:
| > 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.
| https://github.com/tc39/proposal-record-tuple/issues/394
|
| It has been replaced by https://github.com/tc39/proposal-
| composites
| ulrischa wrote:
| The answer is here on the HN Start-page: XSLT
| TheRealPomax wrote:
| > 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.
| vlucas wrote:
| 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:
| 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.
| codedokode wrote:
| 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:
| 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.
| llcooliovice wrote:
| > 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.
___________________________________________________________________
(page generated 2025-06-27 23:01 UTC)