Switching From React To Vue.js
vuejsdevelopers.com
vuejsdevelopers.com
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.
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.
China also has multiple languages and dialects, see: https://en.wikipedia.org/wiki/Languages_of_China#/media/File...
English is the lingua franca of software development and I don't see that changing anytime soon.
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.
That might also be because once people get to Vue, they don't leave it for any "new hotness".
It's about maturity and churn, not something inherent in programming.
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.
https://github.com/vuejs/vue-router
--
https://vuejs.org/v2/guide/state-management.html
Vue offers vuex: our own Elm-inspired state management library.
--
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...
You might as well just write your own react-router implementation for every react project you work on.
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.
Here's what actually happened:
v1: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v2: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v3 mostly just removed APIs that were deprecated in v2. v3 continues being maintained even beyond the v4.0.0 release.
v4: https://github.com/ReactTraining/react-router/blob/master/pa...
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.
The kind of standard that just doesn't stop giving backwards incompatible BS releases...
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.
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?
(I'm one of the current maintainers of Redux.)
Vue has a lot of things going for it. Documentation is not one of them.
When using Vue CLI it configures a project for you with vue-router and vuex.
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.
Besides in 10 years the whole of IT changes. Don't look for "50 year frameworks".
Previous instances of that pattern:
- three20 (used in FB ios app https://en.wikipedia.org/wiki/Three20)
- GWT
- Angular is actually a similar instance of that problem, to some extent
If "large company" switches their goal at some point, then you're still alone.
Currently I'm kind of more confident (in some way) to the future stability of Vue, than of React (just a gut feeling, time will tell!).
Whether it's kept up with the state of the art I don't know, but I think that's a different thing.
I find the argument also quite disturbing because this will add to the already existing monopolies of these "large companies".
One of the reasons for the choice was the FB branding associated as something that can be trusted!
Options like React-Native
There are still some missing components [1], but nothing I really needed (or couldn't work around).
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.
Now I can do them all with one framework.
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.
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.
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.
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.
Not in hobbyspace. But in Deliver-a-Product World, it matters a lot.
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.
2. There is NativeScript which supports Angular 2+ and shortly Vue, and Weex build by Alibaba on top of Vue.
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?
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.
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."
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.
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?
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.
If you like them, check out RE:DOM - the author of that one did some work on Riot too.
RE:DOM might be even more minimalistic and lightweight than Riot.
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.
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.
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.
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.
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!
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.
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.
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.
I like the control react gives me without the black box 'compiler' which seems like it makes a bunch more choices for you.
I'm probably biased, someone cmv?
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.
(but ironically, react-typescript got props checking faster...)
(1) You can use JSX with Vue. https://vuejs.org/v2/guide/render-function.html#JSX
(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.
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.
Having said that, you might be interested to know that there's an official Babel plugin that lets you write your Vue templates with JSX: https://github.com/vuejs/babel-plugin-transform-vue-jsx
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.
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.
But that is important to note - it's not the most performance way to do it.
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?
Airbnb uses React https://www.airbnb.com.au/rooms/432044
Facebook, Facebook Messenger, Instagram, Netflix, Reddit Mobile, new Reddit Profile pages are all high profile sites using React that aren't just 'backend dashboards'.
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.
Both. React makes it easier to write complex JavaScript web apps. Complex JavaScript means you have a lot of rope with which to hang yourself.
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.
The new Reddit profile pages do not.
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.
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.
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.
https://www.reddit.com/user/spez
Aren't those just static html pages rendered serverside?
Is there a blog post about them or something?
I just know that my react-devtools extension and the redux state inspector both lit up when I went on that page.
The old pages like below:
https://www.reddit.com/user/HeinieKaboobler
Are server side rendered.
It's not a popular change. Mostly because of people feeling it'd pull focus from subreddits to profiles, but also some complaints about the performance loss and lower density: https://www.reddit.com/r/announcements/comments/60p3n1/tldr_...
Here is an example where a product demo was built with VueJS while the rest of the site is not. https://sightengine.com/demo
From https://slack.engineering/rebuilding-slacks-emoji-picker-in-...
> 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
Can't wait to see Slack's app be just as slow.
From what I understand, Vue is quite popular with the laravel community.
A more complete solution, Nuxt.js[2], appears to be gaining in popularity as well.
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.
"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.
I understand the concept but Vue was realeased in February 2014, which seems pretty ancient in JavaScript years.
Wasn't React released only a year prior? Well, it's been around since 2011 but it was open sourced in 2013.
Either way, Vue has been around and in use for a little while now.
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.
Uhm, React websites run great in Chrome on a MacBook Pro. You seem to think that most web developers care about users on slow connections.
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.
That statement is completely false.
react@15.5.4:
react.min.js is 21335 bytes uncompressed, 7353 bytes gzipped.
https://www.joeldare.com/blog/post/create-a-react-app/
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.
https://gist.github.com/Restuta/cda69e50a853aa64912d
https://stackoverflow.com/questions/19807946/why-is-reacts-f...
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.
https://webpack.github.io/docs/list-of-plugins.html#uglifyjs...
Aaaand you've just just 90% of projects...