Has Vue passed React yet?
hasvuepassedreactyet.surge.sh
hasvuepassedreactyet.surge.sh
A good comparison is backend stacks. Rails exists, but so does Laravel and Django. If it were truly a big deal which was the biggest, then only one choice would remain. Instead, they all have healthy ecosystems with companies using all three.
It doesn’t have to be a war.
Obviously, it rarely makes sense to select a framework that is completely disused, or unsupported, but there are articles out there by reputable sources who assert that if you're not using the current hotness, you're going to miss out on every new tool that crops up in the ecosystem, and your startup will languish and die as a result of having to spend so many more cycles just to keep up with what other people can 'npm install'.
What's worse is that they're not entirely wrong. Any good plugin for Vue right now is going to show up in React or Angular post-haste, if it doesn't exist there already.
Edit: I also can't help but wonder how many people saw this article, clicked the link, realized it was based on stars, and then went and starred Vue (exactly as I did). Every time I refresh, Vue is closer to 'toppling' React (at least according to these nonsense metrics)
If your startup dies because of your choice in javascript framework, you were doomed from the get go.
“Linux is better than Windows”
“Android is better than iOS”
“Python is better than PHP”
“Vim is better than everything else”
We’re using tech that’s outlived more fads than I can count, yet I’m still surprised when younger hires insists on using stuff that’s basically supported by one man.
I’ll admit JAVA almost made it to the list of techs we were going to have a conversation about in the late 00s, but these days it’s as relevant as ever. So is C#.
The front end is nothing but terrible though. I trained a few of my employees to do angular, and then they had to relearn things with angular2. Maybe that’s not an issue for start ups where youngsters slave away in their free time, but it cost me roughly $60.000 in expenses and missed work to retrain our people.
Had to? Did you hit the limit of the things you could do with AngularJS?
Your developers probably decided to move to Angular2 because it was new and shiny, and when they'll be out for a new job it'll look good on the CV. I doubt there was any business reason for investing those $60k.
* We operate a lot of IT systems, some of them are build in corporation with smaller local firms. This isn't necessarily the most sound decision financially, but it's a political decision to support the local area. We handle the business end, the project management, we do fairly strict code reviews and we take over once it's ready for operations. I said it wasn't the most sound decision financially, but so far it's actually been a cheap way to develop smaller user friendly functionality in a lot of areas. None of these small companies have AngularJS qualified people anymore, and haven't had for a while.
* I can't hire people to do AngularJS. It didn't stick around for long enough for any real talent to develop on it, at least not in Denmark. I'm not hiring from the most lucrative position either, mind you, it's the public sector after all.
* I don't want to operate two Angular versions in my stack. I already manage more than 500 different IT systems, it'd be crazy to manage more JavaScript frameworks than I have to.
* I spend a lot more than $60k upgrading my employees. A few of my developers wanted to go with Angular 2 rather than stick with AngularJS. I'm perfectly fine with that. They could've learned something else, but I generally let my employees chose their direction as long as it also makes sense on the business end. This upgrade was perfectly fine with me.
Unless Google does a completely new take on Angular2-6 in the coming years, it'll turn out to save me a lot more than the $60k in the long run.
They're perfectly valid reasons, but they have nothing to do with the quality of tool, or of the product, or with the cost sustained to develop it. Basically you had to move on just to stay exactly where you were.
We pick a tribe and can be loud and obnoxious in support of them.
- Albert Einstein
In a nutshell, I'm trying to turn <something> into a bare-bones HTML page. We currently use an XML document interpreter that was written in 2006; with performance woes and maintainability woes abound. Transpiling to JS neatly solves this.
I started off with my own Angular-like template language, for which this PM correctly scolded me: people will need to learn it. He indicated that I should just use Angular - but the problem is that Angular is opinionated and at odds with this legacy system that I'm trying to clean up. I struggled for at least a week and I dropped for good reasons. I had a discussion with him last Friday and suggested Vue (as it is far closer in execution model when compared to what I am trying to solve): "what's Vue? We shouldn't use niche frameworks, people will need to learn that." Now I have an answer to that :).
The more popular a library is, the more support its ecosystem gets, and the more likely you can convince your boss/company to use it. So if you prefer one, you may really want it to be "the most popular" to ensure you can keep using it.
Eg: people who really like Angular 2+ are kind of struggling right now. If you join a company and they're not already using Angular 2+, good freagin luck. Chances are they won't switch from React/Vue/whatever to it anytime soon.
Because of this, and the general perceived volatility of the JS ecosystem, its not too surprising people treat this as a "war". It's unfortunate.
Facebook really screwed up by not having Windows support for the longest time, and even after they did, not having it as a first class citizen (since most statistics have FE devs to be roughly 50% on Windows). Not that they cared about adoption, but as Flow users, we did.
At my company we started out with Flow and eventually agreed to switch to TypeScript, as the former is getting to be too obscure a technology.
You can say that about any library; it has nothing to do with the popularity, support or quality of the particular dependency. If the technical decision makers choose not to use something you like then you won't get to use it.
This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
The "technical decision makers" though has very much to do with the "popularity, support or quality of the particular dependency".
If a dependency is popular then more technical decision makers at more companies will be using it, and the more choices one that likes/wants to work with it has for a job.
>This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
Which will make the point moot, as they wont be the one coding using the technology anymore.
1) React 2) Vue 3) Angular 2+ 4) Aurelia
If your preference is 1) or 2), it shouldn't be too difficult, even though it means a complete rewrite or building in-house adapters to migrate gradually. If it's 3), even though similar adapters exist, good luck convincing anyone. If it's 4, you're basically dreaming.
https://trends.google.com/trends/explore?date=today%205-y&ge...
According to NPM download stats, React is 6x larger:
https://www.npmjs.com/package/react https://www.npmjs.com/package/vue
For Vue to catch up to the number of React stars would mean that their rate of starring is significantly higher.
I wonder if rate of new Github stars are a leading indicator of future popularity increases? Probably? Would be interesting if someone could study that.
Weird thing, commits to Vue are decreasing over time and are mainly done by a single individual - I've never seen that pattern in a popular library: https://github.com/vuejs/vue/graphs/contributors
While commits to React are regular and come from a much wider base of contributors: https://github.com/facebook/react/graphs/contributors
The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.
The Sistine Chapel was mainly painted by a single individual.
(for the record, Michelangelo had apprentices to help him mix plaster, etc. But he phased them out when it came to painting. Traditionally master painters had apprentices which would paint with them, but he would rather avoid the differences in opinion and arguments while painting the chapel. He had the vision and the skill. I think that’s the case here as well. Not saying Evan is Michaelangelo, but he does have a good vision with his product and the skill to execute on it.)
https://www.patreon.com/evanyou - It's his full time job, he's making over $15k a month on Vue, everyone else is just an open source contributor.
https://trends.google.com/trends/explore?date=today%205-y&ge...
or how about
https://trends.google.com/trends/explore?date=today%205-y&ge...
Maybe alexa matters?
https://www.alexa.com/siteinfo/vuejs.org
https://www.alexa.com/siteinfo/reactjs.org
Or maybe one community uses their respective primary domain more than the other for one reason or another.
React also has more than 4x as many dependent packages in npm, which could be propping up its install count.
I don't think this would do anything. If you have three packages that depend on React, you still only install it once. If anything, the number of packages that depend on React is an indication of its popularity.
The search I linked to is not a keyword search but rather extracted topics. Your criticism is just based on misunderstanding how Google trends work. Not saying it is accurate but in both of your "corrections" to my link you are getting less accurate Google Trend results.
Regardless of the fact Google trends is not even an accurate way to gauge usage of vue or react to begin with.
I am not responding to any more because it seems that people refuse to understand it.
Country Percent of Visitors Rank in Country
China 59.1% 631
United States 8.7% 7,245
Japan 3.7% 6,109
Iran 2.8% 2,373
India 2.2% 8,422
Country Percent of Visitors Rank in Country
United States 33.3% 3,312
China 9.8% 6,694
India 8.5% 4,016
Japan 4.9% 7,585
Iran 3.6% 2,632
upenn.edu (US) hateblo.jp (Japan) facebook.github.io (US) yiibai.com (China) infoq.com (China)
And to Vue:
sina.com.cn (China) csdn.net (China) wikia.com (US) cnblogs.com (China) blog.jp (Japan)
[1]: https://trends.google.com/trends/explore?date=today%205-y&q=...
That's pretty interesting actually, and presumably means a lot of people find Vue interesting, yet it's not as widely adopted as React.
> The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.
I mean, that is if React usage slows down and Vue's continues to grow. I didn't draw that conclusion from the links you provided (but I didn't conclude otherwise either).
Edit: a downvote with no reply? Why the downvote? Did I say something that's wrong?
Anecdotally from my on and off job searching, React leads here by orders of magnitude. And unfortunately for me, my Vue personal experiments/side projects have to be put in the sideline for a bit. Many people I've talked to want direct React experience and not just experience in reactive frontend stuff.
(have used both React and Vue a lot, haven't starred either one)
In B2B spaces where there are limited competitors and vastly different levels of investment involved for the users, the UI largely becomes irrelevant as long as it works.
I've recommended other b2b services over Salesforce because they have such a shitty UI and it worked out nicely.
I'm still maintaining a web forms program first started in 2002. I dream of MVC.
Stars might matter to some but it looks like React is here to stay and be the most supported and used library for some time.
Looks like they are moving their office suite of software to React.js.
https://mspoweruser.com/no-microsoft-is-not-rewriting-office...
https://blog.meteor.com/meteor-1-7-and-the-evergreen-dream-a...
It's good to see Vue gaining steam as more options = better fit per project.
(Apologies if this was rhetorical and I ruined the point you were trying to make)
Trying new things and taking risks can yield huge rewards! Of course it can fail spectacularly as well but for those that worry about that a lot, jQuery UI still exists!
I'm baffled why anyone thinks anything like this is actually true. So everytime you see a JavaScript or CSS library or framework posted to HN, you think all JavaScript developers switched to it? Game development has well over 1000 engines to choose from. I don't assume you switched from unity to Godot when it showed up on HN.
React: 1,596,809 weekly downloads
(from npm)
Both Angular and Vue have a similar component DSL and contrasts from React by trying to have a complete out-of-the-box experience, rather than the build-your-own framework style of React. But Angular is backed by Google, and it supports TypeScript out of the box as well as RxJS, which is somewhat of a cross-platform API for async. Unfortunately I think the Angular reputation still suffers from its Angular 1 days.
Programming in React requires some basics in JavaScript and functional programming. It helps if you already have a dev background, but if not, then you will learn things really useful for a developer. And not only for frontend dev.
Then you just have to learn the React API: 4 concepts (component, state, props, render) & 3 functions (didMount, didUpdate, willUnmount).
You don't want to bet your company on a project with only a few thousand stars, it could die quickly.
GitHub stars are a more a measure of hype than the size of the community.
And much of it is still on 1.x
It'd be an interesting project to compare frameworks/tools by aggregating the stars (or whatever metric) of its major (i.e. filtering out hobby forks and skeleton repos) dependent projects, e.g. the 22K stars of gatsbyjs/gatsby would count towards React's overall reach/popularity.
I think it just resonates with the community that this is a Patreon-backed, very community-driven project, whereas React has Facebook behind it, and Facebook has been controversial. Not that that has much to do with React itself-- if anything it means it probably scales well.
Either that, or it's another iOS vs Android situation, where people just like picking teams.
It's a pleasure to work with and a much needed tool in the frontend landscape. The more mindshare it gets the better for everyone.
I'll keep on rooting for it!
I'm rooting for Vue.
(I am tongue in cheek here - I realise stars <> actual usage in the wild, and the results can be gamed).
For what it is worth, as a 35+ year veteran in the software coding world, I tried dabbling in both frameworks, and Vue seemed to make more sense to me and fitted my mind's view of how things should work.
Why so? Could you add some detail to this comment?
React also is overly complex because it tries to over-optimize redrawing speed through encouraging components to maintain a lot of local state using setState -- even though the increasingly popular Flux model encourages global-ish state for one-way data flow that makes the internal workings of UIs easier to reason about. Mithril is more Flux-ish out of the box in terms of the design patterns it encourages. Mithril's default behavior is based on rerendering the entire current vdom tree any time the user interacts with a DOM element or after a network request completes -- and the Mithril community only encourages optimizing beyond that if there is a specific performance issue. (You need to add your own redraw calls in callbacks for timeouts and a few other cases.)
That said, I can understand how the herd mentality shapes the employment landscape for both programmers and their managers. It does in my own work life too -- where I have spent a couple of years working in Angular for my day job despite knowing what a mess of accidental complexity it is compared to something like Mithril. Angular was chosen years ago by other developers before I joined the project -- developers who mostly did not stick around to suffer the maintenance consequences. At least new projects may be in something other than Angular -- typically React (which is at least better than Angular).
It's saddening how many times in my career I've ended up having to work with worse technology because of herd effects -- despite knowing better alternatives existed and having personal experience with them. For example, IBM chose to promote Java instead of Smalltalk in the late 1990s (despite having two Smalltalks it owned). Or Netscape ultimately foisted a Java-ish looking JavaScript on the world when Brendan Eich was originally recruited with the promise he could write a Scheme for the browser. Although, as with both Java and JavaScript, after a couple of decades, most of the worst rough edges are worn smoother and many of the worst bugs are fixed, and so the developer experience for both by now is finally not that bad.
Why have I not switched? It is useful to disentangle the value produced in Elm by using vdom (similar to Mithril) versus the value produced by Elm being a better language than JavaScript. Both are true, but which one provides more value in different contexts?
When I researched Elm in the past, I also read posts by a few people who moved away from Elm due to integration issues with the rest of the JavaScript ecosystem (as well as a miscellany of typical other issues any new language has related to bugs/tooling/libraries/platforms/etc.). Whether those criticisms of Elm by past users were fair -- or whether they still are true -- I do not know. But those issues were about the language, not about the vdom/redrawing paradigm.
It seemed to me that TypeScript was a safer bet three or four years back for me to choose for myself over other compile-to JavaScript languages because I would also be learning plain JavaScript better at the same time -- and learning plain JavaScript well seemed like a good thing to do.
These are really tough choices given moving targets for languages and libraries -- including trying to predict where communities and designs will be in a few years.
JavaScript is a badly designed language because in trying to make things "easier" for non-programmers writing a few lines of code (like making vars global by default) it made programming much more difficult for anyone doing anything more complex. Languages like Elm (or many other compile-to-JavaScript languages, even C++ now given WebAssembly) can fix those core issues in JavaScript (given no need for backward compatibility) and are appealing for that reason even as they may have their own challenges.
And as a negative, TypeScript only goes half-way there to a better language -- leaving many of JavaScript's warts in place. Just one example of such a wart is the many globals defined on "window" which make it appear a local variable might be defined when it is actually some global value being referred to (e.g. "length" or "name" are defined as globals on window as in "const x = length"; for more gotchas see: https://developer.mozilla.org/en-US/docs/Web/API/Window ).
But that said, typically issues comes up in any framework or language that involve a "leak" in the abstraction. And then you need to learn about the surrounding system to make your application work well. While things may change in a ten years, right now, to make a good Single-Page Application for the web, you need to learn the basics of HTML, CSS, and JavaScript fairly well. I don't feel there is any substitute for that. I've tried (e.g. using Dojo/Dijit) and gotten burned. One thing I like about Mithril is that, vdom aside, it keeps you close to the "metal" of HTML/CSS/JavaScript with just enough support to handle repetitive issues well while not getting in the way and being relatively easy to debug.
Decades ago when I learned BASIC, I had already learned assembly language before that, and digital electronics before that. The combination of BASIC and Peek-ing and Poke-ing assembly language was great. But just knowing BASIC would have left me pretty mystified about what was going on under the hood of the computer.
I think the same would be true for someone whose first browser-based language was Elm or Java/GWT and not JavaScript. After learning the basics of HTML/CSS/JavaScript (the assembly language of the web), then sure, learning and using other languages like TypeScript or Elm can potentially help a lot -- though with tradeoffs (like Elm integration issues mentioned above).
For simpler things, I find just plain ES6/ES7 with Mithril actually works fairly well given JavaScript has improved a lot with ES6 and ES7 (especially with "let", "const", and "async/await").
For Elm and me personally, it is undoubtedly better to use than JavaScript/TypeScript in-and-of-itself, but having gone up the learning curve on those, whether it would be worth a switch at this point, I don't know. It clearly is "better" as a language -- but I am not convinced it is so much better as to make up for other possible downsides. There are a lot of great languages out there.
Personally, I am tempted by Elixir as a next language to learn (given Erlang's fundamental design beauty). But I feel productive enough in TypeScript and ES6/ES7 at this point (years into the learning curve on "the good parts") that I don't feel an urgent need to do that. Likewise for Clojure/ClojureScript which many developers also love and is also tempting. Or even Scala which can compile to JavaScript.
Anyway, for all my complaints about herd effect, I am sorry to bring up those sorts of issues as negatives for Elm given how entrenched plain JavaScript is right now. One of the problems with making choices like these is that people rarely switch languages because the alternative is 1.1X or even 2.0X better for some task overall. They tend to switch when something is 10X better. And that is a high bar -- especially if you compare Elm against TypeScript+Mithril+Tachyons and not ES5+AngularJS.
Vue and React are great but in my experience they’re virtually an overkill for most projects. I recently come across a Shopify cart integration using Vue and was sorta dumbfounded that an engineer decided to include a 50kb framework to handle a couple of Ajax requests. I ask myself why? The answer is hype. Hype can be the demise sometimes.
That said, I wouldn't use a number of stars in Github as more than an indicator of people pushing a star button in Github.
I've starred many things so that I can remember them some day. If I use something every day it's most certainly not starred.
I haven't had a chance to look at Vue in depth but it seems to me that its useful for building apps where you don't need a build tool which makes sense to me.
The main thing I don't get is why use Vue over React if you're going to use single file components with some kind of build tool?
Someone will inevitably say you can use JSX in Vue but if you do that I don’t see the point in picking Vue.
I'll paste my comment from another post in this thread:
>> I hear a lot that "Vue is easy to learn"...
> That's why I started working with Vue. It seemed easier to approach for someone coming from a server-side language perspective (I'd mostly worked with Python/Flask and PHP/Symfony before). I could slowly ease into using pieces of it until I learned enough to write a whole project in Vue. You can probably do the same thing in React, but the Vue docs were written to address my use case.
Vue is great, but React has about 10x more libraries, frameworks, components and just general "stuff" built around it, along with the mindshare that it brings.
In a few years it won't matter as deep learning will generate front end UI with just a wireframe sketch.
I'm feeling irrationally happy about that.
(iPhone safari)
I started a node/express/vue project about 6 months ago. Here are the APIs and syntaxes and so on I had to learn:
Mongoose API
MongoDb API
Express API
HTML5 Validation and Validity API
Fetch API
Bootstrap 4 API
Flexbox
some new javascript concepts like destructuring
Webpack/source maps/hot modules
Node
The differences between importing/exporting modules in node and the browser
Oh yeah, and the Vue API. You know what percentage of learning the Vue API was? About 0.01%. What is even more ridiculous is that it wasn't even the learning of the API that took the most time.
All of the concepts in Vue/React take more time to learn than the API of Vue. The differences between data and props, what reactivity is, how single page routing works, how components work, and so on. In fact, as React is so barebones, it probably requires more learning than Vue because you have to find all the other libraries to make it the full product.