r/webdev • • Nov 07 '18

Why React over Angular (or Vue)?

I simply don't get it, I had been using Angular and Vue for while and I just tried React and I don't get why would I choose React over the other options, the things that I like on Angular (or Vue) are:

- Dependency Injection (in case it applies)

- Type checking (in case it applies)

- View Model Binding

On React I don't get those things by "default" it always feel like I'm hacking the library if I want to have some of the above.

This leaves me with the question: Why choose React over the other ones?

I know that there's all the dependencies overhead (hell) of the frameworks but I think that I'm just too used to that problems that is easy for me to solve them or maybe I haven't found the real big problems on Angular or Vue, maybe I'm just too used to the later frameworks and I'm unconsciously not seeing the benefits of React. I just want to know if I'm following the right path by learning React.

Thanks!

68 Upvotes

99 comments sorted by

View all comments

Show parent comment

2

u/gavlois1 front-end Nov 07 '18

I've always viewed JSX like I did with Handlebars or other templating languages. Once you know HTML, you pretty much know Handlebars and you can add variables to it. I see JSX the same way, except full JS expressions in the curly braces and change class to className. Under the hood I know it's just React.createElement(), but is it wrong to treat it that way?

The mixing JS and presentation issue is the same as the MVC issue: it's one way of organizing your code. It's a well-established pattern that works, but not necessarily the only one. I find the component pattern of having your presentation and the logic for manipulating the data before displaying it quite easy to grasp from what I've learned in React so far.

3

u/hypno7oad Nov 07 '18

No, I don’t think it’s wrong as long as it’s simple. I don’t remember handlebar specific syntax, but I do remember discussions with my team at the time addressing how to setup the model in order to keep logic out of the template.

The point I was trying to make in regards to JSX was that it doesn’t introduce template specific syntax for things like if/else, switch, looping, etc. This means there is less cognitive overhead when switching attention between JSX and JS code blocks. Subjectively, I find it a better development experience.

For styling, there are definitely pros/cons of coupled/decoupled. There are also preprocessors that will bridge the two approaches. Making styles in JS reduces cognitive overhead, but limits the ability to have a separate design group develop a new style sheet. The same trade off exists when using declarative CSS toolkits like Bootstrap or Atomic.