JavaScript once had a JSX-like syntax called E4X | Hacker News Reader

JavaScript once had a JSX-like syntax called E4X

developer.mozilla.org

171 pointsjekrb48 comments

I wrote a blog post a while ago about how JSX relates to E4X if you are interested: http://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts...

One bit of E4X trivia: a bug in the Firefox E4X implementation was taken advantage of by an exploit called "EgotisticalGiraffe", according to the Snowden documents. The implementation of E4X in Firefox was large and complex.

https://www.schneier.com/blog/archives/2013/10/how_the_nsa_a...

In 2008 I built a production website in Helma (server side JavaScript framework running on Rhino, JS on the JVM) with E4X for the view. You could say I've been waiting for React for a long time. Also that I used way-too-niche technology for a one-off project. :-/

Avantgarde rather than niche I'd say.

Helma, v8cgi and co. pioneered server-side JavaScript and around 2010 inspired CommonJS for portability, which Node.js became the dominant implementation of.

I believe Netscape's original web server product featured JavaScript as server-side scripting language back in 1995/6 already.

And the TU-Graz Hyper-G system => Hyperwave, which was very popular in the early internet days. It preceded WWW and Netscape by a bit.

Fb says:

Prior Art # The JSX syntax is similar to the E4X Specification (ECMA-357). E4X is a deprecated specification with deep reaching semantic meaning. JSX partially overlaps with a tiny subset of the E4X syntax. However, JSX has no relation to the E4X specification.

E4X was part of Actionscript 3. It was very nice.

It was also widely used for Adobe Flex for making Flash interfaces.

"Everything old becomes new again."

I quite loved my small stint developing in Adobe flex. I have to admit it.

I share that sentiment. The complete decoupling of UI presentation and logic all the way up to and through asset deployment via Flex Skins was interesting and had a lot of potential.

You're thinking of MXML. Different thing.

Nope. E4X was inline XML and it has been in AS3 for many many years.

Sad to see that all these great and convenient language features will take years (or never) to reach JS now that we voluntarily handcuffed ourselves to standards based tech just to satisfy the vendetta of a dead man.

But at least Flash is dead, right?

The post you're responding to was talking about the markup language used for Flex, which was MXML, not E4X.

I always found it a little odd but quite pleasant - but I don't at all remember AS3's E4X having interpolation. Did I just never know about this feature (or have since forgotten - it's been, oh, half a decade at least since I've used ActionScript 3 in anger), or was it missing?

It existed in AS3 too. Wasn't widely known to my knowledge though.

Thank you - confirmed. I just dug up a copy of Flash CS6 and tried this:

  var val : String = "foo";
  var foo : XML = <foo><bar prop={val} /></foo>;

...and it worked. I swear this wasn't documented anywhere. That said, I just googled a few Flex examples (I never used Flex) and it seems to be common there, so I guess that explains why at least someone knew it existed!

It's documented. I used to be very fluent in the AS3LR, and I found it in a minute or two here: http://help.adobe.com/en_US/FlashPlatform/reference/actionsc...

The formal language specification came fairly late in AS3's useful life, but it also describes the syntax: http://help.adobe.com/livedocs/specs/actionscript/3/as3_spec...

Ah, thank you for these. I skimmed the documentation about AS3's XML support and didn't see it there, and I'm not sure "operators" would be a place I would've looked!

I don't know if this would've been a super useful feature for me a decade ago, but it's nice to know it was there anyway.

That's possibly why I knew about it then (for a brief period, I did Flex work ten years ago).

I used to do Flex a long time ago, and I love how the frontend dev world is finally catching up to Flash from the late naughties.

Flash won. The world of Internet development is slowly being remade in Flex's image.

That Adobe abandoned he technology rather that retooling it to target HTML5 is a strategic blunder up there with... I can't actually work out an equivalent.

Would be nice to see JSX syntax become standardized. Clearly lots of people like it.

Note that there is a formal specification for JSX: https://facebook.github.io/jsx/ This has been helpful to make sure that all the tooling around JavaScript can work with JSX.

How would that work in practice, though? Using Babel JSX gets compiled to React.createElement('div', null, {}). You can configure babel to output something else if you use something other than React.

So what would a standardized JSX syntax output? It can't be document.createElement since that is a web API and not a generic JS API. So what would it do, exactly?

I've written an in depth blog post on "generic jsx", which turns JSX into function bind/currying syntax that would work fine in any framework (or not framework at all, as we currently use it).

http://tolmasky.com/2016/03/24/generalizing-jsx/

We use this generic-jsx in DemoKit: https://github.com/runkitdev/demokit , and it's really cool because you can do fancy stuff like:

      // Curry your JSX tags!
      const wordmark = <span style = "font-face:custom; font-weight:bold" />;

      .... <wordmark>hello</wordmark>

That would be actually super useful. JSX became for me the best part after writing React applications for quite a while. Performance-wise not using React is actually faster ^^ (If you take care of the dirty updating work of course)

6 years ago I wrote a proof of concept to replace a large Rails application in pure JS using prototypes and constructing the html from strings. The latter turned out to be the most messy part so I stopped that and rather refactored the legacy Rails code to do something useful.

Could be really great for super lightweight JS apps!

Its also important to consider the environment as well since JSX is potentially much bigger than the web.

JSX is much like other generic user interface markup languages[0] and like many other is simply a dialect of XML. Any interface that can be represented with XML/HTML or any other markup language can use JSX and optionally react. We are already seeing this boom with in native mobile environments with React Native, NativeScript, Titanium...

Here are several examples where JSX is used that is not a browser:

- Native desktop apps for Linux, Mac, and Windows (Not including Electron/NW.js)[1][2][3][4]

- TVs with AppleTV apps or Netflix's Gibbon[5][6]

- Command line apps as stdin/stdout with react-blessed[7]/mylittledom[8]

- Direct to Canvas[9]/pixi.js[10]

- Latex documents[11]

- Web Audio[12]

- Conole.logs[13]

- Truly custom direct to hardware[14] as some C code like: `digitalWrite(led, HIGH)`

I definitely believe JSX could use standardization separate from any implementation, JavaScript or otherwise.

[0]: https://en.wikipedia.org/wiki/User_interface_markup_language

[1]: https://github.com/sidorares/react-x11

[2]: https://github.com/grassator/react-qml

[3]: https://github.com/ptmt/react-native-macos

[4]: https://github.com/Microsoft/react-native-windows

[5]: https://github.com/ramitos/react-tvml

[6]: https://www.youtube.com/watch?v=eNC0mRYGWgc

[7]: https://github.com/Yomguithereal/react-blessed

[8]: https://github.com/manaflair/mylittledom

[9]: https://github.com/Flipboard/react-canvas

[10]: https://github.com/Izzimach/react-pixi

[11]: https://github.com/vzaccaria/jsx-latex

[12]: https://github.com/FormidableLabs/react-music

[13]: https://github.com/mohebifar/konsul

[14]: https://github.com/iamdustan/react-hardware

Perhaps providing a parser from something like the tagged template literals[1] from e.g. 'tag `string interpolation`' could be used. For ones lacking a tag, a specially named variable could be looked for (e.g. something like __xml_parser__ ) , it would be up to the program to set that global.

if would mean that jsx would look something like

    function helloEl() {return jsx <div> Hello ${name}! </div>}

as opposed to

    function helloEl() {return <div> Hello {name}! </div>}

It would be a bit different though in what is actually going on though. The top example would just desugar to

    jsx.div(`Hello ${name}`)

jsx would be looked up like any other variable. So you could just define it in global scope to point to ReactDOM

1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You can already translate JSX to `document.createElement` with babel. I haven't seen one, but I wouldn't doubt a `customElements.define` translation is coming as well.

Could you specify the dom nodes that would be created and leave the API that JSX desugars to/calls into in order to create them unspecified?

Does syntax standardization have to necessarily equate to implantation standardization?

No, but the question is what would the syntax actually do? Would it be an extension/wrapper around document.createElement? Could you have custom parsers? What would it mean for React?

If you've ever used Mirth[1] then you've used E4X, for better or worse (usually the latter). It's still used very heavily inside of the transformers, even though Mozilla deprecated it years ago.

[1] https://www.mirth.com/

Haha came to the comments looking for this. Mirth is love, Mirth is life.

Wait till they find out where "use strict" came from.

Yes! I use it from time to time in applications which have rhino as its scripting language(mirth connect and Orion's rhapsody, mainly).

Yes, this was back when the web was all crazy about XML as a data transfer format (redundancies and all). The goal of E4X was to make that data format easier to work with. JSON spelled the end of that.

JSX is more about XML as a development syntax, which makes more sense.

Anyone remember Yahoo Pipes? I wrote some flows at some point and used E4X. It was fun.

So far ahead of its' time.

I was at their launch at ETech in like 2005?

> So far ahead of its' time

Or, JSX is so backward, behind its time?

I remember using this in a Firefox addon. Always seemed like a nice thing, but sadly it never became widespread.

Note that this is rather old (2013).

I wonder what made JSX seem like a good idea then.

The post explains a bunch of things that JSX does better. A heck of a lot of successful ideas look just like something that was tried before but without the one restriction that made that thing fail.

Anyone that uses it ought to be able to explain that. I was sceptical when I first saw it but it really is very useful.

Don't know why this got downvoted. If a standard feature of JavaScript got no love because "XML sucks", then later becomes popular as part of a proprietary lib, this very much questions rationality and taste in JavaScript evolution.

Hahahaha so interesting, I posted it few days back on reddit :P and now it's here

Reply on news.ycombinator.com