|
Well, now. Firstly: context switching is an inevitable inconvenience, but in JSX you're context-switching line by line between two radically different syntaxes. Secondly: switching into what? It's not HTML (Angular templates, for instance, are not going to win any beauty contests, but they are technically valid HTML). XML? No, not that either. So ... something that looks kinda like HTML/XML, but which isn't really. It's perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards. But if you're not going to adhere to that, then why pick something that is merely similarly ugly? I don't get it. Thirdly: templating/view layers always face a trade-off - either they are embedded within the host language, or they use an external DSL which is parsed/compiled by the host language. The trade-off is: better change of 'correctness' and cleaner interop with the rest of the language if it's an internal DSL; on the other hand, with eternal DSLs, at least the possibility that non-engineers will be able to work on things. With JSX, you end up grafting an 'internal' DSL simply by adding a whole pile of syntax to the core language. You don't have the advantages of the separate template language, and you lose some of the advantages of the other by requiring a whole pile of extra tools. JSX is an attempt not to choose, in a situation where compromise is basically impossible. Hence its extreme awkwardness - just like E4X before it. React has done some good things: it's put performance on everyone's agenda in a big way (Hallelujah!), and it has acted as a testbed for interesting front-end architectures. JSX, however, I feel is a serious mistake. I actually enjoy writing React code through Reagent or similar, but in native JS and especially JSX, it just feels awful. I just don't want that in my editor window. |
React goes out of its way to make it look like you're working with the real DOM, but in a different way. Take the event system for example: https://facebook.github.io/react/docs/events.html
In that sense its even closer to the standards than Angular is - it still uses events instead of databinding.
> the possibility that non-engineers will be able to work on things
Its highly suspicious that it was ever possible because of tight coupling between template and its data. Just look at an Angular controller and view. Tell me that two different people can work on that in parallel, one on the JS part, the other on the HTML part. Its impossible.
At best you can have a designer work on the HTML part first, then a programmer can import it (a fancy word for copy paste + add all the dynamic behaviour), then perhaps the designer can do incremental design-related fixes but might need to consult the programmer regarding the data. The programmer can also do HTML fixes but might need to consult the designer regarding how they would look.
Lets see if that workflow works with JSX:
If the designer really can't handle the surrounding JS, (although given what you are saying it sounds more like the programmer cannot handle the sprinkled HTML), you can move the render function in a separate file: Problem solved.Anyways, this is just staying inside the box with old aesthetic sensibilities developed from a bygone dark ages era. React is a peek at what HTML and JS could be, if only they actually worked together. Its also a snide remark * implying: "Hey WWW, you're doing a crappy job at supporting web applications. Let me show you how its done"
* not saying its intentionally snide, just that it might come off that way