Earlier quoted context omitted.
With the TC39 signals proposal, part of that is making progress.
Except React.....
if (when?) Signals become a standard, React will be in a tight corner if they decide to ignore them
The time is right for a DOM templating API
121–130 of 256 posts
Re: The time is right for a DOM templating API
#122Earlier quoted context omitted.
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/
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 a…
Can you generate XSLT from s-expressions though? :thinking:
Re: The time is right for a DOM templating API
#123> 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.
MDN and caniuse say otherwise. I think there might've been an older specification that got implemented, but it's been revised since
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.
Re: The time is right for a DOM templating API
#124> 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
Re: The time is right for a DOM templating API
#125> 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
Re: The time is right for a DOM templating API
#126Earlier quoted context omitted.
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.
React was a solution to a ten years ago problem
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
Re: The time is right for a DOM templating API
#127It’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.
> 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 d…
> 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).
Re: The time is right for a DOM templating API
#128Earlier quoted context omitted.
> 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 th…
> 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…
> 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.
Re: The time is right for a DOM templating API
#129I 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.
> 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.
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.
Re: The time is right for a DOM templating API
#130Earlier quoted context omitted.
It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
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 ?)
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.