I have built applications using React and most recently Vue2.
Both are very very similar and if you are familiar with one you will be able to pick up the other quite easily.
In regards to webpages both are capable of doing the same things and fit the same uses cases.
That said however if I was to start a greenfield application today, I would choose React.
The reason for this is that react is better known, it is easier to find solutions for, and it has more mature guidelines for things like project structure and best practices.
Vue is good competition for React and it will certainly help keep it on it's toes.
However in regards to longevity, I feel React will be around a lot longer than Vue.
React has the full support of facebook and is being used by other major vendors.
Vue is also used by some big sites, however it has no official backing that I know of and is maintained by a "Benevolent dictator for life".
In a year or two I predict that I will see another article with a title along the lines of "Switching From React To <insert new hotness here>". It is very unlikely in my opinion that I will see a "Switching From Vue To <insert new hotness here>" article.
Vue is backed by one of the biggest companies in China. You need to do more research. Vue is more popular in China than React. I would say I would rather start a new an app using Vue because of the learning curve is a lot faster to pick up than React.
A non-trivial amount of info and discussion around Vue (esp. third-party packages) is in Chinese. Whether that's a plus or a minus depends on whether you understand the language.
I have started to use museUI. A material UI library based on vuejs. It is also mostly in Chinese. I was reluctant initially but made the jump.
Then one day I had an issue. Posted it. Interestingly some other guy posted a PR to solve that. And it got merged the next day. So it ended well for me. But can't say that for other repos. Just my experience.
That's for sure a minus, even if you speak the language. You are restricted to a smaller subset of developers that can improve the ecosystem (and let's be frank that most good developers should know English but not Chinese, internationally speaking).
The logic may not be sound as you cannot tell for sure if there are more English speaking front end developers or Chinese-only speaking ones, given the population of China.
> I would say I would rather start a new an app using Vue because of the learning curve is a lot faster to pick up than React.
When we're talking frameworks that you'll use again and again I don't really think this is a factor. You'll only need to pick it up once. I'm a lot more concerned about long term maintainability.
If we move away from only spa appications vue has other use cases. For a Rails / PHP site that only needs small amount of javascript vue feels like a natural choice to replace some of the existing jquery
That's not strictly true: vanilla React doesn't even use a router until you wire one up. It's perfectly cromulent to use just few bits of React on an existing web app/site.
I read through the differences, and they seem small enough that for any decently sized project with a non-trivial team you'd choose React and in most cases probably not even consider Vue.
>In a year or two I predict that I will see another article with a title along the lines of "Switching From React To <insert new hotness here>". It is very unlikely in my opinion that I will see a "Switching From Vue To <insert new hotness here>" article.
That might also be because once people get to Vue, they don't leave it for any "new hotness".
In JS maybe. But I don't think there's anything fatalistic about it. There are still C, C++, Lisp, even Pascal etc codebases maintained and liked just fine.
It's about maturity and churn, not something inherent in programming.
I have (some) experience with both React and Vue 2 and definitely prefer the later. Vue is very minimalistic but unlike React provides a lot of functionality out of the box. Stuff like the router, the computed properties, automatic change detection, HTML templates, scoped css, animations, ... . But what's more important is the fact it does all these things in an extremely elegant and unobtrusive way. The computed properties are an often overlooked but good example of this. You simply declare an object property that is dependent upon other properties and voila, that's it. It's there in your component together with the rest of your data for you to use in your template. It gets memoized, it gets change detection, it just works (TM). No need for Redux, Reselect, selector functions or any of those things. I love the simplicity of this approach. And this is just an example, but this very minimalistic approach applies to everything that Vue offers.
> unlike React provides a lot of functionality out of the box. Stuff like the router, the computed properties, automatic change detection,
I never studied Vue, but the article starts saying "Both have separate, but commonly used, router and state management libraries". This doesn't look like "out of the box" to me.
For most Single Page Applications, it’s recommended to use the officially-supported vue-router library. For more details, see vue-router’s documentation.
Out of the box or not, they're part of the same github org, they're officially supported and they're documented in the official docs. I think this is just splitting hairs.
And react-router, while not being on the same github, is pretty much considered a standard too. It's ok to not split hairs for vue.js, but then you shouldn't do the same for react...
react-router, do you mean v1, v2, v3, or v4 (or perhaps v5 and v6, I haven't checked if there was a new release with breaking API changes during the past 12 hours).
Why downvote? Anyone sane can't seriously be thingking of using react-router in anything non throw away - the library gets rewritten from scratch every year and doesn't provide any backwards compatibility or migration paths.
You might as well just write your own react-router implementation for every react project you work on.
I mean react-router is almost a 3 year old library trying to handle a rather complex problem. The first three versions were largely the same with no major changes that I can think of except for switching from context to higher order functions.
I think everyone is a little dramatic about the number of versions of the library, especially when they are going to continue to support v3.
If you don't like having to choose which version of react-router to choose, you probably should be using a preset like create-react-app which makes this kind of decision for you. Or you should use something other than React which includes everything and the kitchen sink.
This doesn't really make sense to me. You have to pick a version for literally every single library you use. And those different versions have different interfaces, which is why they have different versions...
In my opinion it would have been clearer if react-router v4 had been released under a different name but I guess the authors didn't want to pay the cost of that.
The API changes between 1 and 2 as well as 2 and 3 are mostly cosmetic. It's worth pointing out the authors released codemods which will likely be able to convert your app from one version of the library to the next as long as you don't do something exceptionally clever.
The changes between 0.x and v1 were entirely expected. It seems the authors followed the common semantics that 0.x releases are considered experimental, v1 was based on the lessons learned. v2 and v3 then improved upon that design with relatively minor changes.
On the other hand v4 is an entirely new library using an entirely different paradigm: routes use component semantics and are part of the component structure, rather than just some JS router that uses JSX syntax for aesthetics.
But as I said: v3 is still being actively maintained, the authors have just decided that the v4 API fits React better. And for all major releases from v1 to v3 you should be able to upgrade practically for free by using codemods.
I think the importance of codemods can not be understated though many people are still ignorant of them: Facebook releases codemods for every major version of React and uses them internally to upgrade their tens of thousands of components automatically. Third-party libraries like React Router have also started providing them.
Codemods written well should allow app developers to migrate breaking API changes in dependencies with practically no development effort.
Additionally, like React, React Router seems to have adopted the approach of deprecating APIs in the final release of a major version that is no longer going to be supported so you can upgrade your manually code before moving to the new major version with no fear of things breaking. So when upgrading from v2 to v3 you should be able to upgrade safely by simply upgrading to the latest minor version and fixing any deprecation warnings.
Both codemods as well as deprecations of course assume you're doing the sensible thing and a) upgrading one major version at a time and b) actually maintaining your project rather than just spending half an hour on it once a year to implement a new feature with no test coverage.
Personally I often end up doing the not so sensible thing where I end up having to migrate all third party deps to the latest version once a year or two, but libraries like React and React Router are the least of my worries because they are extremely safe and easy to upgrade -- even to the point where there's no need to upgrade beyond React Router v3 unless you also prefer the v4 API.
To clarify: the ReactJS org is solely a community organization for some commonly used packages. It's not an official Facebook+React thing, even though both Dan Abramov and Andrew Clark, creators of Redux, are now actually on the React team.
react-router is one of the worst evolved software proects I've seen which keeps destroying it's knowledge base with every release with almost everything indexable on the web out of date with the latest version. It's also not as intuitive to use as vue-router (which just worked OOB) and it's root page handling behaves differently to the Routers in Angular, Aurelia and Vue.
It feels like you're incurring tech debt by depending on React Router but unfortunately since it's the defacto standard there's very few other viable options.
By contrast Vue feels like they care about their ecosystem and existing Customer code bases and will publish nice migration guides when they make breaking changes showing how old functionality can be migrated to their new APIs.
> By contrast Vue feels like they care about their ecosystem and existing Customer code bases and will publish nice migration guides when they make breaking changes showing how old functionality can be migrated to their new APIs.
There are migration guides for v0.13.x->v1, v1->v2 and v3->v4 right in the docs of react-router. How is this a contrast?
The official Vue docs? The ones where half of the useful stuff is either missing, incomplete, or doesn't work because it's information for a deprecated version?
Vue has a lot of things going for it. Documentation is not one of them.
Vue is widely praised for its official documentation, often pointed as one of things differing it from React. But if you have other experience, I'd kindly asked you to mention the places you remember were wrong, so that I can submit a PR for them.
Vue is being specifically designed to work as small composable modules. That is a good thing. You get a bunch of boxes you can mix and match as you wish.
Coming from a small-team Rails background, I tried React for a few months, then tried Vue. I found with React I felt compelled to replace and relearn large parts of my stack, and the learning curve as a result was very steep.
In comparison adding Vue components to an existing Rails app was dead simple, and I even got to keep writing my Vue templates in HAML. All the questions I had were easily answered by the Vue documentation without even going to e.g. stackoverflow. Vue was the clear winner for me here.
Things you're sacrificing when going away from React:
1. Stability. FB uses it for their main product, which is probably the biggest web app of them all, they pay many devs to work fulltime on it. People coming from Angular, who had to migrate all those breaking changes over the years know the struggle.
2. Options like React-Native, React-VR and co. React enables your devs to acquire a whole new range of possibilities. It isn't just a web framework.
GWT was first released 11 years ago, the most recent update was less than a month ago. If that's not an example of future-proof (for web technologies) I don't know what is.
Whether it's kept up with the state of the art I don't know, but I think that's a different thing.
I was referring to http://www.gwtproject.org/release-notes.html - e.g. the release hole that happened between 2.7.0 and 2.8.0 (2 years). Some clients actually decided to stop using GWT at that time, because of that.
Three20 was made obsolete by the useful parts of it getting built into the platform SDK, and yet it was still maintained and kept in a working state for longer than it was ever actually useful.
I know that - but the fact is that for one client of mine, the app was initially build on three20, then they had to literally rebuild it from scratch as they realised that three20 was becoming obsolete.
One of the reasons for the choice was the FB branding associated as something that can be trusted!
Just because Facebook is big and supports something isn't necessarily a good thing. Their goals, resources and accepted trade-offs aren't likely the same as your own. For a large company like Facebook, handling large changes to a library aren't a concern because they have essentially limitless development resources. For small operations like mine (and maybe yours) these breaking changes can reduce the time you spend actually improving your product significantly.
For me, the instability and unopinionated nature of the group of technologies that loosely define "React" have been a real turn off. When answers to questions like "What language should you program in?", "How should you store your data?" and "How should I handle routing between pages?" all have no specific answer, it leads to a fragmentation of knowledge that in my past experience usually leads to a technology's demise.
React has some of the best migration policies I've seen. They give plenty of notice about upcoming breaking changes, including messages with pointers output by the library in development mode when code is used in a deprecated way. As well, since there are so many people using React, you can nearly always find a solution to a even obscure problems.
I agree about the un-opinionated nature, though the resulting flexibility has led to some good options, they can be complicated to choose and wire together.
It's difficult to convert a React web app into a React Native app, but you can use many React Native components on the web (via react-native-web. [1]) In other words, you can't run a web app on mobile, but you can run a mobile app on the web.
I just launched a little game that I built with React Native [2], where I have a single codebase that supports iOS, Android, Windows, and web.
It's less about code reuse across a full featured web application and a mobile application. The value comes in that once you master React or React Native, you can easily switch across platforms and be just as efficient. If you learn the ins and outs of Vue and gain depth of best practices / domain knowledge, you are stuck building only for the web.
If you do the same with React, you are then able to take those skills and build VR, Web, iOS, Android, Windows, and soon TVOS ++ many more in the future.
This, along with what has already been stated, is the value of using React vs Vue imo.
I don't see an issue of learning Vue and not being able to write native apps for iOS and Android as a valid one.
Weex quickly gets better and is maintained by Alibaba, a company of the same scale and with development resources comparable to Facebook or Google. NativeScript recently started work on Vue port, the project is already available for testing. That's excluding the Cordova solutions like Onsen and Framework 7 having official Vue ports.
To that, PWA slowly becomes the new trend for mobile development, native apps are not necessarily the optimal solution to every use case.
The "++ many more in the future" is an optimistic assumption. As much as I wish it to be fulfilled, same can be said about any other framework.
the hearsay is that if you used only components that are available for both, it'd take very little extra boiler plate to get it working on both native and web. But all non-trivial apps have their own components and that's what makes native difficult.
This really isn't the case. I have built apps with lots of code reuse on native and web.
Abstract all data logic and you can use the exact same code for both apps. This of course does not include your view layer. If you do it correctly, all you have to do is make a new set of view components. Stateless ones. Because you are injecting the state from your non platform specific components.
It makes it extremely fast to build for other platforms. It just takes a few apps to fully understand how to abstract these things perfectly.
This is not really true, the react-native-web project provides compatibility for all of the fundamental components that you need, such as View, Image, ScrollView, TouchableOpacity, etc.
There are still some missing components [1], but nothing I really needed (or couldn't work around).
If you stick to using `react-native-web` components to design your web UI then your app is likely compatible with React Native and can be run as a mobile app in addition to deployed as a web site.
Do you remember when the first iPhone was released and one of its main marketing points was that it could browse the REAL web? ... Nowadays we are crippling the real web (or at least it's design) so we can have a version for small screens. Oh the irony :(
Nobody. But the fact that they use it now makes it less likely to be abandoned by them that something they don't use (which, while they can't abandon, they haven't adopted either).
Besides in 10 years the whole of IT changes. Don't look for "50 year frameworks".
I honestly don't know, but using it 1. for their main product 2. for many different products in general and 3. rewriting most it (v16) to be more future proof without public API changes sounds like a pretty save bet.
Working with React for almost 3 years now. Came from Angular, Bootstrap, jQuery, etc.. Done small and very large projects with it. It scales better than anything I've used before. It's amazingly reliable and robust.
Looking at Vue I cannot think of 1 single benefit I gain by switching. It doesn't even come close to what React is capable of imao. I really have no clue why people are pushing this at all.. Are there any examples of large projects that switched from React to Vue without suffering a loss?
Vue has electrolytes and it is gluten free. Seriously though I think Vue is the latest shiny example of everything that is wrong with the javascript community.
Javascripts huge problem is the lack of a standard library or better yet a standard way of doing anything. To fill that void alone came NPM. With a million tiny fragmented micro libraries. Then it became a common to start reinventing the wheel and selling your idea to build up your community by claiming the trivial syntax changes make it so much easier to use. I like you have no clue why people are getting so excited about rewriting their apps all the time.
I think of Vue like attempting to reinvent the calculus of react with a clever syntax and more simplified form but results in a Riemann approximation.
I think Vue is more frontend focused where react is achieving far more like react fiber. I do not doubt the power of js community to keep cloning things into forms they are more familiar with and claim a smaller payload is best metric of success.
Who would have thought so much open source collaboration would lead to so much fragmentation?
I wonder what machine learning algos will come up with when they design their own programming language, because I think programming languages are being held back by discussing what syntax makes me feel good to type out.
The problem is that people assume that old = bad.
As soon as one technology is starting to have a nice big community and enough ressources to be usable, the hype for something new destroys it.
People could use Angular 2 Years ago just fine, what on earth happened that it suddenly became so terrible?
Also those are just frontend frameworks! Why is everyone glorifying those??? Is Backend an after thought nowadays? "We got nodeJS... The frontend guy know JS. He will code something, don't worry."
I switched a reasonably large project and there were many gains with no loss. They've all been said before by me and other people, including in this thread. If you don't see them it's because you don't want to.
They switch because it lets you do things the old, incorrect way.
Like using jquery. People want what they don't have to spend time learning. They're used to templates with handlebars. Used to mutating variables. That's why I think so many jquery people and those touting "you don't need jsx or babel" use it.
Because it lets you be lazy and do things they way you're used to instead of better practices that have been found.
It's funny when I hear people act like its way too difficult to setup babel. I'm sorry, but if you're using any ES6 stuff (who doesn't use arrow functions) and you need to support older browsers (a real production app would). Then you're going to need babel and include some polyfills. Go ahead and use vue without all this "horrible babel pipeline" and don't use any language features that have been added in the past three years if that's really what you want.
You probably shouldn't switch. They're both really good templating libraries. Vuejs is smaller an react has react native. The grass is green on both sides.
I think it's important for any comment or post touting the superiority of Vue to also provide insight into the author's experience with and feeings about React. You very rarely hear from devs who were loving React, tried Vue anyway, and came away believers. This leads me to wonder whether it's not so much that Vue is "better," it's more that it operates in paradigms that are intuitive to some individuals and teams in ways that React might not be. I don't see that as a hit against it or anyone but as a very satisfied React, it does make me take every glowing Vue writeup with a grain of salt.
They are pretty similar, though one thing this article lightly touches on is the standalone .vue file, which works absolutely beautifully. JSX feels like a hack to me, and the ability to write HTML, JS, and CSS as such in a single file greatly simplifies everything. You can even use different flavors of each (ES6, Sass, etc) no problem. I would be shocked if this feature doesn't find it's way into react, angular, and others.
Vue and React both seem a little too heavy in boilerplate. It's also interesting that Vue seems to think that mutable state is a good thing (well, vanilla React does have mutable state too...).
For the boilerplate (and large bundle size!) problem we have http://markojs.com that looks very interesting.
However, I think what we really might want is something closer to ClojureScript's re-frame (https://github.com/Day8/re-frame) and Reagent. However, Clojure and it's tools aren't really that great for beginners/juniors and/or people with little experience in FP and lisps.
Maybe in the near future we'll see a little bit more FP style JS solutions pop up?
At the risk of sounding like a shill (I bring up Riot a lot), check out Riot.js. It's a bit rough around the edges in terms of docs/presentation, but it's by far the most minimalistic and most productive "react-like" ui lib I've used.
It's all very very expedient and you can pick it up in a day and be churning out advanced applications with very little mental load. It also supports in-browser compilation so you can get up and running instantly without having to set up Webpack/Browserify/Whatever, which is great for testing it out. Later on you can easily transition to using its offline compiler + whatever packager you want.
The main downside is the community is small. But it's very close to Vanilla JS so I've practically never encountered an issue where I needed riot-specific help.
Our company migrated to vue.js, 4 months ago. Our complex app is messy with JSX, router, and new dev can't keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.
Is it because of the technology or because of the team?
Rhetorical question - I am by no means attacking you or your team, I just clicked on your "is messy with JSX, router" sentence and decided to put my reply under yours.
I see many people tackling React but not developing in a 'React' way. For example I recently saw on HN some user complaining that he had to create N functions to handle N items on a form, while computed properties would have done the trick with only one.
I have no experience with Vue but extensive with React, having developed both small and bigger apps and the only real issue for bigger apps was that it was hard for new users to grok the project initially because of the component-based approach of React.
I do agree that the learning curve for React is pretty steep, but you reap the benefits later on as React 'scales' extremely well in my opinion.
In case anyone reads this and is left wondering, there's no need to have n functions to handle n inputs - you only need one. A simple example would be to set the state based on `event.target.name`.
router and redux make it messy (or rather lack of standard of routing and global state management in react makes every one create their own half assed implementations)...
also transitioning web developers from writing giant HTML pages to thinking about smaller components is a difficult, without dedicated react designer.
All these make non trivial react apps a graveyard of crappy jsx and messy untyped tangles of JavaScript code.
I'd be really surprised if the team you had producing this huge mess was all of a sudden producing super clean code in Vue. It sounds like a very inexperienced team. Probably would be worth investing in a senior developer or team lead to help guide these fresh devs.
> also transitioning web developers from writing giant HTML pages to thinking about smaller components is a difficult, without dedicated react designer.
Can you elaborate? I naturally gravitate towards separating code into components in a framework-agnostic sense - React was very intuitive to me and devs I've talked to seem to feel the same way. Writing huge atomic pieces of HTML is nothing but a huge headache; it's awful to maintain as it results in copious amounts of redundancy / tech debt.
perhaps I was being impatient observing a group of web developers and designers trying to jump into a large React project, practically with no prior experience in react (although familiar with Angularjs, html, css, js, dom) - however the fact is that after 3 months of dev, the react codebase turned into an absolute mess - albeit following best practices around branches, testing, pull request reviews, continuous delivery to staging environments etc...
The main issues seemed to do with global state management favored by Redux (hello global variables, I thought we were over you years ago :) ) and tendency to jam html into react components designed as screens, rather than components.
I have no doubt VueJS will be the most popular framework in a couple of years, right now the adoption rate is not as fast as it could be because people have already invested in React/Angular so switching so soon looks like a downside, but people just getting started and that have zero investment in any of the 3 frameworks will go for VueJS without a doubt, because is much more easy to learn and equally or even more powerful.
That was my case, I spent several years sticking to jQuery and waiting for the wave of "a new JS framework out every x months" was over, and after researching which framework to learn, VueJS was a clear winner.
The syntax is way more simple and elegant, and as soon as Weex is stable it will be able to power mobile apps too!
There is a bit of React kool-aid in here, makes me really wonder if any of them have actually tried using Vue because the benefits and improvements you will see with Vue are immediately noticed.
To be frank, the OP actually did a poor job of presenting Vue here because it only mentioned the similarities, which doesn't do any good for Vue. It did not get into areas where Vue is better than React, which is what most would be interested in hearing.
If you ever put React and Vue.js side by side and compare, it is almost a no brainer to switch. How it handles bindings, the way they got Redux done right, and the single file component style, are all improvements over React IMO. I'd jokingly say if React were to keep improving and evolving for the next couple years, it may possibly look like Vue.js as of today.
Interesting. I hadn't touched React in months and recently spent a week with Vue. I had trouble getting up and running and was soon longing for React, or at least what I remembered of it.
While Vue is awesome, Nuxt is quite horrible. Nuxt's developers have made some very weird design choices that you can't opt out of if you want to use it. For example, you have to define your routes by defining a directory structure[1], which means you have nonsense tree structures, no aliasing, etc. While they've provided an easy to start SSR solution, the rest of it is simply bad.
Well, first, vue.js doesn't force you to use components. So you can just throw your data into the HTML page and see what happens. It's a huge win in the early phase of the project, as most of the time your page will change so much you will not see any reusable components before months. It's a real time saver, and let you refactor only the important parts in components later.
Secondly, you are not tied to JSX. While you can use JSX with Vue, it comes with a very simple and clean templating language that is much more natural to manipulate than mixing JS and a fake HTML.
What's more, you don't need webpack, not even babel to use Vue. You can actually drop the 30ko (gzip + minified) of the lib and create a decent projet as-is. Of course you can later setup a whole pipeline, with even server side rendering if you wish. But for a start, you can just use it as easily has you used to with jquery. Which means people comming to the project will be easy to train to: it takes one afternoon to comprehend react hello world. It's the time to understand the whole Vue lib.
Eventually the community is great : the doc is well written, the tooling is full of small details (such as .once.prevent or the dict classes) that makes your life easier and the API surface is kept small. Most third party tools adopt the same philosophy: pragmatic, useful, scale down then up.
Honestly after so much react, I'm happy I found Vue. It's just better. Doing training for both, I can also tell you that training for Vue is 2 orders of magnitude easier than react.
Vue is what react should have been really. But let's not blame react. The react dev created shoulders for the vue devs to stand one.
To help put this in perspective, how heavily did you use React before switching to Vue? How did you feel about it at the time, before you were aware of Vue?
I used react for one year, for the web, but not react native. I'll be honest: once I got fluent in react, I still didn't enjoy it.
Too much scrolling around, looking up the doc for every simple things, hard to integrate with legacy Python/Ruby/PHP frameworks, etc.
I went from jQuery then Angular 1, and was much less productive in React.
Also, introducing react to a new member in the team has always been dreadful.
All in all, I never benefited from the concurrency part. The performance yes, and the structure for the SPA. But the whole immutable constraint didn't pay off for me in the end, so I felt my stack was overkill.
Do people like Vue because it's more declarative than react? Is it mostly angular devs switching and getting the best of react but still having directives?
I like the control react gives me without the black box 'compiler' which seems like it makes a bunch more choices for you.
I hate directives. There is nothing you can do with them you can't do with just plain callbacks or putting React components inside another that renders its children. HTML templating directives are stupid too, I find myself looking up syntax references for angular even though I've used it for ages. (Think semicolons and magic variables like `$event` or `index` in *ngFor bindings – you don't need these unfortunate and necessary syntactic choices if you just use JSX.)
So yeah, Vue is probably slightly more declarative than react, at the usual cost of having to learn all the declarations. When I first looked at it, I saw the 'v-' prefix on HTML attributes and just stopped.
I recently started forking the github package for atom which is built with react. I found it very confusing that render methods pass scope variables to controllers using directives. The number of times a variable gets passed back and forth from a JavaScript class to a template directive is just silly.
I did ignored all the modern js frameworks for a long time, so for me Vue is jquery replacement, I like that you can use it in lightweight way and mix it into legacy apps.
I'd say that this is a matter of personal taste. After having worked extensively with both, I still can't get used the JSX-way of doing interpolation or conditionals and find the infamous Angular style template easier to reason about and work with.
(2) By "Angular style templates" do you mean Vue's Single File Components? Because from my POV they're glorious, and the primary reason I'd be reluctant to use React instead of Vue.
Re #1: for both React and Vue, if you don't stick to the most common and standard methods for implementing functionality, you're going to cause yourself a lot of unnecessary pain. Everything around those ecosystems (documentation, debugging tools, libraries, etc) is designed for streamlining development for people who don't stray from the mainstream.
Actually the opposite for me, and the original reason I went with Vue (tho after using it more I like a lot about it). I just do not get the appeal of JSX. Directives are meh, but I still prefer it to JSX.
Do you think that your preference is just from your previous experience? JSX feels like uninhibited templating to me, which is great when it is done right (and a little crazy when done poorly). I also feel like it gives cleaner error messages.
Vue (+ ESLint) give pretty clear errors when you've messed up that make it quick to fix.
But yea, I mean I think it's subjective for most people. I'm not sure there's any real reason to go one or the other outside of developer happiness (could be wrong, though). A big part of Vue is to have a low learning curve and be less opinionated. So it feels more like enhancing your workflow (either in existing apps or new ones) than adopting a whole new way of doing things. I'm just personally more into that.
Also, for what it's worth, you can use JSX with Vue. The only downside I can think of is any time you have a problem it might be hard to find solutions since most people stick to directives. If you already know JSX, though, that might not be an issue.
At our company we built single-page apps using Vuejs. It's very simple to pick up and easy to merge with existing templates and code (as it looks and feels a lot like standard HTML).
it takes less than a day for a dev to be up and running with Vuejs, where React is a bit more tedious to get started with.
The major problem with this tutorial is that it doesn't cover single file components (https://vuejs.org/v2/guide/single-file-components.html) at all, which are superior to (and preferred to) implementing string based render functions (which rely on a runtime template compiler). Indeed, the Vue NPM package doesn't even provide the runtime template compiler by default. Stuff like what the article promotes are great for development if you just want to include a <script> file, but are clunkier than the way that you're actually supposed to do things.
I did not see it as a problem. I appreciated the light weight approach being shown first. In fact, for my use case, I prefer not to bring in the ecosystem. That could change, and the article introduces the heavier approach.
> the way that you're actually supposed to do things
The one message that comes out of the Vue camp and happy users is that Vue can fit many project types - small to large. Not having to always use single file components is the pragmatic part of that inclusionary message.
I've never used Vue, and in many ways am the target audience of this post. From my perspective, I think he took the right approach. Starting right off with a .vue file would be pretty alien to newcomers.
I remember a couple of years ago when people were posting about switching from Angular to React. Now it's React to Vue. I'm going to be honest and concede that Vue may well be better than React. But having used React productively for a couple of years now, I don't really see much point in throwing out something that works well in favour of something else that also works well. Back when it was "why we switched from Angular to React", it was easy to understand because Angular 1 is awful. But React isn't awful at all and I don't really see what I'm going to gain by switching to Vue.
What are good examples of popular websites (not behind a login) that make use of Vue or React?
I ask because I keep reading about it, all programmers seem to use it, but I just don't come across websites that use it. Is it only used for backend dashboards? Or do all Vue/React sites fail to gain traction for some reason?
Facebook, Facebook Messenger, Instagram, Netflix, Reddit Mobile, new Reddit Profile pages are all high profile sites using React that aren't just 'backend dashboards'.
Interesting. The ones not behind a login (Twitter,AirBnB,Reddit Mobile) are sites that feel laggy and clunky to me. With slow loading content, loading animations, laggy scrolling, too much stuff opening in new tabs, confusing interfaces.
I wonder if React causes/incentivises this or if it's design decisions by the coders/designers/managers.
In contrast, pages like Reddit Desktop, Google and Amazon work much better for me.
I don't contest that those sites feel laggy and clunky, whether by poor load time, poor UX/UI, or some larger dysfunction.
However, I would offer that the usage of React is not so much the cause of poor performance but rather a step taken to remedy scale lag. Large apps like the one you mention are big behemoths that take months to adopt new architectures and patterns, but those activities are required to ensure the scalability of the infrastructure and product development. During the time those apps are not fully transitioned to React (and Redux, and isomorphic rendering, and a fully-featured API, and webpack, and a litany of other tools), they might feel half-baked or sluggish, because you may have a page loaded with server-side template rendering, but half of your components on the page are upgraded to React, and take a second to initialize.
IMO, React is a tool that provides an appropriately rigorous rubric for component development and a structure for large-scale interplay of reusable/composable frontend components, which was required for it to have any viability for a large org like Facebook. A lot of web apps are on the long trek to avail that potential fully, but while they're in transition, the experience of those apps will be a little disjointed or degraded.
Big web properties like these tend to be developed by huge teams and tend to prioritize features over performance.
It's partly Conway's law and partly the result of having lots of users and features being easier to add than take away.
None of these things really have much to do with React. If your app was going to be slow anyway, React won't help you. However, like Angular, React makes it easier to break things down into components and work on them separately, so it's popular with the same big teams that make bulky and slow web pages, just like Angular was before it. Correlation, not causation.
Unlike Angular, React is also fantastic for small teams making lean pages that load blazing fast, which is why it's become so popular so quickly.
JS libraries (like React) are just tools developers have. They can make fast sites with them, and they can make slow sites with them. We use React because it makes it easier to optimise our site to make it load very fast.
Actually the new Twitter Mobile called Twitter Lite is super fast, did you try the latest version? It's a full progressive web app that works offline, has notifications and super fast scrolling. It was designed to work on low end Android device, give it a try: https://mobile.twitter.com
At first it gives me a white page with a little blue twitter logo. Then the twitter logo disappears and I see a white page for a second. Then it gives me a strange blue page with a giant twitter logo and two buttons glued to the bottom that tell me to log in.
I don't know why you're arbitrarily dividing the data into "behind a login" and, well, "not". I doesn't make any difference.
For the rest: opening in tabs is obviously a design choice. So are "confusing interfaces"–whatever that may mean, because if those reddit and twitter mobile sites are confusing you, good luck with amazon. React build a DOM. You can make a table-based layout with a spinning e-mail icon if that's what you want.
As for load times: mobile.reddit.com comes in at just under 1MB, but that's compressed to 400kb which is basically irrelevant once you expand the first image posts. JS is just about 200kb compressed.
And once it's loaded, only the JSON-encoded data goes over the wire: on the first click anywhere, the data transfer is amortised because the hundreds of <div class="asdasda"> don't have to be transferred.
What part of Facebook? I know the search page on Facebook mobile web version uses React. But what else? It's not like every Facebook page uses React, most pages are still the PHP rendered legacy stuff, that is around for many years.
Vue and React are mostly done for building web apps behind login, public facing websites are usually static html and that's not such a great use case for Vue and React except maybe in the comment section which is usually in an iframe anyway such as a disqus or Facebook comments (which uses react.js).
Aside - Jeffrey Way, who runs a popular tutorial site called Laracasts, maintains a free Learning Vue series. It's worth checking out, Jeffrey is a great teacher.
> Rebuilding the Emoji Picker in React resulted in faster rendering and simplified code that’s easier to maintain. We’re extending these gains to the rest of our codebase by transitioning fully to React
I'm currently making a mobile f2p game in Unity. I previously had created a Cocoa app for the game item creation/ db management. Since we changed the architecture of the game pretty heavily, I needed to rewrite the tool. I chose Electron + Vue over Cocoa. Despite having very little web dev/JS experience, I was able to make a fully functioning app in under 3 months that syncs with a server and has multi user editing. Huge fan of Vue. Haven't had the pleasure/displeasure of React so can't really compare.
I've always felt that React is a constantly churning ecosystem. The patterns keep changing too fast for me to settle down or catch up. That way Vue.js has done an amazing job. Sort of reminded me of Rails. Today I'm happy with Vue.js for my small to medium applications. Keeps things simple and beautiful.
> ... If message is passed as a prop to any child components, Vue knows that they depend on this will be automatically re-rendered as well. That’s why there’s no need for a shouldComponentUpdate method on Vue components.
I think that React does the same? If a component's props and state don't change, shouldComponentUpdate doesn't get called at all IIRC. shouldComponentUpdate, instead, is useful when a state or prop was changed, but it's possible to quickly detect that the change won't require a DOM update anyway.
There's a default shouldComponentUpdate implementation in the React.Component. It does a shallow compare of state and props. When you define shouldComponentUpdate you are just overriding that implementation. So it's always called, its just you don't need to always define it.
"When a component's props or state change, React decides whether an actual DOM update is necessary by comparing the newly returned element with the previously rendered one."
My point is that if a component doesn't receive a setState or new props it just doesn't start the rendering cycle at all (AFAIK), so shouldComponentUpdate doesn't get called at all.
When I switched from Ember to react what I missed the most was the two ways binding, the computed properties and the router. From dabbling in Vue.js it seems to have incorporated the best of both worlds. I read over some of the technical implementation and it seems pretty sane. It seems too good to be true and I am honestly wondering what is the catch. Everything I have read about vue has been very positive so far. I am curious what are some of the cons of using vue
I stopped reading at "both are fast and light weight" because I don't find react to be "light weight". React is 275K (nearly a quarter of a meg) when it is minified and gzipped. 750K when it is not minified/gziped.
We're talking about a web page UI here. It should be tiny for users with slow connections. React seems big to me and I can't justify it except in very large applications.
As such, I struggle to find the reason React is so popular. Perhaps I'm a bit old school. People say it's easy to reason about, but I don't find that to be true in real world large applications with a lot of developers working on them.
Still, I'm trying to like react, but these things are a struggle for me.
I'm including everything you need to deploy in those numbers. You included only React and not React-Dom. My own try at setting up React results in a 750k js file when I follow the instructions below. I realize this isn't minified yet and I welcome feedback on how to make it better.
The top search results for react minified size show similar numbers to my 250k. There are a lot of people throwing out a lot of numbers that are different. Versions likely play a role, especially after 15. Here are some references.
Nothing I can find references a size as small as you mention with react and react dom. Most recommend writing with ES2016 which probably adds Babel overhead as well. When I build "Hello World" myself, I can't get anywhere near the small sizes.
I'd love someone to give me a proper smack-down on this. I want to love React since it's a recent requirement of my job. But with my current knowledge of it, I can't seem to get the size down.
While I agree that React (with ReactDOM) is heavier than it probably should be, a production build is around 140k minified, 45k min+gzipped.
I personally find React applications to be fairly easy to navigate compared to other JS projects, but my use of it has primarily been porting applications from Angular, Knockout or Asp.net Webforms to React.. and I find it a lot easier to work with than those personally. Haven't tried Vue though.
I am assuming that, yes. Websites with mass appeal should probably think about this. Yeah, I develop on a MacBook Pro with Chrome on a massive network connection, but I do an awful lot of web browsing on my phone from resteraunts and offices where there is somewhat crappy data coverage.
I don't get it. Lets say that you have a well formed team, then you have a designer. A designer is who does the UI but know or care so little about programming. With React, the UI is practically JSX that very few people know (in comparison with html) and what we will get instead?, the result is the same html that it tries to avoid.
JSX is very close to HTML. Maybe the issue is expecting designers who have zero dev skills to build front ends in a time of responsive design and rich JS interfaces. You wouldn't hire a print designer with no Photoshop experience to design a site, and you shouldn't hire a graphic designer with no web dev skills to build front ends. If you're team is really well formed, you might have an experienced graphic designer, a UX expert, and a front end developer who does the actual building as well as making day-to-day design decisions. The design/interface experts would work at a higher level of creating an overarching design language and UX guidelines.
I actually was thinking it was a non-issue until I saw a designer actually struggle with working with JSX for doing some animation (I had to help him out), and the designer had some knowledge of JS.
Both are very very similar and if you are familiar with one you will be able to pick up the other quite easily.
In regards to webpages both are capable of doing the same things and fit the same uses cases.
That said however if I was to start a greenfield application today, I would choose React. The reason for this is that react is better known, it is easier to find solutions for, and it has more mature guidelines for things like project structure and best practices.
Vue is good competition for React and it will certainly help keep it on it's toes. However in regards to longevity, I feel React will be around a lot longer than Vue. React has the full support of facebook and is being used by other major vendors. Vue is also used by some big sites, however it has no official backing that I know of and is maintained by a "Benevolent dictator for life".
In a year or two I predict that I will see another article with a title along the lines of "Switching From React To <insert new hotness here>". It is very unlikely in my opinion that I will see a "Switching From Vue To <insert new hotness here>" article.