3 ms·

"If you're going to hate on React for some reason, make it something other than JSX" But what if I hate JSX? It's such a tight coupling to the DOM which is jus

"If you're going to hate on React for some reason, make it something other than JSX" But what if I hate JSX? It's such a tight coupling to the DOM which is just the opposite direction I want to go where the DOM doesn't even matter. But that's just my opinion I haven't done enough research or investigation to try and prove one over the other.

sehr 12y ago
From a couple slides later: Given the extremely tight coupling between the template and it's context (a controller/component), the concerns are the same, and splitting the DOM into a template is an arbitrary separation of technologies rather than a legit separation of concerns
- BinaryIdiot 12y ago
  I get that but disagree with it. I don't see it as an arbitrary separation but a necessary one based on separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events. Honestly I try to use messaging where possible for these types of things. The last app I wrote should, theoretically, be able to be moved from an HTML app to a node-qt app only by swapping the views. But like I said I haven't had a ton of experience with either so I can't make any good, factual points here only my personal preferences and anecdotes.
  - machty 12y ago
    If the rule is a) designers only touch .html/.hbs files and b) only developers touch the view/controller .js files, then if either of them change a property name from `{{displayName}}` to `{{display_name}}`, the whole thing breaks, which is the coupling React is trying to avoid by keeping these similar concerns within the same technology/file (JavaScript).
  - deleted 12y ago
    [deleted]
  - dustingetz 12y ago
    "(which a team of designers can freely modify without worrying about breaking anything or even touching the logic)" wut edit: JSX accomplishes this goal handily, no other tech i have ever used comes anywhere close to JSX, and I have used nearly all of them. (I'm the engineer who manages the designer and integrates his changes. Interactions with the designer are like, "Go to line 37 of XJZ.js and make it look like foo." In JSX, there usually isn't any integration to do as he can commit directly. Which is why JSX rocks.)
    - BinaryIdiot 12y ago
      Never worked with web designers? Typically folks who are great with design and doing some styling and markup? We have some really awesome folks with the current company I'm with so they frequently work with the developers to make their shit sexy. Edit: to address your edit that seems overly complicated to me. Most of the web designers (or designers in general) don't know a lot of JavaScript; asking them to make structural changes inside of JavaScript worries me a little. I'd much rather them change the view in its natural state: html and css. JSX isn't that.
      - mikewhy 12y ago
        so instead of pointing your designers to a .html file, you point them to a .jsx file? not seeing the issue. also: var MyComponent = Reate.createClass({ render: function () { return require('./template-designers-are-not-scared-to-touch').apply(this); } }); but this is a silly separation
  - rakoo 12y ago
    > separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events Where does the designer's job stop ? Does he not handle animation ? Should he be in charge of CSS too, because that's how you do basic animations ? Why shouldn't he be in charge of slightly heavier animations, just because they're in javascript ? The point of the authors (which I agree with) is that the whole notion of "view == template" is wrong, and thus "view == html+css files" is wrong. A view is the thing the user interacts with: a button, a list of items, a search bar. All these components should be handled as a whole, and should be handled independently from one another. If a component doesn't need any javascript for it's logic, fine; if another component needs some javascript for whatever reason it's nonsensical to separate this javascript. A design doesn't always stop purely at static appearance. The fundamental unit is the object you're working on, not the technology you're using.
machty 12y ago
Because it's such a thin layer over JavaScript, you don't have to port/reimplment all the stuff that JavaScript has already solved to your templating language / abstraction of choice. I still prefer Handlebars, but JSX elegantly sidesteps lots of issues at the expense of not actually being real HTML and handling flow control stuff somewhat awkwardly, but you really gotta try it out to get a feel for the tradeoffs.
skrebbel 12y ago
Then you didn't understand what JSX is. JSX is just optional syntactical sugar for declaring (virtual) DOM elements. You can use all of React with JSX and your code will be only slightly more verbose. Your objection is to the very tight coupling of the DOM to React's component abstraction. That's a very valid objection, but unrelated to JSX.
- BinaryIdiot 12y ago
  Okay fair but I still dislike the JSX syntax :)
rakoo 12y ago
Don't use it. JSX is a syntactic sugar for you to manipulate HTML-like stuff, but it's all javascript in the end. It's completely optional.
- mrcwinn 12y ago
  JSX is optional, but I've come to really enjoy it. Here's why: 1. Right next to the logic of how a component is meant to function is the markup it will ultimately render with (or something pretty close to it). 2. I still avoid, for the most part, "magic attributes" like in Ember and especially Angular. It's not perfect, but it is optional. If you're fine transforming CoffeeScript (a bad example - I can't stand CoffeeScript:) then find an inner peace seeing some XML in your JS documents.
  - mikewhy 12y ago
    On the subject of CoffeeScript and React/JSX, our team uses something like this[1] to reduce the need for `React.DOM[...]` or lots of `requires` to components. Our components end up looking like this. As a CoffeeScript/Jade fan, I obviously like it: ReactElementBuilder = require './lib/react-element-builder' # Example: add react-bootstrap components. ReactElementBuilder.addMany require('react-bootstrap') MyComponent = React.createClass mixins: [ReactElementBuilder.mixin] render: -> @e 'div#main', null, @e 'Navbar.fixed', onClick: @handleNavbarClick 'Hello my name is Navbar' [1]: https://gist.github.com/mikew/e737273e42ed704c6c54 https://gist.github.com/mikew/e737273e42ed704c6c54
k__ 12y ago
"It's such a tight coupling to the DOM which is just the opposite direction I want to go" That's what I liked about ExtJS4. They had their own "virtual" component model, which then was rendered as DOM later. But the DOM could change in different versions, because of performance reasons. There was/is probably much wrong with ExtJS, but I liked this approach.
wycats 12y ago
I slightly disagree with @machty. I agree that most of the reasons people give for hating on JSX are somewhat off the mark. HOWEVER: the fact that JSX is XML and not HTML syntax is a real issue. `<label for="foo">` doesn't work; you have to know that it's `<label htmlFor="foo">`. Same with `class` and `className` and multi-word (`maxwidth` vs. `maxWidth`). Early on, before React had fully made the decision to stick with raw property names, they understood the value of making JSX "just HTML" (see @petehunt at https://github.com/facebook/react/pull/269#issuecomment-22912842 https://github.com/facebook/react/pull/269#issuecomment-2291..., for example). The decision that they made is totally reasonable, but having to learn an XML dialect of HTML (not XHTML, but a dialect that uses property names for attributes, and disallows normal attribute usage) is not free. That said, I'm sure it's something you get used to quickly, and isn't something that slows you down much once you understand it.
- lobster_johnson 12y ago
  It's not even XML — it's JavaScript. The problems with for/class/etc. problems aren't because of XML, but exist because the preprocessor just translates everything to React.DOM element declarations, and of course "class" et al are reserved words in JS. I agree that's it super awkward. I have no idea why they don't let the preprocessor be HTML-aware and translates class into className directly. I can't see how something like "class" would clash with the surrounding JS syntax given that it's specific to the local tag syntax. <Foo> isn't valid JS, after all, so why should "class" not be valid JSX? It creates a maintenance problem, too, because React has to play catch up with every HTML tag and attribute and every CSS property.
hcarvalhoalves 12y ago
> But what if I hate JSX? It's such a tight coupling to the DOM It has nothing to do with DOM in principle. It's just a convenient XML-like declarative syntax to describe a component tree. Think XUL [1] or Gtk+ Glade [2]. The <a>, <p>, etc. are components on the React.DOM namespace that output DOM nodes of the same name. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Creating_a_Window https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu... [2] https://glade.gnome.org/ https://glade.gnome.org/
kansface 12y ago
Every thread on React has your comment- JSX sucks or it looks like PHP (which sucks). Half of the thread is then devoted to refuting the comment. At the end everyone's opinion has calcified. I would highly encourage you to try it before you dismiss it.

sehr 12y ago

From a couple slides later: Given the extremely tight coupling between the template and it's context (a controller/component), the concerns are the same, and splitting the DOM into a template is an arbitrary separation of technologies rather than a legit separation of concerns

BinaryIdiot 12y ago
I get that but disagree with it. I don't see it as an arbitrary separation but a necessary one based on separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events. Honestly I try to use messaging where possible for these types of things. The last app I wrote should, theoretically, be able to be moved from an HTML app to a node-qt app only by swapping the views. But like I said I haven't had a ton of experience with either so I can't make any good, factual points here only my personal preferences and anecdotes.
- machty 12y ago
  If the rule is a) designers only touch .html/.hbs files and b) only developers touch the view/controller .js files, then if either of them change a property name from `{{displayName}}` to `{{display_name}}`, the whole thing breaks, which is the coupling React is trying to avoid by keeping these similar concerns within the same technology/file (JavaScript).
- deleted 12y ago
  [deleted]
- dustingetz 12y ago
  "(which a team of designers can freely modify without worrying about breaking anything or even touching the logic)" wut edit: JSX accomplishes this goal handily, no other tech i have ever used comes anywhere close to JSX, and I have used nearly all of them. (I'm the engineer who manages the designer and integrates his changes. Interactions with the designer are like, "Go to line 37 of XJZ.js and make it look like foo." In JSX, there usually isn't any integration to do as he can commit directly. Which is why JSX rocks.)
  - BinaryIdiot 12y ago
    Never worked with web designers? Typically folks who are great with design and doing some styling and markup? We have some really awesome folks with the current company I'm with so they frequently work with the developers to make their shit sexy. Edit: to address your edit that seems overly complicated to me. Most of the web designers (or designers in general) don't know a lot of JavaScript; asking them to make structural changes inside of JavaScript worries me a little. I'd much rather them change the view in its natural state: html and css. JSX isn't that.
    - mikewhy 12y ago
      so instead of pointing your designers to a .html file, you point them to a .jsx file? not seeing the issue. also: var MyComponent = Reate.createClass({ render: function () { return require('./template-designers-are-not-scared-to-touch').apply(this); } }); but this is a silly separation
- rakoo 12y ago
  > separating the view (which a team of designers can freely modify without worrying about breaking anything or even touching the logic) from any logic that can handle events Where does the designer's job stop ? Does he not handle animation ? Should he be in charge of CSS too, because that's how you do basic animations ? Why shouldn't he be in charge of slightly heavier animations, just because they're in javascript ? The point of the authors (which I agree with) is that the whole notion of "view == template" is wrong, and thus "view == html+css files" is wrong. A view is the thing the user interacts with: a button, a list of items, a search bar. All these components should be handled as a whole, and should be handled independently from one another. If a component doesn't need any javascript for it's logic, fine; if another component needs some javascript for whatever reason it's nonsensical to separate this javascript. A design doesn't always stop purely at static appearance. The fundamental unit is the object you're working on, not the technology you're using.

machty 12y ago

Because it's such a thin layer over JavaScript, you don't have to port/reimplment all the stuff that JavaScript has already solved to your templating language / abstraction of choice. I still prefer Handlebars, but JSX elegantly sidesteps lots of issues at the expense of not actually being real HTML and handling flow control stuff somewhat awkwardly, but you really gotta try it out to get a feel for the tradeoffs.

skrebbel 12y ago

Then you didn't understand what JSX is. JSX is just optional syntactical sugar for declaring (virtual) DOM elements. You can use all of React with JSX and your code will be only slightly more verbose. Your objection is to the very tight coupling of the DOM to React's component abstraction. That's a very valid objection, but unrelated to JSX.

BinaryIdiot 12y ago
Okay fair but I still dislike the JSX syntax :)

rakoo 12y ago

Don't use it. JSX is a syntactic sugar for you to manipulate HTML-like stuff, but it's all javascript in the end. It's completely optional.

mrcwinn 12y ago
JSX is optional, but I've come to really enjoy it. Here's why: 1. Right next to the logic of how a component is meant to function is the markup it will ultimately render with (or something pretty close to it). 2. I still avoid, for the most part, "magic attributes" like in Ember and especially Angular. It's not perfect, but it is optional. If you're fine transforming CoffeeScript (a bad example - I can't stand CoffeeScript:) then find an inner peace seeing some XML in your JS documents.
- mikewhy 12y ago
  On the subject of CoffeeScript and React/JSX, our team uses something like this[1] to reduce the need for `React.DOM[...]` or lots of `requires` to components. Our components end up looking like this. As a CoffeeScript/Jade fan, I obviously like it: ReactElementBuilder = require './lib/react-element-builder' # Example: add react-bootstrap components. ReactElementBuilder.addMany require('react-bootstrap') MyComponent = React.createClass mixins: [ReactElementBuilder.mixin] render: -> @e 'div#main', null, @e 'Navbar.fixed', onClick: @handleNavbarClick 'Hello my name is Navbar' [1]: https://gist.github.com/mikew/e737273e42ed704c6c54 https://gist.github.com/mikew/e737273e42ed704c6c54

k__ 12y ago

"It's such a tight coupling to the DOM which is just the opposite direction I want to go" That's what I liked about ExtJS4. They had their own "virtual" component model, which then was rendered as DOM later. But the DOM could change in different versions, because of performance reasons. There was/is probably much wrong with ExtJS, but I liked this approach.

wycats 12y ago

I slightly disagree with @machty. I agree that most of the reasons people give for hating on JSX are somewhat off the mark. HOWEVER: the fact that JSX is XML and not HTML syntax is a real issue. `<label for="foo">` doesn't work; you have to know that it's `<label htmlFor="foo">`. Same with `class` and `className` and multi-word (`maxwidth` vs. `maxWidth`). Early on, before React had fully made the decision to stick with raw property names, they understood the value of making JSX "just HTML" (see @petehunt at https://github.com/facebook/react/pull/269#issuecomment-22912842 https://github.com/facebook/react/pull/269#issuecomment-2291..., for example). The decision that they made is totally reasonable, but having to learn an XML dialect of HTML (not XHTML, but a dialect that uses property names for attributes, and disallows normal attribute usage) is not free. That said, I'm sure it's something you get used to quickly, and isn't something that slows you down much once you understand it.

lobster_johnson 12y ago
It's not even XML — it's JavaScript. The problems with for/class/etc. problems aren't because of XML, but exist because the preprocessor just translates everything to React.DOM element declarations, and of course "class" et al are reserved words in JS. I agree that's it super awkward. I have no idea why they don't let the preprocessor be HTML-aware and translates class into className directly. I can't see how something like "class" would clash with the surrounding JS syntax given that it's specific to the local tag syntax. <Foo> isn't valid JS, after all, so why should "class" not be valid JSX? It creates a maintenance problem, too, because React has to play catch up with every HTML tag and attribute and every CSS property.

hcarvalhoalves 12y ago

> But what if I hate JSX? It's such a tight coupling to the DOM It has nothing to do with DOM in principle. It's just a convenient XML-like declarative syntax to describe a component tree. Think XUL [1] or Gtk+ Glade [2]. The <a>, <p>, etc. are components on the React.DOM namespace that output DOM nodes of the same name. [1] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Creating_a_Window https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tu... [2] https://glade.gnome.org/ https://glade.gnome.org/

kansface 12y ago

Every thread on React has your comment- JSX sucks or it looks like PHP (which sucks). Half of the thread is then devoted to refuting the comment. At the end everyone's opinion has calcified. I would highly encourage you to try it before you dismiss it.