Hacker News new | ask | show | jobs
by serichsen 3932 days ago
I see two problems with the basic idea of JSX:

- Parsing is a mess, it is not even obviously unambiguous.

- HTML syntax is horrible, and all templating language attempts building on it are verbose and clumsy.

That is the negative argument (“That is crap”), but there is also a positive argument (“Here is a much better alternative”):

You can express HTML structure in a concise and relatively readable manner in plain JavaScript, and you do not need a 400 kb interpreter nor a separate compilation step for it!

    ['div', {'class': 'foo'},
      'some text',
      ['span', {}, 'yay']]
You also can embed "directives" or "components" in a rather obvious and unambiguous way:

    ['div', {'class': 'container'},
      [MyConstructor, {'arg': foo()}]]
Implementing a robust interpreter for this is a matter of perhaps 50 to 100 lines of plain JavaScript.
2 comments

The big advantage of JSX to my company is that our design team, which does design in the browser, has a much shorter leap to understanding it than plain JavaScript. These suggestions of "JSX sucks, you can express this in plain JS" always leave people with those skill sets behind. Sure it would be really awesome if the designers were also serious JS programmers, but that's not why we hired them, and with JSX they don't need to be.
I honestly do not see how much effort would it take to get from <foo bar="baz">Quux</foo> syntax to ["foo", {bar: "baz"}, "Quux"] syntax. I believe someone already working with code (HTML, CSS) should be perfectly capable to learn this transformation in well under 15 minutes.
It's a matter of preference. I'd rather shoot myself than write HTML as JS objects like that. I've written countless lines of HTML in my life and don't see any reason to start thinking or writing HTML in the form of JS.