7 ms·

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides

by untog 7y ago

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

stevebmark 7y ago
My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.
- wwright 7y ago
  Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).
lucasmullens 7y ago
> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.
- frank_nitti 7y ago
  By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.
  - TomMarius 7y ago
    For example Angular templates, stuff like Razor in .NET, etc?
    - frank_nitti 7y ago
      Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup. If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations. From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.
      - TomMarius 7y ago
        The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way. Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical. P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.
      - nickcox 7y ago
        > From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application I don't think that's true at all. I find react-hyperscript[0] and friends terser, more regular and just as easy to work with as JSX. [0] https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript
- lhorie 7y ago
  "just convert" is in itself a huge departure from plain Javascript (in the sense that you now need a whole transpiler to get anything running at all, vs just running the source code as is)
TomMarius 7y ago
The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.
sibeliuss 7y ago
<Foo bar="baz"/> = Foo({ bar: "baz" })
- kansface 7y ago
  <Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })
  - lhorie 7y ago
    Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)
  - JMTQp8lwXL 7y ago
    I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
    - kansface 7y ago
      I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
    - kls 7y ago
      The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.
greatwhitenorth 7y ago
JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.
- untog 7y ago
  It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.
  - greatwhitenorth 7y ago
    None of that matters to a React developer. If you know JavaScript, you know JSX.
    - untog 7y ago
      I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important. (also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)
      - greatwhitenorth 7y ago
        We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.
        untog 7y ago
        > We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?

by untog 7y ago

stevebmark 7y ago

My mental model of JSX is that it's vanilla Javascript, and it's helped me appreciate trying to write more expressions and less statements. Like JSX isn't getting transformed into some weird different control flow, it's just a nicer way to write the same expression. And DSLs are a good general computer science principle. Hooks don't seem quite as general of a concept to me as a really well thought out DSL that has a minimal surface area but still turns out to be super useful.

wwright 7y ago
Hooks are very similar to applicatives as you’d see them in Haskell, for what it’s worth (it’s where a lot of the rules of hooks come from). They also have some similarity to algebraic effects (as do sagas).

lucasmullens 7y ago

> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

frank_nitti 7y ago
By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.
- TomMarius 7y ago
  For example Angular templates, stuff like Razor in .NET, etc?
  - frank_nitti 7y ago
    Perhaps I have missed the point, then. I see the same magnitude of departure of Razor from pure C#, QML from pure Qt C++, and JSX from pure DOM JS. All of the above move the developer from procedural native code, to declarative markup. If the assertion is just that `var div = document.createElement('div')` is quite similar to `var div = React.createElement('div');` then of course I agree. In this sense, JSX+React is to DOM what XAML+WinForms is to win32. I had assumed we were discussing conceptual leap between native and framework-based UI implementations. From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application.
    - TomMarius 7y ago
      The point is that <Component prop={0} /> is equivalent to React.createElement(Component, {prop:0}, []) - it's a static, typed descriptor, and you imported the Component from somewhere because it's just another function/class. There is no such equivalence in magical templates of Angular or Razor - the JSX won't break as long as JavaScript can call functions, and will behave exactly in that way. Yes, it's a move to declarative code from procedural one, that's right; what's important for my distinction is how is the move done. The question we're answering with React (as opposed to Vue, Angular, Razor...) is not declarative/procedural, but magical/not magical. P.S. I heard that templates in Angular are not just templates anymore, they're converting them to function calls - I don't know the specifics, last Angular i saw was version 2.
    - nickcox 7y ago
      > From a UI standpoint, it would be virtually just as hard for a JSX dev to implement a React app with purely `React.createElement()` as it would be to just write a native DOM application I don't think that's true at all. I find react-hyperscript[0] and friends terser, more regular and just as easy to work with as JSX. [0] https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript
lhorie 7y ago
"just convert" is in itself a huge departure from plain Javascript (in the sense that you now need a whole transpiler to get anything running at all, vs just running the source code as is)

TomMarius 7y ago

The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.

sibeliuss 7y ago

<Foo bar="baz"/> = Foo({ bar: "baz" })

kansface 7y ago
<Foo bar="baz"/> = React.createElement(Foo, { bar: "baz" })
- lhorie 7y ago
  Technically, it depends on what babel plugin and configuration you use (e.g. it compiles to `h(Foo, {bar: "baz"})` for a preact setup and to completely different code w/ a Solid.js setup)
- JMTQp8lwXL 7y ago
  I don't understand how people claim this is hiding huge levels of complexity. It's trivial syntactic sugar. If stylistically, you don't like it, oppose it on those grounds. But complexity? It is syntactic sugar for a function call.
  - kansface 7y ago
    I agree with you - so much so that I don’t use source maps to debug stuff. It’s also the same reason I strongly dislike hooks (they aren’t really JS) while at the same time, they solve a problem I very rarely have (shared behavior without shared state).
  - kls 7y ago
    The opposition to it on fundamental grounds is born out of wrongheaded and misapplied best practices and quite frankly it needs to die. Dijkstra is credited with the idea of separations of concerns which is a valid application of code organizational management. The problem is, somewhere along the way (in the dawn of the web) we conflated separation of technology with separations of concerns. Thinking that separating technologies for technologies sake somehow made code more maintainable but the reality is, that it was dogma, if a snippet of JS, a snippet of CSS and a snippet of HTML will only ever be used as a black box component and only ever be reused as that black box component in total, separation of technology only leads to more complexity in interfile dependency and mental compos-ability of the whole solution in ones mind. There is an argument that separation of technology leads to simpler build management, but I personally will take a little more complexity in my build over complexity in the code base as usually a build becomes fairly static as a project matures.

greatwhitenorth 7y ago

JSX is 99% map/filter and boolean expressions. It's written between curly braces to be evaluated as a JavaScript expression. I don't understand how it's different from regular JavaScript.

untog 7y ago
It uses tag syntax, which regular JavaScript doesn’t at all. Browsers cannot parse it. These are meaningful differences.
- greatwhitenorth 7y ago
  None of that matters to a React developer. If you know JavaScript, you know JSX.
  - untog 7y ago
    I don't understand how that is relevant to the quote I was replying to: "React is great because it's vanilla Javascript". Vanilla Javascript works in a browser with zero transpiling. That's important. (also, "if you know JavaScript you know JSX" is objectively untrue! There are plenty of JS developers that don't work with JSX)
    - greatwhitenorth 7y ago
      We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.
      - untog 7y ago
        > We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?