Will Vue.js become a giant like Angular or React?(10clouds.com)
10clouds.com
Will Vue.js become a giant like Angular or React?
https://10clouds.com/blog/vuejs-angular-react/
141 comments
Vue.js is a step backwards, relative to React, in my opinion. What I love about React is JSX (or TSX if using TypeScript). JSX is a combination of JavaScript and HTML syntaxes. You don't need to learn a new syntax in order to incorporate loops and conditionals in the view layer, thanks to JSX: you just use JavaScript. More importantly, you get compile-time verification. If you use a JavaScript variable in JSX and someone deletes that variable you find out about this issue at compile time. This is very important for large projects that multiple developers are working on together. Angular and View.js don't have this capability and that's a very serious shortcoming for large projects.
I love React but you're completely wrong here. Vue has JSX support as well https://github.com/vuejs/babel-plugin-transform-vue-jsx. JSX isn't a React thing anymore. Most Virtual DOM solutions offer JSX.
Styling React components is a huge pain. What I like about Vue is the awesome styles, HTML and js in one file for each component. With React projects I have a completely seperate styles folder.
Styling React components is a huge pain. What I like about Vue is the awesome styles, HTML and js in one file for each component. With React projects I have a completely seperate styles folder.
He's definitely not wrong. Vue.js supports and promotes templates (e.g. right on the very "get started" page the homepage links to:
https://vuejs.org/v2/guide/#Conditionals-and-Loops) with yet another NIH looping and conditional syntax. Perhaps it's possible to avoid - but that kind of flexibility simply encourages messy codebases.
JSX is not a requirement for React. React has the same kind of flexibility you are criticizing.
https://facebook.github.io/react/docs/react-without-jsx.html
https://facebook.github.io/react/docs/react-without-jsx.html
That's not at all the same, for (at least) 2 reasons.
- Defaults matter; templates as defaults means most examples, support, tools, extensions, etc. will assume templating.
- React without JSX doesn't actually affect the code structure or flow. Looping, conditionals, composition etc. all stay the same; and that shouldn't be surprising since JSX is essentially no more than a slightly different syntax for nested method calls and object literals; which is quite unlike templates in vue; those have actual semantics too.
I've used react without jsx before (some time ago for a coffeescript based project), and it affects little. If you do that, you'll want to introduce some alternative shorthand to avoid all those repetitive "React.createElement" calls, but doing so is trivial - after all, it's just method calls and object literals.
I'm not a huge fan of custom languages like JSX in general, and indeed JSX too (I believe) was a mistake. However, with sufficient support and a small enough target to support, it's less of an issue. Still, even extremely well funded projects like razor are clearly much less well supported by tooling than the language they're based on, even many years later. Vue's templates? Completely hopeless.
- Defaults matter; templates as defaults means most examples, support, tools, extensions, etc. will assume templating.
- React without JSX doesn't actually affect the code structure or flow. Looping, conditionals, composition etc. all stay the same; and that shouldn't be surprising since JSX is essentially no more than a slightly different syntax for nested method calls and object literals; which is quite unlike templates in vue; those have actual semantics too.
I've used react without jsx before (some time ago for a coffeescript based project), and it affects little. If you do that, you'll want to introduce some alternative shorthand to avoid all those repetitive "React.createElement" calls, but doing so is trivial - after all, it's just method calls and object literals.
I'm not a huge fan of custom languages like JSX in general, and indeed JSX too (I believe) was a mistake. However, with sufficient support and a small enough target to support, it's less of an issue. Still, even extremely well funded projects like razor are clearly much less well supported by tooling than the language they're based on, even many years later. Vue's templates? Completely hopeless.
Not a requirement per se, sure, but it's strongly suggested and other usages are not idiomatic.
That is simply skipping the transpiling of JSX, the structure/nesting is the exact same, not some DSL crafted for templating.
React without JSX is very clunky at best.
The documentation for view.js seems to highlight a custom syntax that cannot be verified at compile-time:
https://vuejs.org/v2/guide/#Conditionals-and-Loops
If you are interested in HTML, JavaScript and Styles in one component you really want Web Components. React and view.js support components but they are brittle. W3 Web Components (implemented by Chrome and Safari) solve this problem. More on that here: https://github.com/wisercoder/uibuilder
If you are interested in HTML, JavaScript and Styles in one component you really want Web Components. React and view.js support components but they are brittle. W3 Web Components (implemented by Chrome and Safari) solve this problem. More on that here: https://github.com/wisercoder/uibuilder
Vue templates are verified at compile time (don't know where you got that from), and static analysis is planned for the future (which isn't directly possible with JSX): https://medium.com/@youyuxi/pretty-good-comparison-overall-b...
There are two distributions of Vue, one in which templates are precompiled (this is the default and recommended build), and one bundling the runtime template compiler. You are most likely thinking of the latter.
There are two distributions of Vue, one in which templates are precompiled (this is the default and recommended build), and one bundling the runtime template compiler. You are most likely thinking of the latter.
[deleted]
Styled components solves this problem very nicely
https://github.com/styled-components/styled-components
https://github.com/styled-components/styled-components
It's hard to take anyone seriously who doesn't even spell the name of the thing they're opining on correctly. I'd venture to say you've never used Vue in a meaningful way so probably aren't qualified to make a comparison.
> More importantly, you get compile-time verification. If you use a JavaScript variable in JSX and someone deletes that variable you find out about this issue at compile time. This is very important for large projects that multiple developers are working on together.
I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.
I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.
Vue templates are checked at compile time with the default runtime-only distribution, and the DSL it uses is arguably more checkable than JSX.
Sure, I'm just saying I don't understand how people that like dynamic typing can't see the productivity value in being told e.g. a variable isn't defined or a function call is missing arguments at compile time.
You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years.
What? You thought dynamic languages were a new fad? They have existed as long as computer science has, exactly like static languages.
For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
What? You thought dynamic languages were a new fad? They have existed as long as computer science has, exactly like static languages.
For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
> You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years.
I've worked a lot with static and dynamic types, read a lot about both and in my opinion static typing has clear and obvious advantages.
> For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
Why is being a "good coder" a factor? Everyone makes mistakes and teams will always consist of a mixture of skill levels. On large code bases especially, getting compile time errors on basic problems like referring to non-existent variables and calling functions with wrongly type arguments is undeniable time saving in my opinion. Types also enable better refactoring automation and autocomplete. All of these are great for small projects and even better for big projects with lots of team members.
What advantages does dynamic typing have that could outweigh those factors?
I've worked a lot with static and dynamic types, read a lot about both and in my opinion static typing has clear and obvious advantages.
> For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
Why is being a "good coder" a factor? Everyone makes mistakes and teams will always consist of a mixture of skill levels. On large code bases especially, getting compile time errors on basic problems like referring to non-existent variables and calling functions with wrongly type arguments is undeniable time saving in my opinion. Types also enable better refactoring automation and autocomplete. All of these are great for small projects and even better for big projects with lots of team members.
What advantages does dynamic typing have that could outweigh those factors?
... What was the point of this reply? It doesn't change or refute anything I said before. All this has been discussed millions of times, why would I engage in a discussion that has been happening for sixty years?
You can read on advantages of dynamic languages everywhere, I was just pointing out that your point of view, and the point of view disagreeing with you, isn't anything close to new, making the attempt to start a flamewar in your first post, and trying to continue it here, all the more pointless.
BTW: Good coders are factor because no amount of "you have to write 'string' or 'int' before the name of the variable" is going to save a bad coder from producing bad code.
You can read on advantages of dynamic languages everywhere, I was just pointing out that your point of view, and the point of view disagreeing with you, isn't anything close to new, making the attempt to start a flamewar in your first post, and trying to continue it here, all the more pointless.
BTW: Good coders are factor because no amount of "you have to write 'string' or 'int' before the name of the variable" is going to save a bad coder from producing bad code.
How you write the elements really isn't a very important aspect of an application. It's just convenience.
Jade/Pug templates (been around for years, and are the ExpressJS default) also offer the same feature of being just "a combination of JavaScript and HTML elements". I haven't been convinced yet that JSX is better, because I can do all the same things in Pug (client or server-side rendering, compile to Hyperscript, compile to Javascript) yet with cleaner syntax.
[deleted]
Funny to read this--talk about the benefits of strong-typing, etc. The dynamic nature of JS was once a benefit. Granted, it wasn't initially purposed for full-out browser facing SPAs, etc.
Still, strong-typing has been with us forever and, in general, I feel like we've solved this problem. I'd like to see a light-weight VM framework that supports Java code compiled down to JS, with an in-browser Swing-like component framework (no, not applets). But a lot of the tenents of async, event-driven Swing style dev (including using workers to keep i/o off the event thread), actually overlay nicely with the challenges that modern JS frameworks are attempting to solve.
I know there's not a lot of Java-love around here, but, pick any language that has modeled out this problem and has a cadre of seasoned developers. Then, rather than re-invent the wheel, just port that to the browser.
Still, strong-typing has been with us forever and, in general, I feel like we've solved this problem. I'd like to see a light-weight VM framework that supports Java code compiled down to JS, with an in-browser Swing-like component framework (no, not applets). But a lot of the tenents of async, event-driven Swing style dev (including using workers to keep i/o off the event thread), actually overlay nicely with the challenges that modern JS frameworks are attempting to solve.
I know there's not a lot of Java-love around here, but, pick any language that has modeled out this problem and has a cadre of seasoned developers. Then, rather than re-invent the wheel, just port that to the browser.
It's funny: I'm not even a web developer by trade, and perhaps precisely because of that fact, every other day at least I have a conversation with a colleague that goes something like, "Wouldn't it be great if there were Swing for browsers?" The idea of pre-styled and easily laid-out widgets holds a great deal of appeal. Vue and Bootstrap come close to giving me that, but not quite.
Yeah, Swing is actually fun to write. Possibly because its paradigm is elegant and such a natural fit for the problem that you don't spend time fighting to fit a square peg in a round hole.
Shame it came with such an unwieldy deployment model that it never gained more traction.
Shame it came with such an unwieldy deployment model that it never gained more traction.
For me personally, the biggest selling point is not having to evolve the skill set of design and layout. I'm a developer, not a designer, and the ROI on me learning the fine points of CSS is very low. I already know the bottom 80% of CSS, but who doesn't? It's the top 20% where the "magic" happens, as with so many things.
Pre-styled, if unremarkable componentry is what I need to deliver business outcomes. Bootstrap is made for people like me, but something like Swing would make it even easier.
Pre-styled, if unremarkable componentry is what I need to deliver business outcomes. Bootstrap is made for people like me, but something like Swing would make it even easier.
Yeah, that's true. Devs spend too much time pixel-wrangling in the minutae of CSS.
But, for me, it's not just the styling, but the architecture and componentry for modeling out async, event-driven web apps in a more natural way. And, I think that's the piece you're referencing that Swing can add to Bootstrap-alone.
But, for me, it's not just the styling, but the architecture and componentry for modeling out async, event-driven web apps in a more natural way. And, I think that's the piece you're referencing that Swing can add to Bootstrap-alone.
I would agree that the deep inheritance hierarchies in verbose OO environments like Java actually do make sense for UI work. I think that's the one area in which they actually do make sense. Otherwise, it's all mostly a fantastical contrivance that leads to far too much boilerplate.
Checkout Element [0], in my opinion it comes very near to a "Swing for browsers". There is a version for Vue.js and React.
[0] http://element.eleme.io/#/en-US
[0] http://element.eleme.io/#/en-US
You can sort of do this with Emscripten + webasm, though I don't think async is supported yet.
Check Vaadin. Might suit your taste.
Just took a glance. Great tip. Looks promising. Thanks!
FWIW, Angular templates are also checked at compile time. (But you're not wrong about the advantages of JSX -- as you observe Angular has its own syntax for looping etc.)
Vue does have JSX backend, so your argument is not really valid
After being burned really badly by Ember and Meteor, I'm probably never going to use tools that are all-in-ones ever again.
With React I get something laser-focused, just does 1 thing well and that's it. With Vue, I have to buy into the entire ecosystem.
I don't want to experience what I did with ember and meteor ever again in my professional life. I think about all the great developers I've worked with and I looked up to, and almost all of them hated all-in-ones. I rolled my eyes when I was younger, but today it's like damn these guys had a point!
With React I get something laser-focused, just does 1 thing well and that's it. With Vue, I have to buy into the entire ecosystem.
I don't want to experience what I did with ember and meteor ever again in my professional life. I think about all the great developers I've worked with and I looked up to, and almost all of them hated all-in-ones. I rolled my eyes when I was younger, but today it's like damn these guys had a point!
I really don't think Vue is an all-in-one. It handles the UI side and the binding and rendering, but is otherwise the least opinionated of any framework I've seen with regard to how you structure and write the rest of your JS. It's much more like the Backbone and Underscore days, except even less opinionated and boilerplate-heavy.
Vue is the antithesis of Angular 1 in that sense. No stupid ontology of inane design patterns - no services, no providers, no factories, none of that mandatory crapola.
Vue is the antithesis of Angular 1 in that sense. No stupid ontology of inane design patterns - no services, no providers, no factories, none of that mandatory crapola.
Vue isn't even close to all in one, and in fact markets itself as the "progressive framework for building user interfaces":
"Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects."
"Unlike other monolithic frameworks, Vue is designed from the ground up to be incrementally adoptable. The core library is focused on the view layer only, and is very easy to pick up and integrate with other libraries or existing projects."
I agree with the general notion, but I fail to see how one would consider Vue an all-in-one, its feature scope and actual size in KB are much closer to small, view focused frameworks such as React.
Out of curiosity, how did Ember and Meteor burn you so hard and why are you so averse to "all-in-one" tools as a result?
A typical all-in-one framework is Ruby on Rails. It is great to quickly start a project that does basic things planned for by the framework.
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.
What drives me insane about Angular, both 1.x and 2.x, is the sheer amount of idiosyncratic boilerplate required to merely get started and do things the "framework way". It's unreal, though of course Angular 2.x takes that to a whole new level. AngularJS could at least be written in vim without boilerplate generators and meta-meta-meta tooling.
I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...
In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.
I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...
In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.
So ... actual developers are people who don't work on teams for large scale applications? Because what you call "childproofing" is basically the most obvious tenets of a shared codebase.
Sure, but there's a subtle difference between having to adhere to shared internal conventions and structure vs. having to adopt some overly complicated and constricting external framework's contrived conventions so that (in theory) a few people don't drive the bus off the cliff as often.
While react is perfectly capable of being mixed freely with vanilla js, you'll likely find that once you start down the react path and build up a library of components, it starts to make sense to do your project 100% in react.
that's not what they mean - they're talking about how ember/meteor etc prescribe how to do everything in the application, like routing, etc - with react you have your pick of routing libraries or can roll your own
> With Vue, I have to buy into the entire ecosystem.
Vue is really just a component framework that deals with the view, it doesn't do Ajax, it doesn't even do routing and don't force a backend or a database like Meteor.
Vue is really just a component framework that deals with the view, it doesn't do Ajax, it doesn't even do routing and don't force a backend or a database like Meteor.
This is the philosophy behind why I went with Knockout years ago - and am now helping maintain and write version 4.
Specific, narrow focus and it's served me well. Sensing the innate liability, I've never felt the allure of the full fledged framework.
Specific, narrow focus and it's served me well. Sensing the innate liability, I've never felt the allure of the full fledged framework.
I understand where you're coming from. However, Vue isn't an "all-in-one" or "batteries included" library. Vue is just a view layer. It fills the same layer of the stack that React does.
+1, Ember especially. Never encountered a framework with so many foot-guns and poorly documented conventions for avoiding said foot-guns.
Maybe polymer and web components are the way to go, at least that is what I'm trying to use these days.
You can very easily use React + Meteor though.
I think there's merit on staying small-ish. Not every framework has to be a giant that dominates the industry.
Having a small community means the potential for focus and strong canonical learning resources, as opposed to the mess of poorly written React and Angular posts/"guides" we get every week. The community feels tighter and it may be easier for the maintainer(s) to manage it and the codebase.
Ember is a good example. Ember's community isn't small (sold out conferences every year), but it's not in the spotlight like React or Angular are. That doesn't mean the framework is doing poorly. If anything, their community and meetups are "better" than React's (for my definitions of a good community/meetup).
Having a small community means the potential for focus and strong canonical learning resources, as opposed to the mess of poorly written React and Angular posts/"guides" we get every week. The community feels tighter and it may be easier for the maintainer(s) to manage it and the codebase.
Ember is a good example. Ember's community isn't small (sold out conferences every year), but it's not in the spotlight like React or Angular are. That doesn't mean the framework is doing poorly. If anything, their community and meetups are "better" than React's (for my definitions of a good community/meetup).
As the author of the article, I would agree with you on that. Still, I would love to see it grow to some extent to allow Vue developers to find jobs more easily and CTO's to see its value, while still managing to hold a good community and not messing the framework up.
You may be right about the quality of meetups, but meetup quality is a pretty unusual metric for a JS framework's success.
True. At work we use React for the practical reasons explained by others in the comments.
My point was that Vue doesn't need to be huge. It's fine the way it is and its current size has some benefits.
My point was that Vue doesn't need to be huge. It's fine the way it is and its current size has some benefits.
Having used all three, it feels like Vue.js will grow to occupy the role that React occupies today. That, or React will (smartly) take on some of Vue's core features like single component files with actual HTML, CSS, and JavaScript in them. Vue is far easier to start with yet feels more powerful too. Angular 2+ is a separate animal for larger teams, so will probably remain for that use case.
React components can have markup, styles and logic in one file. Seems like the only thing Vue brings to the table in this respect is yet another templating pseudolang.
it always amazes me how one person project such as vuejs and laravel can compete against with the frameworks made by giants such as google and facebook. yes there are more developers involved in vuejs and laravel now but the two main authors are still the king to rule these two extremely popular projects, truly amazing.
>it always amazes me how one person project such as vuejs and laravel can compete against with the frameworks made by giants such as google and facebook
Well, by "created by giants" in this instance think more of "a small team in Google/Facebook web-devs went ahead and did it, and then it caught on in the company and Google/Facebook decided to give them some more resources".
It's not the kind of "created by a large company" that something like Java or C# etc have, where there were tons of millions spend, huge 100+ person developer teams, documentation writing teams, etc and tons of paid marketing to promote the effort. That, only huge communities can compete against.
Here's from Quora about React for example:
"React was created by Jordan Walke, a software engineer at Facebook. Jordan deserves all the credit for creating React. He was influenced by XHP, a PHP-based component system that is still in use at Facebook, but also by functional programming ideas. Pete Hunt wanted to use React at Instagram, so he helped to extract React from Facebook-specific code. This prepared React to be open sourced. Later, Facebook put a team of engineers behind React and also received great contributions from the open source community. Significant contributors include Sebastian Markbåge and Ben Alpert, among many others."
So basically a one-man show for the beginning -- and similar story I've heard for Angular.
Well, by "created by giants" in this instance think more of "a small team in Google/Facebook web-devs went ahead and did it, and then it caught on in the company and Google/Facebook decided to give them some more resources".
It's not the kind of "created by a large company" that something like Java or C# etc have, where there were tons of millions spend, huge 100+ person developer teams, documentation writing teams, etc and tons of paid marketing to promote the effort. That, only huge communities can compete against.
Here's from Quora about React for example:
"React was created by Jordan Walke, a software engineer at Facebook. Jordan deserves all the credit for creating React. He was influenced by XHP, a PHP-based component system that is still in use at Facebook, but also by functional programming ideas. Pete Hunt wanted to use React at Instagram, so he helped to extract React from Facebook-specific code. This prepared React to be open sourced. Later, Facebook put a team of engineers behind React and also received great contributions from the open source community. Significant contributors include Sebastian Markbåge and Ben Alpert, among many others."
So basically a one-man show for the beginning -- and similar story I've heard for Angular.
That's also why taking on Vue is a huge risk. The project has a high bus factor. If the main author burnt out and quit, the project is dead.
Vue is used by huge Chinese companies, and tons of Chinese startups. It's also adopted by Laravel, which is very popular in PHP land. It's not going anywhere soon.
That is the word on the street, but I have yet to see publicly visible evidence of it. You can inspect Facebook to see React is there. You can inspect Walmart to see React is there. You can inspect LinkedIn to find Ember there. I have yet to see flagship product of huge companies built on Angular or Vue. Is Alibaba.com built with Vue?
Most of Office 365 and Azure from the web side is Angular. That's a pretty good endorsement.
It definitely is not because not only are there other contributors but Alibaba and Monterail have also made meaningful contributions (the former also developing an analog to React-Native but with Vue).
Meaningful contribution in what way? This is Vue's contribution graph sorted by addition: https://github.com/vuejs/vue/graphs/contributors?from=2016-0...
The #2 person contributes only about 1% compared to the #1 person.
Compare to React's same graph: https://github.com/facebook/react/graphs/contributors?from=2...
The #2 person is at about 50% of the #1 person.
Compare to Ember's same graph: https://github.com/emberjs/ember.js/graphs/contributors?from...
The #2 person is at 75% of the #1 person.
The #2 person contributes only about 1% compared to the #1 person.
Compare to React's same graph: https://github.com/facebook/react/graphs/contributors?from=2...
The #2 person is at about 50% of the #1 person.
Compare to Ember's same graph: https://github.com/emberjs/ember.js/graphs/contributors?from...
The #2 person is at 75% of the #1 person.
Looks like the correct statement is that Alibaba mostly contributed to Weex: https://github.com/apache/incubator-weex/graphs/contributors.
how can I check who downvoted me? why downvote here?
It's a bit disingenuous to say that Facebook uses Vue for Newsfeed. It's on a marketing site, not on a performance and business critical part of the site.
These marketing sites are very often built by contractors, not FB engineers, and tend to be one off efforts.
Not to knock Vue, but it weakens the message when deliberately misleading info like this is used
These marketing sites are very often built by contractors, not FB engineers, and tend to be one off efforts.
Not to knock Vue, but it weakens the message when deliberately misleading info like this is used
>It's a bit disingenuous to say that Facebook uses Vue for Newsfeed. It's on a marketing site, not on a performance and business critical part of the site.
It's still a Facebook owned site, and a public facing one at that.
Even if they just bought if as is ready from some third party, it shows Vue is mature enough to be accepted for such a use.
It's still a Facebook owned site, and a public facing one at that.
Even if they just bought if as is ready from some third party, it shows Vue is mature enough to be accepted for such a use.
I've seen the word "disingenuous" used many, many ways over the internet. People keep using this word, I don't think it means what most people think it means.
Because it doesn't: "not candid or sincere, typically by pretending that one knows less about something than one really does."
There's nothing insincere about saying that newsfeed.fb.com uses vue because it does. It isn't pretending to know less, if it were false, it'd be pretending to know more.
Disingenuous doesn't mean "I don't like that this person said x", or "I like y, so I don't like that this person said a good thing, even if true, about x."
It's becoming a pet peeve.
Because it doesn't: "not candid or sincere, typically by pretending that one knows less about something than one really does."
There's nothing insincere about saying that newsfeed.fb.com uses vue because it does. It isn't pretending to know less, if it were false, it'd be pretending to know more.
Disingenuous doesn't mean "I don't like that this person said x", or "I like y, so I don't like that this person said a good thing, even if true, about x."
It's becoming a pet peeve.
Consider me schooled, thanks :-)
I'm going to go out on a limb here and say "Never attribute to malice what can easily be attributed to ignorance". I have a feeling the author did not intend to mislead their readers. I feel that it is more likely that they didn't look too deeply into the subject. It's fairly simple to attribute some piece of work to Facebook when Facebook's branding is plastered all over it.
Fair comment. However it's fairly clear that there's a difference between a complex web application which pushes a library to its limits, and a page describing that application. The author must have known this and thought it'd be funny to be able to say that Facebook uses Vue in their flagship product. They really didn't need this to sell their point and should have just left it out. While it makes a humorous point, it calls into question the veracity of the other statements which otherwise could stand on their own
Good point. I've been asked several times in Medium comment threads to write a non-biased comparison between React and vue. Since it seems like it's so difficult to find an article like this one without bias, I may just write it. I'll also ensure that I research any use of either library.
A comment on the linked article actually mentions that it was indeed contracted. Very disingenuous indeed by the article's writer.
Right, it's just as valid (that is to say it is not at all) to claim that this comment thread uses Vue since it discusses it. YCombinator runs Hacker News on Vue now!
It's a shame since it's otherwise a well written article
It's a shame since it's otherwise a well written article
Not the same at all. To say that the site newsfeed.fb.com uses Vue is a fact. To say that Facebook owns and operates that site is a fact. The valid point is that Facebook is a large company made up of many people and not a monolithic entity.
The point I was making (badly) is that he states that News Feed by Facebook uses Vue. News Feed is a well known product by one of the largest companies in the world, and if Vue were indeed used by it (as React is) it would be a huge endorsement for the quality, durability, scalability and resilience of the project.
However the reality is so far from that, where a marketing site built by contractors under none of the strict constraints of the product it speaks about uses Vue, that it serves not as an endorsement but instead a needless point of contention in the post.
However the reality is so far from that, where a marketing site built by contractors under none of the strict constraints of the product it speaks about uses Vue, that it serves not as an endorsement but instead a needless point of contention in the post.
Nope. React has 10 people in its core team, highly compensated to work on React. There is at least one genius among those 10. Think of Fiber and how it works. VueJS may copy that model but in this sense, as in the case with JSX, they're a follower. They are not a thought leader. Just a sink/collector for React haters.
Maybe you should share your opinion with Even You at the next conference you go to and see how he takes it. Writing Vue off like this is an insult to it's creator. Evan works really hard on maintaining and improving Vue for what probably amounts to pennies on the dollar when compared with the money Facebook pumps into react.
I'm not saying that you're wrong about Vue not being a "thought-leader" or whatever, just that you really should be more appreciative of developers who release awesome libraries under OSS licensing.
That said, being a "thought-leader" is not necessary in order to make a difference. Software has been, is, and always will be an iterative process. We build upon the shoulders of giants that came before us. We take the best ideas from our predecessors and combine them to create something new and, hopefully, better. Regardless of your opinion on the philosophical aspects of Vue, you have to give credit to its creator and its community.
I'm not saying that you're wrong about Vue not being a "thought-leader" or whatever, just that you really should be more appreciative of developers who release awesome libraries under OSS licensing.
That said, being a "thought-leader" is not necessary in order to make a difference. Software has been, is, and always will be an iterative process. We build upon the shoulders of giants that came before us. We take the best ideas from our predecessors and combine them to create something new and, hopefully, better. Regardless of your opinion on the philosophical aspects of Vue, you have to give credit to its creator and its community.
Point well taken.
> Think of Fiber and how it works. VueJS may copy that model but in this sense, as in the case with JSX, they're a follower. They are not a thought leader.
Fibers only exist because sharing between Javascript threads is not currently an option.
React is a thing only because Javascript sent us back 20 years in time.
Fibers only exist because sharing between Javascript threads is not currently an option.
React is a thing only because Javascript sent us back 20 years in time.
Not true. We have shared memory (SharedArrayBuffer) and we have sharing (Atomics), but parallelism is not the answer. Single threaded concurrency is a better model IMO. From my understanding, what is missing is preemptive scheduling a la delimited continuation...
Yes, I will agree with you, someone who's never created anything of worth nor ever will. And I know this because you have so little agency you had to use a throwaway account to write this.
I think Vue will maybe kill Ember, but not React.
I went Angular, because I can get a well paid job very easily, it's a very fun Framework to work with, TypeScript is awesome, it's complete, fast and powerful, is backed by Google and has a huge community.
Vue might be fun to work with, but it doesn't have all the advantages of Angular (or React) I listed above.
Vue might be fun to work with, but it doesn't have all the advantages of Angular (or React) I listed above.
We ship Vue.js + TypeScript + Webpack templates: http://docs.servicestack.net/templates-single-page-apps
Vue.js also has the nice advantage of being able to use HTML, TypeScript and SASS within the same .vue component:
https://github.com/ServiceStack/Templates/blob/master/src/Si...
Vue.js also has the nice advantage of being able to use HTML, TypeScript and SASS within the same .vue component:
https://github.com/ServiceStack/Templates/blob/master/src/Si...
Vue.js is simpler and complete with integrated well-documented core components that's much faster than Angular.
Vue being stewarded by Benevolent Dictator is why it has an elegant design that's more pleasurable to use. Angular2+ has morphed into another design by committee complex monstrosity requiring much more code, conceptual and cognitive overhead to achieve the same result.
Vue being stewarded by Benevolent Dictator is why it has an elegant design that's more pleasurable to use. Angular2+ has morphed into another design by committee complex monstrosity requiring much more code, conceptual and cognitive overhead to achieve the same result.
I'm a contractor and Vue work seems to be gaining momentum. Another advantage is that you get to work with newer codebases and people that know what they're doing instead of somewhat legacy projects that picked a framework just because it's popular.
You can use TypeScript with Vue without trouble. It is true for employabilty. It will/may come later.
Everything has already been said in the article, but there's one thing that makes Vue stand out the most: The author(s) are really focused on keeping this framework's API simple and getting rid of/deprecating stuff that doesn't promote productivity.
Tried Angular, ReactJS and VueJS and to me, they have their own strengths, but all are more than capable as frameworks for building large and solid enterprise level apps. IMO, productivity and simplicity has Vue winning my preference.
Reading the article, I was surprised at this part:
"Wait, did I just write Facebook? Check Facebook’s newsfeed."
I did checked facebook's newsfeed and certainly, the Vue Devtools lit up on my Chrome browser, which detected VueJS being used on that page. Given that FB has heavily leaned on React, I wonder why they would be using Vue on one of their premiere pages? Is it because they are also trying to analyze what's being offered by Vue and integrate it with React in the future?
Reading the article, I was surprised at this part:
"Wait, did I just write Facebook? Check Facebook’s newsfeed."
I did checked facebook's newsfeed and certainly, the Vue Devtools lit up on my Chrome browser, which detected VueJS being used on that page. Given that FB has heavily leaned on React, I wonder why they would be using Vue on one of their premiere pages? Is it because they are also trying to analyze what's being offered by Vue and integrate it with React in the future?
As other comments here and on the post itself point out, that page which is a marketing site "about" news feed, not actually News feed, was built by contractors with zero knowledge or involvement by Facebook engineering. The reason given was that they had an engineer familiar with Vue and none with React experience
for what it's worth I will say that writing components in Vue is enjoyable in the way that React was initially. the two are definitely more similar than either is to Angular, but I find Vue slightly more easy to get started with (no JSX overhead). JSX is far more powerful than simple HTML templates but I rarely find myself needing that power.
As a reminder, you don't have to use JSX to use React. JSX is just a wrapper that makes it more elegant but you can just use the React API to create and declare element structures.
totally! but the pure JS syntax is pretty rough (IMO) and I was simply comparing their "default" templating languages, since most people will probably start with them.
I love react and have always been super impressed with the ecosystem FB created - just wanted to give Vue credit for being an enjoyable framework.
I love react and have always been super impressed with the ecosystem FB created - just wanted to give Vue credit for being an enjoyable framework.
Facebook news feed always crashing after sometimes of scrolling on mobile devices. The whole version of mobile web Facebook looks terrible, old fashion, completely awful ui\ux. This is a result of working framework. Try to compare it with another social networks like VK.com which is extrimely stable on mobile devices (both desktop and mobile version), very fast and user friendly.
It's the best parts of Angular and React in one framework. I don't know why you'd want to use anything else.
What are the good parts of Angular that are in Vue?
the databinding - though it's a shame Typescript+React+Mobx does databinding with better 'template' typechecking...
While I don't mind if Vue stays small (as in, just used enough to keep momentum), I'd love it if it became more popular. It's truly a joy to work with.
Angular was the first framework I used, and I liked working with it well enough, even if I wasn't a big fan of many of its idiosyncrasies. But then Google announced they were going in an entirely different direction so I decided to try new things.
I tried liking react (gods, I tried, many, many times) but I just can't like how the code looks when using it or the structure it ends up forming, or the boilerplate it requires.
Vue, however, feels like doing plain JS, which I actually like[1], as each component is rarely more than a few objects and functions. Well, that and html templates, which I'm fine with and would have to use anyway as a backend developer.
[1]: JS has always been my second favorite language, after python, and the new versions are just so nice to write.
Angular was the first framework I used, and I liked working with it well enough, even if I wasn't a big fan of many of its idiosyncrasies. But then Google announced they were going in an entirely different direction so I decided to try new things.
I tried liking react (gods, I tried, many, many times) but I just can't like how the code looks when using it or the structure it ends up forming, or the boilerplate it requires.
Vue, however, feels like doing plain JS, which I actually like[1], as each component is rarely more than a few objects and functions. Well, that and html templates, which I'm fine with and would have to use anyway as a backend developer.
[1]: JS has always been my second favorite language, after python, and the new versions are just so nice to write.
This is a valuable discussion to me right now. At work I've been tasked with looking into a number of front end frameworks (Angular 4, React, Vue, Aurelia and Mithril) to see if we'd like to start writing new pages and components in one of those as opposed to AngularJS which we currently use. AngularJS has a few specific pain points for our web app, a complex and (unfortunately) ambitious SPA.
I'm building a prototype of one of our actual landing pages in each framework to get a bird's-eye view of what works and what doesn't. So far I've been really impressed with Vue, but my team has a couple of objections from the outset:
1) Most mid-level developers haven't heard of or used Vue, so the pool of candidates we can hire as our company grows will be smaller if we switch from a common denominator like AngularJS to something relatively unknown like Vue. I personally love to learn new tech, but not everyone does and a "Vue developer" job posting may not get a lot of hits.
Then again, if (e.g.) 15% of devs want to use Vue and only 10% of companies use it, that's a clear advantage over 75% of devs wanting to use Angular and 80% of companies using it. I wouldn't be surprised if the numbers worked out like that.
2) Vue is kind of a one-man band, whereas Angular and React are backed by large cap companies. This is the weaker argument IMO, since there's no law stating that Google and Facebook can't run up on hard times and decide to drop support for their open source projects. And after seeing how sloppy Angular's documentation is, I've lost a lot of confidence in the "bigger is better" argument. However, in a rational universe, it may be fair to say that Vue would die more easily than Angular would.
My view on the situation is that it's better to use the right tool for the job and have less developers/support than to use the wrong tool for the job and have more developers/support. But I'm more technically-minded than business-minded, so I understand that I might need to be open to business concerns outside of my normal decision-making criteria.
I'm keeping detailed notes as I compare frameworks, so I may do a write-up when I'm done if anyone's interested. (Although the "battle of the frameworks" genre has been done to death...)
I'm building a prototype of one of our actual landing pages in each framework to get a bird's-eye view of what works and what doesn't. So far I've been really impressed with Vue, but my team has a couple of objections from the outset:
1) Most mid-level developers haven't heard of or used Vue, so the pool of candidates we can hire as our company grows will be smaller if we switch from a common denominator like AngularJS to something relatively unknown like Vue. I personally love to learn new tech, but not everyone does and a "Vue developer" job posting may not get a lot of hits.
Then again, if (e.g.) 15% of devs want to use Vue and only 10% of companies use it, that's a clear advantage over 75% of devs wanting to use Angular and 80% of companies using it. I wouldn't be surprised if the numbers worked out like that.
2) Vue is kind of a one-man band, whereas Angular and React are backed by large cap companies. This is the weaker argument IMO, since there's no law stating that Google and Facebook can't run up on hard times and decide to drop support for their open source projects. And after seeing how sloppy Angular's documentation is, I've lost a lot of confidence in the "bigger is better" argument. However, in a rational universe, it may be fair to say that Vue would die more easily than Angular would.
My view on the situation is that it's better to use the right tool for the job and have less developers/support than to use the wrong tool for the job and have more developers/support. But I'm more technically-minded than business-minded, so I understand that I might need to be open to business concerns outside of my normal decision-making criteria.
I'm keeping detailed notes as I compare frameworks, so I may do a write-up when I'm done if anyone's interested. (Although the "battle of the frameworks" genre has been done to death...)
Re: the first point -- the counterpoint in my eyes would be that that hiring devs for any particular framework experience might be a losing battle, given the insane life cycles of front-end JS technology.
In web development more than anything else, the chances are higher that whatever keyword you hire for will be sidelined in 1-2 years. Even compared to other fast-moving tech niches, the web front-end arena is a batshit insane ADHD chipmunk in this regard. A DBA or a networking guy's current keywords are going to have at least five years of shelf life in some fashion. You can't count on those kinds of lifespans in the web world anyway. Yes, I also think that's ridiculous.
And so, "all-around competent JS developer experienced in a variety of frameworks and tools" might be the only viable hiring selector here.
Also, the barriers to entry to Vue are much lower. The simplicity is one of the main selling points. I'm not even a web developer by trade, but I picked up most of the essentials in a day or two. Admittedly, I did have a [kind of amateur] AngularJS background, which made that process much simpler, but I gather a React background equally predisposes one to rapid assimilation of Vue.
In web development more than anything else, the chances are higher that whatever keyword you hire for will be sidelined in 1-2 years. Even compared to other fast-moving tech niches, the web front-end arena is a batshit insane ADHD chipmunk in this regard. A DBA or a networking guy's current keywords are going to have at least five years of shelf life in some fashion. You can't count on those kinds of lifespans in the web world anyway. Yes, I also think that's ridiculous.
And so, "all-around competent JS developer experienced in a variety of frameworks and tools" might be the only viable hiring selector here.
Also, the barriers to entry to Vue are much lower. The simplicity is one of the main selling points. I'm not even a web developer by trade, but I picked up most of the essentials in a day or two. Admittedly, I did have a [kind of amateur] AngularJS background, which made that process much simpler, but I gather a React background equally predisposes one to rapid assimilation of Vue.
Don't forget about others, such as Preact [1]
[1] https://github.com/developit/preact
[1] https://github.com/developit/preact
I am a fan of this "small (and focused) is beautiful" approach, like yo-yo [0], hyperHTML [1], and numerous others.
The thing that sold me on Preact is its compatibility layer with React, which provides a kind of de facto standard API for components. One day I just replaced React with Preact, with the only difference being a happily reduced app size - and have been using it since. I don't plan to keep up with React's latest developments - I'm satisfied with the rendering performance of Preact, and want to stick to a stable API which lets me focus on actually building things with it.
I feel the same about client-side routers, the build process with Webpack, etc. - I'm fatigued of keeping up with breaking changes, and have started transitioning to smaller, individual libraries that just do their modular jobs, with minimum API surfaces that are reliable over long-term.
[0] https://github.com/maxogden/yo-yo [1] https://github.com/WebReflection/hyperHTML
The thing that sold me on Preact is its compatibility layer with React, which provides a kind of de facto standard API for components. One day I just replaced React with Preact, with the only difference being a happily reduced app size - and have been using it since. I don't plan to keep up with React's latest developments - I'm satisfied with the rendering performance of Preact, and want to stick to a stable API which lets me focus on actually building things with it.
I feel the same about client-side routers, the build process with Webpack, etc. - I'm fatigued of keeping up with breaking changes, and have started transitioning to smaller, individual libraries that just do their modular jobs, with minimum API surfaces that are reliable over long-term.
[0] https://github.com/maxogden/yo-yo [1] https://github.com/WebReflection/hyperHTML
I hope so, its really easy to use, anyway it has my vote
The only advantage React has is a huge backer..Facebook.
So large companies are more open to using it because it's less risk and has higher chance of being around in 5 years than a framework without a huge backer.
That's my theory on how 'biz' people make I.T. decisions.
So large companies are more open to using it because it's less risk and has higher chance of being around in 5 years than a framework without a huge backer.
That's my theory on how 'biz' people make I.T. decisions.
Another aspect is lower ramp up time for hiring new developers, and easier convincing developers to come on board where they'll learn / use a growing technology rather than some oddball niche thing.
They're solid, non-arbitrary reasons. Given a choice between the most common tech on the market and a niche offering, you need to have a good reason to choose the niche offering, because it comes with real downsides to a development team (as opposed to an individual developer).
They're solid, non-arbitrary reasons. Given a choice between the most common tech on the market and a niche offering, you need to have a good reason to choose the niche offering, because it comes with real downsides to a development team (as opposed to an individual developer).
Yeah, but the simplicity of Vue is one of the main selling points.
I'm not a web developer at all by trade, but it took me only 1-2 days to pick up the essentials of Vue. That's not because I'm brilliant, it's because the barriers to entry really are that low. It's simple. They've nailed that part well, and it's a very seductive differentiator in a JS front-end world that just keeps getting more and more Byzantine.
Admittedly, I did have some Angular 1.x background, but it was really just dabbling in the grand scheme of things. And I gather that a React background is equally advantageous in picking up Vue.
More generally, given the insane ADHD pace at which front-end web technology moves, I'm not sure hiring developers for any particular framework experience is viable. People sometimes say that about tech hiring in general, and I don't necessarily agree, but web front-end work is really the one area where I think it holds true and you just have to hire competent JS developers experienced with a variety of tools and frameworks in general. There's just no telling how different the landscape will be in 1-2 years.
I'm not a web developer at all by trade, but it took me only 1-2 days to pick up the essentials of Vue. That's not because I'm brilliant, it's because the barriers to entry really are that low. It's simple. They've nailed that part well, and it's a very seductive differentiator in a JS front-end world that just keeps getting more and more Byzantine.
Admittedly, I did have some Angular 1.x background, but it was really just dabbling in the grand scheme of things. And I gather that a React background is equally advantageous in picking up Vue.
More generally, given the insane ADHD pace at which front-end web technology moves, I'm not sure hiring developers for any particular framework experience is viable. People sometimes say that about tech hiring in general, and I don't necessarily agree, but web front-end work is really the one area where I think it holds true and you just have to hire competent JS developers experienced with a variety of tools and frameworks in general. There's just no telling how different the landscape will be in 1-2 years.
The "corporate backing" argument is the same as one that people use to justify using Windows rather than Linux. It's not wrong per se, but it's far from telling the whole story; there are some huge and popular projects that didn't have a large corporate sponsor at the beginning.
This seems to be also how 'developers' make decisions. If something is backed by a large company and has adoption then there is more potential for employment. So there is a rush to learn it. Which is logical.
What is not is the next step when these groups become extremely invested and endlessly hype their choice and rubbish others in places like here never mind any technical merits or demerits. The prevents proper technical scrutiny of hyped technologies and allows a lot of bad ideas to gain traction.
What is not is the next step when these groups become extremely invested and endlessly hype their choice and rubbish others in places like here never mind any technical merits or demerits. The prevents proper technical scrutiny of hyped technologies and allows a lot of bad ideas to gain traction.
I can confirm this
I've not used Vue or Angular, but I love React. It feels almost object oriented programming like - kind of like programming in Java. Correct me if I'm wrong (I'm new to web dev).
I feel that the biggest advantage of Vue over React is that it's incrementally-adoptable. It's small and lightweight and fits nicely everywhere.
Preact offers a similar experience.
Preact offers a similar experience.
React will continue to dominate thanks to react native. Neither Angular or Vue.js has a solution for mobile as nice as react native, at least as far as I know.
You might want to have a look at Weex, aka "vue native":
https://weex.incubator.apache.org/
Also nativescript: https://www.nativescript.org/blog/a-new-vue-for-nativescript
React isn't just a web framework like Angular or Vue AND the company creating it uses it for its main product.
So React doesn't compare to any of the others.
So React doesn't compare to any of the others.
Since when is React in the same bracket as AngularJS?
Vue is on par with React but still far to go before its as big as Angular
[deleted]
#JQuery4Ever
Webassembly needs it's own UNIX. A simple abstraction library for browser IO that scales.
Webassembly needs it's own UNIX. A simple abstraction library for browser IO that scales.
Statamic uses Vue.
[deleted]