Vue.js vs. React: what happened in 2017
pixeljets.com
pixeljets.com
My “success story” is how Vue helped me to massively improve our user experience in low bandwidth or high latency environments. Our startup is trying to reinvent the ways that companies approach their review process, and one of the things we do is run a workshop on delivering actionable feedback during the review cycle. We have users log into our app during the workshop, and this often happens in conference rooms over congested WiFi. Our MVP used turbolinks, so it felt generally “snappy” during normal use, but could feel sluggish if moderate latency was introduced (such as a congested router).
Since I completed the rewrite to Vue (which took only about two weeks because of how simple it was to pick up, even for a non frontend person like myself), we’ve had multiple launches that both would have likely bombed had we not done the work to move to something less dependent on a tradition client -> server -> client response cycle to render the next “page”.
Either way, I’ve become an advocate for vue. I love single file components, love the documentation, and am very happy with the community libraries. All in all, I’m very bullish for Vue in 2018 as a happy new users.
Have you had any exposure to using vue as a progressive web app that can sync and work offline first?
Have you come across any vue.js offline app experiences?
For us, the reason why we don't necessarily "need" PWA or full offline is that we do have an initial online component that is dynamic, so fully supporting an offline mode (a la, full on iOS or Android app) would change a lot of assumptions & optimizations we've made with how our product works. PWA seems promising, but it still feels slightly early to me. It's not that I don't think it will eventually win, but right now it has just enough complexity with minimal payoff, that I've punted for now (although it's probably closest to what we're looking for).
The current incarnation / wave / interpretation of PWA still seems to be maturing. The js layer definitely brings its challenges and rewards, while browser innovation and evolution continues to better support PWA.
Still.. A bit of this PWA stuff makes me feel like we're going through a cycle from the past.
Syncing ones data and being offline for the majority of time to work on a mobile laptop or pda was normal with dialup, prior to wifi. Tools like Lotus Notes apps ran and synced data for offline use reasonably well including handling conflicts (while not so good at other things).
Offline first syncing is still largely a need inucrative remote industrial operations today and for the majority of countries in the world whom have much less bandwidth access, I'm glad PWA is emerging as a tool along with WebAssembly.
I found a few projects using vue and PWA and will try some things out - want to avoid any assumptions of adding PWA later as it's a key to my problem set.
It still requires a massive payload to be sent across the wire, as well as a full render on the server, so it's not the "king of efficiency", but it definitely improves the end user experience in many ways.
In my case, I wanted an even snappier experience, where a user clicking on a button would trigger an immediate transition, with the "saving" happening behind the scenes. Before, on a slow or bogged down connection, you could see page transitions take second(s), which felt like an eternity when you had to go through our 50+ screens during our workshop. Now, with heavier backgrounding, those transitions are instantaneous, and the end-user doesn't need to wait but a millisecond (draw time) for the next page.
I'm learning Rails and haven't gotten to that stuff yet, but I'm wondering whether I should even waste my time learning them if something like Vue is just superior and just as easy to implement.
Turbolinks is amazing.
Also tutorials for react+mobx.
We jumped directly from a flux-like state management to mobx (skipping Redux) and the development time has gone down significantly as well.
The reason I'm asking is that I've been diving into Elixir and Phoenix, and I'm wondering if the difference in speed between those two would obviate the 'need' for React/Vue (or even be a faster solution). I'm a front-end dude, so no 'enemy' of those, but I keep finding myself preferring an Elixir-based (and thus server-side) solution because it's just such a nice language and so convenient to not have to switch for significant logic.
For example, the fact that {} in js is a map/object, where in Elixir it is a tuple (a map would be %{}) keeps tripping me up, and it makes me generally either lean toward mostly server-side with some basic js snippets (Turbolinks style), or alternatively mostly client-side (React/Redux) with a 'dump' api backend in Elixir.
At this point I'd really love to lean toward the server-side, but stories like yours make me wonder about that leaning.
Vue is better for onboarding people more in tune with "classic" html + js development; and that's where the advantages end as far as I'm concerned. This might be a big win for some people.
The way I reason about it is that React is simple, Vue is easy. When you take into account Vue's templating language, React's api is small in comparison. A beginner won't know how to do some common use cases reading React's docs, when Vue might have a something built-in in its templating language (e.g. slots, or the component tag for dynamic components).
Slightly annoyed with Vuex too because of its slightly leaky abstraction. You have to remember to setup the properties you mutate so the reactivity will detect a change; and also remember not use array indexes arrays cause it can't detect changes otherwise. The array index thing will be fixed in the next version when they drop support for some older IE. Using Typescript would probably help a bit here, although Typescript being useless for checking Vue templates really feels like a huge chunk of its value is wasted.
Typescript is not currently available in the official blessed boilerplate which greatly affects its uptake in the Vue community.
Anyway, if you already know React, there is zero advantage in investing time in Vue.
That and when you add JSX to mithril, the api just feels so simple and i rarely find myself checking the docs for something.
I especially like the fact that I can easily include it as a script, like Vue, and don't have to have a build chain. That really decreases complexity for smaller projects.
It's certainly common to use React in a larger application that uses a build chain, and that's the recommended approach, but it's not required.
[0] https://raw.githubusercontent.com/reactjs/reactjs.org/master...
https://github.com/styfle/react-server-example-tsx
One of the reasons I picked up React is that views could be type checked at compile time which was not possible with Handlebars a few years ago.
I believe there is work being done to the TS language service to get type checking in other template languages at some point.
[0] https://github.com/NetCoreTemplates/vue-spa
[1] https://github.com/NetFrameworkTemplates/vue-spa-netfx
Vue is also currently our most popular .NET Core 2.0 SPA Template, followed by React.
This is a positive thing imo. It's a declaration of your data schema. You can reference it to remember what kind of data you're working with. This gets rid of unproductive moments like "What was the name of this property again? Is this property an object or an array? Is it nested inside this object or that object?"
Things that are a deal breaker for me:
Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great
State management... I cut my teeth with Ember professionally for a few years, and really loved it up until I built a data intensive app. Having state spread across different controllers is great when you have many different routes and pages, but if one page turns in to a photoshop like app, controllers make a terrible state management tool. It doesn't seem overly complicated to me to use redux along with react-redux's connect function to connect regular functions returning JSX to your state object. Looking at Vue.js, it seems like I need to learn Ember-lite + Angular (custom directives).
> let me generate templates using the language I already know, JSX is great
https://vuejs.org/v2/guide/render-function.html#JSX
> controllers make a terrible state management tool.
I haven't used react-redux but vuex is essentially the same decoupling, and there's very little boilerplate. https://vuex.vuejs.org/en/intro.html
Not everyone knows JSX, so while that argument applies to you, it doesn't apply in general.
v-if is actually a big reason I prefer Vue. Ternary operators in JSX are pretty ugly. The other is that Vuex just feels so perfectly integrated. I've never felt Redux blends in particularly cleanly, though I certainly don't judge people that do prefer it.
All of the following is neither Javascript nor HTML:
v-for=”x in list”
v-if=”conditional”
v-on:click=“function”
v-bind:key=“something.id”
Especially for the else-if case - you end up with repetitive conditionals to replicate that.
Exactly! I don't know, but I've always found that disgusting. It turned me off React when I first saw it, and it still does.
Then people use it to defend react, and I'm just like 'Lolwut? Did we spend years learning that SOC is a good thing only to throw it out of the window?'
I'll be the first to admit that any Vue template quickly becomes soup as well, but at least it's only half of the soup.
Is it just younger developers that think React is the best thing since sliced bread?
You can have as much separation of concern as you like with React.
^ this.
It directly translates to `React.createElement`. This is also why everything inside {} is pure Javascript including things like proper `this` etc.
If you're a startup, it's tempting for many founders to go in headfirst with a Vue or React. In my opinion, it's rarely necessary, and in the end a lot of the stuff has to be thrown out if underlying foundations change. I see it as web development's version of premature optimization.
On the other hand, when I kept all my work in django templates, erb, blade, etc. and just script JS by hand, there's less of a penalty when the data flow changes. When I was using a JS framework, the refactoring was so painful I seriously considered throwing the whole thing out and starting from scratch. Heh, I'd have been better off not buying in so early on.
As a stop-gap, I'm using pjax. (https://github.com/defunkt/jquery-pjax)
My plan is after stuff is solid and in production and the product/service/business is moving forward, taking an incremental approach to moving to vue/react/etc.
P.S. kudos to react for removing the patent stuff in v16.
Ever had a class in school which you hated at the time because it felt super hard, but loved in hindsight because of how much you learned? same sort of vibe. Fight through the pain.
Also, I see Shadow DOM, proper html/js templates and future JS upgrades (modules, etc...) making React totally usesless, or either they will have to uproot themselves all over again to maintain equal performance from native systems.
As soon as I saw that rounded corners were coming to CSS, I stopped all the stupid hacks, I feel like JSX is an immature hack on top of mature tech. Eventually something else will come along and supplant it.
A good indicator of if a technology is going to explode, is if emerging language users are excited about it, as good ideas tend to trickle down from the more advanced/research-y ecosystems which aren't as constrained by legacy. So for example React was built by a user of OCaml.
ClojureScript early adopted React.js through the Om project in 2013 and there is a growing number of competing React adapters, Clojure rewrites etc. I first saw virtual-dom in ClojureScript in 2012 (eight months before React came out).
Number of ClojureScript projects with traction that are based on vue? Zero, that I am aware of.
The Vue reactive and dom model is pretty much entirely the same as React, it's just its layout for frontend applications that's wildly different. Even if you wanted the component-file style thing in clojure (or html-templates), you wouldn't need Vue to do it.
React and Vue are both great technologies, but with Teact the template syntax is optional, and no lisp user wants another syntax...
Last year I had another look at ClojureScript and it felt like a ghost town. This saddens me. There are a few inspiring talks now and then, but nothing I found worth using in a project.
In terms of libraries, I haven't found anything that comes close to reagent/re-frame for building complex UIs.
Meanwhile, hot code reloading with Figwheel works beautifully, and you have a REPL for running code in the browser straight from the editor.
My team is very happy with the results of building ClojureScript based applications. I'd be curious to hear why you feel that there's nothing that's worth putting in a project.
I guess compared to the frantic pace of the JS ecosystem, the ClojureScript ecosystem does feel tiny and slow-paced. But I don't mind that.
2) Ruby (1995) showed no signs of explosion whatsoever, first rails had to come out (2005), and then industry had to realize that it was a good idea (Rails 3 is the first version I ever used, that was in 2009?). So that's 10-14 years. ClojureScript is 6. Give it a chance!
- In 2016:
React - 91% satisfaction
Vue - 91% satisfaction
Angular 2 - 65% satisfaction
No framework - 65% satisfaction
Ember - 50% satisfaction
Angular - 40% satisfaction
Backbone - 31% satisfaction
- In 2017:
React - 93% satisfaction
Vue - 91% satisfaction
Angular 2 - 66% satisfaction
No framework - 65% satisfaction
Aurelia - 56% satisfaction
Polymer - 53% satisfaction
Ember - 41% satisfaction
Angular - 33% satisfaction
Backbone - 23% satisfaction
It's especially interesting that many of the frameworks have a lower satisfaction percentage than using "no framework". Of course this could be largely attributed to who is using no framework. I have encountered a minority of developers (usually backend devs) who think front-end frameworks are nonsense and prefer to just write a bunch of jQuery. Also, if you are working on Wordpress sites, then frameworks are often not necessary.
I've written production code in some of these frameworks (Backbone, Angular 1, Ember, and React) and I would have to say these results are more or less consistent with my experience. I love React and don't feel the need to try anything else.
Also OP has skin in the game to justify to his team that vue was the correct choice.
Nice as an opinion piece but too many red flags to be considered fair and unbiased.
> Vue.js will be dominating only in the web
OP did not say they would've used React given the choice, they said it would have made some things simpler
Your reading and subtle re-wording of OPs comments misrepresent what OP actually says.
> our stack would be simpler if we chose React.js for the web. We definitely do not regret choosing Vue.js for web, read more in my previous post why we did that, my expectations on Vue.js web domination are becoming the reality
React isn't just popular. It also consistently provides good developer experience. You have to compete not only against React's popularity, but also against that.
React:
- Used it, would use again: 14k
- Used it, would not use it again: 1k (7%)
Vue:
- Used it, would use again: 4.6k
- Used it, would not use it again: 454 (9.8%)
That ~3% difference in people who tried it, and didn't like it could be the difference between make it and break it when coming up against React. "I've heard about it, and I'm not interested" is another important metric.
---
Personal take:
Things I personally don't like in Vue:
- String-based programming so prevalent these days.
JSX is a thin layer on top of regular Javascript/Typescript. Where as Vue is often this:
<li v-for="todo in todos">
- It breaks Javascript and how it works:
var app5 = new Vue({
el: '#app-5',
data: {
message: 'Hello Vue.js!'
},
methods: {
reverseMessage: function () {
this.message = this.message.split('').reverse().join('')
}
}
})
Vue is definitely doing things behind the scenes, but it's nothing all that complicated.
I wouldn't say it's hoisting. It uses the data function to create component instance objects which it then adds the template's computed props/methods/watchers etc on to, and links with the life cycle hooks.
If you created the component object yourself instead of a definition for it, there would be less magic going on for sure, but things would be much less organized.
(Minor: I don't use vue without webpack, but I assume data should be a function which returns a data instance, so what you've written won't work in Vue unless it's different for the top level component?)
<template>
<p v-text="message" class="some-class">
</p>
<button v-on:click="reverseMessage">
</button>
</template>
<script>
export default {
data() {
return {
message: "Hello Vue.js!"
};
},
methods: {
reverseMessage(){
this.message = this.message.split('').reverse().join('');
},
},
}
</script>
<style>
.some-class{
color: black;
}
</style>
The game-changer with React is that it presents a declarative way to specify your DOM content, which in turn can significantly reduce the number of cases you have to consider in your rendering and state management code, and it's fast enough to make that work in a lot of real world situations.
In my friend circle everyone wanted/were using Angular.js but it was too heavy for actual production use while react showed much better performance in the benchmarks (almost closer to Dom).
MVVM was a thing for like that six month period in 2012 when backbone.js was causing callback hell and React.js hadn't come out yet, MVVM is an attempt to abstract over the callbacks.
React leads the pack in:
- consistently good DX
- it’s used at FB so all decisions they make are guided by their own practical needs: don’t break backwards ompatibility, don’t break tools, improve tools, create tools where none existed etc. etc. etc.
React team has a very pragmatic approach to development, and it shows.
After looking into this further it seems like Vue Templates also differentiate between values and components. In React I often write components which can take in either: a good example is text which the consumer might want to format. You can easily write the component so that they pass in a string or a <span /> element.
Vue has a lot of good ideas but the templates are almost a non-starter for me.
Redux is not as easy but you can go with MobX instead for easier state management.
You can have vue render jsx or templates, but in practice you can make interactive components very simply using templates which are foundationally simpler and easier to grasp than JSX.
Just reading about slot and slot-scope makes me think Vue's reputation for simplicity is overblown.
Now that they got rid of it, I have no such concern investing time in react for the short/mid term term.
The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern.
What is wrong with me?
Vue currently seems to be a mix bag of styles. My take away from the little that I dabbled: - You need the vue-class-component dependency in order to declare class based components, otherwise, you're stuck with the awkward object literal notation - For state management using Vuex. You are are limited to the object literal style to declare your state store. Very awkward to work with.
Yes to get some data bound to a template and rendered out, Vue takes very little amount of code. However that is not a meaningful benefit to me. I feel Angular's complete framework and class based convention is much more suitable for a team environment.
If you resort to manual change detection, then it's an obvious sign of needing to refactor your design.
If I build a grid with 15 columns and 3500 rows (actual issue faced) which contains 3 characters in a cell and a menu when clicking on the cell.
Out of the box Angular took ~8 seconds to make it appear on the screen.
Vue and React were both less than 1 second.
If I changed the value of a cell, then Angular would redraw the entire grid, Vue and React just updated the cell.
You know what the Angular gitter room told me to do... turn off change detection...
Changing it to 1 way binding resolved the rendering time and made it on par with the other 2, but it's still frustrating, especially when the same example in Angular 1 worked in less than 1s with 2 way binding.
You have to explicitly enable 2 way data binding in Angular 2.x +. Angular 2.x+ is 1 way data binding by default. This is a key differentiation between AngularJS 1.x and Angular 2.x+
The fact that you imply you had 2 way data binding initially means you were using angularJS 1.x (not Angular 2.x +) Or if the latter, you had some very poor design decisions to settle on a 2 way data binding solution. Vue and React both are by default 1 way data binding.
I WANT 2 way binding so I could achieve what I wanted to achieve.
The only way to get the performance out of angular 2 was to NOT use 2 way binding and hack it together.
Vue / React examples didn't suffer from 8 seconds of render time using 2 way binding on a large number of elements.
You can sit and defend angular 2 all you want, doesn't change the fact it's terrible.
Let's not even get into the angular api 2 changing after they said it wouldn't. And regressions of the angular cli, and breaking changes on minor updates.
At the moment, PWA is not a viable replacement for some cases, but it’s about to explode to everyone.
Likely, we can expect something comprehensive for native this year.
I also believe it's a smart strategy to avoid Facebook codebases because they are all meant to somehow benefit FB in some (usually dubious) way.
Also the Vue approach is 1000% cleaner in practice than React, just doesn't have the bandwagon effect going for it
I can say that as you I prefer Vue over React and some of my personal reasons are:
* I like opinionated frameworks
* I don't like to mix Javascript and HTML - I can handle a Vue template to any designer but I would not trust a JSX file to a non-programmer.
* Vue is easier for developer onboarding - with Vue the gap between a junior and a senior developer is way smaller.
React may be better, I don't care, Vue is easier for my development style.
* Vue downscales. If you have a single scripted component in a page, you will get a simple page, with a small amount of Vue added.
This mean, easy way to embedb into iOS/Xamarin.NET.
I have look at react native and NativeScript and both are very hack-ish for my taste.
Should I continue with Angular or move on to React?
My goal is to create a data-driven website, with expressJS & PostgreSQL backend. Not very complicated, but not simple either.
I went the opposite direction - put up a large React/Redux codebase and now have moved on to a position that requires Angular. There is no harm in knowing more than one framework, I find that both will get the job done.
I suppose Angular is more suited for me as it is semi-rigid in the way things have to be done. Complaints about TS eco-system are unfounded in my view as the basic building blocks for building any site, HTML templates, CSS (SASS/SCSS/LESS etc), client side scripting, etc are built in.
When working for a company with staff below me who had very basic understanding of JS (having just done HTML/CSS/JQuery, had no idea what a promise was), there was almost no learning curve with Angular. The hardest part was understanding what a component was, then learning the folder structure.
Angular's seamless use of templating, the built in support for CSS pre-processing and simplicity of uni-directional databinding had the entire team pick it up and be productive almost immediately.
Using decorators to declare inputs/outputs on dumb components is clear, readable and easy to understand.
Class based components are also very clear.
Some say TS is annoying and all power to you, but using types is optional. Personally, TS has allowed me to save on some test cases by virtue of the compiler catching those issues. Plus there is a comfort in quality intellisense.
Vue is cool, it's like a less opinionated Angular. In my opinion, it's strength is its ability to be dropped into any project, giving you client side components and databinding irrespective of your stack. However I have experienced growing pains in larger projects as a result of people over complicating simple solutions.
I am still relatively inexperienced though, and I intend to spend more time with Vue to see if I can't like it more. I'm sure all of my concerns are addressable. So far though, Angular has treated me very kindly, both in large and small scale projects.
I guess it is just how my "programming mind" thinks about problems. I am sure developers who approach problems differently may enjoy React more, but for me, I guess I am a lot more old fashioned and 'structured' in the way I see things.
- I develop APIs and plan to hire freelancers to do the web/mobile clients (so, higher availability of skills in the market is important to me)
- I have a web designer developing the UI with just plain html/css. And this is going thru multiple iterations and the web-designer is able to make all the changes (cheaper because this is just a web-designer, not a programmer).
- Once, the UI is finalized (and fully designed with html/css), I plan to hire a Javascript programmer to do the SPA front-end (so, being able to use existing plain html/css templates with minimal change is a big benefit).
- I do not plan to create native mobile client, just a hybrid app based on webkit. If the web app was developed with React, then will it benefit the mobile clients to be developed with React Native? or, does it matter at all? If Vue.js was used for SPA webapp, what do the Vue programmers use for mobile client? I assume React guys might naturally use React Native.
> So, 1 year passed, and Vue.js is clearly the leader in "would like to learn" by a huge margin
For me, the main takeaway of the newer chart is "React is the clear winner in the 'Happy Customer' category".
For the record, I never used any of the frameworks, though I think I will, some day.
Something similar like using cosmetics that have been tested on animals, if I can choose, I choose something else.
I know this should be more of a technical discussion, just I can't help but think of this aspect when it comes to React.
P.S. Vue contains React. You could in principle write your components React style.
One of the BAT should acquire Vue.js to make it a strong player for the long run, that may happen in 2018 I hope.
Both laravel and vue.js (vue.js is the default frontend choice and embedded in Laravel) are from one core developer, I liked them, but am concerned about the bus factor. I eventually choose nodejs+react because of that.
React gets closer to that with each year.
Second, use of arcane CS lingo and authors writing 10 pages long pages on every known MVC model, FLUX, SCHMUX and etc with weekly regularity.
Third, during transition to Fiber, they went on gigantic increase of complexity by introducing a lot of what can be said to be heuristic rules, and all for non-guaranteed, minor performance gain.
2) Please clarify what you mean by this.
3) By all accounts, the fiber codebase is much simpler than the stack codebase, performs similarly and opens up some exciting new possibilities.
Personally, I am super jealous of angular for having observables. I work with React and would love some Rx in our app too, but we aren't using it. Ditto for typescript - our app is mostly untyped javascript with sprinkles of Flow, while angular would have enforced typescript.
React does not require use of Observables in any way.
I also have no idea what your second and third points could be referring to. If you can supply some links as references, I can try to provide some context or explanation, but at the moment you seem to be making up things that don't exist to complain about.
A question "how to do thing A when user changes thing B" on React forums is usually dismissed with "just use MobX/Rxjs/Kefir/Bacon"
The most basic approach for responding to a change in data is to compare the previous and current props in the `componentWillReceiveProps` or `componentDidUpdate` lifecycle methods.
Meanwhile, Redux is the most common state management library used with React apps.
You certainly _can_ use MobX, RxJS, or some other FRP-type library with React, but to claim that "the whole ecosystem is heavily tied to them" is simply wrong, and shows a gross misunderstanding of the React world.
May be, but this is how it looks from my part of the world, which is Russia or China when I am doing term contracts there from time to time.
Here, the so called "software evangelists", apparently paid or hired by FB, swarm tech events to lecture people on how to do "10 tricks to transform your eCommerce business with Agile management, and FLUX pattern". And they get pretty annoying. My experience with React ends with my interaction with them and doing basic demos for recruitment interviews. I have not yet heard of a FRP-framework-free React site being considered norm for a "serious project" here.
Just like those FB "evangelists" do today, Angular proponents were doing the same 5 years ago with their maxim: "the magic provider/factory/service pattern is the new best thing since a sliced bread" without elaborating much why. That lead to many mentally-infirm developers trying to shove it everywhere, making usage of Angular ecosystem without zealous following of that pattern impossible.
I have impression that the same is happening with FRP-everywhere crowd and React.
If this isn't how it is, I am glad.
I have never heard of Facebook paying "software evangelists". I suppose it's possible, but it really doesn't match with what I know about how Facebook develops and uses React.
That's flat out untrue. This might be some people's approach but in all my years of writing React apps as a consultant I haven't had to use any of those libraries on a project.
FWIW that problem is usually solved by reorganizing code a bit and passing a callback down.
I enjoyed the "Why Vue.js" video. It communicated to me that Vue is really trying to design an easy path (even for non-programmers) to use React's patterns, by mixing in some old ideas that people are familiar and comfortable with.
I would choose riotjs or vuejs anyday before any facebook's code in my apps.
I wouldn't feel confident picking that as my company's future.