Switching From React To Vue.js(vuejsdevelopers.com)
vuejsdevelopers.com
Switching From React To Vue.js
http://vuejsdevelopers.com/2017/05/28/switch-from-react-to-vue-js/
185 comments
Vue is backed by one of the biggest companies in China. You need to do more research. Vue is more popular in China than React. I would say I would rather start a new an app using Vue because of the learning curve is a lot faster to pick up than React.
A non-trivial amount of info and discussion around Vue (esp. third-party packages) is in Chinese. Whether that's a plus or a minus depends on whether you understand the language.
I have started to use museUI. A material UI library based on vuejs. It is also mostly in Chinese. I was reluctant initially but made the jump.
Then one day I had an issue. Posted it. Interestingly some other guy posted a PR to solve that. And it got merged the next day. So it ended well for me. But can't say that for other repos. Just my experience.
Then one day I had an issue. Posted it. Interestingly some other guy posted a PR to solve that. And it got merged the next day. So it ended well for me. But can't say that for other repos. Just my experience.
That's for sure a minus, even if you speak the language. You are restricted to a smaller subset of developers that can improve the ecosystem (and let's be frank that most good developers should know English but not Chinese, internationally speaking).
The logic may not be sound as you cannot tell for sure if there are more English speaking front end developers or Chinese-only speaking ones, given the population of China.
There could roughly be as many front end developers in India ... which has 23 languages.
China also has multiple languages and dialects, see: https://en.wikipedia.org/wiki/Languages_of_China#/media/File...
English is the lingua franca of software development and I don't see that changing anytime soon.
China also has multiple languages and dialects, see: https://en.wikipedia.org/wiki/Languages_of_China#/media/File...
English is the lingua franca of software development and I don't see that changing anytime soon.
Too many VueJS repos I see on Github have Chinese only readme
> I would say I would rather start a new an app using Vue because of the learning curve is a lot faster to pick up than React.
When we're talking frameworks that you'll use again and again I don't really think this is a factor. You'll only need to pick it up once. I'm a lot more concerned about long term maintainability.
When we're talking frameworks that you'll use again and again I don't really think this is a factor. You'll only need to pick it up once. I'm a lot more concerned about long term maintainability.
If we move away from only spa appications vue has other use cases. For a Rails / PHP site that only needs small amount of javascript vue feels like a natural choice to replace some of the existing jquery
Isn't the same true of React however?
It's not the same. VueJS's documentation to add to an existing non-es6 jQuery based project is ahead of react's, and vuejs is a lot smaller.
I read through the differences, and they seem small enough that for any decently sized project with a non-trivial team you'd choose React and in most cases probably not even consider Vue.
>In a year or two I predict that I will see another article with a title along the lines of "Switching From React To <insert new hotness here>". It is very unlikely in my opinion that I will see a "Switching From Vue To <insert new hotness here>" article.
That might also be because once people get to Vue, they don't leave it for any "new hotness".
That might also be because once people get to Vue, they don't leave it for any "new hotness".
Nah, today's hotness is tomorrow's tech debt. Always.
In JS maybe. But I don't think there's anything fatalistic about it. There are still C, C++, Lisp, even Pascal etc codebases maintained and liked just fine.
It's about maturity and churn, not something inherent in programming.
It's about maturity and churn, not something inherent in programming.
I have (some) experience with both React and Vue 2 and definitely prefer the later. Vue is very minimalistic but unlike React provides a lot of functionality out of the box. Stuff like the router, the computed properties, automatic change detection, HTML templates, scoped css, animations, ... . But what's more important is the fact it does all these things in an extremely elegant and unobtrusive way. The computed properties are an often overlooked but good example of this. You simply declare an object property that is dependent upon other properties and voila, that's it. It's there in your component together with the rest of your data for you to use in your template. It gets memoized, it gets change detection, it just works (TM). No need for Redux, Reselect, selector functions or any of those things. I love the simplicity of this approach. And this is just an example, but this very minimalistic approach applies to everything that Vue offers.
> unlike React provides a lot of functionality out of the box. Stuff like the router, the computed properties, automatic change detection,
I never studied Vue, but the article starts saying "Both have separate, but commonly used, router and state management libraries". This doesn't look like "out of the box" to me.
I never studied Vue, but the article starts saying "Both have separate, but commonly used, router and state management libraries". This doesn't look like "out of the box" to me.
https://vuejs.org/v2/guide/routing.html
For most Single Page Applications, it’s recommended to use the officially-supported vue-router library. For more details, see vue-router’s documentation.
https://github.com/vuejs/vue-router
--
https://vuejs.org/v2/guide/state-management.html
Vue offers vuex: our own Elm-inspired state management library.
https://github.com/vuejs/vuex
--
Out of the box or not, they're part of the same github org, they're officially supported and they're documented in the official docs. I think this is just splitting hairs.
For most Single Page Applications, it’s recommended to use the officially-supported vue-router library. For more details, see vue-router’s documentation.
https://github.com/vuejs/vue-router
--
https://vuejs.org/v2/guide/state-management.html
Vue offers vuex: our own Elm-inspired state management library.
https://github.com/vuejs/vuex
--
Out of the box or not, they're part of the same github org, they're officially supported and they're documented in the official docs. I think this is just splitting hairs.
Redux has been from the same github org for a very long time too: https://github.com/reactjs/redux
And react-router, while not being on the same github, is pretty much considered a standard too. It's ok to not split hairs for vue.js, but then you shouldn't do the same for react...
And react-router, while not being on the same github, is pretty much considered a standard too. It's ok to not split hairs for vue.js, but then you shouldn't do the same for react...
react-router, do you mean v1, v2, v3, or v4 (or perhaps v5 and v6, I haven't checked if there was a new release with breaking API changes during the past 12 hours).
Why downvote? Anyone sane can't seriously be thingking of using react-router in anything non throw away - the library gets rewritten from scratch every year and doesn't provide any backwards compatibility or migration paths.
You might as well just write your own react-router implementation for every react project you work on.
You might as well just write your own react-router implementation for every react project you work on.
Agreed. I need to switch from react-router. I think they are now making major changes for no good reason.
I mean react-router is almost a 3 year old library trying to handle a rather complex problem. The first three versions were largely the same with no major changes that I can think of except for switching from context to higher order functions.
I think everyone is a little dramatic about the number of versions of the library, especially when they are going to continue to support v3.
I think everyone is a little dramatic about the number of versions of the library, especially when they are going to continue to support v3.
Well, that just makes things even worse - now you have to choose which version to use, which is just proving the OPs point.
If you don't like having to choose which version of react-router to choose, you probably should be using a preset like create-react-app which makes this kind of decision for you. Or you should use something other than React which includes everything and the kitchen sink.
Exactly! (snark aside)
This doesn't really make sense to me. You have to pick a version for literally every single library you use. And those different versions have different interfaces, which is why they have different versions...
Routing is not very complex.
[deleted]
I'm not a fan of React Router but this sounds like you haven't actually used any of those versions or even looked at the breaking changes.
Here's what actually happened:
v1: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v2: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v3 mostly just removed APIs that were deprecated in v2. v3 continues being maintained even beyond the v4.0.0 release.
v4: https://github.com/ReactTraining/react-router/blob/master/pa...
In my opinion it would have been clearer if react-router v4 had been released under a different name but I guess the authors didn't want to pay the cost of that.
The API changes between 1 and 2 as well as 2 and 3 are mostly cosmetic. It's worth pointing out the authors released codemods which will likely be able to convert your app from one version of the library to the next as long as you don't do something exceptionally clever.
The changes between 0.x and v1 were entirely expected. It seems the authors followed the common semantics that 0.x releases are considered experimental, v1 was based on the lessons learned. v2 and v3 then improved upon that design with relatively minor changes.
On the other hand v4 is an entirely new library using an entirely different paradigm: routes use component semantics and are part of the component structure, rather than just some JS router that uses JSX syntax for aesthetics.
But as I said: v3 is still being actively maintained, the authors have just decided that the v4 API fits React better. And for all major releases from v1 to v3 you should be able to upgrade practically for free by using codemods.
I think the importance of codemods can not be understated though many people are still ignorant of them: Facebook releases codemods for every major version of React and uses them internally to upgrade their tens of thousands of components automatically. Third-party libraries like React Router have also started providing them.
Codemods written well should allow app developers to migrate breaking API changes in dependencies with practically no development effort.
Additionally, like React, React Router seems to have adopted the approach of deprecating APIs in the final release of a major version that is no longer going to be supported so you can upgrade your manually code before moving to the new major version with no fear of things breaking. So when upgrading from v2 to v3 you should be able to upgrade safely by simply upgrading to the latest minor version and fixing any deprecation warnings.
Both codemods as well as deprecations of course assume you're doing the sensible thing and a) upgrading one major version at a time and b) actually maintaining your project rather than just spending half an hour on it once a year to implement a new feature with no test coverage.
Personally I often end up doing the not so sensible thing where I end up having to migrate all third party deps to the latest version once a year or two, but libraries like React and React Router are the least of my worries because they are extremely safe and easy to upgrade -- even to the point where there's no need to upgrade beyond React Router v3 unless you also prefer the v4 API.
Here's what actually happened:
v1: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v2: https://github.com/ReactTraining/react-router/blob/v3/upgrad...
v3 mostly just removed APIs that were deprecated in v2. v3 continues being maintained even beyond the v4.0.0 release.
v4: https://github.com/ReactTraining/react-router/blob/master/pa...
In my opinion it would have been clearer if react-router v4 had been released under a different name but I guess the authors didn't want to pay the cost of that.
The API changes between 1 and 2 as well as 2 and 3 are mostly cosmetic. It's worth pointing out the authors released codemods which will likely be able to convert your app from one version of the library to the next as long as you don't do something exceptionally clever.
The changes between 0.x and v1 were entirely expected. It seems the authors followed the common semantics that 0.x releases are considered experimental, v1 was based on the lessons learned. v2 and v3 then improved upon that design with relatively minor changes.
On the other hand v4 is an entirely new library using an entirely different paradigm: routes use component semantics and are part of the component structure, rather than just some JS router that uses JSX syntax for aesthetics.
But as I said: v3 is still being actively maintained, the authors have just decided that the v4 API fits React better. And for all major releases from v1 to v3 you should be able to upgrade practically for free by using codemods.
I think the importance of codemods can not be understated though many people are still ignorant of them: Facebook releases codemods for every major version of React and uses them internally to upgrade their tens of thousands of components automatically. Third-party libraries like React Router have also started providing them.
Codemods written well should allow app developers to migrate breaking API changes in dependencies with practically no development effort.
Additionally, like React, React Router seems to have adopted the approach of deprecating APIs in the final release of a major version that is no longer going to be supported so you can upgrade your manually code before moving to the new major version with no fear of things breaking. So when upgrading from v2 to v3 you should be able to upgrade safely by simply upgrading to the latest minor version and fixing any deprecation warnings.
Both codemods as well as deprecations of course assume you're doing the sensible thing and a) upgrading one major version at a time and b) actually maintaining your project rather than just spending half an hour on it once a year to implement a new feature with no test coverage.
Personally I often end up doing the not so sensible thing where I end up having to migrate all third party deps to the latest version once a year or two, but libraries like React and React Router are the least of my worries because they are extremely safe and easy to upgrade -- even to the point where there's no need to upgrade beyond React Router v3 unless you also prefer the v4 API.
To clarify: the ReactJS org is solely a community organization for some commonly used packages. It's not an official Facebook+React thing, even though both Dan Abramov and Andrew Clark, creators of Redux, are now actually on the React team.
(I'm one of the current maintainers of Redux.)
(I'm one of the current maintainers of Redux.)
react-router is one of the worst evolved software proects I've seen which keeps destroying it's knowledge base with every release with almost everything indexable on the web out of date with the latest version. It's also not as intuitive to use as vue-router (which just worked OOB) and it's root page handling behaves differently to the Routers in Angular, Aurelia and Vue.
It feels like you're incurring tech debt by depending on React Router but unfortunately since it's the defacto standard there's very few other viable options.
By contrast Vue feels like they care about their ecosystem and existing Customer code bases and will publish nice migration guides when they make breaking changes showing how old functionality can be migrated to their new APIs.
It feels like you're incurring tech debt by depending on React Router but unfortunately since it's the defacto standard there's very few other viable options.
By contrast Vue feels like they care about their ecosystem and existing Customer code bases and will publish nice migration guides when they make breaking changes showing how old functionality can be migrated to their new APIs.
> By contrast Vue feels like they care about their ecosystem and existing Customer code bases and will publish nice migration guides when they make breaking changes showing how old functionality can be migrated to their new APIs.
There are migration guides for v0.13.x->v1, v1->v2 and v3->v4 right in the docs of react-router. How is this a contrast?
There are migration guides for v0.13.x->v1, v1->v2 and v3->v4 right in the docs of react-router. How is this a contrast?
>And react-router, while not being on the same github, is pretty much considered a standard too.
The kind of standard that just doesn't stop giving backwards incompatible BS releases...
The kind of standard that just doesn't stop giving backwards incompatible BS releases...
The official Vue docs? The ones where half of the useful stuff is either missing, incomplete, or doesn't work because it's information for a deprecated version?
Vue has a lot of things going for it. Documentation is not one of them.
Vue has a lot of things going for it. Documentation is not one of them.
Vue is widely praised for its official documentation, often pointed as one of things differing it from React. But if you have other experience, I'd kindly asked you to mention the places you remember were wrong, so that I can submit a PR for them.
Vue is being specifically designed to work as small composable modules. That is a good thing. You get a bunch of boxes you can mix and match as you wish.
In separate repos, yes, but unlike React both the Router and Store are official.
When using Vue CLI it configures a project for you with vue-router and vuex.
When using Vue CLI it configures a project for you with vue-router and vuex.
Coming from a small-team Rails background, I tried React for a few months, then tried Vue. I found with React I felt compelled to replace and relearn large parts of my stack, and the learning curve as a result was very steep.
In comparison adding Vue components to an existing Rails app was dead simple, and I even got to keep writing my Vue templates in HAML. All the questions I had were easily answered by the Vue documentation without even going to e.g. stackoverflow. Vue was the clear winner for me here.
Things you're sacrificing when going away from React:
1. Stability. FB uses it for their main product, which is probably the biggest web app of them all, they pay many devs to work fulltime on it. People coming from Angular, who had to migrate all those breaking changes over the years know the struggle.
2. Options like React-Native, React-VR and co. React enables your devs to acquire a whole new range of possibilities. It isn't just a web framework.
1. Stability. FB uses it for their main product, which is probably the biggest web app of them all, they pay many devs to work fulltime on it. People coming from Angular, who had to migrate all those breaking changes over the years know the struggle.
2. Options like React-Native, React-VR and co. React enables your devs to acquire a whole new range of possibilities. It isn't just a web framework.
I don't consider the fact that a large company uses something for their main product is enough to actually make it future-proof.
Previous instances of that pattern:
- three20 (used in FB ios app https://en.wikipedia.org/wiki/Three20)
- GWT
- Angular is actually a similar instance of that problem, to some extent
If "large company" switches their goal at some point, then you're still alone.
Currently I'm kind of more confident (in some way) to the future stability of Vue, than of React (just a gut feeling, time will tell!).
Previous instances of that pattern:
- three20 (used in FB ios app https://en.wikipedia.org/wiki/Three20)
- GWT
- Angular is actually a similar instance of that problem, to some extent
If "large company" switches their goal at some point, then you're still alone.
Currently I'm kind of more confident (in some way) to the future stability of Vue, than of React (just a gut feeling, time will tell!).
GWT was first released 11 years ago, the most recent update was less than a month ago. If that's not an example of future-proof (for web technologies) I don't know what is.
Whether it's kept up with the state of the art I don't know, but I think that's a different thing.
Whether it's kept up with the state of the art I don't know, but I think that's a different thing.
I was referring to http://www.gwtproject.org/release-notes.html - e.g. the release hole that happened between 2.7.0 and 2.8.0 (2 years). Some clients actually decided to stop using GWT at that time, because of that.
Three20 was made obsolete by the useful parts of it getting built into the platform SDK, and yet it was still maintained and kept in a working state for longer than it was ever actually useful.
I know that - but the fact is that for one client of mine, the app was initially build on three20, then they had to literally rebuild it from scratch as they realised that three20 was becoming obsolete.
One of the reasons for the choice was the FB branding associated as something that can be trusted!
One of the reasons for the choice was the FB branding associated as something that can be trusted!
Absolutely. Look at google for instance and all the things they've stopped supporting.
I find the argument also quite disturbing because this will add to the already existing monopolies of these "large companies".
I find the argument also quite disturbing because this will add to the already existing monopolies of these "large companies".
Just because Facebook is big and supports something isn't necessarily a good thing. Their goals, resources and accepted trade-offs aren't likely the same as your own. For a large company like Facebook, handling large changes to a library aren't a concern because they have essentially limitless development resources. For small operations like mine (and maybe yours) these breaking changes can reduce the time you spend actually improving your product significantly.
For me, the instability and unopinionated nature of the group of technologies that loosely define "React" have been a real turn off. When answers to questions like "What language should you program in?", "How should you store your data?" and "How should I handle routing between pages?" all have no specific answer, it leads to a fragmentation of knowledge that in my past experience usually leads to a technology's demise.
For me, the instability and unopinionated nature of the group of technologies that loosely define "React" have been a real turn off. When answers to questions like "What language should you program in?", "How should you store your data?" and "How should I handle routing between pages?" all have no specific answer, it leads to a fragmentation of knowledge that in my past experience usually leads to a technology's demise.
React has some of the best migration policies I've seen. They give plenty of notice about upcoming breaking changes, including messages with pointers output by the library in development mode when code is used in a deprecated way. As well, since there are so many people using React, you can nearly always find a solution to a even obscure problems.
I agree about the un-opinionated nature, though the resulting flexibility has led to some good options, they can be complicated to choose and wire together.
I agree about the un-opinionated nature, though the resulting flexibility has led to some good options, they can be complicated to choose and wire together.
Just because Facebook is big and supports something isn't necessarily a good thing
Not in hobbyspace. But in Deliver-a-Product World, it matters a lot.
Not in hobbyspace. But in Deliver-a-Product World, it matters a lot.
Options like React-Native
It's difficult to convert a React web app into a React Native app, but you can use many React Native components on the web (via react-native-web. [1]) In other words, you can't run a web app on mobile, but you can run a mobile app on the web.
I just launched a little game that I built with React Native [2], where I have a single codebase that supports iOS, Android, Windows, and web.
[1] https://github.com/necolas/react-native-web
[2] https://sudoblock.com
I just launched a little game that I built with React Native [2], where I have a single codebase that supports iOS, Android, Windows, and web.
[1] https://github.com/necolas/react-native-web
[2] https://sudoblock.com
It's less about code reuse across a full featured web application and a mobile application. The value comes in that once you master React or React Native, you can easily switch across platforms and be just as efficient. If you learn the ins and outs of Vue and gain depth of best practices / domain knowledge, you are stuck building only for the web.
If you do the same with React, you are then able to take those skills and build VR, Web, iOS, Android, Windows, and soon TVOS ++ many more in the future.
This, along with what has already been stated, is the value of using React vs Vue imo.
If you do the same with React, you are then able to take those skills and build VR, Web, iOS, Android, Windows, and soon TVOS ++ many more in the future.
This, along with what has already been stated, is the value of using React vs Vue imo.
I don't see an issue of learning Vue and not being able to write native apps for iOS and Android as a valid one.
Weex quickly gets better and is maintained by Alibaba, a company of the same scale and with development resources comparable to Facebook or Google. NativeScript recently started work on Vue port, the project is already available for testing. That's excluding the Cordova solutions like Onsen and Framework 7 having official Vue ports.
To that, PWA slowly becomes the new trend for mobile development, native apps are not necessarily the optimal solution to every use case.
The "++ many more in the future" is an optimistic assumption. As much as I wish it to be fulfilled, same can be said about any other framework.
Weex quickly gets better and is maintained by Alibaba, a company of the same scale and with development resources comparable to Facebook or Google. NativeScript recently started work on Vue port, the project is already available for testing. That's excluding the Cordova solutions like Onsen and Framework 7 having official Vue ports.
To that, PWA slowly becomes the new trend for mobile development, native apps are not necessarily the optimal solution to every use case.
The "++ many more in the future" is an optimistic assumption. As much as I wish it to be fulfilled, same can be said about any other framework.
the hearsay is that if you used only components that are available for both, it'd take very little extra boiler plate to get it working on both native and web. But all non-trivial apps have their own components and that's what makes native difficult.
This really isn't the case. I have built apps with lots of code reuse on native and web.
Abstract all data logic and you can use the exact same code for both apps. This of course does not include your view layer. If you do it correctly, all you have to do is make a new set of view components. Stateless ones. Because you are injecting the state from your non platform specific components.
It makes it extremely fast to build for other platforms. It just takes a few apps to fully understand how to abstract these things perfectly.
Abstract all data logic and you can use the exact same code for both apps. This of course does not include your view layer. If you do it correctly, all you have to do is make a new set of view components. Stateless ones. Because you are injecting the state from your non platform specific components.
It makes it extremely fast to build for other platforms. It just takes a few apps to fully understand how to abstract these things perfectly.
This is not really true, the react-native-web project provides compatibility for all of the fundamental components that you need, such as View, Image, ScrollView, TouchableOpacity, etc.
There are still some missing components [1], but nothing I really needed (or couldn't work around).
[1] https://github.com/necolas/react-native-web/issues/91
There are still some missing components [1], but nothing I really needed (or couldn't work around).
[1] https://github.com/necolas/react-native-web/issues/91
I'm a freelancer, so I do different projects. Web, Mobile, etc.
Now I can do them all with one framework.
Now I can do them all with one framework.
If you stick to using `react-native-web` components to design your web UI then your app is likely compatible with React Native and can be run as a mobile app in addition to deployed as a web site.
Do you remember when the first iPhone was released and one of its main marketing points was that it could browse the REAL web? ... Nowadays we are crippling the real web (or at least it's design) so we can have a version for small screens. Oh the irony :(
[deleted]
1. Vue has been pretty stable, and Angular has learned from its previous mistakes. Also, remember Parse.
2. There is NativeScript which supports Angular 2+ and shortly Vue, and Weex build by Alibaba on top of Vue.
2. There is NativeScript which supports Angular 2+ and shortly Vue, and Weex build by Alibaba on top of Vue.
Its what they use right now, who knows what is coming down the pipeline?
Nobody. But the fact that they use it now makes it less likely to be abandoned by them that something they don't use (which, while they can't abandon, they haven't adopted either).
Besides in 10 years the whole of IT changes. Don't look for "50 year frameworks".
Besides in 10 years the whole of IT changes. Don't look for "50 year frameworks".
I honestly don't know, but using it 1. for their main product 2. for many different products in general and 3. rewriting most it (v16) to be more future proof without public API changes sounds like a pretty save bet.
Working with React for almost 3 years now. Came from Angular, Bootstrap, jQuery, etc.. Done small and very large projects with it. It scales better than anything I've used before. It's amazingly reliable and robust.
Looking at Vue I cannot think of 1 single benefit I gain by switching. It doesn't even come close to what React is capable of imao. I really have no clue why people are pushing this at all.. Are there any examples of large projects that switched from React to Vue without suffering a loss?
Looking at Vue I cannot think of 1 single benefit I gain by switching. It doesn't even come close to what React is capable of imao. I really have no clue why people are pushing this at all.. Are there any examples of large projects that switched from React to Vue without suffering a loss?
Vue has electrolytes and it is gluten free. Seriously though I think Vue is the latest shiny example of everything that is wrong with the javascript community.
Javascripts huge problem is the lack of a standard library or better yet a standard way of doing anything. To fill that void alone came NPM. With a million tiny fragmented micro libraries. Then it became a common to start reinventing the wheel and selling your idea to build up your community by claiming the trivial syntax changes make it so much easier to use. I like you have no clue why people are getting so excited about rewriting their apps all the time.
I think of Vue like attempting to reinvent the calculus of react with a clever syntax and more simplified form but results in a Riemann approximation.
I think Vue is more frontend focused where react is achieving far more like react fiber. I do not doubt the power of js community to keep cloning things into forms they are more familiar with and claim a smaller payload is best metric of success.
Who would have thought so much open source collaboration would lead to so much fragmentation?
I wonder what machine learning algos will come up with when they design their own programming language, because I think programming languages are being held back by discussing what syntax makes me feel good to type out.
Javascripts huge problem is the lack of a standard library or better yet a standard way of doing anything. To fill that void alone came NPM. With a million tiny fragmented micro libraries. Then it became a common to start reinventing the wheel and selling your idea to build up your community by claiming the trivial syntax changes make it so much easier to use. I like you have no clue why people are getting so excited about rewriting their apps all the time.
I think of Vue like attempting to reinvent the calculus of react with a clever syntax and more simplified form but results in a Riemann approximation.
I think Vue is more frontend focused where react is achieving far more like react fiber. I do not doubt the power of js community to keep cloning things into forms they are more familiar with and claim a smaller payload is best metric of success.
Who would have thought so much open source collaboration would lead to so much fragmentation?
I wonder what machine learning algos will come up with when they design their own programming language, because I think programming languages are being held back by discussing what syntax makes me feel good to type out.
The problem is that people assume that old = bad.
As soon as one technology is starting to have a nice big community and enough ressources to be usable, the hype for something new destroys it.
People could use Angular 2 Years ago just fine, what on earth happened that it suddenly became so terrible?
Also those are just frontend frameworks! Why is everyone glorifying those??? Is Backend an after thought nowadays? "We got nodeJS... The frontend guy know JS. He will code something, don't worry."
People could use Angular 2 Years ago just fine, what on earth happened that it suddenly became so terrible?
Also those are just frontend frameworks! Why is everyone glorifying those??? Is Backend an after thought nowadays? "We got nodeJS... The frontend guy know JS. He will code something, don't worry."
I switched a reasonably large project and there were many gains with no loss. They've all been said before by me and other people, including in this thread. If you don't see them it's because you don't want to.
[deleted]
They switch because it lets you do things the old, incorrect way.
Like using jquery. People want what they don't have to spend time learning. They're used to templates with handlebars. Used to mutating variables. That's why I think so many jquery people and those touting "you don't need jsx or babel" use it.
Because it lets you be lazy and do things they way you're used to instead of better practices that have been found.
It's funny when I hear people act like its way too difficult to setup babel. I'm sorry, but if you're using any ES6 stuff (who doesn't use arrow functions) and you need to support older browsers (a real production app would). Then you're going to need babel and include some polyfills. Go ahead and use vue without all this "horrible babel pipeline" and don't use any language features that have been added in the past three years if that's really what you want.
Like using jquery. People want what they don't have to spend time learning. They're used to templates with handlebars. Used to mutating variables. That's why I think so many jquery people and those touting "you don't need jsx or babel" use it.
Because it lets you be lazy and do things they way you're used to instead of better practices that have been found.
It's funny when I hear people act like its way too difficult to setup babel. I'm sorry, but if you're using any ES6 stuff (who doesn't use arrow functions) and you need to support older browsers (a real production app would). Then you're going to need babel and include some polyfills. Go ahead and use vue without all this "horrible babel pipeline" and don't use any language features that have been added in the past three years if that's really what you want.
You probably shouldn't switch. They're both really good templating libraries. Vuejs is smaller an react has react native. The grass is green on both sides.
I think it's important for any comment or post touting the superiority of Vue to also provide insight into the author's experience with and feeings about React. You very rarely hear from devs who were loving React, tried Vue anyway, and came away believers. This leads me to wonder whether it's not so much that Vue is "better," it's more that it operates in paradigms that are intuitive to some individuals and teams in ways that React might not be. I don't see that as a hit against it or anyone but as a very satisfied React, it does make me take every glowing Vue writeup with a grain of salt.
They are pretty similar, though one thing this article lightly touches on is the standalone .vue file, which works absolutely beautifully. JSX feels like a hack to me, and the ability to write HTML, JS, and CSS as such in a single file greatly simplifies everything. You can even use different flavors of each (ES6, Sass, etc) no problem. I would be shocked if this feature doesn't find it's way into react, angular, and others.
Vue and React both seem a little too heavy in boilerplate. It's also interesting that Vue seems to think that mutable state is a good thing (well, vanilla React does have mutable state too...).
For the boilerplate (and large bundle size!) problem we have http://markojs.com that looks very interesting.
However, I think what we really might want is something closer to ClojureScript's re-frame (https://github.com/Day8/re-frame) and Reagent. However, Clojure and it's tools aren't really that great for beginners/juniors and/or people with little experience in FP and lisps.
Maybe in the near future we'll see a little bit more FP style JS solutions pop up?
For the boilerplate (and large bundle size!) problem we have http://markojs.com that looks very interesting.
However, I think what we really might want is something closer to ClojureScript's re-frame (https://github.com/Day8/re-frame) and Reagent. However, Clojure and it's tools aren't really that great for beginners/juniors and/or people with little experience in FP and lisps.
Maybe in the near future we'll see a little bit more FP style JS solutions pop up?
At the risk of sounding like a shill (I bring up Riot a lot), check out Riot.js. It's a bit rough around the edges in terms of docs/presentation, but it's by far the most minimalistic and most productive "react-like" ui lib I've used.
It's all very very expedient and you can pick it up in a day and be churning out advanced applications with very little mental load. It also supports in-browser compilation so you can get up and running instantly without having to set up Webpack/Browserify/Whatever, which is great for testing it out. Later on you can easily transition to using its offline compiler + whatever packager you want.
The main downside is the community is small. But it's very close to Vanilla JS so I've practically never encountered an issue where I needed riot-specific help.
It's all very very expedient and you can pick it up in a day and be churning out advanced applications with very little mental load. It also supports in-browser compilation so you can get up and running instantly without having to set up Webpack/Browserify/Whatever, which is great for testing it out. Later on you can easily transition to using its offline compiler + whatever packager you want.
The main downside is the community is small. But it's very close to Vanilla JS so I've practically never encountered an issue where I needed riot-specific help.
I've done some work on Riot actually!
If you like them, check out RE:DOM - the author of that one did some work on Riot too.
RE:DOM might be even more minimalistic and lightweight than Riot.
If you like them, check out RE:DOM - the author of that one did some work on Riot too.
RE:DOM might be even more minimalistic and lightweight than Riot.
marko looks good
Our company migrated to vue.js, 4 months ago. Our complex app is messy with JSX, router, and new dev can't keep up with code. Now we start every new app with Vue.js. The gap between junior dev and senior dev comes closer. They can collaborate with less bugs, less problems and less time to develop.
Is it because of the technology or because of the team?
Rhetorical question - I am by no means attacking you or your team, I just clicked on your "is messy with JSX, router" sentence and decided to put my reply under yours.
I see many people tackling React but not developing in a 'React' way. For example I recently saw on HN some user complaining that he had to create N functions to handle N items on a form, while computed properties would have done the trick with only one.
I have no experience with Vue but extensive with React, having developed both small and bigger apps and the only real issue for bigger apps was that it was hard for new users to grok the project initially because of the component-based approach of React.
I do agree that the learning curve for React is pretty steep, but you reap the benefits later on as React 'scales' extremely well in my opinion.
I see many people tackling React but not developing in a 'React' way. For example I recently saw on HN some user complaining that he had to create N functions to handle N items on a form, while computed properties would have done the trick with only one.
I have no experience with Vue but extensive with React, having developed both small and bigger apps and the only real issue for bigger apps was that it was hard for new users to grok the project initially because of the component-based approach of React.
I do agree that the learning curve for React is pretty steep, but you reap the benefits later on as React 'scales' extremely well in my opinion.
In case anyone reads this and is left wondering, there's no need to have n functions to handle n inputs - you only need one. A simple example would be to set the state based on `event.target.name`.
router and redux make it messy (or rather lack of standard of routing and global state management in react makes every one create their own half assed implementations)...
also transitioning web developers from writing giant HTML pages to thinking about smaller components is a difficult, without dedicated react designer.
All these make non trivial react apps a graveyard of crappy jsx and messy untyped tangles of JavaScript code.
also transitioning web developers from writing giant HTML pages to thinking about smaller components is a difficult, without dedicated react designer.
All these make non trivial react apps a graveyard of crappy jsx and messy untyped tangles of JavaScript code.
I'd be really surprised if the team you had producing this huge mess was all of a sudden producing super clean code in Vue. It sounds like a very inexperienced team. Probably would be worth investing in a senior developer or team lead to help guide these fresh devs.
> also transitioning web developers from writing giant HTML pages to thinking about smaller components is a difficult, without dedicated react designer.
Can you elaborate? I naturally gravitate towards separating code into components in a framework-agnostic sense - React was very intuitive to me and devs I've talked to seem to feel the same way. Writing huge atomic pieces of HTML is nothing but a huge headache; it's awful to maintain as it results in copious amounts of redundancy / tech debt.
Can you elaborate? I naturally gravitate towards separating code into components in a framework-agnostic sense - React was very intuitive to me and devs I've talked to seem to feel the same way. Writing huge atomic pieces of HTML is nothing but a huge headache; it's awful to maintain as it results in copious amounts of redundancy / tech debt.
perhaps I was being impatient observing a group of web developers and designers trying to jump into a large React project, practically with no prior experience in react (although familiar with Angularjs, html, css, js, dom) - however the fact is that after 3 months of dev, the react codebase turned into an absolute mess - albeit following best practices around branches, testing, pull request reviews, continuous delivery to staging environments etc...
The main issues seemed to do with global state management favored by Redux (hello global variables, I thought we were over you years ago :) ) and tendency to jam html into react components designed as screens, rather than components.
The main issues seemed to do with global state management favored by Redux (hello global variables, I thought we were over you years ago :) ) and tendency to jam html into react components designed as screens, rather than components.
I think the flux-wars made many codebases messy.
I have no doubt VueJS will be the most popular framework in a couple of years, right now the adoption rate is not as fast as it could be because people have already invested in React/Angular so switching so soon looks like a downside, but people just getting started and that have zero investment in any of the 3 frameworks will go for VueJS without a doubt, because is much more easy to learn and equally or even more powerful.
That was my case, I spent several years sticking to jQuery and waiting for the wave of "a new JS framework out every x months" was over, and after researching which framework to learn, VueJS was a clear winner.
The syntax is way more simple and elegant, and as soon as Weex is stable it will be able to power mobile apps too!
That was my case, I spent several years sticking to jQuery and waiting for the wave of "a new JS framework out every x months" was over, and after researching which framework to learn, VueJS was a clear winner.
The syntax is way more simple and elegant, and as soon as Weex is stable it will be able to power mobile apps too!
There is a bit of React kool-aid in here, makes me really wonder if any of them have actually tried using Vue because the benefits and improvements you will see with Vue are immediately noticed.
To be frank, the OP actually did a poor job of presenting Vue here because it only mentioned the similarities, which doesn't do any good for Vue. It did not get into areas where Vue is better than React, which is what most would be interested in hearing.
If you ever put React and Vue.js side by side and compare, it is almost a no brainer to switch. How it handles bindings, the way they got Redux done right, and the single file component style, are all improvements over React IMO. I'd jokingly say if React were to keep improving and evolving for the next couple years, it may possibly look like Vue.js as of today.
To be frank, the OP actually did a poor job of presenting Vue here because it only mentioned the similarities, which doesn't do any good for Vue. It did not get into areas where Vue is better than React, which is what most would be interested in hearing.
If you ever put React and Vue.js side by side and compare, it is almost a no brainer to switch. How it handles bindings, the way they got Redux done right, and the single file component style, are all improvements over React IMO. I'd jokingly say if React were to keep improving and evolving for the next couple years, it may possibly look like Vue.js as of today.
Interesting. I hadn't touched React in months and recently spent a week with Vue. I had trouble getting up and running and was soon longing for React, or at least what I remembered of it.
Look up nuxt.js. It is like react starter kit for Vue, comes with SSR and webpack configured, etc.
While Vue is awesome, Nuxt is quite horrible. Nuxt's developers have made some very weird design choices that you can't opt out of if you want to use it. For example, you have to define your routes by defining a directory structure[1], which means you have nonsense tree structures, no aliasing, etc. While they've provided an easy to start SSR solution, the rest of it is simply bad.
[1] https://nuxtjs.org/guide/routing/
[1] https://nuxtjs.org/guide/routing/
I'd love to see you elaborate. Your post is just Vue Kool aid.
Well, first, vue.js doesn't force you to use components. So you can just throw your data into the HTML page and see what happens. It's a huge win in the early phase of the project, as most of the time your page will change so much you will not see any reusable components before months. It's a real time saver, and let you refactor only the important parts in components later.
Secondly, you are not tied to JSX. While you can use JSX with Vue, it comes with a very simple and clean templating language that is much more natural to manipulate than mixing JS and a fake HTML.
What's more, you don't need webpack, not even babel to use Vue. You can actually drop the 30ko (gzip + minified) of the lib and create a decent projet as-is. Of course you can later setup a whole pipeline, with even server side rendering if you wish. But for a start, you can just use it as easily has you used to with jquery. Which means people comming to the project will be easy to train to: it takes one afternoon to comprehend react hello world. It's the time to understand the whole Vue lib.
Eventually the community is great : the doc is well written, the tooling is full of small details (such as .once.prevent or the dict classes) that makes your life easier and the API surface is kept small. Most third party tools adopt the same philosophy: pragmatic, useful, scale down then up.
Honestly after so much react, I'm happy I found Vue. It's just better. Doing training for both, I can also tell you that training for Vue is 2 orders of magnitude easier than react.
Vue is what react should have been really. But let's not blame react. The react dev created shoulders for the vue devs to stand one.
Secondly, you are not tied to JSX. While you can use JSX with Vue, it comes with a very simple and clean templating language that is much more natural to manipulate than mixing JS and a fake HTML.
What's more, you don't need webpack, not even babel to use Vue. You can actually drop the 30ko (gzip + minified) of the lib and create a decent projet as-is. Of course you can later setup a whole pipeline, with even server side rendering if you wish. But for a start, you can just use it as easily has you used to with jquery. Which means people comming to the project will be easy to train to: it takes one afternoon to comprehend react hello world. It's the time to understand the whole Vue lib.
Eventually the community is great : the doc is well written, the tooling is full of small details (such as .once.prevent or the dict classes) that makes your life easier and the API surface is kept small. Most third party tools adopt the same philosophy: pragmatic, useful, scale down then up.
Honestly after so much react, I'm happy I found Vue. It's just better. Doing training for both, I can also tell you that training for Vue is 2 orders of magnitude easier than react.
Vue is what react should have been really. But let's not blame react. The react dev created shoulders for the vue devs to stand one.
To help put this in perspective, how heavily did you use React before switching to Vue? How did you feel about it at the time, before you were aware of Vue?
I used react for one year, for the web, but not react native. I'll be honest: once I got fluent in react, I still didn't enjoy it.
Too much scrolling around, looking up the doc for every simple things, hard to integrate with legacy Python/Ruby/PHP frameworks, etc.
I went from jQuery then Angular 1, and was much less productive in React.
Also, introducing react to a new member in the team has always been dreadful.
All in all, I never benefited from the concurrency part. The performance yes, and the structure for the SPA. But the whole immutable constraint didn't pay off for me in the end, so I felt my stack was overkill.
Too much scrolling around, looking up the doc for every simple things, hard to integrate with legacy Python/Ruby/PHP frameworks, etc.
I went from jQuery then Angular 1, and was much less productive in React.
Also, introducing react to a new member in the team has always been dreadful.
All in all, I never benefited from the concurrency part. The performance yes, and the structure for the SPA. But the whole immutable constraint didn't pay off for me in the end, so I felt my stack was overkill.
Do people like Vue because it's more declarative than react? Is it mostly angular devs switching and getting the best of react but still having directives?
I like the control react gives me without the black box 'compiler' which seems like it makes a bunch more choices for you.
I'm probably biased, someone cmv?
I like the control react gives me without the black box 'compiler' which seems like it makes a bunch more choices for you.
I'm probably biased, someone cmv?
I hate directives. There is nothing you can do with them you can't do with just plain callbacks or putting React components inside another that renders its children. HTML templating directives are stupid too, I find myself looking up syntax references for angular even though I've used it for ages. (Think semicolons and magic variables like `$event` or `index` in *ngFor bindings – you don't need these unfortunate and necessary syntactic choices if you just use JSX.)
So yeah, Vue is probably slightly more declarative than react, at the usual cost of having to learn all the declarations. When I first looked at it, I saw the 'v-' prefix on HTML attributes and just stopped.
So yeah, Vue is probably slightly more declarative than react, at the usual cost of having to learn all the declarations. When I first looked at it, I saw the 'v-' prefix on HTML attributes and just stopped.
+1
debugging angular directive was a nightmare...
but things might be different with typescript checking on angular-directives...
(but ironically, react-typescript got props checking faster...)
(but ironically, react-typescript got props checking faster...)
I recently started forking the github package for atom which is built with react. I found it very confusing that render methods pass scope variables to controllers using directives. The number of times a variable gets passed back and forth from a JavaScript class to a template directive is just silly.
It's fairly straightforward to use JSX with Vue, FWIW. Everything gets compiled down to a render function like React.
I did ignored all the modern js frameworks for a long time, so for me Vue is jquery replacement, I like that you can use it in lightweight way and mix it into legacy apps.
The far biggest problem with Vue for me is the template language. Once you've used JSX you just don't go back to Angular style templates.
I'd say that this is a matter of personal taste. After having worked extensively with both, I still can't get used the JSX-way of doing interpolation or conditionals and find the infamous Angular style template easier to reason about and work with.
Having said that, you might be interested to know that there's an official Babel plugin that lets you write your Vue templates with JSX: https://github.com/vuejs/babel-plugin-transform-vue-jsx
Having said that, you might be interested to know that there's an official Babel plugin that lets you write your Vue templates with JSX: https://github.com/vuejs/babel-plugin-transform-vue-jsx
A couple notes:
(1) You can use JSX with Vue. https://vuejs.org/v2/guide/render-function.html#JSX
(2) By "Angular style templates" do you mean Vue's Single File Components? Because from my POV they're glorious, and the primary reason I'd be reluctant to use React instead of Vue.
(1) You can use JSX with Vue. https://vuejs.org/v2/guide/render-function.html#JSX
(2) By "Angular style templates" do you mean Vue's Single File Components? Because from my POV they're glorious, and the primary reason I'd be reluctant to use React instead of Vue.
Re #1: for both React and Vue, if you don't stick to the most common and standard methods for implementing functionality, you're going to cause yourself a lot of unnecessary pain. Everything around those ecosystems (documentation, debugging tools, libraries, etc) is designed for streamlining development for people who don't stray from the mainstream.
Thanks. I mean "v-" etc in HTML, which is like "ng-" in NG1.
Actually the opposite for me, and the original reason I went with Vue (tho after using it more I like a lot about it). I just do not get the appeal of JSX. Directives are meh, but I still prefer it to JSX.
Do you think that your preference is just from your previous experience? JSX feels like uninhibited templating to me, which is great when it is done right (and a little crazy when done poorly). I also feel like it gives cleaner error messages.
Vue (+ ESLint) give pretty clear errors when you've messed up that make it quick to fix.
But yea, I mean I think it's subjective for most people. I'm not sure there's any real reason to go one or the other outside of developer happiness (could be wrong, though). A big part of Vue is to have a low learning curve and be less opinionated. So it feels more like enhancing your workflow (either in existing apps or new ones) than adopting a whole new way of doing things. I'm just personally more into that.
Also, for what it's worth, you can use JSX with Vue. The only downside I can think of is any time you have a problem it might be hard to find solutions since most people stick to directives. If you already know JSX, though, that might not be an issue.
But yea, I mean I think it's subjective for most people. I'm not sure there's any real reason to go one or the other outside of developer happiness (could be wrong, though). A big part of Vue is to have a low learning curve and be less opinionated. So it feels more like enhancing your workflow (either in existing apps or new ones) than adopting a whole new way of doing things. I'm just personally more into that.
Also, for what it's worth, you can use JSX with Vue. The only downside I can think of is any time you have a problem it might be hard to find solutions since most people stick to directives. If you already know JSX, though, that might not be an issue.
At our company we built single-page apps using Vuejs. It's very simple to pick up and easy to merge with existing templates and code (as it looks and feels a lot like standard HTML).
it takes less than a day for a dev to be up and running with Vuejs, where React is a bit more tedious to get started with.
it takes less than a day for a dev to be up and running with Vuejs, where React is a bit more tedious to get started with.
The major problem with this tutorial is that it doesn't cover single file components (https://vuejs.org/v2/guide/single-file-components.html) at all, which are superior to (and preferred to) implementing string based render functions (which rely on a runtime template compiler). Indeed, the Vue NPM package doesn't even provide the runtime template compiler by default. Stuff like what the article promotes are great for development if you just want to include a <script> file, but are clunkier than the way that you're actually supposed to do things.
> The major problem
I did not see it as a problem. I appreciated the light weight approach being shown first. In fact, for my use case, I prefer not to bring in the ecosystem. That could change, and the article introduces the heavier approach.
> the way that you're actually supposed to do things
The one message that comes out of the Vue camp and happy users is that Vue can fit many project types - small to large. Not having to always use single file components is the pragmatic part of that inclusionary message.
I did not see it as a problem. I appreciated the light weight approach being shown first. In fact, for my use case, I prefer not to bring in the ecosystem. That could change, and the article introduces the heavier approach.
> the way that you're actually supposed to do things
The one message that comes out of the Vue camp and happy users is that Vue can fit many project types - small to large. Not having to always use single file components is the pragmatic part of that inclusionary message.
That approach is actually heavier - the template compiler needs to be distributed (extra 15kb gzipped) and templates need to be rendered at runtime.
Turns out it's mentioned lower down, but the focus of the article is still on Vue.component, which really shouldn't be the case.
I've never used Vue, and in many ways am the target audience of this post. From my perspective, I think he took the right approach. Starting right off with a .vue file would be pretty alien to newcomers.
I remember a couple of years ago when people were posting about switching from Angular to React. Now it's React to Vue. I'm going to be honest and concede that Vue may well be better than React. But having used React productively for a couple of years now, I don't really see much point in throwing out something that works well in favour of something else that also works well. Back when it was "why we switched from Angular to React", it was easy to understand because Angular 1 is awful. But React isn't awful at all and I don't really see what I'm going to gain by switching to Vue.
What are good examples of popular websites (not behind a login) that make use of Vue or React?
I ask because I keep reading about it, all programmers seem to use it, but I just don't come across websites that use it. Is it only used for backend dashboards? Or do all Vue/React sites fail to gain traction for some reason?
I ask because I keep reading about it, all programmers seem to use it, but I just don't come across websites that use it. Is it only used for backend dashboards? Or do all Vue/React sites fail to gain traction for some reason?
Mobile Twitter uses React. https://mobile.twitter.com/facebook
Airbnb uses React https://www.airbnb.com.au/rooms/432044
Facebook, Facebook Messenger, Instagram, Netflix, Reddit Mobile, new Reddit Profile pages are all high profile sites using React that aren't just 'backend dashboards'.
Airbnb uses React https://www.airbnb.com.au/rooms/432044
Facebook, Facebook Messenger, Instagram, Netflix, Reddit Mobile, new Reddit Profile pages are all high profile sites using React that aren't just 'backend dashboards'.
Interesting. The ones not behind a login (Twitter,AirBnB,Reddit Mobile) are sites that feel laggy and clunky to me. With slow loading content, loading animations, laggy scrolling, too much stuff opening in new tabs, confusing interfaces.
I wonder if React causes/incentivises this or if it's design decisions by the coders/designers/managers.
In contrast, pages like Reddit Desktop, Google and Amazon work much better for me.
I wonder if React causes/incentivises this or if it's design decisions by the coders/designers/managers.
In contrast, pages like Reddit Desktop, Google and Amazon work much better for me.
I don't contest that those sites feel laggy and clunky, whether by poor load time, poor UX/UI, or some larger dysfunction.
However, I would offer that the usage of React is not so much the cause of poor performance but rather a step taken to remedy scale lag. Large apps like the one you mention are big behemoths that take months to adopt new architectures and patterns, but those activities are required to ensure the scalability of the infrastructure and product development. During the time those apps are not fully transitioned to React (and Redux, and isomorphic rendering, and a fully-featured API, and webpack, and a litany of other tools), they might feel half-baked or sluggish, because you may have a page loaded with server-side template rendering, but half of your components on the page are upgraded to React, and take a second to initialize.
IMO, React is a tool that provides an appropriately rigorous rubric for component development and a structure for large-scale interplay of reusable/composable frontend components, which was required for it to have any viability for a large org like Facebook. A lot of web apps are on the long trek to avail that potential fully, but while they're in transition, the experience of those apps will be a little disjointed or degraded.
However, I would offer that the usage of React is not so much the cause of poor performance but rather a step taken to remedy scale lag. Large apps like the one you mention are big behemoths that take months to adopt new architectures and patterns, but those activities are required to ensure the scalability of the infrastructure and product development. During the time those apps are not fully transitioned to React (and Redux, and isomorphic rendering, and a fully-featured API, and webpack, and a litany of other tools), they might feel half-baked or sluggish, because you may have a page loaded with server-side template rendering, but half of your components on the page are upgraded to React, and take a second to initialize.
IMO, React is a tool that provides an appropriately rigorous rubric for component development and a structure for large-scale interplay of reusable/composable frontend components, which was required for it to have any viability for a large org like Facebook. A lot of web apps are on the long trek to avail that potential fully, but while they're in transition, the experience of those apps will be a little disjointed or degraded.
Big web properties like these tend to be developed by huge teams and tend to prioritize features over performance.
It's partly Conway's law and partly the result of having lots of users and features being easier to add than take away.
None of these things really have much to do with React. If your app was going to be slow anyway, React won't help you. However, like Angular, React makes it easier to break things down into components and work on them separately, so it's popular with the same big teams that make bulky and slow web pages, just like Angular was before it. Correlation, not causation.
Unlike Angular, React is also fantastic for small teams making lean pages that load blazing fast, which is why it's become so popular so quickly.
It's partly Conway's law and partly the result of having lots of users and features being easier to add than take away.
None of these things really have much to do with React. If your app was going to be slow anyway, React won't help you. However, like Angular, React makes it easier to break things down into components and work on them separately, so it's popular with the same big teams that make bulky and slow web pages, just like Angular was before it. Correlation, not causation.
Unlike Angular, React is also fantastic for small teams making lean pages that load blazing fast, which is why it's become so popular so quickly.
Twitter loads pretty well IMHO http://gfycat.com/SkinnyBlueCrane over a 4G connection.
The new Reddit profile pages do not.
JS libraries (like React) are just tools developers have. They can make fast sites with them, and they can make slow sites with them. We use React because it makes it easier to optimise our site to make it load very fast.
The new Reddit profile pages do not.
JS libraries (like React) are just tools developers have. They can make fast sites with them, and they can make slow sites with them. We use React because it makes it easier to optimise our site to make it load very fast.
Actually the new Twitter Mobile called Twitter Lite is super fast, did you try the latest version? It's a full progressive web app that works offline, has notifications and super fast scrolling. It was designed to work on low end Android device, give it a try: https://mobile.twitter.com
At first it gives me a white page with a little blue twitter logo. Then the twitter logo disappears and I see a white page for a second. Then it gives me a strange blue page with a giant twitter logo and two buttons glued to the bottom that tell me to log in.
Are you perchance using a RFC6214 network? Because the page is around 600kb compressed and renders in less than 500ms for me, on an empty cache.
I don't know why you're arbitrarily dividing the data into "behind a login" and, well, "not". I doesn't make any difference.
For the rest: opening in tabs is obviously a design choice. So are "confusing interfaces"–whatever that may mean, because if those reddit and twitter mobile sites are confusing you, good luck with amazon. React build a DOM. You can make a table-based layout with a spinning e-mail icon if that's what you want.
As for load times: mobile.reddit.com comes in at just under 1MB, but that's compressed to 400kb which is basically irrelevant once you expand the first image posts. JS is just about 200kb compressed.
And once it's loaded, only the JSON-encoded data goes over the wire: on the first click anywhere, the data transfer is amortised because the hundreds of <div class="asdasda"> don't have to be transferred.
For the rest: opening in tabs is obviously a design choice. So are "confusing interfaces"–whatever that may mean, because if those reddit and twitter mobile sites are confusing you, good luck with amazon. React build a DOM. You can make a table-based layout with a spinning e-mail icon if that's what you want.
As for load times: mobile.reddit.com comes in at just under 1MB, but that's compressed to 400kb which is basically irrelevant once you expand the first image posts. JS is just about 200kb compressed.
And once it's loaded, only the JSON-encoded data goes over the wire: on the first click anywhere, the data transfer is amortised because the hundreds of <div class="asdasda"> don't have to be transferred.
Presumably he wants to see more than just the landing page and doesn't want to bother registering.
Welcome to large JS apps. Doesn't matter what the library is—they'll always be slow.
> I wonder if React causes/incentivises this or if it's design decisions by the coders/designers/managers.
Both. React makes it easier to write complex JavaScript web apps. Complex JavaScript means you have a lot of rope with which to hang yourself.
Both. React makes it easier to write complex JavaScript web apps. Complex JavaScript means you have a lot of rope with which to hang yourself.
What part of Facebook? I know the search page on Facebook mobile web version uses React. But what else? It's not like every Facebook page uses React, most pages are still the PHP rendered legacy stuff, that is around for many years.
Gitlab uses Vue: https://about.gitlab.com/2017/02/06/vue-big-plan/
Vuejs is also a good match for single-page demos and apps within a larger website.
Here is an example where a product demo was built with VueJS while the rest of the site is not. https://sightengine.com/demo
Here is an example where a product demo was built with VueJS while the rest of the site is not. https://sightengine.com/demo
cool site. It did flag a cardboard box full of beer as nudity. That said, it looks pretty sharp and works well on this terrible old phone I have
https://www.ubereats.com/ uses React
Facebook.com, for example. Here's a more detailed list: https://github.com/facebook/react/wiki/sites-using-react
Facebook is behind a login.
Vue and React are mostly done for building web apps behind login, public facing websites are usually static html and that's not such a great use case for Vue and React except maybe in the comment section which is usually in an iframe anyway such as a disqus or Facebook comments (which uses react.js).
Here you go https://wappalyzer.com/applications/vue-js (first page of google results)
From what I understand, Vue is quite popular with the laravel community.
From what I understand, Vue is quite popular with the laravel community.
Aside - Jeffrey Way, who runs a popular tutorial site called Laracasts, maintains a free Learning Vue series. It's worth checking out, Jeffrey is a great teacher.
https://laracasts.com/series/learn-vue-2-step-by-step
https://laracasts.com/series/learn-vue-2-step-by-step
Reddit's new profile pages and their mobile web app both use react.
These?
https://www.reddit.com/user/spez
Aren't those just static html pages rendered serverside?
Is there a blog post about them or something?
https://www.reddit.com/user/spez
Aren't those just static html pages rendered serverside?
Is there a blog post about them or something?
The new pages like above are React apps.
The old pages like below:
https://www.reddit.com/user/HeinieKaboobler
Are server side rendered.
It's not a popular change. Mostly because of people feeling it'd pull focus from subreddits to profiles, but also some complaints about the performance loss and lower density: https://www.reddit.com/r/announcements/comments/60p3n1/tldr_...
The old pages like below:
https://www.reddit.com/user/HeinieKaboobler
Are server side rendered.
It's not a popular change. Mostly because of people feeling it'd pull focus from subreddits to profiles, but also some complaints about the performance loss and lower density: https://www.reddit.com/r/announcements/comments/60p3n1/tldr_...
If they made a technical post about them I haven't seen it, but there was an announcement for them as a feature.
I just know that my react-devtools extension and the redux state inspector both lit up when I went on that page.
I just know that my react-devtools extension and the redux state inspector both lit up when I went on that page.
That page is using React.
Slack will.
From https://slack.engineering/rebuilding-slacks-emoji-picker-in-...
> Rebuilding the Emoji Picker in React resulted in faster rendering and simplified code that’s easier to maintain. We’re extending these gains to the rest of our codebase by transitioning fully to React
Can't wait to see Slack's app be just as slow.
From https://slack.engineering/rebuilding-slacks-emoji-picker-in-...
> Rebuilding the Emoji Picker in React resulted in faster rendering and simplified code that’s easier to maintain. We’re extending these gains to the rest of our codebase by transitioning fully to React
Can't wait to see Slack's app be just as slow.
I'm currently making a mobile f2p game in Unity. I previously had created a Cocoa app for the game item creation/ db management. Since we changed the architecture of the game pretty heavily, I needed to rewrite the tool. I chose Electron + Vue over Cocoa. Despite having very little web dev/JS experience, I was able to make a fully functioning app in under 3 months that syncs with a server and has multi user editing. Huge fan of Vue. Haven't had the pleasure/displeasure of React so can't really compare.
What is the state of isomorphic / server side rendering for Vue and React? Is it a straightforward thing to setup?
I haven't done this with Vue yet, but it looks pretty easy to do both prerendering and server-side rendering[1].
A more complete solution, Nuxt.js[2], appears to be gaining in popularity as well.
[1] https://ssr.vuejs.org/en/ [2] https://nuxtjs.org/guide
A more complete solution, Nuxt.js[2], appears to be gaining in popularity as well.
[1] https://ssr.vuejs.org/en/ [2] https://nuxtjs.org/guide
For vuejs, https://nuxtjs.org is straightforward and easy to get started with isomorphic apps.
I've always felt that React is a constantly churning ecosystem. The patterns keep changing too fast for me to settle down or catch up. That way Vue.js has done an amazing job. Sort of reminded me of Rails. Today I'm happy with Vue.js for my small to medium applications. Keeps things simple and beautiful.
> ... If message is passed as a prop to any child components, Vue knows that they depend on this will be automatically re-rendered as well. That’s why there’s no need for a shouldComponentUpdate method on Vue components.
I think that React does the same? If a component's props and state don't change, shouldComponentUpdate doesn't get called at all IIRC. shouldComponentUpdate, instead, is useful when a state or prop was changed, but it's possible to quickly detect that the change won't require a DOM update anyway.
I think that React does the same? If a component's props and state don't change, shouldComponentUpdate doesn't get called at all IIRC. shouldComponentUpdate, instead, is useful when a state or prop was changed, but it's possible to quickly detect that the change won't require a DOM update anyway.
There's a default shouldComponentUpdate implementation in the React.Component. It does a shallow compare of state and props. When you define shouldComponentUpdate you are just overriding that implementation. So it's always called, its just you don't need to always define it.
The shallow check is on React.PureComponent. shouldComponentUpdate just returns true by default in React.Component components. See here for details: https://facebook.github.io/react/docs/react-api.html#react.p...
From the React website:
"When a component's props or state change, React decides whether an actual DOM update is necessary by comparing the newly returned element with the previously rendered one."
My point is that if a component doesn't receive a setState or new props it just doesn't start the rendering cycle at all (AFAIK), so shouldComponentUpdate doesn't get called at all.
"When a component's props or state change, React decides whether an actual DOM update is necessary by comparing the newly returned element with the previously rendered one."
My point is that if a component doesn't receive a setState or new props it just doesn't start the rendering cycle at all (AFAIK), so shouldComponentUpdate doesn't get called at all.
[deleted]
When I switched from Ember to react what I missed the most was the two ways binding, the computed properties and the router. From dabbling in Vue.js it seems to have incorporated the best of both worlds. I read over some of the technical implementation and it seems pretty sane. It seems too good to be true and I am honestly wondering what is the catch. Everything I have read about vue has been very positive so far. I am curious what are some of the cons of using vue
It's been eighteen months guys, time to rewrite all our front end code from scratch!
So true! And now you need to do a re-write with each of the top 250 frameworks of 2017.
https://twitter.com/HackerNewsOnion/status/86819780153190809...
The things touted as benefits sound like disadvantages.
I'm curious as to why some people refer to Vue as "the new hotness".
I understand the concept but Vue was realeased in February 2014, which seems pretty ancient in JavaScript years.
Wasn't React released only a year prior? Well, it's been around since 2011 but it was open sourced in 2013.
Either way, Vue has been around and in use for a little while now.
I understand the concept but Vue was realeased in February 2014, which seems pretty ancient in JavaScript years.
Wasn't React released only a year prior? Well, it's been around since 2011 but it was open sourced in 2013.
Either way, Vue has been around and in use for a little while now.
I dunno. I wouldn’t call React lightweight.
you can use mobx to make react 'vue-like'
I stopped reading at "both are fast and light weight" because I don't find react to be "light weight". React is 275K (nearly a quarter of a meg) when it is minified and gzipped. 750K when it is not minified/gziped.
We're talking about a web page UI here. It should be tiny for users with slow connections. React seems big to me and I can't justify it except in very large applications.
As such, I struggle to find the reason React is so popular. Perhaps I'm a bit old school. People say it's easy to reason about, but I don't find that to be true in real world large applications with a lot of developers working on them.
Still, I'm trying to like react, but these things are a struggle for me.
We're talking about a web page UI here. It should be tiny for users with slow connections. React seems big to me and I can't justify it except in very large applications.
As such, I struggle to find the reason React is so popular. Perhaps I'm a bit old school. People say it's easy to reason about, but I don't find that to be true in real world large applications with a lot of developers working on them.
Still, I'm trying to like react, but these things are a struggle for me.
> React is 275K (nearly a quarter of a meg) when it is minified and gzipped. 750K when it is not minified/gziped.
That statement is completely false.
[email protected]:
react.min.js is 21335 bytes uncompressed, 7353 bytes gzipped.
That statement is completely false.
[email protected]:
react.min.js is 21335 bytes uncompressed, 7353 bytes gzipped.
I'm including everything you need to deploy in those numbers. You included only React and not React-Dom. My own try at setting up React results in a 750k js file when I follow the instructions below. I realize this isn't minified yet and I welcome feedback on how to make it better.
https://www.joeldare.com/blog/post/create-a-react-app/
The top search results for react minified size show similar numbers to my 250k. There are a lot of people throwing out a lot of numbers that are different. Versions likely play a role, especially after 15. Here are some references.
https://gist.github.com/Restuta/cda69e50a853aa64912d
https://stackoverflow.com/questions/19807946/why-is-reacts-f...
Nothing I can find references a size as small as you mention with react and react dom. Most recommend writing with ES2016 which probably adds Babel overhead as well. When I build "Hello World" myself, I can't get anywhere near the small sizes.
I'd love someone to give me a proper smack-down on this. I want to love React since it's a recent requirement of my job. But with my current knowledge of it, I can't seem to get the size down.
https://www.joeldare.com/blog/post/create-a-react-app/
The top search results for react minified size show similar numbers to my 250k. There are a lot of people throwing out a lot of numbers that are different. Versions likely play a role, especially after 15. Here are some references.
https://gist.github.com/Restuta/cda69e50a853aa64912d
https://stackoverflow.com/questions/19807946/why-is-reacts-f...
Nothing I can find references a size as small as you mention with react and react dom. Most recommend writing with ES2016 which probably adds Babel overhead as well. When I build "Hello World" myself, I can't get anywhere near the small sizes.
I'd love someone to give me a proper smack-down on this. I want to love React since it's a recent requirement of my job. But with my current knowledge of it, I can't seem to get the size down.
You need to add uglify to your webpack.config.js.
https://webpack.github.io/docs/list-of-plugins.html#uglifyjs...
https://webpack.github.io/docs/list-of-plugins.html#uglifyjs...
[deleted]
While I agree that React (with ReactDOM) is heavier than it probably should be, a production build is around 140k minified, 45k min+gzipped.
I personally find React applications to be fairly easy to navigate compared to other JS projects, but my use of it has primarily been porting applications from Angular, Knockout or Asp.net Webforms to React.. and I find it a lot easier to work with than those personally. Haven't tried Vue though.
I personally find React applications to be fairly easy to navigate compared to other JS projects, but my use of it has primarily been porting applications from Angular, Knockout or Asp.net Webforms to React.. and I find it a lot easier to work with than those personally. Haven't tried Vue though.
> As such, I struggle to find the reason React is so popular.
Uhm, React websites run great in Chrome on a MacBook Pro. You seem to think that most web developers care about users on slow connections.
Uhm, React websites run great in Chrome on a MacBook Pro. You seem to think that most web developers care about users on slow connections.
I am assuming that, yes. Websites with mass appeal should probably think about this. Yeah, I develop on a MacBook Pro with Chrome on a massive network connection, but I do an awful lot of web browsing on my phone from resteraunts and offices where there is somewhat crappy data coverage.
I don't get it. Lets say that you have a well formed team, then you have a designer. A designer is who does the UI but know or care so little about programming. With React, the UI is practically JSX that very few people know (in comparison with html) and what we will get instead?, the result is the same html that it tries to avoid.
JSX is very close to HTML. Maybe the issue is expecting designers who have zero dev skills to build front ends in a time of responsive design and rich JS interfaces. You wouldn't hire a print designer with no Photoshop experience to design a site, and you shouldn't hire a graphic designer with no web dev skills to build front ends. If you're team is really well formed, you might have an experienced graphic designer, a UX expert, and a front end developer who does the actual building as well as making day-to-day design decisions. The design/interface experts would work at a higher level of creating an overarching design language and UX guidelines.
Only in the first world clients pay enough for such a team to make a living. Not a case for other countries.
"Lets say that you have a well formed team"
Aaaand you've just just 90% of projects...
Aaaand you've just just 90% of projects...
Not sure what your concern is, JSX is extremely simple to pick up with a cursory knowledge of HTML and Javascript.
I actually was thinking it was a non-issue until I saw a designer actually struggle with working with JSX for doing some animation (I had to help him out), and the designer had some knowledge of JS.
Both are very very similar and if you are familiar with one you will be able to pick up the other quite easily.
In regards to webpages both are capable of doing the same things and fit the same uses cases.
That said however if I was to start a greenfield application today, I would choose React. The reason for this is that react is better known, it is easier to find solutions for, and it has more mature guidelines for things like project structure and best practices.
Vue is good competition for React and it will certainly help keep it on it's toes. However in regards to longevity, I feel React will be around a lot longer than Vue. React has the full support of facebook and is being used by other major vendors. Vue is also used by some big sites, however it has no official backing that I know of and is maintained by a "Benevolent dictator for life".
In a year or two I predict that I will see another article with a title along the lines of "Switching From React To <insert new hotness here>". It is very unlikely in my opinion that I will see a "Switching From Vue To <insert new hotness here>" article.