No one I work with has ever even brought up the possibility of switching from React to Vue, let alone counting Github stars.
Compare to when React came out, it was immediate consensus that we need to switch from Backbone to React. When Angular gained popularity, we did not have an urge to switch because it felt unclear what the scope and direction of Angular actually was.
React (really JSX) solves the single problem of making HTML a part of JavaScript. For me, it's game over, they have solved the problem or came close enough to where I'm comfortable staying in the React ecosystem for the rest of my career.
With React there's no weird "v-if ng-if" template logic that you have to grapple with. To me, Handlebars already gave me enough taste of how horrible and limiting maintaining template logic outside of components is.
Just my take. No desire to even download Vue and try it out, I don't foresee any productivity gains from it.
> React (really JSX) solves the single problem of making HTML a part of JavaScript.
This is the crux of the matter. The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery. We're not looking to get html into our JavaScript -- rather we're looking to get JavaScript into our html!
There is absolutely no reason to switch from React to Vue if it's working for you (and I don't think anyone in the Vue community would argue with that). But you came from using backbone -- the people who love Vue I think primarily come from using jQuery. We feel the same way about Vue as you do about React, and that's okay! (btw I also use react and also think it's great)
As for staying in React for the rest of your career -- give yourself more credit and hope you'll be around long enough that this isn't true :)
> The people who find Vue appealing (myself included) come from the world of design and html+css markup and jQuery.
This is something I've noticed-- spot on. Vue seems popular to people coming from the direction of "augmenting their HTML", whereas React is appealing to me precisely because it's all JavaScript.
Appreciate your comment, it sounds like Vue may be an easier option for you, if you don't want to write JavaScript. However, you should just learn JavaScript, even if you're doing nothing but designing components, will explain why.
I also came from jQuery (Backbone and jQuery was a popular duo, in fact using jQuery in everything was).
The way people wrote apps at one point basically was a stream of jQuery statements, $thing.add('something'), etc.. This created nothing but spaghetti code over time.
Now, we're using React to design extendable components that can be nested, or structured to add more functionality. Check out styled components below to see how much easier it is to combine CSS, HTML into JavaScript. Rebass is built on this as a minimal component library. I know this might be really advanced and you may not adopt any of this, I'm just showing you the latest in what we could be moving toward.
I don't think I would leave React unless JS/HTML/Browsers dramatically changed. The industry is too far into JavaScript code at this point to where I am concerned about job security.
Back to your original point, I don't think Vue would scale well for serious JavaScript heavy apps, so that's why I don't think it's fair to compare it with React, but that's not how it's being discussed, which is some sort of React killer.
It kinda bothers me when people say X won't scale (implying that React is somehow special in this regard).
For one thing, we're not talking about things like database throughput where you can actually have scalability bottlenecks.
If we want to talk about scaling maintainability, React is definitely not much of a poster child either, compared to other solutions I've used over the years. We got a new context API only recently to deal with concerns Angular had already accounted for years ago, and things like the Enzyme adapter state of the world is pretty terrible - and don't even get me started on React Router migrations :)
IMHO, one major thing Vue did right that React didn't which has an impact on scaling maintainability is that Vue owns its most important peripherals (data management via vuex, styling via single file components, animations, etc). In my experience, the React model (also adopted by webpack and babel) is a real pain in the ass to support at scale as a web platform engineer, because many times you're at the mercy of some random dude with no connection to the core project and you end up having to settle with bizarre makeshift configurations, fork things or do other nasty things to get around random design direction changes.
> However, you should just learn JavaScript, even if you're doing nothing but designing components, will explain why.
I think you are reading wrong between the lines. There are no vue users who dont know javascript or are not using with it. The concern is really how are you mixing the two. vue is more of js inside html, while react is html inside js.
And its just a matter of opinion. I work on both vue and react apps and personally dislike writing html inside js. But if the project started earlier using react, I am not going to suggest a rewrite just because of this single preference.
lol, I've been a javascript developer (among other things) for over 15 years :)
The point is that some people/teams/environments prefer to not treat everything as a javascript app. Especially in the agency world -- thinking about one's website from a markup/design-first perspective is a totally viable thing. And if you have designers on your team (or for solo practitioners) you sometimes don't want to javascript all the things. It's great that you found an approach that works for you, but it doesn't mean that it's the only best way for everyone and every situation.
> With React there's no weird "v-if ng-if" template logic that you have to grapple with.
Yes, I hate that syntax. It's like they picked the worst from HTML and Javascript. Instead "if" statements should be dealt with in Javascript entirely.
that was how i felt too which was the same reason i disliked angular. but vue's templating syntax have turned out to be really enjoyable to use. it made me think how wrong i was of my initial impression of vue. you have to give it a try to understand it.
There’s nothing enjoyable about Vue’s syntax. It’s not really HTML, and not really Javascript (it’s Javascript-like ... sometimes). Same goes for Angular, Polymer and Svelte.
And on the Javascript side Vue actually breaks existing assumptions about code. For example, it hoists methods and properties and makes `this` available where it can’t be available.
I also wanted to make an additional comment expressing my frustration with the consistently negative comments on posts like this about JS Frameworks.
These commenters, those who see React as "just another JS Framework" and whom see JavaScript developers as people who would change JS Frameworks as if they were ordering a new drink at Starbucks: These people are the epitome of amateur.
Building web apps has been my career for nearly a decade. If you think entire teams would just up and switch to a new JS framework tomorrow because of a Medium article, or because of Github stars, you don't understand how the industry works at all.
React is not a fashion statement, it's an evolved paradigm shift in the web. Vue is not, it looks like Angular and Handlebars, the way apps were built 5 years ago, it adds nothing to the industry but more bloat and distracting people from using React.
Personally, I view it as a case of right-tool-for-the-job vs the-one-true-way.
The core of the matter boils down to one thing...everything on the web doesn't need to be an SPA because most things are open, check, close experiences.
For the things that don't need to be an SPA, where a server side app serving HTML is a significantly faster user experience and dropping in a small bit of JS here and there is the right approach...Vue makes sense. This is the same place that jQuery makes sense because it makes the goal simple.
For the places where you do need an SPA because the user is going to be opening your site/app and working within it for a while...absolutely...use React. If that's going to translate to a native application, even more so...use React.
The concern is that Single Page Apps with React are gaining the hammer-and-everything-is-a-nail experience...when really only a few things are nails and most things are actually screws.
Just pick the right tool for the job without all of the zealotry, like suggesting anything that is not react distracts people from using react.
React was created by Jordan Walke, a software engineer at Facebook. Facebook had a good reputation at the time, and so we forgive Jordan's divine genius for that slight error in career choice.
It's grand pronouncements like that that epitomize amateurishness. I am so sick of seeing people complain about how things are being X years ago, as if old techniques somehow magically become invalid. Maybe they seem so bad because the practitioner sucked at that time.
React doesn't really respect separation of concerns, and it's rare to find an SPA (and now, desktop apps -- thanks Electron!) that isn't complete garbage. Disciplined approach with battle-tested techniques creates much higher-quality software, every time.
Also, "paradigm shift" is nonsense. The web is a platform -- fetishizing specific tools and techniques is foolish. There are many ways to skin a cat.
You're right! I'm sure there's plenty of high-grade apps still out there that are built on jQuery plugin spaghetti code. No problem with that at all. No reason to criticize that either in any way shape or form. jQuery spaghetti is still a perfectly delicious way to enjoy a web app. Who doesn't love spaghetti?
To me, React also has the killer feature of being "generic enough" that I can see directly migrate-able variants of it still being used in ten years. The backend may change, but the basic setup of JSX -> function transpiling with param-attribute equivalency is simple enough to be a new foundational structure.
That's a big one for me, particularly with the way I prefer to write all my React components: as stateless functional components (just a function that takes props as its only argument and returns some JSX). For adding state, lifecycle methods, etc. I'm using recompose, which is also generic enough that I could easily see myself reimplementing it for some future view library.
Yep, React seems to have been built from the beginning as a new foundation. It leveraged ES6 features just as they were coming out, so we got to learn a new way to write JavaScript and HTML at the same time.
As someone who has built with both professionally, I'd say you're spot on. Vue has been great to work with because its readability and low-barrier to get started, but nothing beats writing plain-old JavaScript with some JSX. Not to mention, Vue can get really hairy with something as simple as passing props between components while React makes that a breeze.
Also curious about why someone would choose Vue/JSX over React. My argument is essentially in favor of JSX, if Vue or something else uses JSX in a more interesting way or creates something better than JSX, that's cool.
- Not all features (e.g. most built in directives) work in JSX, and some 3rd party libs didn't work at all as JSX components.
- The JSX isn't a direct mapping to the object properties in `createElement`, which is how (almost?) every other flavor of JSX works. This means you don't just have to learn the the low-level `createElement` API, you also have to learn how that API maps to JSX. [1]
For example, you can't do `<div domProps={{ innerHTML: 'foobar' }} />`, which you might expect if you just read the `createElement` docs. Instead, you have to use `<div domPropsInnerHTML="foobar" />` (but note that not all `domProps` actually need the prefix [2]). Likewise, event handlers use an `onEvent` camel case convention that maps to the `on` property in `createElement`, which is kinda nice because that's how you add event handlers in other JSX flavors. However, it also means that if a Vue component accepts an `onSomething` prop, you actually have to do something like `propsOnSomething` [3] in JSX, because passing just `onSomething` would convert it to `on: { something: ... }` instead of `props: { onSomething: ... }`.
Overall, when I was trying to use JSX with Vue, it very much felt like a second-class feature, tacked on primarily (if not exclusively) to help convert people from React. However, Vue's flavor of JSX doesn't seem to appreciate that the simplicity of how React maps JSX to `React.createElement` is a large part of its brilliance.
In other words, I think that Vue's flavor of JSX introduces just enough magic to make it confusing. It sacrifices consistency for haphazard ergonomics, making the experience frustrating for someone used to JSX being just an XML-like alternative syntax for `createElement` (or `h` or `m`). I think Vue's JSX would be much better if it didn't try to do any magic, and just forced people to write stuff like `<button on={{ click: () => {} }} />` instead.
In the end, I gave up on using JSX with Vue, tried templates for a bit, didn't like them, and moved away from Vue altogether.
Caveat lector: Things might be a lot better now. I tried to read up a bit to see, but I didn't dig very deeply.
This is pretty much exactly how I feel. There has been a lot of "anti-React" virtue signaling in the Javascript community over the past few years, and I just don't get it. Why is your whole front-end team switching from React to X, where React - X ~ epsilon? If it ain't broke, don't fix it. If you're switching from jQuery or templates to X, it is more reasonable, but I've seen teams rewrite Angular and React codebases in Vue (i.e. "we're hip and modern now").
In my experience, React's API has been far more intuitive than directive-based frameworks, and switching between the various directive-based frameworks seems like too much work for too little change. I would be interested in frameworks which aim to mimic React's API but offer more in terms of size (smaller is better) and performance. This is why I closely watch projects like Preact.
What do you mean by virtue signaling, and how should they defend their choice without virtue signaling?
Is it possible that some just prefer to use something that feels closer to the W3C standards?
Or is the virtue signaling about it being a facebook project, with facebook being a threat to the open web? Angular is a google project, but I've heard some say that since Evan You used to work for google it's sort of like it's a google project, which I disagree with. The clear winner of the three for being independent of FAAMG is Vue. Angular at least has its own GitHub organization that makes it a bit less blatant of an ad for its corporate steward (remember io.js and the movement to get Node moved out of Joyent to a foundation?).
Maybe I was being hyperbolic, but it could refer to any or all of the following:
1. The W3C standards convention
2. Being a product of Facebook
3. The old license being restrictive
4. Too much hype around the framework
I'm positive I've seen people conjure these reasons before. I was deterred from React mainly for the third reason. When they fixed their license, I felt no need to pursue alternatives. I've played around with Vue a bit, and I just wasn't compelled enough to switch to it. It seemed like a solved problem already. The only thing that will get me to switch from React is a 2x in performance and/or a 10x reduction in complexity or size.
Those are all very good reasons, especially #3. It's part of React's track record and you don't have to look far to see other similarities to it. It isn't a sign of being a responsive to their userbase because they waited until the inventor of the world's most popular website publishing platform complained about it.
I don't see it as virtue-signaling but I do think there are three distinct JS communities, even if they overlap a lot, and sometimes they take swipes at each other. Maybe someone can point out more? The three I'm thinking of are 1) the classic webmaster group, aimed at building dynamic and interactive websites 2) the SPA group, making webapps, also extending into things like React-Native, but the web is just a delivery medium for their app 3) the backend group with Node, aiming at the types of things you'd otherwise have used PHP/Ruby/Python for.
I find the whole premise of putting the html in JavaScript bizarre and I think it is a passing fashion while the various debates around web components and shadow DOM isolation get sorted out.
I would hope my graphic artist will eventually be mixing 3 layers of HTML elements that seem entirely standard to him except the 3 different sources of docs.
JSX isn't really an abstraction over HTML, it's an abstraction over document.createElement and the other related DOM APIs. I always liked it because that's really what is happening, JS is causing HTML elements to be created via those APIs. We aren't feeding the browser html files for it to parse.
How is that bizarre? Trying to enforce MVC is done even when it is a lost cause.. But you properly separate html, css and (arbitrary Code language to be replaced by transpiling) and all you hear is "I wish my graphic artist had to understand all of this and what a compiler does before he could fix my poor UX ideas.. and my copywriter should have to find my spelling mistakes using an IDE too."
If my graphic artist expected me to go into Adobe every time I needed a new background, I would ask him what his job was.
It sounds like you're coming from a landing page/blog/Wordpress background. I'm primarily building data-driven apps, like financial data or dashboards. My UX/UI people don't come near my code, and I wouldn't want them to.
For me, every time I need a new button, I'm not going to my designer, I'm just copying over the last button. So I need to be able to quickly edit styles, and state functionality, like dropdowns and date pickers. For these types of components, your life will be a living hell if every time you needed to add a style, you were going to a CSS/HTML file. This was how we first worked with Backbone and Handlebars, and it absolutely sucked.
I see just enough of landingpages and corporate customers and multilingual to see why most of these frameworks ship with toy features when it comes to the lifecycle of the overall site. Then you end up with two parts (a site in so.e kind of CMS and a compiled SPA) that have to look kind of alike where they can only sort of edit one..
Handlebars is just a general text template language so it was naturaly quite rough. From there one can move to dressing components in the angular style and keep the templates all in one folder and the custom CSS in one file.
My designer and I share the templates folder, I usually add enough attributes for bootstrap to do something or other and then the custom CSS is his and the code is mine.
If we were writing our SPAs for consulting clients it would be essential that the templates and CSS were not compiled so they could go on with them without us and without either paying us to keep a bunch of unstable node tooling able to compile and up to date or feeling like we intentionally snuck a time bomb into the project and are underhanded in seeking hours.
That's probably because HTML came first, and the web was meant to be a document sharing platform, not an app environment for everything under the sun. Anyway, people were mixing the PHP with their HTML long before everything got rewritten in JS. The whole argument over what constitutes proper separation of concerns probably proceeds Smalltalk and MVC.
> the various debates around web components and shadow DOM isolation get sorted out.
They won’t. jQuery was a much simpler concept and basically a fluent wrapper around a lot of existing APIs.
11 years later none of the browser APIs are not nearly as easy to use or powerful as jQuery. (Did you know that querySelectorAll returns an object that, unlike jQuery, isn’t an array and doesn’t have the same APIs? They added frigging .forEach to it only a few years ago).
Components are a more complex concept. You need data binding, and virtual DOMs (to prevent out-of-order janky updates to the DOM), and templating, and a solution for both global and isolated CSS, and..., and..., and...
These issues won’t be solved in the next 50 years. And that’s the reason no one uses (or talks about) vanilla WebComponents. Everyone is using any of the dozens of wrappers or frameworks on top of them.
I'm comfortable staying in the React ecosystem for the rest of my career.
You won’t have that option. No one has had it with their favourite tech for decades now. Hell I’d still be writing Motif code if I could. Unless you are 2 years from retirement in which case, enjoy!
2008 is more similar to 2018 than it is to 1998. I will wager that 2028 more similar to 2018 than 2018 was to 2008.
Doesn't look like there's a future appearing where we strap on our Magic Leap and wave our hands around and suddenly single page apps appear.
I'm giving my opinion that React ecosystem will stay around for an absurd amount of time because unlike jQuery, the size of the community and usability of the tool scales really well. Maybe people said the same thing about Rails, or Motif, but I just feel like React is the end of the line for whatever we're doing here.
See if the question is how do you host an application on a server and run thin clients with local rendering and some limited local interactivity... then that problem keeps getting solved over and over again. X11/Motif and “React running in the browser” are fundamentally the same thing. Every solution actually works pretty well, fulfilling all use cases. Then for no reason we chuck it all away and start again.
All of this has happened before and will happen again
> With React there's no weird "v-if ng-if" template logic that you have to grapple with. To me, Handlebars already gave me enough taste of how horrible and limiting maintaining template logic outside of components is.
React was a good step in the right direction. But IMO they lost the plot with things like:
> React (really JSX) solves the single problem of making HTML a part of JavaScript
The reason I like the way Vue works is because it makes javascript part of the HTML definition (with component definitions), essentially the opposite of what you like about React. That said, my use case of Vue is very different to my use case for React. Even though Vue does essentially solve the same problem set, their approaches have pros and cons in different scenarios.
(all that said I typically don't need to use either for what I do, in preference of light vanilla JS classes)
My use case where Vue fits better is in lots of isolated reusable components that aren't tied to a global state. So an image slider or datepicker for example.
But I would consider React and Vue for building a larger scale, stateful application like Spotify or Slack.
>When Angular gained popularity, we did not have an urge to switch because it felt unclear what the scope and direction of Angular actually was.
I do not remember React coming in before Angular. I loved Angular1. But Angular2 made me very uncomfortable and thats when I switched to React. And I'm not looking back.
Even if I need a very simple drop-in not-transpiled solution without the React tooling - I always fall back to Angular1 instead of using Vue. Fortunately I have no regrets moving to React.
Sorry, I told the story out of order, we saw Angular and passed on it.
Also have no regrets or issues with React. Been 3 years now and I have no complaints or frustrations with my job anymore, compared to the horror of adding jQuery plugins.
With Vue and Angular you don't have to deal with controlled components, and you don't have to figure out how to mix JavaScript expressions with JSX expressions (sometimes it gets ugly).
Javascript-like scripting in strings? Check. Different versions of HTML-like attributes? Check. Magic binding of all that to specific structures in JS code? Check.
But please, do tell me how it’s beter than React where you “have to figure out how to mix JavaScript expressions with JSX expressions (sometimes it gets ugly).”
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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)
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.
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.
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.
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.
Isn't the survey you posted, counting the "number of pages" (which isn't exactly a good metric in the world of SPAs), even funnier by entirely looking at the development side of things?
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.
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.
Vue, React and Angular (and many other frameworks) have enough critical mass that they aren't going away, and will continue to get regular updates. This, combined with how well the framework fits your particular use case and team, is all that matters. Why we focus on which one is "biggest" is beyond me. Biggest doesn't matter. Big enough does. Once a framework achieves that size, it can be considered for things other than personal toy projects, and all the other factors are what should guide your final decision.
I've never heard anyone say that you can do X in Vue much easier than in React. I've heard a bunch of people say that it's easier to learn than React, but I found React very very easy to learn anyway. Basically, I've not heard a convincing reason to look into Vue yet, so I haven't.
Also, people contact me about jobs involving React several times a week. I've never been contacted about a job involving Vue. Not once.
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)
I had a friend say something that I think is a pretty good way to look at it. He said: "React is the blockbuster hit at the box office, while Vue is the critics' darling"
The big question is if it's good enough to replace what's already established. Things will probably equalize eventually, but by the time Vue overtakes, if it does, there will probably be some kind of new and shinier thing that intends to replace both of them.
I think using number of downloaded will also count number of build on each commit. Imagine if you have three branch in your repository, each push will rebuild the project (redownload dependencies). If you push three times a day it will download three dependencies three times.
Also, some project include their dependencies to VCS which only count once per build.
I was thinking what is the reason that Vue have more stars than React given it is not used more (perhaps in China it is). My guess would be that it's because Vue is more community driven than React. Vue is dependent only on community while React is dependent on Facebook & community. Therefore I believe Vue community share more excitement for the project.
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.
That's alright to me, I use vue in my own projects and react at work and while I greatly prefer one, I don't hate the other (anymore).
An aside note is that I wish there were fewer developers in this type of threads pretending that the abomination that is JSX makes react better than vue... which can use JSX just fine.
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)
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.
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.
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.
Compare to when React came out, it was immediate consensus that we need to switch from Backbone to React. When Angular gained popularity, we did not have an urge to switch because it felt unclear what the scope and direction of Angular actually was.
React (really JSX) solves the single problem of making HTML a part of JavaScript. For me, it's game over, they have solved the problem or came close enough to where I'm comfortable staying in the React ecosystem for the rest of my career.
With React there's no weird "v-if ng-if" template logic that you have to grapple with. To me, Handlebars already gave me enough taste of how horrible and limiting maintaining template logic outside of components is.
Just my take. No desire to even download Vue and try it out, I don't foresee any productivity gains from it.