4 ms·

E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. That's why JSX eclipsed it, and there hasn't been a

E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. That's why JSX eclipsed it, and there hasn't been a serious proposal for HTML templating in JS since then. But maybe we can revive the general idea with a modern take: https://github.com/WICG/webcomponents/issues/1069 https://github.com/WICG/webcomponents/issues/1069

lolinder 2y ago
> had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. Isn't this what we have in TFA?
- bastawhiz 2y ago
  Yes, for elements. The project here also supports a notion of components, though, which E4X didn't contemplate.
olliej 2y ago
Also E4X was only ever implemented in Firefox, never really got traction even in Firefox. But even considering the single implementation problem, it also was just not a good language model, nor was it well specified or defined and it brought with it a pile of weird baggage and complexity. Then because it was The Future there was no real thought into proper interop with JS (it was essentially a completely independent spec so adopted general syntax but specified in a way that meant JS could not simply adopt that syntax).
kreetx 2y ago
With "imperatively" you mean that the user of the templating system has to do it imperatively, and that is bad? Asking because imperative updates seem to be the way to go within the implementation, instead of creating new instances of elements every time.
Sephr 2y ago
> E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively Firefox never shipped the optional E4X DOM APIs. I wrote a polyfill for them at the time.[1] 1. https://github.com/eligrey/e4x.js/blob/master/e4x.js https://github.com/eligrey/e4x.js/blob/master/e4x.js
SkiFire13 2y ago
> which needed to be updated imperatively VanillaJSX seems to suffer from the same problem though.
megaman821 2y ago
There are separate proposals from web components that get rid of imperative updates. https://eisenbergeffect.medium.com/the-future-of-native-html-templating-and-data-binding-5f3e52fda259 https://eisenbergeffect.medium.com/the-future-of-native-html...

lolinder 2y ago

> had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. Isn't this what we have in TFA?

bastawhiz 2y ago
Yes, for elements. The project here also supports a notion of components, though, which E4X didn't contemplate.

olliej 2y ago

Also E4X was only ever implemented in Firefox, never really got traction even in Firefox. But even considering the single implementation problem, it also was just not a good language model, nor was it well specified or defined and it brought with it a pile of weird baggage and complexity. Then because it was The Future there was no real thought into proper interop with JS (it was essentially a completely independent spec so adopted general syntax but specified in a way that meant JS could not simply adopt that syntax).

kreetx 2y ago

With "imperatively" you mean that the user of the templating system has to do it imperatively, and that is bad? Asking because imperative updates seem to be the way to go within the implementation, instead of creating new instances of elements every time.

Sephr 2y ago

> E4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively Firefox never shipped the optional E4X DOM APIs. I wrote a polyfill for them at the time.[1] 1. https://github.com/eligrey/e4x.js/blob/master/e4x.js https://github.com/eligrey/e4x.js/blob/master/e4x.js

SkiFire13 2y ago

> which needed to be updated imperatively VanillaJSX seems to suffer from the same problem though.

megaman821 2y ago

There are separate proposals from web components that get rid of imperative updates. https://eisenbergeffect.medium.com/the-future-of-native-html-templating-and-data-binding-5f3e52fda259 https://eisenbergeffect.medium.com/the-future-of-native-html...