7 ms·

JSX frustrates me. When did we suddenly start thinking <> syntax was desirable again? When did the complexity of combining markup syntax and a programming langu

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(...); } }
      - hacker_9 10y ago
        I agree that I wouldn't change your current tooling, as the cost isn't worth it. JSX isn't that great. But even though it turns that HTML into function calls, there is still an expectation of how it will work: i.e. those functions will still produce the specified html. At the end of the day, writing a layout in html is so much more intuitive than using function calls. Makes me think of how MS introduced the XAML language when they created WPF, making it far nicer to build UIs out of code than in winforms.
      - mattmanser 10y ago
        In my experience, using a programming syntax for markup actually turns into a PITA. My only experience is HTML + Silverlight, but in both instances doing it in markup over code is almost always easier/quicker/simpler to read/less TLOC.
      - 10y ago
  - dchest 10y ago
    (The JSX one returns undefined)
  - justinlaster 10y ago
    I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.
    - sb8244 10y ago
      I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}
      - justinlaster 10y ago
        You could, but it's unintuitive (in my opinion) to do so -- which was the parent's comment larger point. You're not doing anything different, and to an extent the latter is actually lying about what's going on (you're not writing HTML). I also lose a certain level of tooling by doing it the JSX way. Why try to mask what you're doing? Why make it harder for your tools to help you out?
        sb8244 10y ago
        I guess I haven't felt this pain that you've felt. I'm satisfied with my tooling and feel that small components help keep things very clear and focused.
  - vog 10y ago
    > That single line was more of an HN comment format limitation. What limitation are you talking about? var element = DOM.p( {id : "thing"}, DOM.div(), DOM.div() );
- hinkley 10y ago
  The time I spent fixing logic and layout bugs on several build-a-dom projects has taught me this. For the same reason using CSS Selectors to crawl the DOM is superior. When it doesn't work, how hard is it to spot the bug? If you're working on the front end you need to look things up roughly the same way for style and behavior, and emit them roughly the way the browser will see them when it's time to look them up. And yet I'm still in the anti JSX camp. I think it has something to do the gear switching that comes with opening up the mixing of data and logic but I can't articulate it farther than that, Your brain can only juggle a handful of bits of data at a time. If you see someone doing something that looks like this doesn't apply to them, it's most likely because they've memorized the code. And to memorize code, that means it can't change much or very often. Which makes them dangerous. They have a bias toward maintaining the status quo, no matter how awful it is. Don't be that person.
- deleted 10y ago
  [deleted]
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.

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(...); } }
    - hacker_9 10y ago
      I agree that I wouldn't change your current tooling, as the cost isn't worth it. JSX isn't that great. But even though it turns that HTML into function calls, there is still an expectation of how it will work: i.e. those functions will still produce the specified html. At the end of the day, writing a layout in html is so much more intuitive than using function calls. Makes me think of how MS introduced the XAML language when they created WPF, making it far nicer to build UIs out of code than in winforms.
    - mattmanser 10y ago
      In my experience, using a programming syntax for markup actually turns into a PITA. My only experience is HTML + Silverlight, but in both instances doing it in markup over code is almost always easier/quicker/simpler to read/less TLOC.
    - 10y ago
- dchest 10y ago
  (The JSX one returns undefined)
- justinlaster 10y ago
  I will never understand why people think JSX style processing is a good idea. It's hiding what's actually happening, at no benefit (or very little benefit). At least with the former (C#) I can neatly build things up, reuse those components, instead of passing some monstrosity around.
  - sb8244 10y ago
    I don't understand this. You could build up the template using jsx exactly like you could otherwise. For instance, I could put that in a variable and then use it in another template via {}
    - justinlaster 10y ago
      You could, but it's unintuitive (in my opinion) to do so -- which was the parent's comment larger point. You're not doing anything different, and to an extent the latter is actually lying about what's going on (you're not writing HTML). I also lose a certain level of tooling by doing it the JSX way. Why try to mask what you're doing? Why make it harder for your tools to help you out?
      - sb8244 10y ago
        I guess I haven't felt this pain that you've felt. I'm satisfied with my tooling and feel that small components help keep things very clear and focused.
- vog 10y ago
  > That single line was more of an HN comment format limitation. What limitation are you talking about? var element = DOM.p( {id : "thing"}, DOM.div(), DOM.div() );
hinkley 10y ago
The time I spent fixing logic and layout bugs on several build-a-dom projects has taught me this. For the same reason using CSS Selectors to crawl the DOM is superior. When it doesn't work, how hard is it to spot the bug? If you're working on the front end you need to look things up roughly the same way for style and behavior, and emit them roughly the way the browser will see them when it's time to look them up. And yet I'm still in the anti JSX camp. I think it has something to do the gear switching that comes with opening up the mixing of data and logic but I can't articulate it farther than that, Your brain can only juggle a handful of bits of data at a time. If you see someone doing something that looks like this doesn't apply to them, it's most likely because they've memorized the code. And to memorize code, that means it can't change much or very often. Which makes them dangerous. They have a bias toward maintaining the status quo, no matter how awful it is. Don't be that person.
deleted 10y ago
[deleted]

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.