Fisrt include jQuery as a whole into the base standard. That would help a lot.
Out of FE for a whole but isn't that done to a great extent.
done, how?
The time is right for a DOM templating API
81–90 of 256 posts
Re: The time is right for a DOM templating API
#82Re: The time is right for a DOM templating API
#83Earlier quoted context omitted.
jQuery is large and contains a lot of things. Which specific features do you think the DOM needs?
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.
Doesn't querySelector(All) provide this?
Re: The time is right for a DOM templating API
#84Earlier quoted context omitted.
> 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…
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 and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
Re: The time is right for a DOM templating API
#85What 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".…
Virtual DOM is a useless abstraction, there are numerous libs that perform fine without it.
Re: The time is right for a DOM templating API
#86> 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.
Re: The time is right for a DOM templating API
#87I 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 eff…
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.
Re: The time is right for a DOM templating API
#88Earlier quoted context omitted.
Except React.....
Was react ever about progress?
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.
Re: The time is right for a DOM templating API
#89I 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 eff…
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.
DOM + CSS is a hugely rich layout / rendering engine. The problem is that it's heavyweight.
Re: The time is right for a DOM templating API
#90Earlier 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…
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.