8 ms·

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. E

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.

neikos 10y ago
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 https://github.com/developit/preact
duncanawoods 10y ago
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 10y ago
  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.
  - duncanawoods 10y ago
    > will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle brackets, end tags and escaping expressions with {}, it can actually be more verbose.
    - hacker_9 10y ago
      I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.
      - duncanawoods 10y ago
        I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs. > I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case JSX is literally an extra level of abstraction. You are not writing html but calling a function to create a data structure element and JSX totally obfuscates that. I pity poor programming newbies trying to understand what JSX is actually doing "so you are telling me <div> is a function...but?". In the functional form its just your normal language, nothing is disguised, everyone can see what it is doing and no post-processing magic is required e.g. public class DOM { public static IElement div(object attributes, params IElement[] children) { return new Element(...); } }
- dustingetz 10y ago
  point of jsx is to make react more intuitive to non-programmers
  - falcolas 10y ago
    If JSX is embedded in a codebase, what is the value of that? Let me clarify a bit. What is the value in creating a limited tool optimized for neophytes that will be used extensively by experienced professionals, who would be better served by flexibility?
    - dustingetz 10y ago
      I had a lot of success back in 2013/14 by having our outsourced graphic designer directly modify JSX files in our codebase. He picked up just enough javascript to figure it out. I just told him where the file was or set up a test harness and he delivered pull requests against our actual codebase.
- spyder 10y ago
  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 10y ago
  Don't use it! I just use hyperscript and functions. Works great.
- j_r_f 10y ago
  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.
  - lhorie 10y ago
    DOM.div() vs <div/> seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain of ternaries that's where angled bracket syntax starts to become unwieldy. The className thing is a big deal too, in my opinion. Preact and Mithril do what you would expect, and perf doesn't suffer, so why can't React/JSX normalize it as well?
    - Bahamut 10y ago
      className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.
      - jmtulloss 10y ago
        It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
        rmetzler 10y ago
        And the reason why the DOM API uses className is: class is a reserved keyword in JavaScript for a long time.
      - 10y ago
- treehau5 10y ago
  > 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-the-coin-2ace7ab62b98#.bk65yunbp https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...
- keymone 10y ago
  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 https://github.com/lantiga/react.hiccup
  - mullsork 10y ago
    Yeah hiccup syntax is my favorite as well. JSX is mentally the same thing for me except I read "HTML" faster than data structures if that makes sense. I wonder if Hiccup was the first one to introduce this syntax? I never bothered to check but I always thought the JSX inventors might have been inspired by it.
- peterhunt 10y ago
  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.
  - reddit_clone 10y ago
    People who use Lispy languages do _not_ balance parenthesis mentally. In fact they completely ignore parenthesis and go only by indentation. Parenthesis disappear when you are at certain level of proficiency.
    - peterhunt 10y ago
      Yep, but most people don't get to that level of proficiency.
Existenceblinks 10y ago
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 10y ago
  > 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?
  - Existenceblinks 10y ago
    Higher order components to me is a hacky technique and mostly seen as a monkey patch to the limitation of lower component. A concrete example is responsive table components with the help of HOC, says `react-dimensions` (sorry author, I have to mention here but there is nothing specifically wrong with it), why do I need it as a separate component? Oh flexibility and reusability but when I tried wrapping 2 or 3 table libraries with it, it sucks at rendering on desktop, even worse on mobile! I gave up on performance issue. Ah that doesn't mean the HOC technique itself is bad, but from my experience it is.
- fleshweasel 10y ago
  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.
savitur_it 10y ago
also in vue 2.0 you can use jsx e hyperscript
steinuil 10y ago
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 10y ago
  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.
k__ 10y ago
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-turing-complete-templates.html https://lhorie.github.io/mithril-blog/getting-over-a-fear-of...
Unbeliever69 10y ago
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.
rk06 10y ago
You do know that Vue support jsx. Just not react's jsx.
jasim 10y ago
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 10y ago
  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.
chiefalchemist 10y ago
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.

neikos 10y ago

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 https://github.com/developit/preact

duncanawoods 10y ago

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 10y ago
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.
- duncanawoods 10y ago
  > will look fine when nesting dozens Nesting dozens of items is fine. That single line was more of an HN comment format limitation. This might be a better judge of readability: C# http://imgur.com/a/nVWdC http://imgur.com/a/nVWdC JSX http://imgur.com/a/qwAfD http://imgur.com/a/qwAfD You may prefer one or the other but most would admit they are pretty similar its just that the former hasn't needed an entire new language inlined into it. Given JSX has all its angle brackets, end tags and escaping expressions with {}, it can actually be more verbose.
  - hacker_9 10y ago
    I'm a C# guy and even I would say the JSX is far more readable there. I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case.
    - duncanawoods 10y ago
      I don't mind if people prefer JSX its just a shocking cost - rewriting language ASTs, build tools and IDEs for something that rhymes with html but is really only a couple of characters away from standard language constructs. > I'm sure there's a law somewhere that says the less abstraction the better, that can be applied in this case JSX is literally an extra level of abstraction. You are not writing html but calling a function to create a data structure element and JSX totally obfuscates that. I pity poor programming newbies trying to understand what JSX is actually doing "so you are telling me <div> is a function...but?". In the functional form its just your normal language, nothing is disguised, everyone can see what it is doing and no post-processing magic is required e.g. public class DOM { public static IElement div(object attributes, params IElement[] children) { return new Element(...); } }
dustingetz 10y ago
point of jsx is to make react more intuitive to non-programmers
- falcolas 10y ago
  If JSX is embedded in a codebase, what is the value of that? Let me clarify a bit. What is the value in creating a limited tool optimized for neophytes that will be used extensively by experienced professionals, who would be better served by flexibility?
  - dustingetz 10y ago
    I had a lot of success back in 2013/14 by having our outsourced graphic designer directly modify JSX files in our codebase. He picked up just enough javascript to figure it out. I just told him where the file was or set up a test harness and he delivered pull requests against our actual codebase.
spyder 10y ago
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 10y ago
Don't use it! I just use hyperscript and functions. Works great.
j_r_f 10y ago
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.
- lhorie 10y ago
  DOM.div() vs <div/> seems like a bad example. IMHO, when you get an element with tons of event handlers and conditional classes, or when you have a deep chain of ternaries that's where angled bracket syntax starts to become unwieldy. The className thing is a big deal too, in my opinion. Preact and Mithril do what you would expect, and perf doesn't suffer, so why can't React/JSX normalize it as well?
  - Bahamut 10y ago
    className was named that to avoid conflict with the JS class syntax originally I believe, since JSX is inline - they probably could put in the work to change it at this point, but it seems like a minimally beneficial change but massively disruptive at this point.
    - jmtulloss 10y ago
      It was named that to match the DOM api[0], which React does whenever possible. The DOM api is probably named for the reason you state. [0]: https://developer.mozilla.org/en-US/docs/Web/API/Element/className https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
      - rmetzler 10y ago
        And the reason why the DOM API uses className is: class is a reserved keyword in JavaScript for a long time.
    - 10y ago
treehau5 10y ago
> 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-the-coin-2ace7ab62b98#.bk65yunbp https://medium.com/@housecor/react-s-jsx-the-other-side-of-t...
keymone 10y ago
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 https://github.com/lantiga/react.hiccup
- mullsork 10y ago
  Yeah hiccup syntax is my favorite as well. JSX is mentally the same thing for me except I read "HTML" faster than data structures if that makes sense. I wonder if Hiccup was the first one to introduce this syntax? I never bothered to check but I always thought the JSX inventors might have been inspired by it.
peterhunt 10y ago
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.
- reddit_clone 10y ago
  People who use Lispy languages do _not_ balance parenthesis mentally. In fact they completely ignore parenthesis and go only by indentation. Parenthesis disappear when you are at certain level of proficiency.
  - peterhunt 10y ago
    Yep, but most people don't get to that level of proficiency.

Existenceblinks 10y ago

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 10y ago
> 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?
- Existenceblinks 10y ago
  Higher order components to me is a hacky technique and mostly seen as a monkey patch to the limitation of lower component. A concrete example is responsive table components with the help of HOC, says `react-dimensions` (sorry author, I have to mention here but there is nothing specifically wrong with it), why do I need it as a separate component? Oh flexibility and reusability but when I tried wrapping 2 or 3 table libraries with it, it sucks at rendering on desktop, even worse on mobile! I gave up on performance issue. Ah that doesn't mean the HOC technique itself is bad, but from my experience it is.
fleshweasel 10y ago
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.

savitur_it 10y ago

also in vue 2.0 you can use jsx e hyperscript

steinuil 10y ago

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 10y ago
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.

k__ 10y ago

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-turing-complete-templates.html https://lhorie.github.io/mithril-blog/getting-over-a-fear-of...

Unbeliever69 10y ago

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.

rk06 10y ago

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

jasim 10y ago

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 10y ago
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.

chiefalchemist 10y ago

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.