7 ms·

These "what ifs" are kinda funny because the origins of JSX can be traced back to Facebook's XHP[1], which took explicit inspiration from E4X[2], an early JS st

These "what ifs" are kinda funny because the origins of JSX can be traced back to Facebook's XHP[1], which took explicit inspiration from E4X[2], an early JS standard that looked and behaved similar to the library described here. [1] https://engineering.fb.com/2010/02/09/developer-tools/xhp-a-new-way-to-write-php/ https://engineering.fb.com/2010/02/09/developer-tools/xhp-a-... [2] https://en.m.wikipedia.org/wiki/ECMAScript_for_XML https://en.m.wikipedia.org/wiki/ECMAScript_for_XML

spankalee 2y ago
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...
olliej 2y ago
Fun fact, E4X is the reason JavaScript has ‘for(of)’ instead of ‘for each’ (the reason we didn’t get ‘for (:)’ is even dumber - it would conflict with ‘:type’ annotations a few TC39 members were convinced would magically be in the language)
- rlt 2y ago
  Like the type annotations that are now in TypeScript?
  - olliej 2y ago
    Yup, that were in typescript, pascal (and rust, etc when they came out). But there was no real progress after years of them pushing this syntax, but failing to actually define a type system that was coherent, or a model that would allow it. As a result I proposed `for (of)` largely to prevent sane enumeration from being blocked on the intransigence of two people. It's also worth noting that for(:) enumeration would not even preclude their syntax - it's certainly not grammatically ambiguous - and most real world code in languages that support enumeration directly and support inference doesn't explicitly specify the types , so the ugliness of `for(let a:type:expression)` would have be rare anyway. shrug Given that ECMA literally killed E4X a few years later the blanket ban on "for each" or "foreach" (because it would be "confusing" in E4X) is arguably worth than for(:), but again shrug
- IshKebab 2y ago
  There is a proposal to add them, though it does seem to be stalled.
  - olliej 2y ago
    There were proposals almost 2 decades ago. They've never gone anywhere because proponents of type specifiers don't want to do the necessary corollary: specifying the type system. Typescript and similar can do it because they don't have to specify the type system, and can't change it in meaningful ways over time. Things in the language standard cannot be easily changed, if they can be changed at all.

spankalee 2y ago

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...

olliej 2y ago

Fun fact, E4X is the reason JavaScript has ‘for(of)’ instead of ‘for each’ (the reason we didn’t get ‘for (:)’ is even dumber - it would conflict with ‘:type’ annotations a few TC39 members were convinced would magically be in the language)

rlt 2y ago
Like the type annotations that are now in TypeScript?
- olliej 2y ago
  Yup, that were in typescript, pascal (and rust, etc when they came out). But there was no real progress after years of them pushing this syntax, but failing to actually define a type system that was coherent, or a model that would allow it. As a result I proposed `for (of)` largely to prevent sane enumeration from being blocked on the intransigence of two people. It's also worth noting that for(:) enumeration would not even preclude their syntax - it's certainly not grammatically ambiguous - and most real world code in languages that support enumeration directly and support inference doesn't explicitly specify the types , so the ugliness of `for(let a:type:expression)` would have be rare anyway. shrug Given that ECMA literally killed E4X a few years later the blanket ban on "for each" or "foreach" (because it would be "confusing" in E4X) is arguably worth than for(:), but again shrug
IshKebab 2y ago
There is a proposal to add them, though it does seem to be stalled.
- olliej 2y ago
  There were proposals almost 2 decades ago. They've never gone anywhere because proponents of type specifiers don't want to do the necessary corollary: specifying the type system. Typescript and similar can do it because they don't have to specify the type system, and can't change it in meaningful ways over time. Things in the language standard cannot be easily changed, if they can be changed at all.