13 ms·
Vue.js vs. React: what happened in 2017
- fictionfuture 9y agoI see a lot of commits from the Vue team into the core repo that are meant to support use in native. Likely, we can expect something comprehensive for native this year. I also believe it's a smart strategy to avoid Facebook codebases because they are all meant to somehow benefit FB in some (usually dubious) way. Also the Vue approach is 1000% cleaner in practice than React, just doesn't have the bandwagon effect going for it
- scardine 9y agoMy typical use case doesn't need native apps - a PWA is good enough for me. I will not comment on speculation about the compile-to-native feature because personally it is irrelevant. I can say that as you I prefer Vue over React and some of my personal reasons are: * I like opinionated frameworks * I don't like to mix Javascript and HTML - I can handle a Vue template to any designer but I would not trust a JSX file to a non-programmer. * Vue is easier for developer onboarding - with Vue the gap between a junior and a senior developer is way smaller. React may be better, I don't care, Vue is easier for my development style.
- jetter 9y agoPWA is not good enough for us due to heavy usage of mobile device camera and picture resizing (client side) for package receiving process in the warehouse. PWA fails to provide consistent performance in such conditions, and issues with bluetooth scanners in Safari/PWA on iOS devices add up. Other than that, I agree Vue.js is superior to React in a lot of use cases, especially for web.
- marcosdumay 9y agoThe one reason why I favor Vue more than React is: * Vue downscales. If you have a single scripted component in a page, you will get a simple page, with a small amount of Vue added.
- mamcx 9y agoA thing that will sell vue/react native for me is the ability to only use them for UI. I don't wanna use them for logic or heavy stuff. Just have them for render the UI. This mean, easy way to embedb into iOS/Xamarin.NET. I have look at react native and NativeScript and both are very hack-ish for my taste.
- hbhakhra 9y agoGood assessment. To summarize the argument, Vue.js is just as good and some would argue better than React for web development, but the React ecosystem really puts it over the top, especially React Native.
- hakcermani 9y agoFor those like me in the Vue camp, with the React-native dilemma, there is Fuse tools for the interim till week matures. Very clean separation between UI and JS logic.
- hypercluster 9y agoThough there is Nativescript Vue now.
- diminish 9y agoI truly love Vue and hope it evolves and spreads everywhere.
- wjossey 9y agoI’m the founder writing code (but not the only technical person) for my three person startup. In October I started migrating our MVP from server side templates to Vue, given we had direction and traction on a product line that justified the time investment. It’s turned out to be a great decision (although likely one that could have been made with react as the choice as well). My “success story” is how Vue helped me to massively improve our user experience in low bandwidth or high latency environments. Our startup is trying to reinvent the ways that companies approach their review process, and one of the things we do is run a workshop on delivering actionable feedback during the review cycle. We have users log into our app during the workshop, and this often happens in conference rooms over congested WiFi. Our MVP used turbolinks, so it felt generally “snappy” during normal use, but could feel sluggish if moderate latency was introduced (such as a congested router). Since I completed the rewrite to Vue (which took only about two weeks because of how simple it was to pick up, even for a non frontend person like myself), we’ve had multiple launches that both would have likely bombed had we not done the work to move to something less dependent on a tradition client -> server -> client response cycle to render the next “page”. Either way, I’ve become an advocate for vue. I love single file components, love the documentation, and am very happy with the community libraries. All in all, I’m very bullish for Vue in 2018 as a happy new users.
- j45 9y agoAppreciate the comment about high and low bandwidth performance by vue. 80% of the world is low bandwidth and such solutions built with such tools have an opportunity to have a much farther reach. Have you had any exposure to using vue as a progressive web app that can sync and work offline first? Have you come across any vue.js offline app experiences?
- wjossey 9y agoI've looked at PWA & working with offline, but it's an optimization I'd like to have, not one that we absolutely need. Right now, given how crunched we are for resources, everything I work on has to fall into the category of "absolutely need", otherwise I de-prioritize it. For us, the reason why we don't necessarily "need" PWA or full offline is that we do have an initial online component that is dynamic, so fully supporting an offline mode (a la, full on iOS or Android app) would change a lot of assumptions & optimizations we've made with how our product works. PWA seems promising, but it still feels slightly early to me. It's not that I don't think it will eventually win, but right now it has just enough complexity with minimal payoff, that I've punted for now (although it's probably closest to what we're looking for).
- sarahcross 9y agoReact changing their license probably saved them. My web dev office was going to transition from them until they changed it.
- jjeaff 9y agoSame here. For us personally, the license made no difference. We know we will never come across any patent issues with Facebook. But the fact that it existed led us to believe that in the long run an alternative would emerge since larger corps would avoid it because of the license. Now that they got rid of it, I have no such concern investing time in react for the short/mid term term.
- jasonkostempski 9y agoBut what are you going to do when they pull the next community enraging stunt?
- ng12 9y agoDo Vue templates play nicely with Typescript? That's something I love about JSX -- "it's just JavaScript" is an incredibly sublime feature. I know you can use JSX with Vue but I'm skeptical since it's a first-order feature with React.
- KitDuncan 9y agoSince October (I think) vue single file components work flawlessly with typescript. Can't speak for jsx though.
- tomonl 9y agoIt works in the <script lang="ts"> part of your .vue file, but not the <template> part.
- ng12 9y agoAh, that's a bummer. Vue Templates seem wildly regressive to me -- I can't fathom going back to stringly-typed Handlebars wrangling after using JSX/TSX. After looking into this further it seems like Vue Templates also differentiate between values and components. In React I often write components which can take in either: a good example is text which the consumer might want to format. You can easily write the component so that they pass in a string or a <span /> element. Vue has a lot of good ideas but the templates are almost a non-starter for me.
- faitswulff 9y agoYou don't have to use the templates, though. Define a render function and you can even use JSX in it: https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX
- ng12 9y agoWhy wouldn't I just use React at that point? Same behavior, less complexity.
- baybal2 9y agoI'm afraid React is eventually turning into Angular. At some point, I felt that Angular is somebody's PhD work exploring arcane computer science concepts, not a piece of software for practical use. React gets closer to that with each year.
- acemarke 9y agoCan you clarify that comment? What aspects of React's development are you concerned with?
- oaxacaoaxaca 9y agoWondering the same thing myself. They are very different all the way to their core. Angular is a full-blown framework; React is a view library. Angular's API and documentation are (excessively) large; React's documentation can be easily perused in under a day. React components are just functions (or classes) and thus can be tested with such ease. Angular testing is, last time I checked, way too complex to get up and running.
- baybal2 9y agoFirst, probably was their approach to implicitly require use of Observable objects everywhere. Second, use of arcane CS lingo and authors writing 10 pages long pages on every known MVC model, FLUX, SCHMUX and etc with weekly regularity. Third, during transition to Fiber, they went on gigantic increase of complexity by introducing a lot of what can be said to be heuristic rules, and all for non-guaranteed, minor performance gain.
- deleted 9y ago[deleted]
- andrewingram 9y ago1) I've been using React for 4 years and never used observables, what do you mean? 2) Please clarify what you mean by this. 3) By all accounts, the fiber codebase is much simpler than the stack codebase, performs similarly and opens up some exciting new possibilities.
- marcfawzi 9y agoWhen it comes to UI need to start thinking past Framework A vs Framework B. There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out. Copying from Readme my WIP project that uses Skate: "SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on. With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements. SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used. This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
- platz 9y agoOP predicts with absolute certainty vue "will become dominant" next year many times. Also OP has skin in the game to justify to his team that vue was the correct choice. Nice as an opinion piece but too many red flags to be considered fair and unbiased.
- ec109685 9y agoHuh? OP said the power of the React ecosystem and change in license will keep it on top in 2018 and that if they were starting from scratch they probably would have used React for their website.
- platz 9y ago> next year would be the year of Vue.js success > Vue.js will be dominating only in the web OP did not say they would've used React given the choice, they said it would have made some things simpler Your reading and subtle re-wording of OPs comments misrepresent what OP actually says. > our stack would be simpler if we chose React.js for the web. We definitely do not regret choosing Vue.js for web, read more in my previous post why we did that, my expectations on Vue.js web domination are becoming the reality
- ec109685 9y ago> Synergy, my friends, is the key to React upcoming monopoly.
- ozim 9y agoAgree, also drawing conclusions form "heard of it would like to learn" on the graph seems a bit far fetching. I would like to learn vue but I do not see opportunities in my job to use it next year.
- chvid 9y agoReact IMHO is good enough that I don't want to change framework/basic frontend technology again.
- rvanmil 9y agoAgreed, it’ll take another paradigm shift to switch to something else.
- murukesh_s 9y agoNot necessarily.. I wonder had react not been backed by FB, it certainly would have had a beating in its popularity given lighter and arguably faster alternatives like vue. Remember, performance was one of the main argument React had when compare to Angular. Now since performance is no more a differentiating factor, developers might look into other aspects like better ROI in short and long term..
- Silhouette 9y agoJust as one anecdotal data point, we didn't choose React for its performance when evaluating tools for our recent projects. (React can still be orders of magnitude slower than localised direct DOM updates on demand, after all, and in cases where performance really matters that might still be what you have to fall back on.) The game-changer with React is that it presents a declarative way to specify your DOM content, which in turn can significantly reduce the number of cases you have to consider in your rendering and state management code, and it's fast enough to make that work in a lot of real world situations.
- murukesh_s 9y agoCould be for you, but have you wondered if React was say way slower than Angular and heavier, the adoption would have been much much lower?. Agreed, the model that React brought is superior but the catalyst was performance. They even highlighted performance as the main selling point with introducing the virtual dom, where the computation (dom querying) happens not in the dom but in the javascript, which is arguably faster and only differential updates are applied to the actual dom. In my friend circle everyone wanted/were using Angular.js but it was too heavy for actual production use while react showed much better performance in the benchmarks (almost closer to Dom).
- dustingetz 9y agoI write ClojureScript A good indicator of if a technology is going to explode, is if emerging language users are excited about it, as good ideas tend to trickle down from the more advanced/research-y ecosystems which aren't as constrained by legacy. So for example React was built by a user of OCaml. ClojureScript early adopted React.js through the Om project in 2013 and there is a growing number of competing React adapters, Clojure rewrites etc. I first saw virtual-dom in ClojureScript in 2012 (eight months before React came out). Number of ClojureScript projects with traction that are based on vue? Zero, that I am aware of.
- owebmaster 9y agoThis is my reasoning too. Until someone creates a better reagent and reframe and renatal I'm gonna stick with React
- yogthos 9y agoWhat do you find missing in Reagent currently that works better in React?
- owebmaster 9y agoNothing (?!).
- yogthos 9y agoSo what would you expect to see in a better reagent and reframe and renatal that would make you switch from React?
- owebmaster 9y agoNo, what I mean is that I'd only switch from reagent with react for a better-than-reagent fw based on vue.
- 9y ago
- git-pull 9y agoI think both of them are awesome and have great communities. Especially seeing as webpack has stabilized. If you're a startup, it's tempting for many founders to go in headfirst with a Vue or React. In my opinion, it's rarely necessary, and in the end a lot of the stuff has to be thrown out if underlying foundations change. I see it as web development's version of premature optimization. On the other hand, when I kept all my work in django templates, erb, blade, etc. and just script JS by hand, there's less of a penalty when the data flow changes. When I was using a JS framework, the refactoring was so painful I seriously considered throwing the whole thing out and starting from scratch. Heh, I'd have been better off not buying in so early on. As a stop-gap, I'm using pjax. (https://github.com/defunkt/jquery-pjax https://github.com/defunkt/jquery-pjax) My plan is after stuff is solid and in production and the product/service/business is moving forward, taking an incremental approach to moving to vue/react/etc. P.S. kudos to react for removing the patent stuff in v16.
- kortex 9y agoI disagree. Coming from python, my first foray into web frontend was a SPA for mobile. Both my coworkers convinced me to go right to react + redux (after some bumbling first with more "traditional" ajax). After a few weeks of utter bewilderment, I have to say I really enjoy this stack. Some say it's overkill, but the framework really helps me organize things into cognitive chunks, and makes debugging so much easier. Ever had a class in school which you hated at the time because it felt super hard, but loved in hindsight because of how much you learned? same sort of vibe. Fight through the pain.
- RobertRoberts 9y agoI am in the same boat you are. I've tried frameworks before that ended up being a mess later to recover from. Also, I see Shadow DOM, proper html/js templates and future JS upgrades (modules, etc...) making React totally usesless, or either they will have to uproot themselves all over again to maintain equal performance from native systems. As soon as I saw that rounded corners were coming to CSS, I stopped all the stupid hacks, I feel like JSX is an immature hack on top of mature tech. Eventually something else will come along and supplant it.
- deleted 9y ago[deleted]
- toothfairy1 9y agoWhen it comes to UI need to start thinking past Framework A vs Framework B. There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out. Copying from Readme my WIP project that uses Skate: "SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on. With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements. SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used. This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
- jjj1256 9y agoWhen it comes to UI need to start thinking past Framework A vs Framework B. There is already a browser-native compatibility layer known as the Web Components API that allow components rendered by different frameworks to work together, so we won't ever have to be stuck in Framework A or Framework B and can migrate in agile manner (one component at a time) from one to the other or whatever new framework may come next year. I agree Web Components have some major warts and DX issues but libraries like SkateJS and others help smooth those out. Copying from Readme my WIP project that uses Skate: "SkateJS allows us to export components rendered by React, Angular 2, 4, Vue, and other modern composition-oriented frameworks as W3C Custom Elements and compose those Custom Elements into higher order Custom Elements with data flowing from parent to descendants and so on. With SkateJS we can have an Angular 4-rendered Form custom element composing Angular 2-rendered input and selection custom elements, or the other way around with Angular 2-rendered Form custom element composing Angular 5 --and Angular 4-- rendered input and selection custom elements. SkateJS also provides a Router that is framework agnostic. Only the rendering part of any framework (Angular, React, Preact, Vue, et al) is ever used. This way we can build SkateJS-based reusable component libraries using any version of Angular (> 2), React, Vue et al and be able to use those components in our SkateJs-based site together, including via composition, and be able to upgrade our app (when a new version of React, Angular or Vue et al comes out) one component at a time, in piecemeal fashion as in iterative agile development, as opposed to having to do it all at once, as in waterfall development, which is almost always an unrealistic approach. This works because our components are essentially all custom elements regardless of rendering library we use (different versions of Angular, React, Preact, Vue, et al)"
- buamaharami 9y agoWhy in earth people would like to to use anything from facebook in they business ? Why do you trust they licensing ? I would choose riotjs or vuejs anyday before any facebook's code in my apps.
- joobus 9y agoYou apparently aren't keeping up with the latest about riotjs: https://github.com/riot/riot/issues/2283 https://github.com/riot/riot/issues/2283 I wouldn't feel confident picking that as my company's future.
- ricardobeat 9y agoWhoa. Thanks for the link, wasn't aware of that. A lesson on how not to run OSS: https://github.com/riot/riot/issues/2512 https://github.com/riot/riot/issues/2512
- jjeaff 9y agoFacebook has corrected the licensing issue. Most consider it a non-issue now. And I think Facebook proved with that move that they are willing to play ball.
- deleted 9y ago[deleted]
- faitswulff 9y agoIt's a shame there's no first party supported Vue native library, but I suppose that's too much even for Evan.
- benatkin 9y agoThat might not matter that much. There's still a strong argument for implementing native apps using their own SDKs. There are more developers with experience with them, there is more boilerplate and examples, third party integrations are typically designed for them, and more books and documentation are for them. On the front page of HN today there was a stackshare post about a startup with only three engineers that used a lot of cutting edge tools, but React Native was not one of them.
- baybal2 9y agoWeex is not a part of the titular Vue project, but can be said to be the most endorsed one, and one that is the most up to date with Vue upstream development.
- throwaway0255 9y agoOne thing I'm noticing about SPAs is that they're often slower to load, but the slowness and loading animations gives me a higher perception of the quality of the application. The same application loading and doing things instantly as server-side templates feels comparatively cheap and un-modern. What is wrong with me?
- d357r0y3r 9y agoReact + TypeScript is simply too good to not use for me. The idea of going back to unsafe templates is just not acceptable.
- dbrgn 9y agoElm would deserve a mention too. One of the very few sane frontend development approaches.
- simonhamp 9y agoI personally prefer Vue because it is approachable and easy to adopt. I believe that if Vue embraces PWAs in a pragmatic way that performs and is accessible, it will be top for a while. At the moment, PWA is not a viable replacement for some cases, but it’s about to explode to everyone.
- lsdafjklsd 9y agoI really don't get the love around vue... I always read the glowing sentiment and go, "Ok, I'm missing something, let me go back to the vue.js docs and see what's good" Things that are a deal breaker for me: Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great State management... I cut my teeth with Ember professionally for a few years, and really loved it up until I built a data intensive app. Having state spread across different controllers is great when you have many different routes and pages, but if one page turns in to a photoshop like app, controllers make a terrible state management tool. It doesn't seem overly complicated to me to use redux along with react-redux's connect function to connect regular functions returning JSX to your state object. Looking at Vue.js, it seems like I need to learn Ember-lite + Angular (custom directives).
- kevmo314 9y agoAre you sure you read the right docs? > let me generate templates using the language I already know, JSX is great https://vuejs.org/v2/guide/render-function.html#JSX https://vuejs.org/v2/guide/render-function.html#JSX > controllers make a terrible state management tool. I haven't used react-redux but vuex is essentially the same decoupling, and there's very little boilerplate. https://vuex.vuejs.org/en/intro.html https://vuex.vuejs.org/en/intro.html
- nawitus 9y ago"Template language... You can call it 'separation of concerns' all you want, but just let me generate templates using the language I already know, JSX is great" Not everyone knows JSX, so while that argument applies to you, it doesn't apply in general.
- jonreem 9y agoThey mean javascript; jsx is a very small amount of new syntax and is embedded in normal javascript. Learning a completely separate template language with all of its own constructs for conditionals, iteration, etc. is significantly more work.
- apatheticonion 9y agoHaving used all of the big three. Am I the only one who likes and prefers Angular?
- nikkwong 9y agoCurious—what makes you prefer angular?
- jcroll 9y agoService container for one
- apatheticonion 9y agoIt's very well structured, easy to understand, batteries included, lends itself well to maintainability and scale. When working for a company with staff below me who had very basic understanding of JS (having just done HTML/CSS/JQuery, had no idea what a promise was), there was almost no learning curve with Angular. The hardest part was understanding what a component was, then learning the folder structure. Angular's seamless use of templating, the built in support for CSS pre-processing and simplicity of uni-directional databinding had the entire team pick it up and be productive almost immediately. Using decorators to declare inputs/outputs on dumb components is clear, readable and easy to understand. Class based components are also very clear. Some say TS is annoying and all power to you, but using types is optional. Personally, TS has allowed me to save on some test cases by virtue of the compiler catching those issues. Plus there is a comfort in quality intellisense. Vue is cool, it's like a less opinionated Angular. In my opinion, it's strength is its ability to be dropped into any project, giving you client side components and databinding irrespective of your stack. However I have experienced growing pains in larger projects as a result of people over complicating simple solutions. I am still relatively inexperienced though, and I intend to spend more time with Vue to see if I can't like it more. I'm sure all of my concerns are addressable. So far though, Angular has treated me very kindly, both in large and small scale projects.
- Bahamut 9y agoThere are some things Angular does do far better than React IMO - Angular’s pain points are frustrating to me in terms of how I prefer to code though, largely due to its choice of supporting TS first and TS’s issues with toolchain integration/perf & not very conducive to FP, but it also has less pain in some respects such as when it comes to state.
- badbanana 9y agoHaving used both React (with Typescript and Redux) and the latest Vue (with es6 and Vuex) I prefer React, and I don't even use React Native. Vue is better for onboarding people more in tune with "classic" html + js development; and that's where the advantages end as far as I'm concerned. This might be a big win for some people. The way I reason about it is that React is simple, Vue is easy. When you take into account Vue's templating language, React's api is small in comparison. A beginner won't know how to do some common use cases reading React's docs, when Vue might have a something built-in in its templating language (e.g. slots, or the component tag for dynamic components). Slightly annoyed with Vuex too because of its slightly leaky abstraction. You have to remember to setup the properties you mutate so the reactivity will detect a change; and also remember not use array indexes arrays cause it can't detect changes otherwise. The array index thing will be fixed in the next version when they drop support for some older IE. Using Typescript would probably help a bit here, although Typescript being useless for checking Vue templates really feels like a huge chunk of its value is wasted. Typescript is not currently available in the official blessed boilerplate which greatly affects its uptake in the Vue community. Anyway, if you already know React, there is zero advantage in investing time in Vue.
- shard972 9y agoI have already moved to using React for my larger projects and Mithril for my smaller ones instead of Vue because of the lack of typescript support. That and when you add JSX to mithril, the api just feels so simple and i rarely find myself checking the docs for something.
- rsyring 9y agoGlad to see Mithril mentioned. I like it better than React when comparing the APIs, It just seems simpler. But React obviously has the mind share. I'd love to see Mithril gain momentum. I especially like the fact that I can easily include it as a script, like Vue, and don't have to have a build chain. That really decreases complexity for smaller projects.
- 9y ago
- perlgeek 9y agoIsn't it funny how you can read different things into the same data? > So, 1 year passed, and Vue.js is clearly the leader in "would like to learn" by a huge margin For me, the main takeaway of the newer chart is "React is the clear winner in the 'Happy Customer' category". For the record, I never used any of the frameworks, though I think I will, some day.
- ausjke 9y agovuejs does gain strong interests from large companies such as alibaba,baidu and tencent, the three are called BATs in China similar(or larger) to amazon, google and facebook in US. One of the BAT should acquire Vue.js to make it a strong player for the long run, that may happen in 2018 I hope. Both laravel and vue.js (vue.js is the default frontend choice and embedded in Laravel) are from one core developer, I liked them, but am concerned about the bus factor. I eventually choose nodejs+react because of that.
- hypercluster 9y agoI like the simplicity of React though I don't mind the Vue templating language that much either. Sometimes I actually prefer Vue templates because with React you often see components where it's not so clear how the rendered output will look like.
- dmitriid 9y agoThe simple answer is in reading the chart. Look at "I've USED it before, and WOULD use it again". React isn't just popular. It also consistently provides good developer experience. You have to compete not only against React's popularity, but also against that. React: - Used it, would use again: 14k - Used it, would not use it again: 1k (7%) Vue: - Used it, would use again: 4.6k - Used it, would not use it again: 454 (9.8%) That ~3% difference in people who tried it, and didn't like it could be the difference between make it and break it when coming up against React. "I've heard about it, and I'm not interested" is another important metric. --- Personal take: Things I personally don't like in Vue: - String-based programming so prevalent these days. JSX is a thin layer on top of regular Javascript/Typescript. Where as Vue is often this: <li v-for="todo in todos"> Really? - It breaks Javascript and how it works: var app5 = new Vue({ el: '#app-5', data: { message: 'Hello Vue.js!' }, methods: { reverseMessage: function () { this.message = this.message.split('').reverse().join('') } } }) There's no chance in hell that `this.message` exists on app5. And yet, there it is. And then data becomes $data and a lot of other weird stuff such as computed properties being also hoisted up to the top-level object etc. etc. etc.
- jordache 9y agoI absolutely hate that object literal style of defining a component... Terrible readability and annoying obj literal syntax to deal with...
- caseymarquis 9y agoIt's not really fair to make a comparison between react with JSX and vue without webpack. In practice you use webpack for making components with separated js/html/css, so Vue ends up looking a lot better than the above. That's actually the big draw for me, organization into single file components which can be parsed as simple html. The js component structure is just another piece of that. You're passing vue a template for creating components in an organized/standard way. You can define your own render function if you want the freedom, but you start out with something clean and well organized. Vue is definitely doing things behind the scenes, but it's nothing all that complicated. I wouldn't say it's hoisting. It uses the data function to create component instance objects which it then adds the template's computed props/methods/watchers etc on to, and links with the life cycle hooks. If you created the component object yourself instead of a definition for it, there would be less magic going on for sure, but things would be much less organized. (Minor: I don't use vue without webpack, but I assume data should be a function which returns a data instance, so what you've written won't work in Vue unless it's different for the top level component?)
- jordache 9y agoComing from Angular, I'm biased towards entities declared in the form of a class. It's a style that is easy to manage and familiar to most programmers. Vue currently seems to be a mix bag of styles. My take away from the little that I dabbled: - You need the vue-class-component dependency in order to declare class based components, otherwise, you're stuck with the awkward object literal notation - For state management using Vuex. You are are limited to the object literal style to declare your state store. Very awkward to work with. Yes to get some data bound to a template and rendered out, Vue takes very little amount of code. However that is not a meaningful benefit to me. I feel Angular's complete framework and class based convention is much more suitable for a team environment.
- philliphaydon 9y agoI couldn’t disagree more. Unless your team have Super in depth knowledge of angular then it’s the wrong choice. It’s defaults to progagate changes cause rendering perf issues that are so frustrating to fix. Out of the box react or vue performs better than angular hands down. I hate that after learning angular 2 I realise I should not followed tutorials and advice and just switched all the defaults off on classes and manually propagate changes when required cos it’s a painful task to do.
- jordache 9y agoI don't know what convoluted patterns you where implementing, but out of the box, the default change detection in angular is performant, esp if you start to leverage observables and the async pipe (to eliminate the need for component onDestroy maintenance tasks). It's a joy to use. Yes Angular provides a lot more options than react or vue, and maybe confusing given the scope of what's possible. However, after the initial learning curve, Angular is a very efficient framework / pattern to work with in a team setting. If you resort to manual change detection, then it's an obvious sign of needing to refactor your design.
- philliphaydon 9y agoThe default change detection can cause the whole page to redraw. Especially if you have a lot of data. It gets even worse.
- toddmorey 9y agoJust to set record clear, vue components can be written in pure JS or using JSX, in addition to the template files.
- Can_Not 9y agoAnd pug/jade.
- cyberferret 9y agoI evaluated both earlier in the year, and to me (spending the last 30 years developing software), Vue just seemed to fit my mindset better. I just couldn't "get" React, no matter how many times I tried. I guess it is just how my "programming mind" thinks about problems. I am sure developers who approach problems differently may enjoy React more, but for me, I guess I am a lot more old fashioned and 'structured' in the way I see things.
- santoriv 9y agoWhat I find most interesting in these results is the satisfaction percentage i.e. (Used it before and would use again) / (Used it before and would use again + Used before and would not use again). - In 2016: React - 91% satisfaction Vue - 91% satisfaction Angular 2 - 65% satisfaction No framework - 65% satisfaction Ember - 50% satisfaction Angular - 40% satisfaction Backbone - 31% satisfaction - In 2017: React - 93% satisfaction Vue - 91% satisfaction Angular 2 - 66% satisfaction No framework - 65% satisfaction Aurelia - 56% satisfaction Polymer - 53% satisfaction Ember - 41% satisfaction Angular - 33% satisfaction Backbone - 23% satisfaction It's especially interesting that many of the frameworks have a lower satisfaction percentage than using "no framework". Of course this could be largely attributed to who is using no framework. I have encountered a minority of developers (usually backend devs) who think front-end frameworks are nonsense and prefer to just write a bunch of jQuery. Also, if you are working on Wordpress sites, then frameworks are often not necessary. I've written production code in some of these frameworks (Backbone, Angular 1, Ember, and React) and I would have to say these results are more or less consistent with my experience. I love React and don't feel the need to try anything else.
- philliphaydon 9y agoAngular 2 I would like to never use again. It’s caused far more problems than it’s solved. It requires deep knowledge to build large applications or else it will suffer performance problems.
- jayflux 9y agoThat result doesn’t surprise me at all, not everyone is working on a huge project and most of those frameworks are overkill for small tasks, sometimes pure js (with the odd library here and there) is all you need.
- dvirsky 9y agoWhat I find odd/funny is that a significant chunk of people have "never heard" of using no framework. Either it's a mistake or there are that many people who've never just written some JS code.
- kumarvvr 9y agoI have spent quite a bit time into learning Angular (4/5). I am new to front-end dev, and found that the structured approach of Angular more appealing than React. Should I continue with Angular or move on to React? My goal is to create a data-driven website, with expressJS & PostgreSQL backend. Not very complicated, but not simple either.
- code_chimp 9y agoIMHO, keep on the path you are on until you are really comfortable with Angular, then learn React as well. I went the opposite direction - put up a large React/Redux codebase and now have moved on to a position that requires Angular. There is no harm in knowing more than one framework, I find that both will get the job done.
- kumarvvr 9y agoThanks. I am thinking in a similar way. I guess knowing concepts is more important than any framework / library in particular. I suppose Angular is more suited for me as it is semi-rigid in the way things have to be done. Complaints about TS eco-system are unfounded in my view as the basic building blocks for building any site, HTML templates, CSS (SASS/SCSS/LESS etc), client side scripting, etc are built in.
- homakov 9y agoI had trouble getting started with React but Vue was a breeze. Better for newbies imo.
- qdoop 9y agoWhich is faster? Vue; Which is more modular? Vue; Which is simpler to grasp and reason about? Vue; Build in CSS support? Vue; P.S. Vue contains React. You could in principle write your components React style.
- vitro 9y agoThe reason I am not even remotely considering React is the Facebook itself and what this company represents - exploiting people's minds and emotions to fulfill their business plan. I can't help it but if I would use react, I would not be able to get this feeling out of my mind, so if there is viable alternative - vue.js, I am definitely going that way. Something similar like using cosmetics that have been tested on animals, if I can choose, I choose something else. I know this should be more of a technical discussion, just I can't help but think of this aspect when it comes to React.
- guru4consulting 9y agoAny suggestion for the below use case? Whether to use Vue or React? - I develop APIs and plan to hire freelancers to do the web/mobile clients (so, higher availability of skills in the market is important to me) - I have a web designer developing the UI with just plain html/css. And this is going thru multiple iterations and the web-designer is able to make all the changes (cheaper because this is just a web-designer, not a programmer). - Once, the UI is finalized (and fully designed with html/css), I plan to hire a Javascript programmer to do the SPA front-end (so, being able to use existing plain html/css templates with minimal change is a big benefit). - I do not plan to create native mobile client, just a hybrid app based on webkit. If the web app was developed with React, then will it benefit the mobile clients to be developed with React Native? or, does it matter at all? If Vue.js was used for SPA webapp, what do the Vue programmers use for mobile client? I assume React guys might naturally use React Native.