Hacker News new | past | comments | ask | show | jobs | submit login
Vue.js vs. React: what happened in 2017 (pixeljets.com)
285 points by jetter on Dec 24, 2017 | hide | past | favorite | 167 comments

I’m the founder writing code (but not the only technical person) for my three person startup. In October I started migrating our MVP from server side templates to Vue, given we had direction and traction on a product line that justified the time investment. It’s turned out to be a great decision (although likely one that could have been made with react as the choice as well).

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.

I agree. We still admire Vue.js after using it for more than a year and writing hundreds of lines of Vue.js code every day. No chance I would choose React+Redux in cases when I know I need quick progress on my web project - Vue.js allows you to be very productive, cutting corners in the right places, while still keeping the reasonable code quality, and writing very little of boilerplate.

MobX+React would be just like Vue, but with the benefits of the larger React ecosystem and full type checking with typescript/flow, and the drawback of mandatory build tooling.

It is similar, but it will mean you get off the highway of React "preferred way" - for example, in case you start working with React Native you might have an issue of using different state management solutions for your web and mobile stack - it looks like nobody is using Mobx with RN in serious projects.

Actually we use React+mobx on both our web and RN stacks and it's been great. What we really like is that it is simple and extremely performant since in most cases it automatically updates only the React components that need to be re-rendered based on the state that's been modified.

We jumped directly from a flux-like state management to mobx (skipping Redux) and the development time has gone down significantly as well.

Cool! I think you guys should do a writeup since "react native mobx" results in google clearly state the mind share is not there yet.

Chiming in with another "we use mobx and react native." Sorry for the overload of comments like this but I think it's perfectly fine.

There is no react preferred way of state management. I have used mobx in many of my reactjs native projects.

I've used MobX for React Native (though I went back to Redux for familiarity). I found it to be transparent enough.

We're using RN with mobx and it has been great. We'd probably have 3x more code if we went with redux.

i've been wondering about that too, and would love to see some write-ups of people that have react+mobx for at least a few months if not more, how it worked out for them, plusses and minuses.

Also tutorials for react+mobx.

Appreciate the comment about high and low bandwidth performance by vue. 80% of the world is low bandwidth and such solutions built with such tools have an opportunity to have a much farther reach.

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?

I've looked at PWA & working with offline, but it's an optimization I'd like to have, not one that we absolutely need. Right now, given how crunched we are for resources, everything I work on has to fall into the category of "absolutely need", otherwise I de-prioritize it.

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).

Appreciate your detailed reply. I'm working on a problem with mobile, offline first as a key part of the solution and have been leaning towards vue if for nothing else it's appearing simplicity, flexibility, and ability for new devs to get up to speed on the project quicker.

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.

I'm assuming you used Rails as a back-end?

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.

What is a turbolink?

Yes, sorry for just tossing this one in there. Our product is build on top of rails 5.x, and rails has support for turbolinks. They make your server-side rendered application 'Feel' more SPA, by only refreshing the parts of the page that have actually changed upon server response.

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.

When would you recommend using turbo links over Vue? Or, conversely, would you recommend people not even bother with turbolinks?

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.

You can have both at the same time. If you want to build a SPA, go for Vue only. Build if you want to have a more traditional application and only use Vue for some views, it will work with turbolinks, you just have to use a gem to help you with the caching (turbolinks cachês the body tag to speed up the back button, and the gem clears the Vue app before the caching happens making it idempotent).

Turbolinks is amazing.

Haven't used it, but it seems to avoid a full page reload but still does a round trip:


Having used both React (with Typescript and Redux) and the latest Vue (with es6 and Vuex) I prefer React, and I don't even use React Native.

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.

I have already moved to using React for my larger projects and Mithril for my smaller ones instead of Vue because of the lack of typescript support.

That and when you add JSX to mithril, the api just feels so simple and i rarely find myself checking the docs for something.

Glad to see Mithril mentioned. I like it better than React when comparing the APIs, It just seems simpler. But React obviously has the mind share. I'd love to see Mithril gain momentum.

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.

FWIW, you can absolutely use React as just a pair of script tags - see the "React Single-File Example" template [0].

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...

> You have to remember to setup the properties you mutate so the reactivity will detect a change

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?"

We maintain Vue and TypeScript Single Page App templates for Vue and TypeScript for .NET Core [0] and and .NET Framework [1].

[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.

If anyone wants to try out React SSR + TypeScript, I have a working example here:


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.

I really don't get the love around vue... I always read the glowing sentiment and go, "Ok, I'm missing something, let me go back to the vue.js docs and see what's good"

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).

Are you sure you read the right docs?

> let me generate templates using the language I already know, JSX is great


> 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

"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"

Not everyone knows JSX, so while that argument applies to you, it doesn't apply in general.

They mean javascript; jsx is a very small amount of new syntax and is embedded in normal javascript. Learning a completely separate template language with all of its own constructs for conditionals, iteration, etc. is significantly more work.

There’s not any more to learn vs html than jsx. It’s like 5 relevant constructs that all follow the same form, and the colon. Takes 20 minutes to have it down pat.

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.

Ternary operators in JSX are valid javascript expressions. As is anything that goes into {}

All of the following is neither Javascript nor HTML:

    v-for=”x in list”
etc. etc. etc.

I'm aware of that bit, I just think they're an ugly piece of control flow inside JSX, and they're also not a particularly versatile piece of control flow.

Especially for the else-if case - you end up with repetitive conditionals to replicate that.

If `do { }` syntax makes it into ES9, the whole ternary-operator-hate business will be a moot point

That's alright. I love and appreciate React too, I just prefer Vue now.

> and is embedded in normal javascript

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?

JSX is a thin XML-like DSL on top of Javascript.[1] Unlike untyped strings with a custom parser of Vue, which require you to write something that’s neither HTML nor Javascript.

You can have as much separation of concern as you like with React.

[1] https://reactjs.org/docs/jsx-in-depth.html

JSX is also neither HTML nor JavaScript.

> JSX is a thin XML-like DSL on top of Javascript

^ this.

It directly translates to `React.createElement`. This is also why everything inside {} is pure Javascript including things like proper `this` etc.

Ok, so they both let you use something more like what you already know, except neither of them are technically JavaScript or HTML. Glad we established that. I think the understated bikeshed color here is that VueJS allows you to use jade/pug syntax instead of HTML.

I can’t stand Jsx personally. Vue files with the entire component defined in 1 place and writing HTML templates... preferred for me.

I think both of them are awesome and have great communities. Especially seeing as webpack has stabilized.

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.

I disagree. Coming from python, my first foray into web frontend was a SPA for mobile. Both my coworkers convinced me to go right to react + redux (after some bumbling first with more "traditional" ajax). After a few weeks of utter bewilderment, I have to say I really enjoy this stack. Some say it's overkill, but the framework really helps me organize things into cognitive chunks, and makes debugging so much easier.

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.

I am in the same boat you are. I've tried frameworks before that ended up being a mess later to recover from.

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.

I write ClojureScript

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.

Speaking as someone who writes ClojureScript themselves, ClojureScript is definitely in the category of technologies that show no sign of explosion whatsoever.

React and Vue are both great technologies, but with Teact the template syntax is optional, and no lisp user wants another syntax...

I picked up ClojureScript at the end of 2013. I was a C++ developer then in a small firm and was tasked to write a web frontend. Outsourcing that project had failed before (2 times iirc), so my boss bet on me to do it. I knew HTML and had written probably < 1000 lines of Javascript code in my life before. Anyway, I needed to write an interactive single page app (basically it was a visualization of simulation results), so I needed Javascript. But it was so frustrating to write Javascript (also, tooling was mediocre back then or I didn't know it). So at the same time, I stumbled over ClojureScript and had a try (I new Scheme before and was especially outraged by JS syntax quirks, so I hoped S-expressions would rescue me). With ClojureScript in 2013 I had a module system that handled dependencies, an emerging library ecosystem that had what I needed for that specific case, I was pretty happy. This was more advanced than what I got with JS (I might not have found the viable options for such stuff with JS, but at least information on them wasn't widely found then).

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.

I'm really surprised by this assessment. I've been working with ClojureScript for the past three years, and I find the ecosystem is very vibrant. ClojureScript itself has been evolving rapidly. Lately there's been a lot of focus on Js ecosystem integration allowing you to do things such as consuming NPM modules directly. The compiler itself is very efficient doing things like dead code elimination and minification out of the box.

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.

Not sure about the inspiring talks or whatnot, but I've been writing clojure/clojurescript (reagent, re-frame et al.) professionally for a couple of years and there's nothing I can't find that I need in a project. With simple js interoperability, native use of js/react components in reagent and ease of wrapping any vanilla js library, there really is nothing you can't do with clojurescript. You should take a closer look!

I really enjoy ClojureScript, and haven't found it to be a ghost town at all. Reagent and re-frame + Figwheel are a killer combo. ClojureScript's JS interop is stellar.

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.

I also find the ClojureScript ecosystem vibrant and growing

1) I didn't say that, I said good ideas trickle from research ecosystems to industry ecosystems, because legacy

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!

This is my reasoning too. Until someone creates a better reagent and reframe and renatal I'm gonna stick with React

What do you find missing in Reagent currently that works better in React?

Nothing (?!).

So what would you expect to see in a better reagent and reframe and renatal that would make you switch from React?

No, what I mean is that I'd only switch from reagent with react for a better-than-reagent fw based on vue.

Ah sorry, I completely misread your original comment. :)

I think it's really people's experience. I'm in your camp, I write functional javascript, I learned clojure, I think about writing software in a way where react-redux (and re-frame) fit the paradigm and get out of the way. Vue seems like Backbone v2 after drawing inspiration from Ember and Angular

Ehhh, I don't think that's really telling in this case. Clojurescript layers plenty on top React, so it's really just a library layer over which cljs devs write entirely different DSLs.

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.

What I find most interesting in these results is the satisfaction percentage i.e. (Used it before and would use again) / (Used it before and would use again + Used before and would not use again).

- 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.

Angular 2 I would like to never use again. It’s caused far more problems than it’s solved. It requires deep knowledge to build large applications or else it will suffer performance problems.

What I find odd/funny is that a significant chunk of people have "never heard" of using no framework. Either it's a mistake or there are that many people who've never just written some JS code.

That result doesn’t surprise me at all, not everyone is working on a huge project and most of those frameworks are overkill for small tasks, sometimes pure js (with the odd library here and there) is all you need.

OP predicts with absolute certainty vue "will become dominant" next year many times.

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.

Huh? OP said the power of the React ecosystem and change in license will keep it on top in 2018 and that if they were starting from scratch they probably would have used React for their website.

> next year would be the year of Vue.js success

> 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

> Synergy, my friends, is the key to React upcoming monopoly.

Agree, also drawing conclusions form "heard of it would like to learn" on the graph seems a bit far fetching. I would like to learn vue but I do not see opportunities in my job to use it next year.

The simple answer is in reading the chart. Look at "I've USED it before, and WOULD use it again".

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.


- Used it, would use again: 14k

- Used it, would not use it again: 1k (7%)


- 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('')
There's no chance in hell that `this.message` exists on app5. And yet, there it is. And then data becomes $data and a lot of other weird stuff such as computed properties being also hoisted up to the top-level object etc. etc. etc.

It's not really fair to make a comparison between react with JSX and vue without webpack. In practice you use webpack for making components with separated js/html/css, so Vue ends up looking a lot better than the above. That's actually the big draw for me, organization into single file components which can be parsed as simple html. The js component structure is just another piece of that. You're passing vue a template for creating components in an organized/standard way. You can define your own render function if you want the freedom, but you start out with something clean and well organized.

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?)

Follow up, I was on my phone before, this is what working with Vue typically looks like:

        <p v-text="message" class="some-class">
        <button v-on:click="reverseMessage">

        export default {
            data() {
                return {
                    message: "Hello Vue.js!"
            methods: {
                    this.message = this.message.split('').reverse().join('');

            color: black;
The thing to note is that there are other objects which can be added to the component definition which add a lot of utility and keeps things standardized: created, mounted, computed, watch, etc. There's a bit of magic behind the scenes to make it work, but it's worth it for the standardization/organization in my opinion.

I absolutely hate that object literal style of defining a component... Terrible readability and annoying obj literal syntax to deal with...

React IMHO is good enough that I don't want to change framework/basic frontend technology again.

Agreed, it’ll take another paradigm shift to switch to something else.

Not necessarily.. I wonder had react not been backed by FB, it certainly would have had a beating in its popularity given lighter and arguably faster alternatives like vue. Remember, performance was one of the main argument React had when compare to Angular. Now since performance is no more a differentiating factor, developers might look into other aspects like better ROI in short and long term..

Just as one anecdotal data point, we didn't choose React for its performance when evaluating tools for our recent projects. (React can still be orders of magnitude slower than localised direct DOM updates on demand, after all, and in cases where performance really matters that might still be what you have to fall back on.)

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.

Could be for you, but have you wondered if React was say way slower than Angular and heavier, the adoption would have been much much lower?. Agreed, the model that React brought is superior but the catalyst was performance. They even highlighted performance as the main selling point with introducing the virtual dom, where the computation (dom querying) happens not in the dom but in the javascript, which is arguably faster and only differential updates are applied to the actual dom.

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).

React and Angular are solutions to different problems. I don't think React would have succeeded without adequate performance, but I also don't think it is why React has been successful or the main reason it has displaced some of Angular's "market share"; being fast enough is necessary but not sufficient to do its job.

Angular came out of Google, so what ;)

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.

vue wouldn't even exist if react had not paved the way first

Not true - Ractive is a library much like vue on the surface that came out _before_ React. It's all about timing, promotion and hitting a feature sweet spot.

Ractive is MVVM, it is a totally different paradigm https://ractive.js.org/tutorials/two-way-binding/

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.

Do Vue templates play nicely with Typescript? That's something I love about JSX -- "it's just JavaScript" is an incredibly sublime feature. I know you can use JSX with Vue but I'm skeptical since it's a first-order feature with React.

I agree JSX is the best part of React. The second best part is dom diffing and incremental screen update. Obviously this second part is only useful if your application needs to update screens it previously rendered. In fact I'd argue that React is only useful if you need to incrementally update complex screens, because simple screens can be re-rendered completely and no one will know the difference. Very few applications need to incrementally update complex screens. If your application doesn't have this need you can use simpler technologies that don't have the same "Care and feed" requirements of React, such as UIBuilder: https://github.com/wisercoder/uibuilder

Since October (I think) vue single file components work flawlessly with typescript. Can't speak for jsx though.

It works in the <script lang="ts"> part of your .vue file, but not the <template> part.

Ah, that's a bummer. Vue Templates seem wildly regressive to me -- I can't fathom going back to stringly-typed Handlebars wrangling after using JSX/TSX.

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.

You can use slots to pass HTML or Components into child components.

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.

How so? In my mind templates and JSX are equally complex from a user standpoint. In fact I'd argue that JSX is simpler because you don't have to invent slots -- it's an obvious side effect of using JavaScript to generate your structure.

Just reading about slot and slot-scope makes me think Vue's reputation for simplicity is overblown.

It may seem "obvious" to you after being in the water with JSX for a while, but the free-style abstractions afforded by being 'just' JavaScript, like the one you mention, look incredibly complex for someone approaching an unknown codebase.

You don't have to use the templates, though. Define a render function and you can even use JSX in it: https://vuejs.org/v2/guide/render-function.html#JSX

Why wouldn't I just use React at that point? Same behavior, less complexity.

I agree; using JSX outside React feels kinda silly. But Vue is much simpler to grok than React.

I believe React is very simple and easy to understand.

Redux is not as easy but you can go with MobX instead for easier state management.

React + TypeScript is simply too good to not use for me. The idea of going back to unsafe templates is just not acceptable.

Good assessment. To summarize the argument, Vue.js is just as good and some would argue better than React for web development, but the React ecosystem really puts it over the top, especially React Native.

For those like me in the Vue camp, with the React-native dilemma, there is Fuse tools for the interim till week matures. Very clean separation between UI and JS logic.

Though there is Nativescript Vue now.

React changing their license probably saved them. My web dev office was going to transition from them until they changed it.

Same here. For us personally, the license made no difference. We know we will never come across any patent issues with Facebook. But the fact that it existed led us to believe that in the long run an alternative would emerge since larger corps would avoid it because of the license.

Now that they got rid of it, I have no such concern investing time in react for the short/mid term term.

But what are you going to do when they pull the next community enraging stunt?

One thing I'm noticing about SPAs is that they're often slower to load, but the slowness and loading animations gives me a higher perception of the quality of the application.

The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern.

What is wrong with me?

Coming from Angular, I'm biased towards entities declared in the form of a class. It's a style that is easy to manage and familiar to most programmers.

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.

I couldn’t disagree more. Unless your team have Super in depth knowledge of angular then it’s the wrong choice. It’s defaults to progagate changes cause rendering perf issues that are so frustrating to fix. Out of the box react or vue performs better than angular hands down. I hate that after learning angular 2 I realise I should not followed tutorials and advice and just switched all the defaults off on classes and manually propagate changes when required cos it’s a painful task to do.

I don't know what convoluted patterns you where implementing, but out of the box, the default change detection in angular is performant, esp if you start to leverage observables and the async pipe (to eliminate the need for component onDestroy maintenance tasks). It's a joy to use. Yes Angular provides a lot more options than react or vue, and maybe confusing given the scope of what's possible. However, after the initial learning curve, Angular is a very efficient framework / pattern to work with in a team setting.

If you resort to manual change detection, then it's an obvious sign of needing to refactor your design.

The default change detection can cause the whole page to redraw. Especially if you have a lot of data. It gets even worse.

it's pretty much the same change detection logic across all of these frameworks. Immutable data is key to performant change detection. Angular provides the ability to bind template to immutable state data so the framework can provide the most performant change detection

Except it's not the same across all these frameworks.

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.

>Changing it to 1 way binding resolved the rendering time and made it on par with the other 2,

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.

all performan comparisons out there have the three frameworks neck and neck. Your anecdote is certainly interesting in terms of the diffference in performance. I would chalk it up as poor implementation / understanding of angular, rather than some special edge case that tested the limitation of angular

I personally prefer Vue because it is approachable and easy to adopt. I believe that if Vue embraces PWAs in a pragmatic way that performs and is accessible, it will be top for a while.

At the moment, PWA is not a viable replacement for some cases, but it’s about to explode to everyone.

I see a lot of commits from the Vue team into the core repo that are meant to support use in native.

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

My typical use case doesn't need native apps - a PWA is good enough for me. I will not comment on speculation about the compile-to-native feature because personally it is irrelevant.

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.

The one reason why I favor Vue more than React is:

* 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.

PWA is not good enough for us due to heavy usage of mobile device camera and picture resizing (client side) for package receiving process in the warehouse. PWA fails to provide consistent performance in such conditions, and issues with bluetooth scanners in Safari/PWA on iOS devices add up. Other than that, I agree Vue.js is superior to React in a lot of use cases, especially for web.

A thing that will sell vue/react native for me is the ability to only use them for UI. I don't wanna use them for logic or heavy stuff. Just have them for render the UI.

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.

I have spent quite a bit time into learning Angular (4/5). I am new to front-end dev, and found that the structured approach of Angular more appealing than React.

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.

IMHO, keep on the path you are on until you are really comfortable with Angular, then learn React as well.

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.

Thanks. I am thinking in a similar way. I guess knowing concepts is more important than any framework / library in particular.

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.

Having used all of the big three. Am I the only one who likes and prefers Angular?

There are some things Angular does do far better than React IMO - Angular’s pain points are frustrating to me in terms of how I prefer to code though, largely due to its choice of supporting TS first and TS’s issues with toolchain integration/perf & not very conducive to FP, but it also has less pain in some respects such as when it comes to state.

Curious—what makes you prefer angular?

It's very well structured, easy to understand, batteries included, lends itself well to maintainability and scale.

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.

Service container for one

I like the simplicity of React though I don't mind the Vue templating language that much either. Sometimes I actually prefer Vue templates because with React you often see components where it's not so clear how the rendered output will look like.

I evaluated both earlier in the year, and to me (spending the last 30 years developing software), Vue just seemed to fit my mindset better. I just couldn't "get" React, no matter how many times I tried.

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.

Elm would deserve a mention too. One of the very few sane frontend development approaches.

Any suggestion for the below use case? Whether to use Vue or React?

- 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.

Isn't it funny how you can read different things into the same data?

> 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.

Just to set record clear, vue components can be written in pure JS or using JSX, in addition to the template files.

And pug/jade.

I truly love Vue and hope it evolves and spreads everywhere.

The reason I am not even remotely considering React is the Facebook itself and what this company represents - exploiting people's minds and emotions to fulfill their business plan. I can't help it but if I would use react, I would not be able to get this feeling out of my mind, so if there is viable alternative - vue.js, I am definitely going that way.

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.

Which is faster? Vue; Which is more modular? Vue; Which is simpler to grasp and reason about? Vue; Build in CSS support? Vue;

P.S. Vue contains React. You could in principle write your components React style.

vuejs does gain strong interests from large companies such as alibaba,baidu and tencent, the three are called BATs in China similar(or larger) to amazon, google and facebook in US.

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.

It's a shame there's no first party supported Vue native library, but I suppose that's too much even for Evan.

That might not matter that much. There's still a strong argument for implementing native apps using their own SDKs. There are more developers with experience with them, there is more boilerplate and examples, third party integrations are typically designed for them, and more books and documentation are for them. On the front page of HN today there was a stackshare post about a startup with only three engineers that used a lot of cutting edge tools, but React Native was not one of them.

Weex is not a part of the titular Vue project, but can be said to be the most endorsed one, and one that is the most up to date with Vue upstream development.

I had trouble getting started with React but Vue was a breeze. Better for newbies imo.

I'm afraid React is eventually turning into Angular. At some point, I felt that Angular is somebody's PhD work exploring arcane computer science concepts, not a piece of software for practical use.

React gets closer to that with each year.

Hmm, Vue is the one that reminds me of Angular, since it seems to emphasize the ease of constructing views, by its two-way data binding and custom directive syntax inside html.

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.

Vue data is one-way binding these days. There’s a separate way to do two way binding for forms though (which is really a much more convenient mechanism for forms)

Regardless of React's minor growth in complexity it still pales in comparison to Angular's api from a new learners perspective. After finishing a project in Angular I still feel dumb to it's central concepts. React made sense before I wrote anything.

Can you clarify that comment? What aspects of React's development are you concerned with?

Wondering the same thing myself. They are very different all the way to their core. Angular is a full-blown framework; React is a view library. Angular's API and documentation are (excessively) large; React's documentation can be easily perused in under a day. React components are just functions (or classes) and thus can be tested with such ease. Angular testing is, last time I checked, way too complex to get up and running.

First, probably was their approach to implicitly require use of Observable objects everywhere.

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.

1) I've been using React for 4 years and never used observables, what do you mean?

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.

The first point must be cross-over from angular :-) He said he doesn't like angular, that must be why.

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.

Your comment is very confusing.

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.

It looks like you might be conflating React with some other parts of the ecosystem that has built up around it. React retains a far simpler API than the heavier JS frameworks, and AFAIK it doesn't need or do any of the things you mentioned there on its own.

What heuristic rules? We don't have any new heuristic rules at the moment. Source: I work on React.

There is no explicit dependency on RXJS or its analogs, but the whole ecosystem is heavily tied to on them.

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"

> There is no explicit dependency on RXJS or its analogs, but the whole ecosystem is heavily tied to on them.

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.

Citation Needed, please.

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.

>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 certainly don't claim to know everything that goes on in the React ecosystem (especially outside the US), but I _am_ pretty tuned in with the major trends and discussions that are going on, and I've seen plenty of real-world React applications and codebases. None of that matches anything I've seen thus far.

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.

Can you mention a few examples?

Why in earth people would like to to use anything from facebook in they business ? Why do you trust they licensing ?

I would choose riotjs or vuejs anyday before any facebook's code in my apps.

You apparently aren't keeping up with the latest about riotjs: https://github.com/riot/riot/issues/2283

I wouldn't feel confident picking that as my company's future.

Whoa. Thanks for the link, wasn't aware of that. A lesson on how not to run OSS: https://github.com/riot/riot/issues/2512

Facebook has corrected the licensing issue. Most consider it a non-issue now. And I think Facebook proved with that move that they are willing to play ball.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact