34 ms·

Don't forget E4X: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tutorial/Introduction https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tut...

by db48x 7y ago

Don't forget E4X: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tutorial/Introduction https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tut... It never really caught on.

unilynx 7y ago
That MDN article is fairly limited - a whole javascript syntax for querying documents came with it: https://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e72.html https://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e... In the end we jumped from ES3 to ES5, skipping all of E4X. I wonder if we're better off.
52-6F-62 7y ago
Wow. I'd never heard of this. And now instead we have virtually the same thing via JSX except we now require a compilation stage to achieve essentially the same thing...
- brlewis 7y ago
  I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art https://facebook.github.io/jsx/#prior-art
  - jannes 7y ago
    The creators of JSX (Facebook employees obviously) once said in a talk that their biggest inspiration for JSX was server-side PHP code which supports being interspersed with HTML.
    - TomMarius 7y ago
      Yes, XHP, also by Facebook
    - hombre_fatal 7y ago
      Link? You might be misremembering Pete Hunt's talk about React's design decisions: https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY where he makes the case against the "separation of concerns" cargo cult.
      - jannes 7y ago
        Sorry, I don't remember the link. It may have been this talk from 2013, but I haven't rewatched it: https://www.youtube.com/watch?v=XxVg_s8xAms https://www.youtube.com/watch?v=XxVg_s8xAms However, if you check out the History section [0] on Wikipedia you will see this confirmed: > React was created by Jordan Walke, a software engineer at Facebook, who released an early prototype of React called "FaxJS". He was influenced by XHP, an HTML component library for PHP. [0]: https://en.wikipedia.org/wiki/React_(web_framework)#History https://en.wikipedia.org/wiki/React_(web_framework)#History
    - brlewis 7y ago
      > PHP code which supports being interspersed with HTML You're one of a large number of people who say this, but it is false. PHP intersperses a programming language with static strings. Those static strings frequently adhere to HTML syntax, but that's aside from PHP. What is HTML? It's not random strings; it's a syntax. JSX is much closer to interspersing HTML with a Turing-complete programming language than PHP ever was, because frequently the mistakes that make JSX not compile are the same mistakes that make HTML invalid. Admittedly I haven't used PHP since 2012, but at least back then you could make all the HTML mistakes you wanted, and PHP wouldn't bat an eyelash. EDIT: Here's someone else's comment making the same point in different words. If my comment doesn't make sense to you try this one: https://news.ycombinator.com/item?id=23144268 https://news.ycombinator.com/item?id=23144268
      - wtetzner 7y ago
        You're technically correct, but I don't think the distinction adds anything to the conversation. I don't know if PHP was the inspiration for JSX, but if the strings they were using in PHP was HTML, then it could have been. EDIT: Sounds like JSX was inspired by XHP: https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/ https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...
        jraph 7y ago
        Besides, the parent never said that PHP was restricted to being mixed with HTML, they just said that it was possible. The contradiction of this is technically incorrect.
        brlewis 7y ago
        A lot of the objections people have to "mixing code and HTML" stem from experience with PHP and similar technologies. The distinction is important, because JSX is less objectionable than PHP.
  - ahupp 7y ago
    JSX was a direct port of XHP to Javascript.
eyelidlessness 7y ago
I mean, it kind of caught on. It's syntactically very close (if not identical) to JSX. It just caught on in a different form/technology than what was built into Gecko. I think if it had been introduced later, with the kinds of performance seen in VDOM implementations, it may have had a greater chance of becoming a web standard.
- 52-6F-62 7y ago
  Ultimately what is in the way of it being implemented now or in the near future? Is there anything? I don't see why it couldn't just live beside the current Element API.
  - eyelidlessness 7y ago
    The standards bodies have historically tended to adopt lower level APIs over higher level abstractions. I think the likelihood of JSX or E4X or whatever, as such, making it through the standards process is fairly low.
tjansen 7y ago
Yes, I am still sad about this. A simplified XML (without entities, PIs and CData sections), XHTML and E4X would have been an awesome platform. Almost as simple as JSON, and with a single format for both data and markup.
leovander 7y ago
We use it in healthcare, at least in NextGen Connect, formerly Mirth Connect[0]. It uses Rhino[1] as its scripting engine which still supports E4X. [0] https://en.wikipedia.org/wiki/NextGen_Connect https://en.wikipedia.org/wiki/NextGen_Connect [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rh...
- db48x 7y ago
  That is really cool. I had no idea anyone was still using it.
ahupp 7y ago
The problem with E4X is that it's only data; you can't define a new tag that reduces to new primitives. This kind of composability is why XHP (in PHP) and JSX are so useful.
- db48x 7y ago
  Javascript already has the ability to define new abstractions. They're called functions. Imagine you want a new "tag" for defining a Widget. Make yourself a Widget function which takes some arguments, maybe the name of the widget, the mass, and the price. Those arguments can themselves be HTML, created either using E4X or any other means you like. This lets you compose things together. For example, perhaps the price could just be a number today, but tomorrow you want to let the user do currency conversions and so you make it a more complicated AJAX thing that lets the user view the price in any currency they want. Today you would have Widget("Plumbus", kg(1.1), 49.99), but tomorrow you could change it to Widget("Plumbus", kg(1.1), Currency(USD, 49.99)). No new inventions required.
  - ahupp 7y ago
    Sure, but the why are we talking about special syntax in the first place? In any non-trivial projects you're rarely going to be working with primitive tags, it's always higher level components.
    - db48x 7y ago
      Because all higher-level components must be created out of primitive html tags with a sprinkling of attributes, and it's nice to have a convenient way to create those. This is the same reason why modern languages include some kind of object-literal syntax rather than relying purely on constructor functions. Even C has a comprehensive syntax for initializing objects now. E4X was just that for HTML and XML.

by db48x 7y ago

Don't forget E4X: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tutorial/Introduction https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tut... It never really caught on.

unilynx 7y ago

That MDN article is fairly limited - a whole javascript syntax for querying documents came with it: https://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e72.html https://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e... In the end we jumped from ES3 to ES5, skipping all of E4X. I wonder if we're better off.

52-6F-62 7y ago

Wow. I'd never heard of this. And now instead we have virtually the same thing via JSX except we now require a compilation stage to achieve essentially the same thing...

brlewis 7y ago
I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art https://facebook.github.io/jsx/#prior-art
- jannes 7y ago
  The creators of JSX (Facebook employees obviously) once said in a talk that their biggest inspiration for JSX was server-side PHP code which supports being interspersed with HTML.
  - TomMarius 7y ago
    Yes, XHP, also by Facebook
  - hombre_fatal 7y ago
    Link? You might be misremembering Pete Hunt's talk about React's design decisions: https://www.youtube.com/watch?v=x7cQ3mrcKaY https://www.youtube.com/watch?v=x7cQ3mrcKaY where he makes the case against the "separation of concerns" cargo cult.
    - jannes 7y ago
      Sorry, I don't remember the link. It may have been this talk from 2013, but I haven't rewatched it: https://www.youtube.com/watch?v=XxVg_s8xAms https://www.youtube.com/watch?v=XxVg_s8xAms However, if you check out the History section [0] on Wikipedia you will see this confirmed: > React was created by Jordan Walke, a software engineer at Facebook, who released an early prototype of React called "FaxJS". He was influenced by XHP, an HTML component library for PHP. [0]: https://en.wikipedia.org/wiki/React_(web_framework)#History https://en.wikipedia.org/wiki/React_(web_framework)#History
  - brlewis 7y ago
    > PHP code which supports being interspersed with HTML You're one of a large number of people who say this, but it is false. PHP intersperses a programming language with static strings. Those static strings frequently adhere to HTML syntax, but that's aside from PHP. What is HTML? It's not random strings; it's a syntax. JSX is much closer to interspersing HTML with a Turing-complete programming language than PHP ever was, because frequently the mistakes that make JSX not compile are the same mistakes that make HTML invalid. Admittedly I haven't used PHP since 2012, but at least back then you could make all the HTML mistakes you wanted, and PHP wouldn't bat an eyelash. EDIT: Here's someone else's comment making the same point in different words. If my comment doesn't make sense to you try this one: https://news.ycombinator.com/item?id=23144268 https://news.ycombinator.com/item?id=23144268
    - wtetzner 7y ago
      You're technically correct, but I don't think the distinction adds anything to the conversation. I don't know if PHP was the inspiration for JSX, but if the strings they were using in PHP was HTML, then it could have been. EDIT: Sounds like JSX was inspired by XHP: https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/ https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...
      - jraph 7y ago
        Besides, the parent never said that PHP was restricted to being mixed with HTML, they just said that it was possible. The contradiction of this is technically incorrect.
      - brlewis 7y ago
        A lot of the objections people have to "mixing code and HTML" stem from experience with PHP and similar technologies. The distinction is important, because JSX is less objectionable than PHP.
- ahupp 7y ago
  JSX was a direct port of XHP to Javascript.

eyelidlessness 7y ago

I mean, it kind of caught on. It's syntactically very close (if not identical) to JSX. It just caught on in a different form/technology than what was built into Gecko. I think if it had been introduced later, with the kinds of performance seen in VDOM implementations, it may have had a greater chance of becoming a web standard.

52-6F-62 7y ago
Ultimately what is in the way of it being implemented now or in the near future? Is there anything? I don't see why it couldn't just live beside the current Element API.
- eyelidlessness 7y ago
  The standards bodies have historically tended to adopt lower level APIs over higher level abstractions. I think the likelihood of JSX or E4X or whatever, as such, making it through the standards process is fairly low.

tjansen 7y ago

Yes, I am still sad about this. A simplified XML (without entities, PIs and CData sections), XHTML and E4X would have been an awesome platform. Almost as simple as JSON, and with a single format for both data and markup.

leovander 7y ago

We use it in healthcare, at least in NextGen Connect, formerly Mirth Connect[0]. It uses Rhino[1] as its scripting engine which still supports E4X. [0] https://en.wikipedia.org/wiki/NextGen_Connect https://en.wikipedia.org/wiki/NextGen_Connect [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rh...

db48x 7y ago
That is really cool. I had no idea anyone was still using it.

ahupp 7y ago

The problem with E4X is that it's only data; you can't define a new tag that reduces to new primitives. This kind of composability is why XHP (in PHP) and JSX are so useful.

db48x 7y ago
Javascript already has the ability to define new abstractions. They're called functions. Imagine you want a new "tag" for defining a Widget. Make yourself a Widget function which takes some arguments, maybe the name of the widget, the mass, and the price. Those arguments can themselves be HTML, created either using E4X or any other means you like. This lets you compose things together. For example, perhaps the price could just be a number today, but tomorrow you want to let the user do currency conversions and so you make it a more complicated AJAX thing that lets the user view the price in any currency they want. Today you would have Widget("Plumbus", kg(1.1), 49.99), but tomorrow you could change it to Widget("Plumbus", kg(1.1), Currency(USD, 49.99)). No new inventions required.
- ahupp 7y ago
  Sure, but the why are we talking about special syntax in the first place? In any non-trivial projects you're rarely going to be working with primitive tags, it's always higher level components.
  - db48x 7y ago
    Because all higher-level components must be created out of primitive html tags with a sprinkling of attributes, and it's nice to have a convenient way to create those. This is the same reason why modern languages include some kind of object-literal syntax rather than relying purely on constructor functions. Even C has a comprehensive syntax for initializing objects now. E4X was just that for HTML and XML.