5 ms·
> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.
by lucasmullens 6y 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 6y agoBy 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 6y agoFor example Angular templates, stuff like Razor in .NET, etc?
- frank_nitti 6y agoPerhaps 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 6y agoThe 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 6y 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
- hajile 6y agoThat's just reductio ad absurdum claim. JSX is one simple conversion while coffeescript or elm are entire turing-complete languages. It's like claiming a smiley face on the back of a receipt is no different from the Mona Lisa.
- hombre_fatal 6y agoYeah, all of the dynamic parts of JSX are Just Javascript. You can also look at JSX and know exactly how it will compile to Javascript because it's so simple. (foo && <Component {...props} />) -> (foo && React.createElement(Component, props)). It really is just React.createElement calls. It just isn't a huge departure. Meanwhile, what Elm compiles to is very nontrivial. The comparison only makes sense if you never actually looked at what JSX does thus mistake it for something much more complex. Try it out yourself: https://babeljs.io/repl https://babeljs.io/repl
- lhorie 6y 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)