Maybe star power is more of a sign of acceleration than usage. For example, if I have several projects in react, and then I start to move into Vue, it is not like I am going to convert my past projects over to Vue as well. I'll only be starting my future projects in Vue.
So that means more and more developers are beginning to get interested into Vue.
Artifactory is a pain in the butt, but it’s atill a lot better than sharing a gigabit line with twenty other developers, the IT dept and those assholes in management who watch the ball gane on their work computer.
I agree that number of use is a good factor when choosing a framework. But Vue has incredible tools, resources and community so don't let that get in your way. I've tried all three and Vue is just such a pleasure to use.
People have wildly different views on what Github stars are. Some see it as a way to bookmark project you find interesting while other simply stars whenever they feel like the project is impressive.
Bottomline is: it's not a good metric, it's simply a way to see how "popular" something is and how likely it is that some random developer saw your project.
While anecdotal, I've starred Vue because I see it as a cool project and I've starred React as another cool project. In both case, I did toy projects with the frameworks and never used it in production. On the other hand, apache/httpd I did a lot of projects with and I did not give it a star yet.
In my opinion stars are not endorsement, they're a questionable way to measure how likely it is that your coworker have heard of a given project.
Also having created, promoted, and contributed to repositories with >100 stars it seems that ~10% of people who view the repository will star it. Not sure how reliable it is but I've always taken stars to indicate how many people have seen the project.
Ohhhhh, now I understand why that one ex-coworker that 'follow' stars about 20 projects a week. I always used them as bookmarks and I couldn't believe that they ever were going to use that many things.
React ecosystem heavily encourages the use of build tools dependent on NPM package management.
Vue users are more likely to bypass NPM. They are often on-boarded with the gentler approach most familiar to those who "sprinkle in some jQuery" - Drop in a <script> tag and you are ready to rock. This approach is more likely to use a local file or from CDN.
Curious how Vue users are getting by without Webpack / Parcel for Babel and maintaining 3rd party dependencies via NPM? Copying and pasting Vue components from Stack Overflow? That approach may be fine for small web pages, but for commercial applications, it's not a viable approach.
You don't need babel if you don't use jsx (which for vue is the default). I've personally only used vue the way you would use jquery. Adding a full webpack/babel/npm stack with a build step and all would be too much work; I barely understand what webpack is in the first place.
If you barely understand what Webpack is then you probably aren't in a good position to argue for or against it's usage. You do need Babel if you intend to use newer JavaScript features but still have to support older browsers or even many mobile browsers. If you're only writing with ES5 features then you don't need any transpilation but many people want to use the new features available in newer versions of JavaScript/ECMAScript.
Webpack is great for, among other things, combining your code into single packages instead of including many script tags. It's also useful for optimizing the output of your build in various ways which makes it very valuable for large-scale applications.
We avoid Webpack/Parcel and NPM dependencies entirely. I understand that convenience wins for most people, but it comes with a cost. Dependencies are magically stitched together with limited developer insight, arbitrary 3rd party code can make it into your production bundle on a whim, and it is far from "optimized" output.
We use rollup[1] for our production bundle. We manage all 3rd party dependencies by source control. We don't need to rely on NPM for ES5/ES6/CommonJS/AMD/Modules - We have full control of each dependency to use the code that is most fit. Sometimes that is already checked-in by the author, sometimes we need to build it, sometimes we can use the modern ES6 code directly, sometimes we can remove duplicate polyfills already in our bundle.
It takes bit more discipline, but the extra security, optimal build, and peace of mind knowing how things work, are well worth the effort to us.
I star plenty of things that might be crap, but have something interesting about them. Not saying that applies here, but some of my favorite libraries aren’t starred because I use them so much and have the page memorized. Stars are a terrible metric. For example, I don’t have Rails starred.
Appreciate !== vs !=, no type conversion on Stars and Usage in comparison.
Also, agreed. Would be more interesting to crawl all repos to see which have React vs Vue vs Angular for a more detailed understanding of usage.
Why do people care which framework "blows" the other one away? In my opinion, it literally doesn't matter at all and arguing over such things seems amateur.
I mean, I could technically dig a hole in the ground with a spoon...it would get the job done, after all...or I could use a shovel or a back hoe. All three are capable of digging holes. Discussing which tools work best is an important question in software development. After all, the tools you choose can be force multipliers in your overall productivity as a team or organization.
No, because the cost of switching between the two is roughly zero. If switching took 6 months and $100K there would be lots of articles in the hole digging community about when and why to pick between the two.
> Why do people care which framework "blows" the other one away?
I suppose two factors:
- The scale/"startups = growth" tenet of Silicon Valley/Wall Street trickling down to micro business decisions — pick as many of (whatever is most popular | comes from Massively Scaled Company | used by companies trying to Massively Scale | growing in popularity fast) as possible
- Feedback loop of bosses/managers who make technical decisions based on hirability/availability of paid long-term technical support/brand name (In 2018, nobody ever gets fired for choosing whatever is the equivalent of IBM now)
I agree. The use of "Blowing away" in the title is incendiary and unnecessary.
It would be far better to state the metric they're using, i.e. "GitHub Stars !== Usage: React downloads still surpass Vue and Angular"
It's taken React about 2-3 years to go from being head to head with Angular(JS) to being the dominant frontend ecosystem. I expect within 2-3 years Vue and React will be on far more equal footing in terms of usage and jobs. (Assuming something else doesn't come along and topple the current trend towards reactive frontend tools.)
> I expect within 2-3 years Vue and React will be on far more equal footing in terms of usage and jobs.
I don't think this is true, primarily because of the number of large companies getting behind React and contributing to the ecosystem. Also, the difference between Angular and React is much larger (IMO) than the difference between React and Vue, which means there is less incentive to move to Vue if you already know React because the latter is Good Enough™.
On the other end, Vue is a natural move for companies looking to move off of jQuery and AngularJS but afraid or unwilling to make the move to React, and I suspect there are an order of magnitude more companies in this category than companies that have already adopted React.
I think you are right about the volume of companies in that category, though I think you are underestimating the network effect of a library with as much momentum as React. The libraries are similar enough that, for many (most?) projects, it makes more sense to use the more popular one.
That's the problem: there are so many tools/frameworks/libraries etc. with so much overlap that people don't know what tool is for what job anymore. And there might not be a real answer to that. When you have a situation like this, people tend to use proxy measures like github stars to figure out what tool to use. Sure, it might not be the right tool, but it's at least picking a tool, as opposed to being locked in constant confusion about which path to take. Sometimes the right tool is the tool you have.
I don't strictly disagree, but it is worth considering for anything other than hobby projects what is the mid to long life expectancy of the stack you are relying on.
An unmaintained lib might not become a problem or it could become a major obstacle down the line. It's a gamble.
While we're talking about starring, here's a great webapp that lets you tag and organise your existing GitHub stars beyond the anemic official capability (filter by language)
A lot of people using Vue just link Vue from a CDN and drop it in a webpage as a script, without using NPM. Does the stats account that fact? Sure you can do that with React as well, but you wont in production with JSX as one needs to compile it with node.js toolchain. Same for Angular. Vue usage is more like jQuery usage than React in practice.
After building two large applications using React, Redux, Redux Sagas, and Typescript, I feel burnt out. I'm honestly surprised Elm or ReasonML aren't more popular as they seem to provide all those aforementioned libraries in one go.
Vue is ascending precisely because it combines some of the better features of those libraries - most notably, the centralized data store concept, which was the driving force behind developing Redux (having your state in one place instead of spread out across many components.)
The problem with elm and reasonML is that they are entirely different languages. Untill they are validated by big companies like Google, FaceBook or Microsoft, they won't become mainstream.
Not really big fan of articles like this. Why the need to compare and say this one has more stars, or is more used, etc.
I am thankful that we have these frameworks / libraries / modules that have greatly helped in our software development process.
At the end of the day, what matters is developer productivity, their happiness and satisfaction (regardless of the toolkit they use), and the overall value that their product brings to their intended target (outcomes).
P.S.
I use Vue, React, Angular, whichever suits the need of the client the most.
If approaching a choice of tech stack in a bubble; it can be a useful datapoint to know which is more widely used. Waaaay back when, maybe I would have chosen jQuery instead of MooTools if I had better metrics, both did everything I wanted.
Though to be fair; by the time it would have mattered I had moved on.
In general I agree with you, but our company is very "consistency" heavy. So someone high up has to make a decision: which framework to adopt, because once that decision is made, it's sticking for a long time.
And sadly I don't think developer happiness & satisfaction are real concerns for a company that knows how to make money.
It's a reasonable expectation that a framework with more users will have more documentation, more examples, more contributions from the community, etc. While I agree that a developer should choose based on what will make them most productive and happy, popularity is still an important factor.
When comparing 2 or more frameworks or libraries to use, I always check out the github repo and look at the number of stars. I don't see a problem with this article pointing out that this metric may not be the best indicator of usage.
Also, in enterprise consultant built apps we often have to consider what kind of talent we're going to be able to get for that project. It's much easier to get Angular and React developers than Vue developers at the moment. That could certainly change in a year of course.
It boggles my mind that companies don’t expect frontend devs to be able to transfer knowledge between frameworks. Do they just not have that skill or do companies really not believe those devs are capable of that? Or both?
We know that good devs can pickup new frameworks quickly and easily. But, when we're charging our customers top dollar they want devs who are experts day 1, and (unfortunately) we can only charge top dollar if we bring those people. But, that's just our business model... I know some other consulting companies that charge lower rates and hire people with less experience.
I think that Vue.js is on the ascendance. I mentioned this earlier. It is on track to exceed React.js if things continue in this fashion. Github stars are a reflection of interest.
I for one measure my developer e-peen (used to get me real women interwebz dates) by how many stars my framework of choices uses. I am shocked and appalled by these findings.
In usage, maybe. React is the "people are learning this instead of raw javascript" kind of default that jQuery became.
I hope it does the same thing that jQuery did, and that is essentially make itself unnecessary in a lot of ways. Take all the really good features of React and make them browser-native.
To a certain degree, this is already happening. Web components are inching closer every day.
One thing to think about is what is the motivation/incentive for someone to take a specific action. For me personally, I will "star" something that I find interesting AND I think I might forget how to find it again. Example: people might forget the exact name/repo for colors.js so they will be incentivized to star it, but no one will forget "apache".
That's why vue might gain more stars than the current dominant players (react and/or angular)
139 comments
[ 2.2 ms ] story [ 240 ms ] threadSo that means more and more developers are beginning to get interested into Vue.
Bottomline is: it's not a good metric, it's simply a way to see how "popular" something is and how likely it is that some random developer saw your project.
While anecdotal, I've starred Vue because I see it as a cool project and I've starred React as another cool project. In both case, I did toy projects with the frameworks and never used it in production. On the other hand, apache/httpd I did a lot of projects with and I did not give it a star yet.
In my opinion stars are not endorsement, they're a questionable way to measure how likely it is that your coworker have heard of a given project.
- One has 3750 unique visitors, and 680 stars in 2 weeks
- Another has 80 unique visitors, 20 stars in 2 weeks
Vue users are more likely to bypass NPM. They are often on-boarded with the gentler approach most familiar to those who "sprinkle in some jQuery" - Drop in a <script> tag and you are ready to rock. This approach is more likely to use a local file or from CDN.
Webpack is great for, among other things, combining your code into single packages instead of including many script tags. It's also useful for optimizing the output of your build in various ways which makes it very valuable for large-scale applications.
We use rollup[1] for our production bundle. We manage all 3rd party dependencies by source control. We don't need to rely on NPM for ES5/ES6/CommonJS/AMD/Modules - We have full control of each dependency to use the code that is most fit. Sometimes that is already checked-in by the author, sometimes we need to build it, sometimes we can use the modern ES6 code directly, sometimes we can remove duplicate polyfills already in our bundle.
It takes bit more discipline, but the extra security, optimal build, and peace of mind knowing how things work, are well worth the effort to us.
[1] https://rollupjs.org
There is no winner anyway, both React and Vue are amazing tools giving you the power to solve the same problem in different ways: building UIs.
And at least a half of them hated it. When something better came along they dropped it like a rock.
Usage is a poor predictor of future sucesses. If people ar rooting for someone else, people have already started turning on you.
Use whatever tool gets the job done.
I completely agree, but would you write an article titled "Spoons still blowing away Forks in digging holes"?
I suppose two factors:
- The scale/"startups = growth" tenet of Silicon Valley/Wall Street trickling down to micro business decisions — pick as many of (whatever is most popular | comes from Massively Scaled Company | used by companies trying to Massively Scale | growing in popularity fast) as possible
- Feedback loop of bosses/managers who make technical decisions based on hirability/availability of paid long-term technical support/brand name (In 2018, nobody ever gets fired for choosing whatever is the equivalent of IBM now)
It would be far better to state the metric they're using, i.e. "GitHub Stars !== Usage: React downloads still surpass Vue and Angular"
It's taken React about 2-3 years to go from being head to head with Angular(JS) to being the dominant frontend ecosystem. I expect within 2-3 years Vue and React will be on far more equal footing in terms of usage and jobs. (Assuming something else doesn't come along and topple the current trend towards reactive frontend tools.)
I don't think this is true, primarily because of the number of large companies getting behind React and contributing to the ecosystem. Also, the difference between Angular and React is much larger (IMO) than the difference between React and Vue, which means there is less incentive to move to Vue if you already know React because the latter is Good Enough™.
That's the problem: there are so many tools/frameworks/libraries etc. with so much overlap that people don't know what tool is for what job anymore. And there might not be a real answer to that. When you have a situation like this, people tend to use proxy measures like github stars to figure out what tool to use. Sure, it might not be the right tool, but it's at least picking a tool, as opposed to being locked in constant confusion about which path to take. Sometimes the right tool is the tool you have.
An unmaintained lib might not become a problem or it could become a major obstacle down the line. It's a gamble.
https://astralapp.com/
(I'm unaffiliated)
React 138,829,602
VueJs 33,952,225
I am thankful that we have these frameworks / libraries / modules that have greatly helped in our software development process.
At the end of the day, what matters is developer productivity, their happiness and satisfaction (regardless of the toolkit they use), and the overall value that their product brings to their intended target (outcomes).
P.S. I use Vue, React, Angular, whichever suits the need of the client the most.
Though to be fair; by the time it would have mattered I had moved on.
And sadly I don't think developer happiness & satisfaction are real concerns for a company that knows how to make money.
When comparing 2 or more frameworks or libraries to use, I always check out the github repo and look at the number of stars. I don't see a problem with this article pointing out that this metric may not be the best indicator of usage.
I do worry that Vue.js is mostly one guy, you like to at least have a higher bus factor than one: https://en.wikipedia.org/wiki/Bus_factor
I hope it does the same thing that jQuery did, and that is essentially make itself unnecessary in a lot of ways. Take all the really good features of React and make them browser-native.
To a certain degree, this is already happening. Web components are inching closer every day.
This makes me reluctant to jump in and burn bridges.
That's why vue might gain more stars than the current dominant players (react and/or angular)