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.
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. :-/
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.
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.
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.
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.
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?
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!
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.
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.
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).
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.
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
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.
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.
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.
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.
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.
