
Has Vue passed React yet? - supermdguy
https://hasvuepassedreactyet.surge.sh
======
Shank
I kind of think this herd mentality in the tech industry is annoying. There
are a lot of people using React, but that doens’t make Vue a bad choice.
Conversely, just because Vue is new and relatively popular doesn’t make it the
“new React.” Pitting them against each other like this is disingenuous, as
engineers will make choices and use both — it’s not like picking React will
kill Vue or vice versa. That doesn’t say anything about the likes of Ember and
Angular that are still in use.

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.

~~~
ggregoire
I wonder if it’s a nerd thing.

“Linux is better than Windows”

“Android is better than iOS”

“Python is better than PHP”

“Vim is better than everything else”

~~~
oorza
Once you get old enough, you realize everything is shit and nothing is better
than anything else because, again, it's all shit.

~~~
eksemplar
Especially when you work in enterprise, and even more so when you work in
public sector enterprise.

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.

~~~
Udik
> I trained a few of my employees to do angular, and then they had to relearn
> things with angular2

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.

~~~
eksemplar
There are several business reasons to do update, I'll take you through a few
if them.

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

~~~
Udik
It's fine, just none of the reasons you gave is an actual business reason.
Basically you moved to Angular2 because everybody else around did, and it
would have been harder to recruit and to keep developers, and to interact with
developers of other companies.

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.

~~~
eksemplar
You’re not really reading what I write, are you?

~~~
Udik
Am I missing a bit of sarcasm in the first line, maybe? Yes, you are right,
those you list are all valid business reasons. They just don't have anything
to do with the frameworks: if everyone had made the inverse move from Angular2
to AngularJS, you would have done the same for the exact same reasons. Do you
agree?

------
bhouston
According to Google search traffic, React is 10x popular:

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=%2Fg%2F11c0vmgx5d,%2Fm%2F012l1vxv,%2Fm%2F0j45p7w)

According to NPM download stats, React is 6x larger:

[https://www.npmjs.com/package/react](https://www.npmjs.com/package/react)
[https://www.npmjs.com/package/vue](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](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](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.

~~~
throwaway0255
Comparisons in Google Trends are extremely easy to manipulate (or just
interpret wrong). The ".js" you added to Vue is killing its results, and the
generic term "react" is propping that one up.

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=vuejs,reactjs)

or how about

[https://trends.google.com/trends/explore?date=today%205-y&ge...](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=vue.js,react.js)

Maybe alexa matters?

[https://www.alexa.com/siteinfo/vuejs.org](https://www.alexa.com/siteinfo/vuejs.org)

[https://www.alexa.com/siteinfo/reactjs.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.

~~~
bhouston
> Comparisons in Google Trends are extremely easy to manipulate (or just
> interpret wrong). The ".js" you added to Vue is killing its results, and the
> generic term "react" is propping that one up.

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.

~~~
philliphaydon
You typed vue.js so technically your results are less accurate. :/

Regardless of the fact Google trends is not even an accurate way to gauge
usage of vue or react to begin with.

~~~
bhouston
Vue.js category that I used is the official Google aggregate category. You do
not understand how Google Trends work. There are keywords you can use or you
can pick Google aggregate categories. I pick the aggregate category, which
generally should be the most accurate.

I am not responding to any more because it seems that people refuse to
understand it.

~~~
Isinlor
Quite likely Google is underrating Vue, because Vue has heavy presence in
China and Google does not.

------
ineedtosleep
Stars don't matter. If we want a measure that's actually meaningful to some
developers, look at job postings.

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.

~~~
optimiz3
Meanwhile we're still using ASP.Net MVC w/ a vintage 2008 web design. Could
care less about $latest_web_technology, because having a viable business is
more important than what the site is coded in or how it looks.

~~~
paulie_a
While that is a valid point and a company should never leapfrog to the new
hotness. Using outdated technology can have major pitfalls with technical
debt. Also looks, ie ui/ux does matter greatly. A modern Android app wins vs
something built for 4.0

~~~
hueving
UI look really only matters in competitive consumer markets.

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.

~~~
paulie_a
I have evaluated b2b on a regular basis, features matter, but UI absolutely
matter to me when I make a recommendation. If it looks like shit from the 90s
I won't even put it on the list. If it doesn't have a solid UI it's a
nonstarter.

I've recommended other b2b services over Salesforce because they have such a
shitty UI and it worked out nicely.

~~~
megaman22
There's a lot of other reasons to run the other direction from Salesforce.
Ugh, their REST api...

~~~
paulie_a
While I hated their stupid custom software I think it worked over rest API.
That was probably was a better feature they had, which isn't saying a lot.

------
sotojuan
Microsoft just announced they are betting big on React, and a quick search at
JS/frontend job posts only show React and the odd Angular/Ember ones in my
area.

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.

~~~
robotkdick
React is the heavyweight, no doubt, but it also feels heavy for smaller
projects. VUE is a great option and believe it or not Meteor just announced
1.7 with at least one killer feature: Babel-free JS for modern browsers.

[https://blog.meteor.com/meteor-1-7-and-the-evergreen-
dream-a...](https://blog.meteor.com/meteor-1-7-and-the-evergreen-
dream-a8c1270b0901?gi=c82300da60f4)

It's good to see Vue gaining steam as more options = better fit per project.

~~~
quest88
What does heavyweight mean?

~~~
saghm
The term comes from the name of a boxing weight class; the analogy is that a
heavyweight would be hard to "knock out" of the fight. In this case, it means
that the existing market share of React and resources of the team behind it
will make it hard to displace. Note that in this case, it doesn't necessarily
refer to the perceived bloat of the framework (although a pun may have been
intended).

(Apologies if this was rhetorical and I ruined the point you were trying to
make)

~~~
quest88
Seems like a great contender for a small project then. KO in no time :).

------
overgard
I'm always baffled by web developers constantly moving to new frameworks and
toolchains. I can't really think of other sectors of development that chase as
many fads. I mean its one thing if it solves a significantly new problem, but
a lot of times it comes down to like "so and so likes gulp better than grunt
or sass better than less and they're going to stall the project for two weeks
while they switch the codebase over while pretending they're fixing tech
debt". In game development, where developers are frequently on the cutting
edge of things, the idea of switching engines and apis all the time for
marginal benefits would get you a lot of raised eyebrows, and im guessing
desktop app developers and people into scientific computing feel likewise.
Don't get me wrong things evolve, but code in those fields doesn't seem to be
treated as disposably.

~~~
Can_Not
> I'm always baffled by web developers constantly moving to new frameworks and
> toolchains

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.

------
andyfleming
Vue: 238,410 weekly downloads

React: 1,596,809 weekly downloads

(from npm)

~~~
Reedx
I wonder though, how CDN links might mess with this comparison? And whether
devs are more likely to use the CDN version with Vue vs React.

------
threatofrain
To me the most obvious technical competition for Vue is Angular, not React,
and if Microsoft were going to choose something other than React, I would've
presumed it would be Angular.

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.

~~~
exclusiv
I think you're spot on about Angular 1. I really like Angular myself despite
that transition issue but I also like React and Vue. I currently use Angular
for larger web projects (it's more complete out of the box), Vue for smaller
web apps and widgets and React Native for mobile.

------
ggregoire
I often read “I chose Vue because it feels easier than React”.

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

~~~
bhouston
Ease of use matters.

~~~
wetpaws
I found the biggest barrier with react in understanding concepts, not learning
API. API is 3 methods as mentioned above. Once you got the concepts you will
never go back to old ways.

------
crooked-v
As somebody who really likes Vue, I feel like it's hampered by comparison by
not being able to use "real" JS in the bulk of the view templates. There's a
lot of minor boilerplate annoyances in outputting stuff that go away when you
can do array maps and Ramda functions as a direct part of your rendering.

~~~
burlesona
Vue supports both JSX and JavaScript rendering functions and has for a long
time (since at least v2.0 IIRC)

------
kbd
I wish Ebay's Marko got _any_ mindshare. It'd be nice if our choices weren't
limited to React and Vue.

[https://markojs.com/](https://markojs.com/)

~~~
bobjordan
That link is blocked in China.

------
dopamean
Why should anyone care how many github stars one library has compared to
another?

~~~
wmil
Github stars are proportional to the size of the community.

You don't want to bet your company on a project with only a few thousand
stars, it could die quickly.

~~~
atombender
Anecdotal counterpoint: I star projects to bookmark them, so that when I have
a spare moment I can go through the list and find interesting repos that I
might use. But I typically don't unstar later if I stop using something. I
should, but I just don't "clean" my collection that often.

~~~
Torn
+1 for this - I star things to come back to and try out. I've started Vue for
this reason, unlike React which I use in working hours

------
aylmao
This frames it a lot as a competition; it really isn't. Facebook Open Source
is a contributor to Vue.

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.

------
tylerjwilk00
Competitive angle aside, Vue deserves all the stars it gets.

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!

------
matthoiland
Reminds me of [http://isitsnowinginpdx.com/](http://isitsnowinginpdx.com/).

I'm rooting for Vue.

------
cyberferret
Do we consider js frameworks to have 'jumped the shark' when they descend to
the same sort of popularity polling as a reality TV contest? :)

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

~~~
interlocutor
_fitted my mind 's view of how things should work_

Why so? Could you add some detail to this comment?

------
Jonovono
Both are outdated. Cycle.js is the new framework. :)

------
breinhart
I just starred it, and moved it across the finish line! I actually do like
Vue.js more than react, so it wasn't just for the fame!

------
pdfernhout
I prefer Mithril.js, used from TypeScript, with Tachyons for inline-ish CSS.
That is what I use when I have a choice like for personal projects that are
single-page applications (e.g. StoryHarp, NarraFirma, Twirlip7 on github).
That way almost all code is in one language and can be easily refactored.
Mithril is most naturally used via a "HyperScript" API where you define
DOM/vdom nodes via function calls -- e.g. m("div.ba.bw2", m("span.blue",
"Hello World")). Templating systems (including JSX for React) are unfortunate
crutches which ultimately make development harder because they get in the way
of refactoring, modularizing, and testing. And typical semantic CSS use (e.g.
.warning vs. .red) often ends up in a messy snowball where people eventually
are too afraid to remove anything -- whereas if you make your components in
JavaScript code, you don't need semantic CSS. It turns out that "best
practices" for server-driven Web 1.0 applications (e.g. HTML-ish templates and
semantic CSS) often are "worst practices" for JavaScript-first single-page
applications.

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.

~~~
buvanshak
Have you used Elm and if yes, what do you think about it. As far as I have
seen, it blows everything out of the water for me. It feels a bit weird at
first, and It may not be just there yet in terms of features, but the paradigm
is solid.

~~~
pdfernhout
I have not used Elm other than to play with it briefly. I see a lot of great
praise for it though. It seems like a great set of concepts (including design
choices for functional, immutable, and static support -- a bit like Clojure in
the first two) and is very Mithril-like in its vdom and redrawing approach. I
think I would enjoy programming in it. I can see why many people have the
reaction you have -- especially if they come at Elm from, say, using ES5
JavaScript and some complex UI library like AngularJS or Dojo/Dijit or
whatever else.

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

------
keyle
I use Vue at work every day. We build large applications in it and it's
extremely pleasant to use.

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.

------
sdnguyen90
Question for Vue users: whats the value prop over React?

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?

~~~
Kihashi
> Question for Vue users: whats the value prop over React?

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.

------
manigandham
Github stars are a rather meaningless proxy. Many people like have all the
major libraries starred but actual usage is quite different.

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.

------
polymerase
Provocative and simply wrong.

------
projectramo
Microsoft rewrote the whole thing in React Native! It’s like keeping score of
the opposing team in the match when they have already qualified for the
Olympics. Play the long game.

------
luord
I used to hate react, but being forced to work with it for a while has helped
me get used to it. I still very much prever vue so this is great news to me.

------
pwaai
meh, I've given up. At the end, it's whatever your client wants and will
ultimately pay for. React is popular in enterprise circles, Vue.js is also
popular amongst new front end developers and seasoned.

In a few years it won't matter as deep learning will generate front end UI
with just a wireframe sketch.

------
dzonga
It will pass React, when they're more Job posting about Vue more than React.
The market determines the winner not GitHub stars. Even here on the HN
WhoIsHiring threads, React is miles ahead of anything. brutal law of the
market, Vue is pleasurable to use, but the market doesn't care what you think
or care about.

~~~
mrath
I see a lot more jobs on Angular(2+) and React in Australia. Hardly ever do I
see Vue mentioned in jobs and I don't even hear people talking about it. Even
while starting a new internal project, people are just comparing React vs
Angular. But my exposure to frontend stack is limited so I could be wrong.

------
vikaskyadav
Because vue is Chinese and China has huge population of developers! lol Haha

------
elygre
I just starred Vue to give it 100,000 stars.

I'm feeling irrationally happy about that.

------
khazhou
Loading...

(iPhone safari)

------
Apocryphon
Does this mean Nativescript will be on the rise?

------
ryanmarr
22...17...15.. It's about to happen.

------
internalfx
People are actually un-starring react.

------
jaequery
vue makes coding so much more enjoyable than reqct for me that im glad to see
it get more traction

------
dylanhassinger
I love Vue!

------
6nf
It's happening!

------
fowkswe
I just starred Vue to make it even with React at 98,564

------
stevev
Woot! Go Vue.

------
1298471924
People say that "you only have to learn a few things to know react" and that
with Vue you need to learn this whole API and well that is just too much to
learn! These people are of course just trying to find an argument to match
their emotional investment in a product. It isn't a real argument and can be
refuted with logic and maths.

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.

------
megaman22
Maybe people could just stick with one frigging thing for more than 12 months?
I'm sick to death of Javascript churn. Polish one thing up until it is
actually done before chasing some shiny new half-baked thing like a cat with a
laser pointer. A slightly different spin on MVC concepts from twenty or thirty
years ago doesn't get me out of bed, much less rewriting my front-end code
more often than I file my taxes.

~~~
xkcd-sucks
Job security

------
cvakiitho
hehe, my star passed it.

