Note that this isn't mixing just any JS, it's only presentational javascript. Either you're using some templating language like Handlebars or Jinja/Django's or Angular's HTML attribute data binding, or lots-of-jquery-selectors-tied-directly-to-the-html, you still need some sort of view logic to build your DOM.
Don't get me wrong, I've never really used React/JSX in depth enough, and I'm not overly enthusiastic about all these 'HTML' tags in my JS. But lets not pretend this is any worse than the current approach of $('.modal').append(document.createElement('button'))
What I want is the wicket model, essentially a stricter version of Angular's HTML attribute data binding, where virtually the only thing you can do is <tag myframework:id="someid">, and you can connect to "someid" in code - but only as a literal, and the only thing you can do is replace that tag with a component, nothing more complex. All the current approaches are too liberal, too "there is more than one way to do it". I want to have one, and only one, simple rule for how data goes into HTML.
I reflexively dislike the notion, but am trying to consider it with an open mind. The notion that a subtree of the DOM and some JavaScript that manipulates it, designed together to create a single functional component, represent a single concern and should be packaged together, is not unreasonable.
I think it is very different than the spaghetti pages found in jsps and php pages of yore, and the emphasis on component is a big part of why.
I took the same route - instead of trying to keep HTML in one place, JS in another, CSS in another I made separate files for each component including all the necessary HTML, JS and CSS in one file. It makes more sense because I write them together and debug them together. Also, I don't need to find where are the CSS selectors in a huge monolithic CSS file, or the same about JS functions. I don't let a component become too complex, so the 1 file/component ratio is just right.
> The notion that a subtree of the DOM and some JavaScript that manipulates it, designed together to create a single functional component, represent a single concern and should be packaged together, is not unreasonable.
I think part of the problem is how you think about it. You're not writing some HTML and then some Javascript to manipulate it. Conceptually, you're writing a Javascript function to create a chunk of HTML.
From a developer standpoint, I always felt HTML and JS to be extremely tight together. So whether or not they're in different files, they were linked to each others. Now, with JSX, it just feel like a more powerful html without all the crapy extremely limited template language..
Maybe for a static website, it doesn't feel right. But for a webapp it feels much better than before for me.
I hated it (a lot) before I tried it out. You could just put the render function in a separate file since it's just a function and then it's basically the same as a template anyway
JSX [1] is essentially a syntax fix for something people have been doing for a long time in JavaScript with DOM building libraries.
Having extensively used nested function call (like MochiKit.DOM [2]) and nested JSON-ML-ish array (like dombuilder [3]) variants of DOM builders in the past, JSX's syntax is a lot more friendly to write and maintain.
I'm sure this similarity has been pointed out before, but I think JSX is tangible for many of the same reasons PHP templating was. It only makes sense that a company that operates predominately in PHP would pass the baton of markup interpolation to JS as the web becomes more client oriented.
I personally lean towards logic interpolation (Handlebars, AngularJS), but both have their potentials for abuse. I don't know enough about JSX to say one way or the other what good practices are enforced and what bad practices are available.
Trust me, I know Lisp. In Lisp, there's built-in templating via quasiquote, so we can easily construct HTML documents by first writing them as s-expressions.
JSX is a far cry from how Lisp does things. You get all of the nastiness of the redundant typing involved with hand-writing HTML mixed in with your JavaScript, plus the addition of another compilation step in your build!
I like Mithril's virtual DOM API[0] much more. It's really pleasing to use, but of course not as good as SXML in Lisp because JavaScript doesn't have macros or quasiquote.
But JS isn't lisp, and to manipulate it you have to turn it into an AST and traverse it with a lot of extra tooling. It's not as (easily) pliable as lisp.
You're in luck. ES6 introduces quasi-literals which are multi-line and will do exactly what you want. You can even tag them to set up parsing.
jsx`<div><p>${hello_world}</p></div>`
I don't know why it'd be a better option. You're moving the time/cost of parsing client side and preventing minification. If you're going to do a build time parse, I don't understand what the extra quoting buys you.
