I've spent the past few days looking at VueJs 2 with Vuex and i really like it.
Having only had a brief introduction to React, I've found vue js 2 has been easier to pick up.
React seems to be growing in popularity, but I can't see the benefits of React over Vue 2.
Both are component based frameworks with routing and state management tools.
So can someone explain which are the main differences between those frameworks?
This is an opinionated and subjective question. And it often starts holy-wars than really answering anything and thus it is not really suitable for StackOverflow. However, I will try to answer this in an objective manner as possible. (Note: I am purely comparing Vue with React and deliberately avoiding Vuex vs Redux)
Why Vue.js?
It is designed to be an approachable framework. It is suitable for beginners and advanced users alike. When you are starting with Vue.js, it is as simple as adding a script tag to your page. For the advanced developer, the possibilities are endless. You can start with any sophisticated build tools - TypeScript, Babel, Webpack, etc.
Vue.js is developed much after Angular and React. It has learned from both and managed to pick many best things from them into Vue. For a beginner, Angular's idea of components, services, dependency injection, bootstrapping application, etc can feel overwhelming. Same is applicable to React; JSX can feel odd (Even after years, I still find it weird.). Now, Vue.js is a cross-path. You can use angular like templates or you have the freedom to choose React like JSX.
Vue.js reactivity is very well abstracted. With Angular (digest cycle in v1 and zones in v2) or React, it is bit different. It takes time to learn these concepts.
There are tons of other reasons why Vue.js should be your choice. Sometime back, I had written an article explaining why Vue.js:
https://blog.webf.zone/vue-js-answering-the-why-after-15-months-62db797f75cc
Why React?
React is a pioneering library (It is not a framework) just like Angular. It introduced the ideas of uni-directional architecture, virtual-dom, components (stateful and stateless), etc.
React Native is another reason why you may want to consider React. It allows you to take the same code that you wrote for Web and build native mobile applications. Now solutions do exist in the Vue.js world. But definitely not as mature as React Native.
Functional programming: No way React is a library based on functional programming. But doing React right way means you need to use immutability, explicit state management and all these allied concepts stemming from functional world.
Redux: Redux is the darling of React world. It has unlocked wonderful architectural patterns for front-end world like time-travel debugging, explicit side-effects, functional components, etc.
Innovation: React has some crazy ideas like Relay, Next.js (Vue.js has Nuxt.js). I also heard about some Drap-n-drop editor for React; first class TypeScript and Flow support (You just cannot get TypeScript + Vue.js + JSX working together even in 2018).
Why not React?
Using only React is not enough. Very soon, you will end up with using Redux, Redux middleware, Immutable.js, etc. Doing all of that at once can be intimidating.
Redux. It is wonderful but it is verbose.
Most important: Using React without any sophisticated build system is cumbersome. To do anything serious, you will need Babel, Webpack, etc.
Again, which one is better?
There is no better solution. I will choose Vue.js if I need to accommodate a vast array of developers (beginners-advanced). I will choose React if my team is versed with all the extra overload that comes with React and team loves everything JavaScript approach to web development (Even CSS is JS).
Finally, there is one another angle to it. Programming in React needs discipline and hence, there is a good chance that you will find it easier to bring homogeneity to your codebase. With Vue.js, there is often more than one solution to a problem. That makes it good and bad at the same time.
You will not go wrong with either of them.
Related
Good day! I have a question. It is planned to develop a large web project, which will be scaled in the future. I would like to know what is better to choose EmberJS or React? There is experience with EmberJs, but I would like to hear the opinion of experts who have experience with both frameworks. I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js. Tell me, please. It would be great to see some benchmarks in various conditions. Thanks guys!
I started with React and later moved to Ember. The truth of the matter is that the core problems teams face when developing frontend / single-page-apps are about the same regardless of what tool you're using. Those problems are going to include learning the business, learning the history, struggling with how to not over-use the framework, and instead using "the platform" (using MDN more than framework docs, etc). Generally, it takes way more time to learn a business / existing product than it does to learn a framework.
For some benefits of ember's whole ecosystem, which React does not have:
Ember has a more cohesive ecosystem which makes upgrades much more straight forward.
Ember's goal in frontend is to reduce the meanial differences between apps so that you can focus on features. This includes stuff like state management, routing, etc. For comparison, there are features in Next.JS that landed in the last month or so that Ember has had since the beginning.
Ember's discord is an invaluable tool of helpful people. A bit US-work-week centric at times, but it is the go-to place to get more synchronous help outside of your own team. Link here: https://discord.gg/emberjs (which is found on the community page: https://emberjs.com/community/) -- React also has a discord, but I found it way less welcoming due to the sheer volume of people moving through there.
Conventions is key to any framework in the single-page-app approaching SDK space. Conventions are optional guidance that are happy-path defaults that, once memorized, bring productivity ahead of where it would be without the conventions
Ember is mostly "Just JS". React has this same claim, and maybe that was true back when they were using classes for things, but with everything needing hooks now, and the over-use of useEffect, Folks end up writing more React than they write JS. With Ember, you still write more JS than the framework. Ember has tried very hard to allow you to stick to MDN for for anything but reactivity and routing. State management is even allow "normal JS" (with some conventions due to limitations of JS, itself)
I've heard that react is lighter, but at the same time, you need to include a lot of libraries to add functionality like ember js.
This is true, however, It stops mattering very quickly. Ember is only 100KB (min+gzip) -- React (at a minimum, I think is ~40kb (min+gzip), with no libraries (react + react-dom)), and the size of your underlying framework begins to not matter in comparison to the rest of your app's code very quickly.
Unless you're targeting low-connectivity areas and trying to also get your site to load in < 0.1s, the framework choice w/r/t size also doesn't matter. (I'd say this of Angular, too!).
Fwiw, and maybe this is a bit of a disclaimer, I feel like React is a modern day jQuery (usage in the vernacular is nearly the same as jQuery). Nearly everyone is using it because nearly everyone knows it. It doesn't matter if the tool is good or not, it's everywhere, yet holds no opinions about anything and relies on the broader community tot learn how to use it. You can't build products out of just React.
And kind of more cynical, React is an avenue to very cheap labor for employers to hire straight out of bootcamps.
As an aside, one thing I've noticed about frameworks, is that most of the "cool stuff" (that you'd want to use day to day) isn't documented in the framework docs. It's knowledge derived from knowledge of both the framework, and what the web can do on its own.
For example:
handling form submissions without a ton of wireup: https://twitter.com/nullvoxpopuli/status/1502682732178124805
dynamic imports / await importing a component: https://twitter.com/nullvoxpopuli/status/1507715367581462531
testing with MSW:
https://twitter.com/nullvoxpopuli/status/1525509103317041152
https://twitter.com/nullvoxpopuli/status/1525508184353406978
Filtering local data: https://twitter.com/nullvoxpopuli/status/1496512125237440515
Integrating Tailwind: https://twitter.com/nullvoxpopuli/status/1481993894430658568 (the lazy way)
Thinking about template syntax: https://twitter.com/nullvoxpopuli/status/1474037335583080449
The team and I are embarking on a React project. We are primarily a Microsoft team who are all experienced with .Net for decades!
We have been really impressed with React and feel like we are going down that route. We have done all the Angular vs Vue vs other options to death.
As we are all C# developers we are planning to use React with TypeScript. Mainly for two reasons
We are used to a strongly typed code bases coming from C#, so we have been more successful with the React with TypeScript.
The code base has the potential to become quite large and we plan on sharing React components and TypeScript interfaces between teams/projects via an internal NPM registry. We think TypeScript will highlight typing issues early especially when refactoring and allow sharing more effectively.
I have talked with another similar sized team who did not start out with TypeScript (or Flow) they ran into refactoring problems when their solution got large and retrofitted in TypeScript.
I would like to start out with TypeScript from day one as a result
However, I am getting some push back from the more Javascript orientated developers. Who say:
TypeScript not required in modern ES6 JavaScript applications
The wider React community does not use TypeScript
Hooks which are new to React compound the points above
Have I wandered into a religious argument rather than a technical one (static typing vs dynamic) or are there points justified?
Happy to admit I am a JavaScript novice compared to my C# experience so I could be totally missing the point.
I thought I would pose the question to the community and find out some educated opinions. Please be kind
TypeScript not required in modern ES6 JavaScript applications
It depends on what the requirements are. You say you anticipate refactoring, I have some experience with refactoring my own javascript and TypeScript projects. I can say that without TypeScript, refactoring takes more effort - you have to look at the implementation code a lot, just to be able to understand what the interface is. This can be alleviated by extensive amount of API documentation and unit tests, but - how many projects out there have those, and how many projects maintain the API doc so that it matches 100% with the actual code? Type annotations are a nice way to express what the expectations in the code are, and have a side benefit to be maintained together with the code.
The wider React community does not use TypeScript
Everyone uses what's best for their needs. In reality, there is no "community", there's just a bunch of people working on different projects. What's suitable for a majority of people might not be the best for you.
Hooks which are new to React compound the points above
The recent version of typings for React does seem to support hooks. The result of google search for "react hooks with typescript" shows that a lot of people are using React hooks with TypeScript. I'm not aware of any specific problems, but if there are any, there's a chance they will be sorted out, eventually.
So my question is pretty self explanatory. Does it make sense to use Vue.js and React.js together on a same project ?
No. Both Vue.js and React are for the same purpose - building UI components.
The only situation that it might make sense is that if you are doing a migration. From Vue.js to React or from React to Vue.js.
But I think in most scenarios it doesn't worth to do this kind of migration. Both Vue.js and React are really great. So my conclusion is, no, it doesn't make sense.
Both Vue and Reactjs are javascript Frameworks that are in themselves self sufficient. Also since both do the same job it makes sense to use either one of them.
If you use both Vue and React together it will make it more and more difficult for you to share states and data between parts written with Vue and Parts written with React.
What you would have to do is to keep them as independent modules.
Also both Vue and ReactJs have different APIs so it makes it difficult for a developer to code it out too. This will lead to bad patterns and hacks developing in your code which will later lead to issues such as maintainability and feature extension.
If you have control over your entire code, its better to just evaluate what better suits your purpose and then choose that framework for development of the entire app.
P.S. Certains exceptions to using both of them together will include a migration from framework to another in progress or your app having various modules in your App each of which independent from one another and included as plugins in the main code.
You can use the two together but you will have to carefully consider the architecture. You might have to consider something like the Microfrontend architecture but remember this comes at the cost of a lot of complexity and is not suited for all use cases.
Good intro to Micro Frontends
Building app with react with flux, I'm wondering developing an app with react is really efficient.
With flux all states are maintained by domain. All state of components have to manuplate in flux. I need to normalize data structure to consume in react components. This is verbose.
And more components are listed we have to consider rerender optimization. This is time consumer stuff.
Of course reusing react components is nice but configuring, designing, planning are also complex.
I need some advice of using react.
It is very overwhelming at first as there are so many decisions to be made. Just do a google search for "JavaScript fatigue" and you will realize you are not alone.
Fortunately, there are lots of great resources out there (both free and paid) to learn about all of this stuff. I personally used Cory House's two React courses on Pluralsight to get up to speed and found this route very helpful.
Still, project setup can be very time consuming with flux or redux, and you have to consider whether your application is complicated enough to warrant their use. React itself is extremely flexible and can be used in a simple application on it's own, or even in conjunction with other frameworks or tools like backbone.
There are plenty of things out there to help ease some of the pain of setting boilerplate for a react project.
https://github.com/coryhouse/react-flux-starter-kit
https://github.com/coryhouse/react-slingshot
Both of those are good resources (there are many more out there as well) and serve as good starting places.
Lastly, Facebook just the other day released an official tool that allows developers to start writing react apps without having to worry about any configuration. There are still some limitations to the tool, but it seems very promising and looks like a great place to start for beginners.
https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
I'm new to react and while browsing through the net I came across various terms associated with React - Flux, Redux, Relay, Graph QL.
So far I understand these are design patterns for a React app.
I want to embark on a small side project using react and am confused as to which architecture to invest time and effort in learning and implementing .
Could someone please help me out here ? Thanks!
A brief overview of each with the pros and cons would be ideal .
Yeah, it can be daunting. The thing is React is just a UI component framework (but an awesome one) so the rest of the application architecture is up to you. Flux and Redux are solutions to managing state (not just in React), both are certainly worth learning about. Relay and GraphQL from Facebook are solutions to fetching data from a server and requires both client-side and server-side implementations to be used.
I agree with Tom's comment: for a small project start with just React (and complimentary libraries for details like AJAX and routing). There are still basic React patterns to get the hang off. Once you are comfortable with React and your app gets large enough, you will likely start to feel the strain of managing state in your UI, and that will be a good time to seek out something like Flux or Redux.