[fleshweasel]

One of the biggest reasons I favor React is that it's much easier to add a templating language to a programming language (i.e. JSX) than the other way around. Every construct for making decisions based on your data, traversing your data, etc. is more cumbersome and harder to validate in handlebars or whatever identical looking templating language the community came up with this week.

I also am strongly against string references to model properties in your template. Again, it's much better to use tools that provide some static validation of what you're doing.

Give me React with TypeScript to help me make sure I'm passing around what I said I'm expecting to receive at each point as features are changed and added, and I'll be in business.

Honestly, I use React in spite of my opinion of Facebook.

[duncanawoods]

JSX frustrates me. When did we suddenly start thinking <> syntax was desirable again? When did the complexity of combining markup syntax and a programming language become a good idea? Why are we forcing this crazy complexity into every language and every IDE / code editor out there?

I much prefer react with standard functions e.g.

    var element = DOM.p({id : "thing"}, DOM.div(), DOM.div());

You can use an API like this in every language without any hacks. It doesn't hurt readability or productivity and it has normal expression evaluation semantics. JSX isn't syntactic sugar, its a gross "syntactic artificial flavour" because it doesn't make the syntax easier, it just makes it look something a bit like HTML but with dozens of subtle differences e.g. attribute names, attributes values, tag closing rules, special extensions etc.

[scrollaway]

Frankly, yes it does hurt readability. I used to have your mindset and you're making the assumption that what looks okay when creating one single element will look fine when nesting dozens (which react excels at).

JSX is well defined and does not support any of HTML's looseness. It's predictable. It makes the code easier to follow. And if you don't want to use it, you don't have to. I see no issue.

[peterhunt]

Many people find deeply nested tree structures hard to read when you need to mentally balance a bunch of parentheses. The inability for s-expression languages to gain significant traction with lay programmers is evidence of this.

[treehau5]

> When did the complexity of combining markup syntax and a programming language become a good idea?

When unobtrusive javascript became a thing.

> As an industry, we’ve already decided: HTML and JavaScript belong together.

https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...

[keymone]

having played with clojure i really fell in love with hiccup syntax:

    var element = hiccup [p {id: "thing"}
                          [div "first"]
                          [div "second"]]

https://github.com/lantiga/react.hiccup

[spyder]

I somewhat agree, but a little inconvenience comes when you have to insert HTML that you got from somebody else, like from a design template or an ad or analytics code. Sure you can convert it by hand or with an editor extension but then you are just doing the same as JSX, or you can insert it as a string but then it becomes inconsistent.

[hashkb]

Don't use it! I just use hyperscript and functions. Works great.

[dustingetz]

point of jsx is to make react more intuitive to non-programmers

[j_r_f]

I think you are being a bit overdramatic about JSX. There was zero learning curve -- except for a few errors initially when using class instead of className...

The argument that DOM.div() is more readable than <div/> is honestly hilarious to me. Any non-trivial tag structure will be unnecessarily complicated through the API. Especially when you can just write it almost exactly how it's going to look when it becomes HTML in JSX.

[steinuil]

Have you tried Elm? It is strongly typed and it uses function to represent html elements and attributes, which end up looking a lot like JSX.

[fleshweasel]

Haven't had the chance to try it myself but I have read quite a bit and I like what I see, particularly the high quality error messages in the compiler. However, I think I'd have a hard time getting my team on board with it as we use Visual Studio for the bulk of our development, and we would need to learn to work with the JavaScript interop APIs to do things like try Elm out for a single new feature on a page.

[Unbeliever69]

I've personally been impressed with learning Mithril over React. Surprisingly easy to learn for people coming from React and super fast. XHR and routing are included. You can use JSX but hyperscript (pure JS that has no compilation step) is favored for markup. Add in some Aphrodite for inline styling your components, Redux for state management and you have a pretty robust, blazing fast framework that is sufficient for many modern application without all the package bloat.

[jasim]

In support of this argument -

The HTML snippet embedded in `let titleView = "<h1>Hello</h1>"` can only be parsed as a string. This means no tooling support - no linting, no tags that autoclose, no code formatting. But if you have a distinct syntax for XML, the parser can clearly figure out what the strings are, and what the tags are.

First class support for XML is, after using JSX, just so obvious in hindsight if you're building anything to do with the web.

[Cyph0n]

Scala introduced first-class support for XML through a DSL a decade ago. I believe the feature has been phased out because it was useless. I've personally never found it useful either.

[Existenceblinks]

When a react component tree has more than 3 level height, react component's lifecycle callbacks start getting crazy unmanageable.

Mounting, unmounting, rendering, props receiving, updating etc, these callbacks' calling orders open to bad rendering practice(e.g. unnecessary render, unexpected calls), that's why people avoid putting logics in there. It claims to be self-contained but parent-child communication breaks it in several ways, I am not a big fan of HOC.

People claim the simple of "just a view layer" of react, I don't think so. I haven't tried vuejs, but it seems like it takes care of most rendering callbacks/component communication seamlessly.

[lojack]

> It claims to be self-contained but parent-child communication breaks it in several ways

I think you'll find that most react developers advise against doing parent-child communication in react components for all but the simplest cases. Does it involve writing higher order components? Probably. Curious, why aren't you a big fan of them?

[fleshweasel]

I know what you mean with regard to event handlers being passed down to children and children of children and so on and the complexity that can bring. I haven't used redux, but I understand it as being an attempt to simplify that kind of problem.

I haven't written any higher order components myself, unless you consider parameterizing event handlers in props to be higher order.

[k__]

This.

"Good view layer code means that templates should be as declarative as possible, NOT that the view layer as a whole should avoid procedural logic altogether." - https://lhorie.github.io/mithril-blog/getting-over-a-fear-of...

[neikos]

There is the choice of preact[1], that has a very similar api, is more lightweight and even has a compatibility layer for the few react packages that need it.

[1]: https://github.com/developit/preact

[savitur_it]

also in vue 2.0 you can use jsx e hyperscript

[chiefalchemist]

Why would you? React is a tool. The fact that FB doesn't use the tool correctly shouldn't reflect negatively on the tool. That "honor" goes to the product.

[rk06]

You do know that Vue support jsx. Just not react's jsx.