A poorly done React component (mixing props and state?) and what looks to be a poorly done Vue component (with some jQuery lib thrown in?), are the basis of the opinion? Seems weird.
Yeah, pick any framework that you don't know how to use properly, drop it for another framework that you don't know how to use properly, write a post on medium about it, repeat.
Yep, I think a lot of a confusing parts of React components is state and ES6 classes. Luckily, you don't actually have to use those, React really shines (IMO) when you write stateless components, using ordinary functions.
Standard React advice is that copying values from props to state is _usually_ a bad idea and should generally be avoided. It _can_ be useful in cases where you have something like an editor component that wants to allow updates to the values internally, only notify the parent when the edits are complete, and overwrite the edited values if the props change. The most common mistake in copying props to state is only doing it in the constructor, and forgetting to also do it in `componentWillReceiveProps`.
So, that snippet is actually valid - presumably they want to initialize the internal state value based on the corresponding prop, and use an empty string if it doesn't exist.
I don't disagree, it's just why place merit into an opinion that is poorly using a library(ies in this case). If I were to compare two libraries I wouldn't use the exception cases to show their differences - it's unhelpful and misleading.
Seems more like they threw their hands up in frustration and went with something that was more immediately understandable to them.
I haven't used Vue yet, but I'm curious how nice it is to develop with after the codebase has grown significantly - I remember Angular 1.x had that same "magic" that made it easy to appreciate and pick up, but ended up being a huge headache after writing production code with it for over a year.
And really, there's a reason why React isn't designed to work well with jQuery. That's one of its biggest strengths - writing code declaratively and letting it figure out what the correct state/DOM should be. I can't imagine trying to write a complex SPA and modifying the DOM directly - that was the reason Facebook came up with React to begin with.
React is the only web framework I've ever used that has held up to the trials of a long-lived application. I thought it was pretty good when I first picked it up, two years later and I'm in love with it. That alone makes me incredibly hesitant to try new frameworks.
One of the nice things about React's component model is that it's fairly straightforward to wrap up imperative DOM manipulation like a jQuery plugin into a declarative React component (assuming the DOM manip is scoped and not page-wide).
The React docs recently added a section on integrating with non-React code [0], and I've got links to several more articles discussing integration and interop at [1].
I find Vue to be such a breath of fresh air. All I wanted out of React was shadow DOM and then it went and turned into this whole cultural movement thing.
Isn't that a pretty much foregone conclusion given a large enough adoption and ecosystem? After all, ColdFusion has less of a cultural influence on its users than Rails does.
Isn't the ability to just include a js file going away in version 15? react_on_rails already pulls in v8 when all I wanted was for the browser to load it, and it requires I stick my components in a weird place. With Vue, components can live with the rest of the view code and I don't have to write JSX (which I hate), or React's verbose alternative. Plus, whenever I look up information it alsways seems to be geared to node.js users.
A long time ago I wrote a DOM templating engine in like 10 lines of ES5, and what I really wanted was a faster and more complete version of that. Vue fits in much more nicely.
I think the differentiating factor is React is much more (dare I say it) enterprise. It shines when you have lots of developers, large codebases, and shared code. Vue is much scrappier and the literature tends to reflect that.
Indeed - very poorly written and very misleading. Redux is just a library for state management which is NOT correlated with React (although people seem to think so because Redux's author now works on React at Facebook).
It wasn't written at all by the "React guys".
It also implies Redux englobes React which it most certainly doesn't - they're just 2 independent libraries.
> ...jQuery it’s still a thing... for example a grid with a subgrid that supports bootstrap and is easy to change...
No way. Angular made me leave jQuery forever. React made it even simpler to create components. People should still learn jQuery and its internals because of its simplistic (api) interface and internal code.
I like Vue too, because its so easy to develop a lot in a few hours. But as code grows and complexity grows - Vue loses its simplicity and I end up migrating to React.
EDIT: Reading the article it feels like they lack expertise in both JS and CSS (and Thinking in React way pushed them over the edge)
That Vue component, from a glance, seems less readable, more complex, and more stateful than the given (poorly written) React component. And none of the arguments against React really make sense to me (ES6 is not complicated, JSX is light syntactic sugar, and you probably don't need FLUX to start...).
It seems like the _main_ problem they were having was that they were trying to graft React onto an environment based on jQuery and then realized that it made things complicated. That's not a knock against React, that's just shooting yourself in the foot and blaming the gun.
"trying to graft React onto an environment based on jQuery"
Welcome to the world of web development. Not everyone has the luxury of throwing out the last 11+ years of jQuery knowledge, plugins, tooling, etc. and building everything from scratch in React. Some people—gasp!—might have legacy codebases that they want to slowly introduce a new front-end framework into. Vue is a much better solution in both cases.
The problem is this article is making general statements off of their specific use case. Like this complaint:
> Simple things were made harder to develop. React was created to make DOM changes fast, really fast, so you will have to use React functions to make use of this, some of which you will not be familiar with (because React has a different architectural style)
It's utterly meaningless. What it really sounds like is they didn't understand React, didn't research what using React with jQuery would entail (given by the fact that they couldn't make it work), and didn't bother to learn the (relatively small) React API. React is not hard.
Then this gem:
> React is great, but only if you want to develop a simple application where the UI should not be consistent across different technologies
Is _completely_ incorrect.. React is used at enterprise scale by many companies to develop all sorts of complex apps, and surely many of them have or had existing systems coexisting side-by-side.
I've found Vue code to be the opposite, at least for my use case. It is easier to read and more in-line with naive expectations as it looks like handlebars or any other templating solution.
Am I missing something? The example React and Vue components they provide seem to be completely different components, and the React one is missing most of the code.
This seems like a particularly poor example just because the author is trying hard to graft vue/React onto an older style of web development. Why bother using either if you're relying on jQuery?
27 comments
[ 4.7 ms ] story [ 68.3 ms ] threadSo, that snippet is actually valid - presumably they want to initialize the internal state value based on the corresponding prop, and use an empty string if it doesn't exist.
I haven't used Vue yet, but I'm curious how nice it is to develop with after the codebase has grown significantly - I remember Angular 1.x had that same "magic" that made it easy to appreciate and pick up, but ended up being a huge headache after writing production code with it for over a year.
And really, there's a reason why React isn't designed to work well with jQuery. That's one of its biggest strengths - writing code declaratively and letting it figure out what the correct state/DOM should be. I can't imagine trying to write a complex SPA and modifying the DOM directly - that was the reason Facebook came up with React to begin with.
The React docs recently added a section on integrating with non-React code [0], and I've got links to several more articles discussing integration and interop at [1].
[0] https://facebook.github.io/react/docs/integrating-with-other...
[1] https://github.com/markerikson/react-redux-links/blob/master...
You can just use that if you'd like.
> turned into this whole cultural movement thing
Isn't that a pretty much foregone conclusion given a large enough adoption and ecosystem? After all, ColdFusion has less of a cultural influence on its users than Rails does.
Isn't the ability to just include a js file going away in version 15? react_on_rails already pulls in v8 when all I wanted was for the browser to load it, and it requires I stick my components in a weird place. With Vue, components can live with the rest of the view code and I don't have to write JSX (which I hate), or React's verbose alternative. Plus, whenever I look up information it alsways seems to be geared to node.js users.
A long time ago I wrote a DOM templating engine in like 10 lines of ES5, and what I really wanted was a faster and more complete version of that. Vue fits in much more nicely.
This is wrong; Redux is not a framework, it's just a technique for managing state.
It wasn't written at all by the "React guys".
It also implies Redux englobes React which it most certainly doesn't - they're just 2 independent libraries.
No way. Angular made me leave jQuery forever. React made it even simpler to create components. People should still learn jQuery and its internals because of its simplistic (api) interface and internal code.
I like Vue too, because its so easy to develop a lot in a few hours. But as code grows and complexity grows - Vue loses its simplicity and I end up migrating to React.
EDIT: Reading the article it feels like they lack expertise in both JS and CSS (and Thinking in React way pushed them over the edge)
It seems like the _main_ problem they were having was that they were trying to graft React onto an environment based on jQuery and then realized that it made things complicated. That's not a knock against React, that's just shooting yourself in the foot and blaming the gun.
Welcome to the world of web development. Not everyone has the luxury of throwing out the last 11+ years of jQuery knowledge, plugins, tooling, etc. and building everything from scratch in React. Some people—gasp!—might have legacy codebases that they want to slowly introduce a new front-end framework into. Vue is a much better solution in both cases.
> Simple things were made harder to develop. React was created to make DOM changes fast, really fast, so you will have to use React functions to make use of this, some of which you will not be familiar with (because React has a different architectural style)
It's utterly meaningless. What it really sounds like is they didn't understand React, didn't research what using React with jQuery would entail (given by the fact that they couldn't make it work), and didn't bother to learn the (relatively small) React API. React is not hard.
Then this gem:
> React is great, but only if you want to develop a simple application where the UI should not be consistent across different technologies
Is _completely_ incorrect.. React is used at enterprise scale by many companies to develop all sorts of complex apps, and surely many of them have or had existing systems coexisting side-by-side.
Is it Thursday already ?