3 ms·

Ah yes, the classic "I spent a couple weeks learning technology X, got confused and gave up, so therefore it's bad". What a lot of these articles miss is a good

Ah yes, the classic "I spent a couple weeks learning technology X, got confused and gave up, so therefore it's bad". What a lot of these articles miss is a good analysis of why. Generally if something is confusing, weird, or wrong, it's for a particular reason. Even if the reason is poor, it's important to know it before you bash. So here's some of the reasons: The whole v-if statement versus JSX is rather superficial imo. Personally I don't like awkward DSLs that depend on code inside a string, but that aside, did the author ever wonder why JSX uses &&? JSX is fundamentally a fancy syntax over function composition. What's nice about this is that it's a more general abstraction than what Vue offers. Vue has to give the user all these v-if, v-for, v-whatever directives, while React just gives two tools: function composition and brackets to return an expression. You could argue that this is more tedious, more code to write, whatever, but it also means that you don't have to depend on your library writers to add more directives. That being said, I understand the joys of syntactic sugar and I guess v-if is kind of nice. Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary. setState exists for a reason as well: state updates in React should be controlled and minimized when possible. I don't want my state in React to update like a normal JS object. In fact, I'd prefer if React moved to a ReasonReact style reducer format just to emphasize that state should be treated immutably. All the "code is smaller in Vue" is extremely subjective. I'd need better examples than v-if to judge that. Plus, terseness comes at a cost. I can write extremely terse, metaprogrammed Ruby or even worse, Perl. Chances are I won't understand it within a month. Finally, I see the author using the word "template" repeatedly. React is NOT templating. This is a very important point. Components are a far far more important abstraction than templating. Components can be wrappers that provide state, or a way of abstracting API calls, or a way to control routing. In the end, they're functions (or rather closures) that call other functions. Calling components "templates" betrays a fundamental misunderstanding of React's core principles.

BigJono 8y ago
> Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary. This is going to be a huge problem going forward since the React documentation team seems to have made it their mission to try and obfuscate the details of JS away from their readers rather than educate them. Which is a terrible decision.
- _hardwaregeek 8y ago
  Yeah this is a common problem when your library/framework/tool becomes too popular. Your users focus too much on learning the shiny tech and not the foundation. Rails faced a similar issue where people would come in without understanding Ruby and struggle with even the most simple tasks. Of course it didn't help that Rails also tried to hide many of the details of Ruby.
fro0116 8y ago
Well said. I'd wholeheartedly recommend anyone learning React to try manually converting a component written in JSX syntax into a bunch of React.createElement calls. The exercise itself is really easy and mechanical, but I find it very enlightening nontheless. What people coming from a templating background often consider as "quirks" of JSX (such as the limitations around conditional branching and why properties need to be camelCase rather than kebab-case) become painfully self-evident after seeing how the equivalent JSX code would look like in the plain JS React.createElement form. In fact, in my own projects I often prefer to import createElement, alias it as something short and use it directly to write rendering functions over using JSX because I find it removes a lot of the impedance mismatch involved with switching back and forth between JSX's psuedo html syntax and regular JS syntax in JSX expressions (and basically any other part of the codebase that's all written in JS). Plus, JSX syntax is actually generally _more_ verbose than the raw createElement calls when aliased due to things like requiring named closing tags for any component that takes children and needing to use `blah={blah}` over the `blah,` object property shorthand for passing through props. Though in team settings I still resort to begrudgingly writing JSX because people are more familiar with it, and I'd probably have to pick a fight with every new team member to get them onboard with the idea, and I'd rather spend that political capital on less superficial issues. I sometimes really wish the React folks never invented JSX, and just forced everyone to write createElement calls to begin with, then all of these points of confusion from people coming from templates could have been avoided (and we'd end up with only my preferred syntax as the one true way to write components, haha), but I do wonder if React would have taken off as it did if it didn't come with JSX to give people that sense of familiarity, even if it ends up causing much more undue confusion over the long term.

BigJono 8y ago

> Binding is a JS problem not a React problem. The fact that these are confused leaves me even less credence in the author. If the author learned about the mess that is JS scoping, they'd understand why binding is necessary. This is going to be a huge problem going forward since the React documentation team seems to have made it their mission to try and obfuscate the details of JS away from their readers rather than educate them. Which is a terrible decision.

_hardwaregeek 8y ago
Yeah this is a common problem when your library/framework/tool becomes too popular. Your users focus too much on learning the shiny tech and not the foundation. Rails faced a similar issue where people would come in without understanding Ruby and struggle with even the most simple tasks. Of course it didn't help that Rails also tried to hide many of the details of Ruby.

fro0116 8y ago

Well said. I'd wholeheartedly recommend anyone learning React to try manually converting a component written in JSX syntax into a bunch of React.createElement calls. The exercise itself is really easy and mechanical, but I find it very enlightening nontheless. What people coming from a templating background often consider as "quirks" of JSX (such as the limitations around conditional branching and why properties need to be camelCase rather than kebab-case) become painfully self-evident after seeing how the equivalent JSX code would look like in the plain JS React.createElement form. In fact, in my own projects I often prefer to import createElement, alias it as something short and use it directly to write rendering functions over using JSX because I find it removes a lot of the impedance mismatch involved with switching back and forth between JSX's psuedo html syntax and regular JS syntax in JSX expressions (and basically any other part of the codebase that's all written in JS). Plus, JSX syntax is actually generally _more_ verbose than the raw createElement calls when aliased due to things like requiring named closing tags for any component that takes children and needing to use `blah={blah}` over the `blah,` object property shorthand for passing through props. Though in team settings I still resort to begrudgingly writing JSX because people are more familiar with it, and I'd probably have to pick a fight with every new team member to get them onboard with the idea, and I'd rather spend that political capital on less superficial issues. I sometimes really wish the React folks never invented JSX, and just forced everyone to write createElement calls to begin with, then all of these points of confusion from people coming from templates could have been avoided (and we'd end up with only my preferred syntax as the one true way to write components, haha), but I do wonder if React would have taken off as it did if it didn't come with JSX to give people that sense of familiarity, even if it ends up causing much more undue confusion over the long term.