Has Vue passed React yet?(hasvuepassedreactyet.surge.sh)
hasvuepassedreactyet.surge.sh
Has Vue passed React yet?
https://hasvuepassedreactyet.surge.sh
169 comments
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.
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 used to hate react, but being forced to work with it for a while has helped me get used to it. I still very much prever vue so this is great news to me.
Why should anyone care how many github stars one library has compared to another?
[deleted]
Github stars are proportional to the size of the community.
You don't want to bet your company on a project with only a few thousand stars, it could die quickly.
You don't want to bet your company on a project with only a few thousand stars, it could die quickly.
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.
+1 for this - I star things to come back to and try out. I've started Vue for this reason, unlike React which I use in working hours
Yeah, same way I 'favorite' something on Twitter. I might disagree with the tweet, but I want to come back to it later to read the conversation, etc.
Second that, and just like any bookmarks – I rarely return to them afterwards )
Angular has a monumental enterprise userbase, and I wonder what percentage of those developers even have a GitHub account.
GitHub stars are a more a measure of hype than the size of the community.
GitHub stars are a more a measure of hype than the size of the community.
>Angular has a monumental enterprise userbase, and I wonder what percentage of those developers even have a GitHub account.
And much of it is still on 1.x
And much of it is still on 1.x
I agree there's a decent correlation. There are a few notable exceptions/edge cases. For example, Ruby's rake has just ~1,300 stars:
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.
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.
Vue: 238,410 weekly downloads
React: 1,596,809 weekly downloads
(from npm)
React: 1,596,809 weekly downloads
(from npm)
I wonder though, how CDN links might mess with this comparison? And whether devs are more likely to use the CDN version with Vue vs React.
[deleted]
Yeah I think this is a much more relevant metric. But also, who cares? Both are good tools.
Yeah, I'm all for the growth of vue in addition to react. Just thought it was a relevant metric to share.
combine that with number of projects with react or vue in the package.json in github.
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.
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.
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.
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.
What does heavyweight mean?
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)
(Apologies if this was rhetorical and I ruined the point you were trying to make)
Seems like a great contender for a small project then. KO in no time :).
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.
Meaning there are clearly more React jobs, and they have the support of a massive company.
Can you point me to the announcement? Hopefully you're not referring to that recent weird tweet that has been disputed by several MS employees.
You can see the older HN article here: https://news.ycombinator.com/item?id=17310738
Looks like they are moving their office suite of software to React.js.
Looks like they are moving their office suite of software to React.js.
It looks like it may only be a "thin veneer" on the top of it:
https://twitter.com/migueldeicaza/status/1007016681426898945
That's based on a nonsense message posted by a rogue employee.
https://mspoweruser.com/no-microsoft-is-not-rewriting-office...
https://mspoweruser.com/no-microsoft-is-not-rewriting-office...
Reminds me of http://isitsnowinginpdx.com/.
I'm rooting for Vue.
I'm rooting for Vue.
[deleted]
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.
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.
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.
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.
I've recommended other b2b services over Salesforce because they have such a shitty UI and it worked out nicely.
> Meanwhile we're still using ASP.Net MVC w/ a vintage 2008 web design.
I'm still maintaining a web forms program first started in 2002. I dream of MVC.
I'm still maintaining a web forms program first started in 2002. I dream of MVC.
I use React every day and haven't starred it. I star random stuff I want to come back to later (like Vue).
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...
And Laravel is pro VueJS (or at least was last time I checked)
I haven't seen VueJS specifically (yet) in my endeavor to learn everything about Laravel. Bootstrap is a common theme I'm seeing at the moment.
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.
what’s funny is, if you go on youtube to learn VueJS, you’re going to get a bunch of Laravel videos teaching you to use VueJS with Laravel
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.
Wow, it dominates that much? No Symfony?
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!"
And I just came across one post for Laravel, that also says "Should also know about...." "- SOLID principles, application architecture" face palm
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.
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.
I'm hiring specifically for Vue experience.
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.
(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.
fitted my mind's view of how things should work
Why so? Could you add some detail to this comment?
Why so? Could you add some detail to this comment?
[deleted]
Provocative and simply wrong.
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.
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.
It doesn’t have to be a war.
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.
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.
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.
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.
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.
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.
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.
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)
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)
> What's worse is that they're not entirely wrong.
If your startup dies because of your choice in javascript framework, you were doomed from the get go.
If your startup dies because of your choice in javascript framework, you were doomed from the get go.
I don’t think there’s a war. I think there’s a fanboy who was amused by this and took 5m to put a page together.
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 :).
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 wonder if it’s a nerd thing.
“Linux is better than Windows”
“Android is better than iOS”
“Python is better than PHP”
“Vim is better than everything else”
“Linux is better than Windows”
“Android is better than iOS”
“Python is better than PHP”
“Vim is better than everything else”
Once you get old enough, you realize everything is shit and nothing is better than anything else because, again, it's all shit.
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?
It's just a matter of which shit tastes better to you. =)
[deleted]
Gersploosh is clearly the superior framework.
[deleted]
You might enjoy Gary Bernhardt's talk "Wat"[1] and, well, pretty much all the other ones.
[1]: https://www.destroyallsoftware.com/talks/wat
[1]: https://www.destroyallsoftware.com/talks/wat
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.
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.
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.
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.
* 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.
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.
You’re not really reading what I write, are you?
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?
I imagine 60k saved you the cost of having to train replacements for your developers that left for companies already using Angular 2.
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.
Just because everything is shit (yes I'm grumpy too) doesn't mean it's the same level of shit: https://www.readthesequences.com/The-Fallacy-Of-Gray
Some software just sucks less.
Vim is better than everything else.
- Albert Einstein
- Albert Einstein
They are called "holy wars", the Jargon File has an entry
[deleted]
It's our version of sports teams. ("Cavs are better than 76ers!")
We pick a tribe and can be loud and obnoxious in support of them.
We pick a tribe and can be loud and obnoxious in support of them.
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?
[deleted]
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.
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.
According to Google search traffic, React is 10x popular:
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.
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.
> Weird thing, commits to Vue are decreasing over time and are mainly done by a single individual
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://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.
For better or worse this does not scale with how Facebook is supporting React
Comparisons in Google Trends are extremely easy to manipulate (or just interpret wrong). The ".js" you added to Vue is killing its results, and the generic term "react" is propping that one up.
https://trends.google.com/trends/explore?date=today%205-y&ge...
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.
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.
> 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.
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.
You typed vue.js so technically your results are less accurate. :/
Regardless of the fact Google trends is not even an accurate way to gauge usage of vue or react to begin with.
Regardless of the fact Google trends is not even an accurate way to gauge usage of vue or react to begin with.
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 am not responding to any more because it seems that people refuse to understand it.
Quite likely Google is underrating Vue, because Vue has heavy presence in China and Google does not.
Sounds like you’re upset vue is more popular than you wished.
If you look further in Alexa by country I believe it says that React's rank is higher than Vue's site, but that in China Vue is insanely hot.
> 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.
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.
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:
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=...
Country Percent of Visitors Rank in Country
China 59.1% 631
United States 8.7% 7,245
Japan 3.7% 6,109
Iran 2.8% 2,373
India 2.2% 8,422
Country Percent of Visitors Rank in Country
United States 33.3% 3,312
China 9.8% 6,694
India 8.5% 4,016
Japan 4.9% 7,585
Iran 3.6% 2,632
upenn.edu (US) hateblo.jp (Japan) facebook.github.io (US) yiibai.com (China) infoq.com (China)
And to Vue:
sina.com.cn (China) csdn.net (China) wikia.com (US) cnblogs.com (China) blog.jp (Japan)
[1]: https://trends.google.com/trends/explore?date=today%205-y&q=...
My experience with Alexa incoming links is really inaccurate. The numbers are fairly decent for popularity though.
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?
> 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.)
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.)
Exactly, the dude has a background in arts and design. Something that I truly believe helped shaped vue.js to what it is.
[deleted]
> 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?
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).
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).
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 wish Ebay's Marko got any mindshare. It'd be nice if our choices weren't limited to React and Vue.
https://markojs.com/
https://markojs.com/
That link is blocked in China.
22...17...15.. It's about to happen.
It's happening!
People are actually un-starring react.
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.
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.
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.
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.
On so many levels, your statements speaks my personal truths and experiences. Thank you.
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 first browser-based language was Elm or Java/GWT and not JavaScript. After learning the basics of HTML/CSS/JavaScript (the assembly language of the web), then sure, learning and using other languages like TypeScript or Elm can potentially help a lot -- though with tradeoffs (like Elm integration issues mentioned above).
For simpler things, I find just plain ES6/ES7 with Mithril actually works fairly well given JavaScript has improved a lot with ES6 and ES7 (especially with "let", "const", and "async/await").
For Elm and me personally, it is undoubtedly better to use than JavaScript/TypeScript in-and-of-itself, but having gone up the learning curve on those, whether it would be worth a switch at this point, I don't know. It clearly is "better" as a language -- but I am not convinced it is so much better as to make up for other possible downsides. There are a lot of great languages out there.
Personally, I am tempted by Elixir as a next language to learn (given Erlang's fundamental design beauty). But I feel productive enough in TypeScript and ES6/ES7 at this point (years into the learning curve on "the good parts") that I don't feel an urgent need to do that. Likewise for Clojure/ClojureScript which many developers also love and is also tempting. Or even Scala which can compile to JavaScript.
Anyway, for all my complaints about herd effect, I am sorry to bring up those sorts of issues as negatives for Elm given how entrenched plain JavaScript is right now. One of the problems with making choices like these is that people rarely switch languages because the alternative is 1.1X or even 2.0X better for some task overall. They tend to switch when something is 10X better. And that is a high bar -- especially if you compare Elm against TypeScript+Mithril+Tachyons and not ES5+AngularJS.
Why have I not switched? It is useful to disentangle the value produced in Elm by using vdom (similar to Mithril) versus the value produced by Elm being a better language than JavaScript. Both are true, but which one provides more value in different contexts?
When I researched Elm in the past, I also read posts by a few people who moved away from Elm due to integration issues with the rest of the JavaScript ecosystem (as well as a miscellany of typical other issues any new language has related to bugs/tooling/libraries/platforms/etc.). Whether those criticisms of Elm by past users were fair -- or whether they still are true -- I do not know. But those issues were about the language, not about the vdom/redrawing paradigm.
It seemed to me that TypeScript was a safer bet three or four years back for me to choose for myself over other compile-to JavaScript languages because I would also be learning plain JavaScript better at the same time -- and learning plain JavaScript well seemed like a good thing to do.
These are really tough choices given moving targets for languages and libraries -- including trying to predict where communities and designs will be in a few years.
JavaScript is a badly designed language because in trying to make things "easier" for non-programmers writing a few lines of code (like making vars global by default) it made programming much more difficult for anyone doing anything more complex. Languages like Elm (or many other compile-to-JavaScript languages, even C++ now given WebAssembly) can fix those core issues in JavaScript (given no need for backward compatibility) and are appealing for that reason even as they may have their own challenges.
And as a negative, TypeScript only goes half-way there to a better language -- leaving many of JavaScript's warts in place. Just one example of such a wart is the many globals defined on "window" which make it appear a local variable might be defined when it is actually some global value being referred to (e.g. "length" or "name" are defined as globals on window as in "const x = length"; for more gotchas see: https://developer.mozilla.org/en-US/docs/Web/API/Window ).
But that said, typically issues comes up in any framework or language that involve a "leak" in the abstraction. And then you need to learn about the surrounding system to make your application work well. While things may change in a ten years, right now, to make a good Single-Page Application for the web, you need to learn the basics of HTML, CSS, and JavaScript fairly well. I don't feel there is any substitute for that. I've tried (e.g. using Dojo/Dijit) and gotten burned. One thing I like about Mithril is that, vdom aside, it keeps you close to the "metal" of HTML/CSS/JavaScript with just enough support to handle repetitive issues well while not getting in the way and being relatively easy to debug.
Decades ago when I learned BASIC, I had already learned assembly language before that, and digital electronics before that. The combination of BASIC and Peek-ing and Poke-ing assembly language was great. But just knowing BASIC would have left me pretty mystified about what was going on under the hood of the computer.
I think the same would be true for someone whose first browser-based language was Elm or Java/GWT and not JavaScript. After learning the basics of HTML/CSS/JavaScript (the assembly language of the web), then sure, learning and using other languages like TypeScript or Elm can potentially help a lot -- though with tradeoffs (like Elm integration issues mentioned above).
For simpler things, I find just plain ES6/ES7 with Mithril actually works fairly well given JavaScript has improved a lot with ES6 and ES7 (especially with "let", "const", and "async/await").
For Elm and me personally, it is undoubtedly better to use than JavaScript/TypeScript in-and-of-itself, but having gone up the learning curve on those, whether it would be worth a switch at this point, I don't know. It clearly is "better" as a language -- but I am not convinced it is so much better as to make up for other possible downsides. There are a lot of great languages out there.
Personally, I am tempted by Elixir as a next language to learn (given Erlang's fundamental design beauty). But I feel productive enough in TypeScript and ES6/ES7 at this point (years into the learning curve on "the good parts") that I don't feel an urgent need to do that. Likewise for Clojure/ClojureScript which many developers also love and is also tempting. Or even Scala which can compile to JavaScript.
Anyway, for all my complaints about herd effect, I am sorry to bring up those sorts of issues as negatives for Elm given how entrenched plain JavaScript is right now. One of the problems with making choices like these is that people rarely switch languages because the alternative is 1.1X or even 2.0X better for some task overall. They tend to switch when something is 10X better. And that is a high bar -- especially if you compare Elm against TypeScript+Mithril+Tachyons and not ES5+AngularJS.
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.
Competitive angle aside, Vue deserves all the stars it gets.
It's a pleasure to work with and a much needed tool in the frontend landscape. The more mindshare it gets the better for everyone.
I'll keep on rooting for it!
It's a pleasure to work with and a much needed tool in the frontend landscape. The more mindshare it gets the better for everyone.
I'll keep on rooting for it!
Maybe people could just stick with one frigging thing for more than 12 months? I'm sick to death of Javascript churn. Polish one thing up until it is actually done before chasing some shiny new half-baked thing like a cat with a laser pointer. A slightly different spin on MVC concepts from twenty or thirty years ago doesn't get me out of bed, much less rewriting my front-end code more often than I file my taxes.
Job security
Progress
Does this mean Nativescript will be on the rise?
Both are outdated. Cycle.js is the new framework. :)
I just starred it, and moved it across the finish line! I actually do like Vue.js more than react, so it wasn't just for the fame!
I just starred Vue to make it even with React at 98,564
I'm always baffled by web developers constantly moving to new frameworks and toolchains. I can't really think of other sectors of development that chase as many fads. I mean its one thing if it solves a significantly new problem, but a lot of times it comes down to like "so and so likes gulp better than grunt or sass better than less and they're going to stall the project for two weeks while they switch the codebase over while pretending they're fixing tech debt". In game development, where developers are frequently on the cutting edge of things, the idea of switching engines and apis all the time for marginal benefits would get you a lot of raised eyebrows, and im guessing desktop app developers and people into scientific computing feel likewise. Don't get me wrong things evolve, but code in those fields doesn't seem to be treated as disposably.
> I'm always baffled by web developers constantly moving to new frameworks and toolchains
I'm baffled why anyone thinks anything like this is actually true. So everytime you see a JavaScript or CSS library or framework posted to HN, you think all JavaScript developers switched to it? Game development has well over 1000 engines to choose from. I don't assume you switched from unity to Godot when it showed up on HN.
I'm baffled why anyone thinks anything like this is actually true. So everytime you see a JavaScript or CSS library or framework posted to HN, you think all JavaScript developers switched to it? Game development has well over 1000 engines to choose from. I don't assume you switched from unity to Godot when it showed up on HN.
Resume Driven Development. No one wants to be left behind because it would hurt your chances of getting a new job.
As a business owner I'd be VERY interested in something (fad or not) that cuts development time and complexity by a substantial amount. As a developer I want to use things that make my life vastly easier and lets me focus on the product rather than the programming.
Trying new things and taking risks can yield huge rewards! Of course it can fail spectacularly as well but for those that worry about that a lot, jQuery UI still exists!
Trying new things and taking risks can yield huge rewards! Of course it can fail spectacularly as well but for those that worry about that a lot, jQuery UI still exists!
On the one hand, "web developers constantly moving to new frameworks" sounds like a myth. I'd suggest "periodically" instead. I've been a web developer for 20 years, and the first 19 of those years were miserable. It's just an immature field with lousy tools.
I counter that perhaps it feels like people are switching all the because there are more people and projects in web development than games or scientific development. Most all games have websites, whereas, few websites have games.
It does in the web world, too, but you don’t hear about it as much because nobody writes self-promotional posts about how they decided not to switch because it wasn’t worth it.
I use Vue at work every day. We build large applications in it and it's extremely pleasant to use.
That said, I wouldn't use a number of stars in Github as more than an indicator of people pushing a star button in Github.
I've starred many things so that I can remember them some day. If I use something every day it's most certainly not starred.
That said, I wouldn't use a number of stars in Github as more than an indicator of people pushing a star button in Github.
I've starred many things so that I can remember them some day. If I use something every day it's most certainly not starred.
Woot! Go Vue.
I love Vue!
People say that "you only have to learn a few things to know react" and that with Vue you need to learn this whole API and well that is just too much to learn! These people are of course just trying to find an argument to match their emotional investment in a product. It isn't a real argument and can be refuted with logic and maths.
I started a node/express/vue project about 6 months ago. Here are the APIs and syntaxes and so on I had to learn:
Mongoose API
MongoDb API
Express API
HTML5 Validation and Validity API
Fetch API
Bootstrap 4 API
Flexbox
some new javascript concepts like destructuring
Webpack/source maps/hot modules
Node
The differences between importing/exporting modules in node and the browser
Oh yeah, and the Vue API. You know what percentage of learning the Vue API was? About 0.01%. What is even more ridiculous is that it wasn't even the learning of the API that took the most time.
All of the concepts in Vue/React take more time to learn than the API of Vue. The differences between data and props, what reactivity is, how single page routing works, how components work, and so on. In fact, as React is so barebones, it probably requires more learning than Vue because you have to find all the other libraries to make it the full product.
I started a node/express/vue project about 6 months ago. Here are the APIs and syntaxes and so on I had to learn:
Mongoose API
MongoDb API
Express API
HTML5 Validation and Validity API
Fetch API
Bootstrap 4 API
Flexbox
some new javascript concepts like destructuring
Webpack/source maps/hot modules
Node
The differences between importing/exporting modules in node and the browser
Oh yeah, and the Vue API. You know what percentage of learning the Vue API was? About 0.01%. What is even more ridiculous is that it wasn't even the learning of the API that took the most time.
All of the concepts in Vue/React take more time to learn than the API of Vue. The differences between data and props, what reactivity is, how single page routing works, how components work, and so on. In fact, as React is so barebones, it probably requires more learning than Vue because you have to find all the other libraries to make it the full product.
vue makes coding so much more enjoyable than reqct for me that im glad to see it get more traction
Github stars are a rather meaningless proxy. Many people like have all the major libraries starred but actual usage is quite different.
Vue is great, but React has about 10x more libraries, frameworks, components and just general "stuff" built around it, along with the mindshare that it brings.
Vue is great, but React has about 10x more libraries, frameworks, components and just general "stuff" built around it, along with the mindshare that it brings.
Question for Vue users: whats the value prop over React?
I haven't had a chance to look at Vue in depth but it seems to me that its useful for building apps where you don't need a build tool which makes sense to me.
The main thing I don't get is why use Vue over React if you're going to use single file components with some kind of build tool?
I haven't had a chance to look at Vue in depth but it seems to me that its useful for building apps where you don't need a build tool which makes sense to me.
The main thing I don't get is why use Vue over React if you're going to use single file components with some kind of build tool?
> Question for Vue users: whats the value prop over React?
I'll paste my comment from another post in this thread:
>> I hear a lot that "Vue is easy to learn"...
> That's why I started working with Vue. It seemed easier to approach for someone coming from a server-side language perspective (I'd mostly worked with Python/Flask and PHP/Symfony before). I could slowly ease into using pieces of it until I learned enough to write a whole project in Vue. You can probably do the same thing in React, but the Vue docs were written to address my use case.
I'll paste my comment from another post in this thread:
>> I hear a lot that "Vue is easy to learn"...
> That's why I started working with Vue. It seemed easier to approach for someone coming from a server-side language perspective (I'd mostly worked with Python/Flask and PHP/Symfony before). I could slowly ease into using pieces of it until I learned enough to write a whole project in Vue. You can probably do the same thing in React, but the Vue docs were written to address my use case.
To me it comes down to if you like the style of using a template language for the render or not.
Someone will inevitably say you can use JSX in Vue but if you do that I don’t see the point in picking Vue.
Someone will inevitably say you can use JSX in Vue but if you do that I don’t see the point in picking Vue.
Because vue is Chinese and China has huge population of developers! lol Haha
hehe, my star passed it.
I just starred Vue to give it 100,000 stars.
I'm feeling irrationally happy about that.
I'm feeling irrationally happy about that.
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.