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.
It'd be an interesting project to compare frameworks/tools by aggregating the stars (or whatever metric) of its major (i.e. filtering out hobby forks and skeleton repos) dependent projects, e.g. the 22K stars of gatsbyjs/gatsby would count towards React's overall reach/popularity.
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.
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.
Mature. It has nothing to do with the framework itself -- with CRA React is as dead-simple as it gets. However people look at all the infrastructure made for people who build large, complex React applications and assume it's more complicated than Vue.
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)
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.
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.
Yeah it's tough. Do you go into a new technology and have issues finding jobs or do you use the tried and true, risk stagnating and costing yourself future jobs.
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.
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
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.
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.
99% the jobs for PHP "development" I've come across in the past couple months have been requiring lots Laravel experience. And quite a few of those have required a bachelors in computer science...
I think I saw maybe one that said something about Symfony. I've been doing the "I'll just learn it, even though the framework is built upon horrible practices that we've been screaming not to do for over 10 years now!"
Yeah and the interesting thing is it uses a lot of Symfony components. The Symfony components are really high quality themselves but I strongly dislike the framework.
VueJS has been officially blessed by the creator of laravel and one of the top contributors Jeffery Way made a video tutorial series. I think the latest version of laravel mix has first class support for VueJS.
Well I'm going throug a 31 hour Udemy "course", after doing a couple of other tutorials (one having some SQL/ORM issues which I had to comment to point out the issues and fix). Also I find it still feel funny about learning something about things done in text through videos, so that's probably why I really haven't come across the usage of Vue.JS yet.
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.
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.
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.
I agree that they're very different, but at the same time, there's a non-trivial base of users who earnestly believe that when you're picking a JS framework to use for <insert whatever>, momentum is a meaningful factor in it.
Obviously, it rarely makes sense to select a framework that is completely disused, or unsupported, but there are articles out there by reputable sources who assert that if you're not using the current hotness, you're going to miss out on every new tool that crops up in the ecosystem, and your startup will languish and die as a result of having to spend so many more cycles just to keep up with what other people can 'npm install'.
What's worse is that they're not entirely wrong. Any good plugin for Vue right now is going to show up in React or Angular post-haste, if it doesn't exist there already.
Edit: I also can't help but wonder how many people saw this article, clicked the link, realized it was based on stars, and then went and starred Vue (exactly as I did). Every time I refresh, Vue is closer to 'toppling' React (at least according to these nonsense metrics)
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.
> 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.
Then let's say that Angular2 had the same business value of, for example, free meals, stock options, cool company parties and a sense of purpose. In other words, keeping the developers entertained. With the possibile difference that while the above things actually have a value in themselves, the new shiny framework only has one because people are afraid to be left behind.
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.
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.
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?
This seems like a very cynical comment to me, and I find it strange that no one has tried to rebut this yet. I always found it refreshing that Hacker News tried to resist this kind of thinking. Is that spirit fading?
I still see both React and Angular as extremely compelling choices. This website merely turns Vue into another viable choice. However, I sent this link to a PM who I frequent for feedback on pet projects (smart colleague, lots of valuable dissent).
In a nutshell, I'm trying to turn <something> into a bare-bones HTML page. We currently use an XML document interpreter that was written in 2006; with performance woes and maintainability woes abound. Transpiling to JS neatly solves this.
I started off with my own Angular-like template language, for which this PM correctly scolded me: people will need to learn it. He indicated that I should just use Angular - but the problem is that Angular is opinionated and at odds with this legacy system that I'm trying to clean up. I struggled for at least a week and I dropped for good reasons. I had a discussion with him last Friday and suggested Vue (as it is far closer in execution model when compared to what I am trying to solve): "what's Vue? We shouldn't use niche frameworks, people will need to learn that." Now I have an answer to that :).
I completely agree with you, but there is still the point of 3rd party support and workplace acceptance (this is somewhat similar to the stupid "gaming console war").
The more popular a library is, the more support its ecosystem gets, and the more likely you can convince your boss/company to use it. So if you prefer one, you may really want it to be "the most popular" to ensure you can keep using it.
Eg: people who really like Angular 2+ are kind of struggling right now. If you join a company and they're not already using Angular 2+, good freagin luck. Chances are they won't switch from React/Vue/whatever to it anytime soon.
Because of this, and the general perceived volatility of the JS ecosystem, its not too surprising people treat this as a "war". It's unfortunate.
Another example: Typescript vs. Flow. Two different type checkers, with different capabilities and pros/cons. But given that many devs are using VSCode now there is so much emphasis being placed on Typescript by MS that Flow is slowly becoming a second-class citizen.
Great example. Also means you can google anything about TypeScript like the most obscure bug, and SOMEONE has hit it before you. Flow, not so much.
Facebook really screwed up by not having Windows support for the longest time, and even after they did, not having it as a first class citizen (since most statistics have FE devs to be roughly 50% on Windows). Not that they cared about adoption, but as Flow users, we did.
At my company we started out with Flow and eventually agreed to switch to TypeScript, as the former is getting to be too obscure a technology.
If you join a company and they're not already using Angular 2+, good freagin luck.
You can say that about any library; it has nothing to do with the popularity, support or quality of the particular dependency. If the technical decision makers choose not to use something you like then you won't get to use it.
This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
>You can say that about any library; it has nothing to do with the popularity, support or quality of the particular dependency. If the technical decision makers choose not to use something you like then you won't get to use it.
The "technical decision makers" though has very much to do with the "popularity, support or quality of the particular dependency".
If a dependency is popular then more technical decision makers at more companies will be using it, and the more choices one that likes/wants to work with it has for a job.
>This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
Which will make the point moot, as they wont be the one coding using the technology anymore.
Example: a company is using Angular 1 today and looking to modernize their stack. You have been hired, and one of your first tasks is to pick a new framework and convince the rest of the team that it's the best choice. You're thinking about the following options:
1) React
2) Vue
3) Angular 2+
4) Aurelia
If your preference is 1) or 2), it shouldn't be too difficult, even though it means a complete rewrite or building in-house adapters to migrate gradually. If it's 3), even though similar adapters exist, good luck convincing anyone. If it's 4, you're basically dreaming.
People are crazy. You give them options, and they want a war to extinguish them and create a winner. There must be a narrative and a winner to rule them all. Otherwise, how do you know what you’re doing is right, after all?
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.
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.
I disagree. Vue is just a view layer, as is React. Angular is much more. Also, a lot of people are saying Vue and React are so different, but to me they actually seem very similar. They require the same kind of component-thinking and they both let you declare your view as a function of state in a similar way (JSX vs DSL). They both have similar problems with similar solutions.
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.
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.
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
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.
> Weird thing, commits to Vue are decreasing over time and are mainly done by a single individual
The Sistine Chapel was mainly painted by a single individual.
(for the record, Michelangelo had apprentices to help him mix plaster, etc. But he phased them out when it came to painting. Traditionally master painters had apprentices which would paint with them, but he would rather avoid the differences in opinion and arguments while painting the chapel. He had the vision and the skill. I think that’s the case here as well. Not saying Evan is Michaelangelo, but he does have a good vision with his product and the skill to execute on it.)
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.
> React also has more than 4x as many dependent packages in npm, which could be propping up its install count.
I don't think this would do anything. If you have three packages that depend on React, you still only install it once. If anything, the number of packages that depend on React is an indication of its popularity.
> 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.
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.
I think it's interesting that much like on the global trends on Google [1], Alexa surfaces that Vue seems to have some traction in China:
Country Percent of Visitors Rank in Country
China 59.1% 631
United States 8.7% 7,245
Japan 3.7% 6,109
Iran 2.8% 2,373
India 2.2% 8,422
Country Percent of Visitors Rank in Country
United States 33.3% 3,312
China 9.8% 6,694
India 8.5% 4,016
Japan 4.9% 7,585
Iran 3.6% 2,632
The top Sites linking into React (according to those Alexa links):
Similarly to number of stackoverflow questions not being a valid gauge for popularity, I don't think that this is necessarily representative of popularity. What if react is simply more mature and doesn't need to market itself as much, so more people are using it than need to find out about it?
> For Vue to catch up to the number of React stars would mean that their rate of starring is significantly higher.
That's pretty interesting actually, and presumably means a lot of people find Vue interesting, yet it's not as widely adopted as React.
> The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.
I mean, that is if React usage slows down and Vue's continues to grow. I didn't draw that conclusion from the links you provided (but I didn't conclude otherwise either).
Edit: a downvote with no reply? Why the downvote? Did I say something that's wrong?
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).
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.
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.
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.
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.
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 ).
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 fir...
This was beautifully composed. I also use Mithril.js for most if not all my SPA builds. It’s an 8kb solid little framework and I can cook it into virtually any web application because of this.
Vue and React are great but in my experience they’re virtually an overkill for most projects. I recently come across a Shopify cart integration using Vue and was sorta dumbfounded that an engineer decided to include a 50kb framework to handle a couple of Ajax requests. I ask myself why? The answer is hype. Hype can be the demise sometimes.
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.
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.
169 comments
[ 3.1 ms ] story [ 219 ms ] threadYou don't want to bet your company on a project with only a few thousand stars, it could die quickly.
GitHub stars are a more a measure of hype than the size of the community.
And much of it is still on 1.x
https://github.com/ruby/rake
It'd be an interesting project to compare frameworks/tools by aggregating the stars (or whatever metric) of its major (i.e. filtering out hobby forks and skeleton repos) dependent projects, e.g. the 22K stars of gatsbyjs/gatsby would count towards React's overall reach/popularity.
(iPhone safari)
React: 1,596,809 weekly downloads
(from npm)
Stars might matter to some but it looks like React is here to stay and be the most supported and used library for some time.
Looks like they are moving their office suite of software to React.js.
https://mspoweruser.com/no-microsoft-is-not-rewriting-office...
https://blog.meteor.com/meteor-1-7-and-the-evergreen-dream-a...
It's good to see Vue gaining steam as more options = better fit per project.
(Apologies if this was rhetorical and I ruined the point you were trying to make)
I'm rooting for Vue.
Anecdotally from my on and off job searching, React leads here by orders of magnitude. And unfortunately for me, my Vue personal experiments/side projects have to be put in the sideline for a bit. Many people I've talked to want direct React experience and not just experience in reactive frontend stuff.
(have used both React and Vue a lot, haven't starred either one)
In B2B spaces where there are limited competitors and vastly different levels of investment involved for the users, the UI largely becomes irrelevant as long as it works.
I've recommended other b2b services over Salesforce because they have such a shitty UI and it worked out nicely.
I'm still maintaining a web forms program first started in 2002. I dream of MVC.
(I am tongue in cheek here - I realise stars <> actual usage in the wild, and the results can be gamed).
For what it is worth, as a 35+ year veteran in the software coding world, I tried dabbling in both frameworks, and Vue seemed to make more sense to me and fitted my mind's view of how things should work.
Why so? Could you add some detail to this comment?
In a few years it won't matter as deep learning will generate front end UI with just a wireframe sketch.
A good comparison is backend stacks. Rails exists, but so does Laravel and Django. If it were truly a big deal which was the biggest, then only one choice would remain. Instead, they all have healthy ecosystems with companies using all three.
It doesn’t have to be a war.
Obviously, it rarely makes sense to select a framework that is completely disused, or unsupported, but there are articles out there by reputable sources who assert that if you're not using the current hotness, you're going to miss out on every new tool that crops up in the ecosystem, and your startup will languish and die as a result of having to spend so many more cycles just to keep up with what other people can 'npm install'.
What's worse is that they're not entirely wrong. Any good plugin for Vue right now is going to show up in React or Angular post-haste, if it doesn't exist there already.
Edit: I also can't help but wonder how many people saw this article, clicked the link, realized it was based on stars, and then went and starred Vue (exactly as I did). Every time I refresh, Vue is closer to 'toppling' React (at least according to these nonsense metrics)
If your startup dies because of your choice in javascript framework, you were doomed from the get go.
“Linux is better than Windows”
“Android is better than iOS”
“Python is better than PHP”
“Vim is better than everything else”
[1]: https://www.destroyallsoftware.com/talks/wat
We’re using tech that’s outlived more fads than I can count, yet I’m still surprised when younger hires insists on using stuff that’s basically supported by one man.
I’ll admit JAVA almost made it to the list of techs we were going to have a conversation about in the late 00s, but these days it’s as relevant as ever. So is C#.
The front end is nothing but terrible though. I trained a few of my employees to do angular, and then they had to relearn things with angular2. Maybe that’s not an issue for start ups where youngsters slave away in their free time, but it cost me roughly $60.000 in expenses and missed work to retrain our people.
Had to? Did you hit the limit of the things you could do with AngularJS?
Your developers probably decided to move to Angular2 because it was new and shiny, and when they'll be out for a new job it'll look good on the CV. I doubt there was any business reason for investing those $60k.
* We operate a lot of IT systems, some of them are build in corporation with smaller local firms. This isn't necessarily the most sound decision financially, but it's a political decision to support the local area. We handle the business end, the project management, we do fairly strict code reviews and we take over once it's ready for operations. I said it wasn't the most sound decision financially, but so far it's actually been a cheap way to develop smaller user friendly functionality in a lot of areas. None of these small companies have AngularJS qualified people anymore, and haven't had for a while.
* I can't hire people to do AngularJS. It didn't stick around for long enough for any real talent to develop on it, at least not in Denmark. I'm not hiring from the most lucrative position either, mind you, it's the public sector after all.
* I don't want to operate two Angular versions in my stack. I already manage more than 500 different IT systems, it'd be crazy to manage more JavaScript frameworks than I have to.
* I spend a lot more than $60k upgrading my employees. A few of my developers wanted to go with Angular 2 rather than stick with AngularJS. I'm perfectly fine with that. They could've learned something else, but I generally let my employees chose their direction as long as it also makes sense on the business end. This upgrade was perfectly fine with me.
Unless Google does a completely new take on Angular2-6 in the coming years, it'll turn out to save me a lot more than the $60k in the long run.
They're perfectly valid reasons, but they have nothing to do with the quality of tool, or of the product, or with the cost sustained to develop it. Basically you had to move on just to stay exactly where you were.
We pick a tribe and can be loud and obnoxious in support of them.
- Albert Einstein
Stop being apologetic of that piece of shit.
In a nutshell, I'm trying to turn <something> into a bare-bones HTML page. We currently use an XML document interpreter that was written in 2006; with performance woes and maintainability woes abound. Transpiling to JS neatly solves this.
I started off with my own Angular-like template language, for which this PM correctly scolded me: people will need to learn it. He indicated that I should just use Angular - but the problem is that Angular is opinionated and at odds with this legacy system that I'm trying to clean up. I struggled for at least a week and I dropped for good reasons. I had a discussion with him last Friday and suggested Vue (as it is far closer in execution model when compared to what I am trying to solve): "what's Vue? We shouldn't use niche frameworks, people will need to learn that." Now I have an answer to that :).
The more popular a library is, the more support its ecosystem gets, and the more likely you can convince your boss/company to use it. So if you prefer one, you may really want it to be "the most popular" to ensure you can keep using it.
Eg: people who really like Angular 2+ are kind of struggling right now. If you join a company and they're not already using Angular 2+, good freagin luck. Chances are they won't switch from React/Vue/whatever to it anytime soon.
Because of this, and the general perceived volatility of the JS ecosystem, its not too surprising people treat this as a "war". It's unfortunate.
Facebook really screwed up by not having Windows support for the longest time, and even after they did, not having it as a first class citizen (since most statistics have FE devs to be roughly 50% on Windows). Not that they cared about adoption, but as Flow users, we did.
At my company we started out with Flow and eventually agreed to switch to TypeScript, as the former is getting to be too obscure a technology.
You can say that about any library; it has nothing to do with the popularity, support or quality of the particular dependency. If the technical decision makers choose not to use something you like then you won't get to use it.
This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
The "technical decision makers" though has very much to do with the "popularity, support or quality of the particular dependency".
If a dependency is popular then more technical decision makers at more companies will be using it, and the more choices one that likes/wants to work with it has for a job.
>This is one of the key reasons to climb your career ladder. If you climb high enough you get to be that decision maker.
Which will make the point moot, as they wont be the one coding using the technology anymore.
1) React 2) Vue 3) Angular 2+ 4) Aurelia
If your preference is 1) or 2), it shouldn't be too difficult, even though it means a complete rewrite or building in-house adapters to migrate gradually. If it's 3), even though similar adapters exist, good luck convincing anyone. If it's 4, you're basically dreaming.
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.
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.
https://trends.google.com/trends/explore?date=today%205-y&ge...
According to NPM download stats, React is 6x larger:
https://www.npmjs.com/package/react https://www.npmjs.com/package/vue
For Vue to catch up to the number of React stars would mean that their rate of starring is significantly higher.
I wonder if rate of new Github stars are a leading indicator of future popularity increases? Probably? Would be interesting if someone could study that.
Weird thing, commits to Vue are decreasing over time and are mainly done by a single individual - I've never seen that pattern in a popular library: https://github.com/vuejs/vue/graphs/contributors
While commits to React are regular and come from a much wider base of contributors: https://github.com/facebook/react/graphs/contributors
The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.
The Sistine Chapel was mainly painted by a single individual.
(for the record, Michelangelo had apprentices to help him mix plaster, etc. But he phased them out when it came to painting. Traditionally master painters had apprentices which would paint with them, but he would rather avoid the differences in opinion and arguments while painting the chapel. He had the vision and the skill. I think that’s the case here as well. Not saying Evan is Michaelangelo, but he does have a good vision with his product and the skill to execute on it.)
https://www.patreon.com/evanyou - It's his full time job, he's making over $15k a month on Vue, everyone else is just an open source contributor.
https://trends.google.com/trends/explore?date=today%205-y&ge...
or how about
https://trends.google.com/trends/explore?date=today%205-y&ge...
Maybe alexa matters?
https://www.alexa.com/siteinfo/vuejs.org
https://www.alexa.com/siteinfo/reactjs.org
Or maybe one community uses their respective primary domain more than the other for one reason or another.
React also has more than 4x as many dependent packages in npm, which could be propping up its install count.
I don't think this would do anything. If you have three packages that depend on React, you still only install it once. If anything, the number of packages that depend on React is an indication of its popularity.
The search I linked to is not a keyword search but rather extracted topics. Your criticism is just based on misunderstanding how Google trends work. Not saying it is accurate but in both of your "corrections" to my link you are getting less accurate Google Trend results.
Regardless of the fact Google trends is not even an accurate way to gauge usage of vue or react to begin with.
I am not responding to any more because it seems that people refuse to understand it.
upenn.edu (US) hateblo.jp (Japan) facebook.github.io (US) yiibai.com (China) infoq.com (China)
And to Vue:
sina.com.cn (China) csdn.net (China) wikia.com (US) cnblogs.com (China) blog.jp (Japan)
[1]: https://trends.google.com/trends/explore?date=today%205-y&q=...
That's pretty interesting actually, and presumably means a lot of people find Vue interesting, yet it's not as widely adopted as React.
> The writing is clearly on the wall (or the stars are on github), Vue is definitely going to overtake React usage in the long run unless another new library appears or React changes significantly.
I mean, that is if React usage slows down and Vue's continues to grow. I didn't draw that conclusion from the links you provided (but I didn't conclude otherwise either).
Edit: a downvote with no reply? Why the downvote? Did I say something that's wrong?
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).
https://markojs.com/
React also is overly complex because it tries to over-optimize redrawing speed through encouraging components to maintain a lot of local state using setState -- even though the increasingly popular Flux model encourages global-ish state for one-way data flow that makes the internal workings of UIs easier to reason about. Mithril is more Flux-ish out of the box in terms of the design patterns it encourages. Mithril's default behavior is based on rerendering the entire current vdom tree any time the user interacts with a DOM element or after a network request completes -- and the Mithril community only encourages optimizing beyond that if there is a specific performance issue. (You need to add your own redraw calls in callbacks for timeouts and a few other cases.)
That said, I can understand how the herd mentality shapes the employment landscape for both programmers and their managers. It does in my own work life too -- where I have spent a couple of years working in Angular for my day job despite knowing what a mess of accidental complexity it is compared to something like Mithril. Angular was chosen years ago by other developers before I joined the project -- developers who mostly did not stick around to suffer the maintenance consequences. At least new projects may be in something other than Angular -- typically React (which is at least better than Angular).
It's saddening how many times in my career I've ended up having to work with worse technology because of herd effects -- despite knowing better alternatives existed and having personal experience with them. For example, IBM chose to promote Java instead of Smalltalk in the late 1990s (despite having two Smalltalks it owned). Or Netscape ultimately foisted a Java-ish looking JavaScript on the world when Brendan Eich was originally recruited with the promise he could write a Scheme for the browser. Although, as with both Java and JavaScript, after a couple of decades, most of the worst rough edges are worn smoother and many of the worst bugs are fixed, and so the developer experience for both by now is finally not that bad.
Why have I not switched? It is useful to disentangle the value produced in Elm by using vdom (similar to Mithril) versus the value produced by Elm being a better language than JavaScript. Both are true, but which one provides more value in different contexts?
When I researched Elm in the past, I also read posts by a few people who moved away from Elm due to integration issues with the rest of the JavaScript ecosystem (as well as a miscellany of typical other issues any new language has related to bugs/tooling/libraries/platforms/etc.). Whether those criticisms of Elm by past users were fair -- or whether they still are true -- I do not know. But those issues were about the language, not about the vdom/redrawing paradigm.
It seemed to me that TypeScript was a safer bet three or four years back for me to choose for myself over other compile-to JavaScript languages because I would also be learning plain JavaScript better at the same time -- and learning plain JavaScript well seemed like a good thing to do.
These are really tough choices given moving targets for languages and libraries -- including trying to predict where communities and designs will be in a few years.
JavaScript is a badly designed language because in trying to make things "easier" for non-programmers writing a few lines of code (like making vars global by default) it made programming much more difficult for anyone doing anything more complex. Languages like Elm (or many other compile-to-JavaScript languages, even C++ now given WebAssembly) can fix those core issues in JavaScript (given no need for backward compatibility) and are appealing for that reason even as they may have their own challenges.
And as a negative, TypeScript only goes half-way there to a better language -- leaving many of JavaScript's warts in place. Just one example of such a wart is the many globals defined on "window" which make it appear a local variable might be defined when it is actually some global value being referred to (e.g. "length" or "name" are defined as globals on window as in "const x = length"; for more gotchas see: https://developer.mozilla.org/en-US/docs/Web/API/Window ).
But that said, typically issues comes up in any framework or language that involve a "leak" in the abstraction. And then you need to learn about the surrounding system to make your application work well. While things may change in a ten years, right now, to make a good Single-Page Application for the web, you need to learn the basics of HTML, CSS, and JavaScript fairly well. I don't feel there is any substitute for that. I've tried (e.g. using Dojo/Dijit) and gotten burned. One thing I like about Mithril is that, vdom aside, it keeps you close to the "metal" of HTML/CSS/JavaScript with just enough support to handle repetitive issues well while not getting in the way and being relatively easy to debug.
Decades ago when I learned BASIC, I had already learned assembly language before that, and digital electronics before that. The combination of BASIC and Peek-ing and Poke-ing assembly language was great. But just knowing BASIC would have left me pretty mystified about what was going on under the hood of the computer.
I think the same would be true for someone whose fir...
Vue and React are great but in my experience they’re virtually an overkill for most projects. I recently come across a Shopify cart integration using Vue and was sorta dumbfounded that an engineer decided to include a 50kb framework to handle a couple of Ajax requests. I ask myself why? The answer is hype. Hype can be the demise sometimes.
> 6778 lines (5726 sloc) 239 KB
awwwwww yeahhhhhhhhhhh