You have a magic button and you can learn React or Vue.js
Which one do you use and why based on these factors:
CLI
Community
Easy of work
Speed of prototype
Anything else?
I know this very much depends on the project, but I'm sick of Angular and want something easier to prototype with.
React, just because of its popularity. I'd assume they're basically equal in other respects.
I like React because the community is probably the largest and it seems less “magical” to me. People seem to say Vue is a bit easier, though, especially if you’re coming from Angular.
All in all, I think either one would be fine. People advocating strongly for one or the other are just imposing their own opinions. Just make a choice and stick with it!
I did a comparison of React & Vue https://jatinsandilya.substack.com/p/beginning.
Verdict: React all the way!
In MY opinion it is really up to you and your team, which will work for you best. Every Frontend Libs/frameworks has its cons/pros. BTW you can made the same project with Angular/React/Vue and almost got the same result.
As I see it now, the market goes for React in hardcore mode, so it could be the choice if you wanna keep up with the market. (There are tons of React developer jobs, but few Angular/Vue)
For me, Angular is the choice, because it's uses typescript by default and have an excellent CLI tool and can write injectable services. (I know, that you can use typescript with React and Vue too).
As i mentioned it: this is just MY opinion.
Why are you sick of Angular? The best tool is the tool you know and can use well. Once you identify a list of things you hate about angular you can first decide if migrating to a new tool is even worth it and secondly what things you are looking for in a new tool. I am going to bet just building the project using Angular would be much faster than learning a new tool + building that project. Also, you have to take into consideration context switching as a cost/negative. If you work all day at a job with angular then go home and work with React/Vue there will likely be a performance penalty where you are adjusting to the different ecosystem. There are people who would build a brand new product today using PHP because it is the tool that they know. Unless you have a concrete reason why you want to ditch Angular it might be worth it to just continue with it. Your productivity is probably best with it.
If it HAS to be one of those two it would have to be for the mobile play, thus React / React Native. But honestly vanilla JavaScript is what I'd go with 95% of the time, and you then survive UI framework of the week syndrome. ;)
I've used React professionally for close to four years. However, about 6 months ago I decided to give Vue a try. I absolutely love it! I feel so much more productive.
My preferred stack is Nuxt, Vuetify, and Hasura.
Either of them is fine for solo projects, maybe just play with both and see which one you like more. But, if you think you might end up in the job market in the next 1-3 years, React + Redux is a really valuable skillset to have.
I would go with React. You get double the front-end milage because you're effectively learning large parts of React Native at the same time. You don't need to learn Redux to use React, but to be honest I would anyway because they work so well together and lead you towards writing better code. Especially Redux-Saga once you progress to needing async actions. This new lib by the Redux devs counters most complaints people have about Redux: https://redux-toolkit.js.org/
I actually disagree with this — I would avoid Redux from the start and just use prop drilling as long as possible. Redux comes at the cost of increased statefulness and complexity. It's much simpler to e.g. send a request, handle the loading state and display the response within a component than it is to deal with wiring all of that up in Redux.
If your app ends up growing to have complex state requirements I might consider it, but until then I don't think it's worth it.
I'm not quite sure what you mean by Redux increasing statefulness as I've always used it to remove almost all state from components by centralising it in the store. Do you mean it increases tracked state? If so I would argue untracked state is still state, you just don't know what it is and how/when it's going to pop-out and hurt your application.
Prop drilling is an entirely acceptable way to move data around, especially in smaller projects, and I've definitely done it before. I'll still pass down one or two props (but only a single level) if the parent is already connected to my store and it's not worth plumbing up that lower component.
In my experience there is often a point when you cross a threshold where the prop drilling "boilerplate" is bigger than a simple Redux setup.
E.g. "Hmm I need this button to know about this setting, but it is eight components deep and none of them currently has access to that data. Time to modify every one of those files".
You don't have to jump straight to Redux at that point, you can just use the React Context api, but Redux also comes with goodies like:
E.g. You're sorting a list of foos inside your <FooList /> component's render method. With a selector, that sorting only happens the minimum number of times - once to start, then only again whenever the you add another foo or change the sort parameters.
Sagas for clean mixing of sync and async code (no callback hell, makes promises less frustrating to work with)
Redux devtools are amazing for debugging your application (action and state diff history, injecting actions, more)
Forcing you to consider the state machine that is your code, and the transitions that are your actions. (I think this leads to better application structure, fewer bugs because there are fewer unexpected states, and makes working with other devs easier)
But really it comes down to what you're working on, who you're working with, time constraints, familiarity, performance requirements and so much more. These days I just tend to lean towards pulling in Redux for most projects, but that's my opinion and it's totally fair if you don't agree
In my experience, you end up using Redux like a database and caching every bit of state you receive from the server. It's much less error–prone to hold onto the state only as long as you need it — discarding it when, say, you change routes or close a modal — and re–fetch a fresh copy when you need it again. (I know you can use Redux this way, I just think it tends not to happen).
The new context API is great, and a lot of the things people used Redux for are covered between that and hooks. Your reselect example, for instance, can also be accomplished with the useMemo hook.
Re: sagas, async/await make promises basically equivalent to generators. And the indirection makes trivial things like getting an error message for a failed request much more difficult than they would be if you just handled the request in your component.
I will agree that using a popular tool with a large community and known idioms/advantages/pitfalls makes it much easier to work on a team. But that's what I'm getting at. OP isn't an experienced React developer working on a team at a company. They're about to start from scratch learning a new framework, probably on their own. So they don't know the tradeoffs that make Redux a good fit or not.
TL;DR not saying it's never good to use Redux. I just wouldn't frontload that complexity, especially if you've never used React before. (Dan Abramov agrees!)
my vote is on React
I don't do a ton of web development so I can't speak too in depth but I tried each framework hoping to find one that I enjoyed working with. It started with Angular, then I tried Vue and finally I landed on React. I love it.
it's very intuitive, JSX is awesome, the community is huge and they are only making improvements on the speed in which you can prototype (i.e. react hooks)
i'd love to hear from people who disagree so I can understand what some of it's short comings might be but I haven't found any yet
This comment was deleted 6 years ago