Having used both React and Vue extensively. I'd say React's great at Single Page Apps in the true sense of the word, Apps that have a single UI like an IDE:
Vue's also nicer for "page-based" Websites that are converted into Single Page Apps. Nuxt.js really shines here which lets you develop complete Websites using Vue's Single File Components and takes care of routing by following a conventional page structure. Nuxt.js + Vuetify will be my goto for many traditional Website style Apps (implemented as SPAs) going forward. It imposes an opinionated convention but saves you a lot of effort having to manually configure and integrate different libraries together.
Vuex is more pragmatic and requires less effort/code to use than Redux, but Redux is great when you need to access previous states, e.g. it makes it effortless to capture "Snapshots" of the entire current state of the App that you can send to someone else so they load your App exactly as you see it:
As an aside (and since you brought up snapshots), mobx state tree https://github.com/mobxjs/mobx-state-tree seems to have combined the ease of use of Mobx with the power (and beyond) of Redux and its ecosystem.
I watched a video about Vuex last night, and with mutations, it seemed more convoluted than mobx state tree.
All of these are possible with Vuex. It's based on the same fundamental paradigm: a single state Singleton that renders everything.
You can even use Jest's snapshot testing for Vue components. Time travel also exists in Vue developer tools, and there are plenty of undo/redo plugins available.
It will never be as easy as Redux where the entire state is maintained in an immutable and naturally serializable plain JavaScript object in which all messages can be inspected, serialized, dehydrated, sent over the network, etc with every App state transition being easily captured / replayed or reverted to any period of time. You can force it with other state management libraries with additional machinery, but Redux's approach of sending plain JS object messages to create immutable states is naturally well suited for the task.
Coming from Angular, I hated seeing another framework that has conditions inside elements, like v-if, v-bind, etc.
Especially when I saw things like @click, @submit, etc, I said Vue is not for me.
However, you quickly realize it's not like Angular where those declarations can at times be overwhelming. In Vue, there are not that many and it is actually much more simpler and even intuitive.
Also, when coming from React, being able to use certain things like v-model makes you not want to go back to React, and has shrunk the code and simplified it quite a bit.
> Also, when coming from React, being able to use certain things like v-model makes you not want to go back to React
Could you explain that further? I definitely see Vue as an improvement over Angular, but React still is much better for me than Vue, so I'm curious what you mean.
v-model is a two-way binding. In other words, you don’t have to write a setter function for every piece of state - you can hook up a state field directly to a text input, for example.
React doesn’t allow two-way binding, or at least heavily discourages it. The downside of two-way bindings is that they can make it hard to track and understand state changes. The upside is that they drastically cut down on boilerplate for things like forms.
These posts are becoming redundant. Although I do understand where the author is coming from. I think the issue is that frontend development is hard! Especially modern frontend dev. It requires an entirely different thought process than backend development and this is why I think so many people get scared and reach for the most familiar lib out there.
However, getting used to the React ecosystem really does have huge benefits (code clarity, minimization of bugs, ease of creating complex interactions) and I do recommend that those interested really just dive in and build something simple to see for themselves.
All the extra libs and tools are helpful and make your job easier in most cases. But they can be phased in as you get a deeper understanding of the ecosystem.
The ecosystem is standardizing now. And I don't see webpack or React going away anytime soon.
I'd love to read the follow up article 1 year from now. And then 3 years, and 5 and 10.
Vue 2.0 was a complete rewrite and their "long-term-support" for v1 was 9 months of security updates.
I'm not trying to single out Vue, but I wonder how many job posting are for someone to maintain a legacy framework code base. (Legacy meaning 6 months old.)
Yeah, I'm always a bit sceptical of these kinds of articles. Been saying to people for years that everything we build today is tomorrow's legacy.
This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
In the face of changing business and product requirements, and evolving markets and technologies, you have to accept the fact that almost every piece of software you build has a shelf life, and that shelf life is often surprisingly short.
Therefore, rather than try to guess the future (and get it wrong, because most people do, most of the time) you're much better to focus on the problems you have to solve rightnow. Sure, don't code yourself into a corner by building some sort of tightly coupled ball of spaghetti, because that's always going to turn out badly, but to think that's what you're resigning yourself to by focussing only on problems you need to solve rightnow is to conflate two entirely separate issues.
> This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
I'm glad smart people before me have decided that they're going to try and get stuff right or at least more right. Say what you will about Java or C# enterprise software, but I can't imagine COBOL was any more fun.
The difference to me with other frameworks (most notably Angular) is that the transition from Vue 1.0 to 2.0 was relatively smooth. I've migrated a couple of smaller applications and that was done in just a couple of minutes. If Vue keeps the core and focus small i think maintenance will be easier than with comparable frameworks.
For me this is actually a reason to use React even if Vue might be more appropriate. I fear that the 'front-end ecosystem' is still a bit too much in flux to settle on a framework as relatively opinionated as Vue.
What makes React both nice and complicated is that it's really pretty bare-bones (even with Redux), and as a consequence a lot of the stuff you learn with either be useful for JS programming in general, functional programming, and UI building in general.
For example, I've been working on a little command-line tool in Elixir, and a lot of what I do in the view/render code is very much like React and what I learned by using React.
Anecdotal, but I had to migrate a mid-sized app (about 400 components) from Vue 1 to Vue 2 and it took less than a day of work to modify the code, test it and push to production. We weren't using that many removed features to begin with, though.
VueJS 2 was an easy upgrade. Most people are probably starting on VueJS 2 anyways, coming from jQuery or ng1. When I started using VueJS my biggest pain point was how much bootstrap assumed you were using jQuery.
I don't get the Vue hype. Sure, Vue seems nice enough, but it is concepteually very similar to React, so nothing new there. The pros of React are a smaller API and JSX instead of an added templating language (the latter being a contentious issue, I know).
EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
I find vue much simpler to start out with and build off of, since it is almost all just regular html and JavaScript, as opposed to React which uses jsx and has lots of painful setup of tools like redux and react router. Vue.js has a really good webpack starter kit that will give you a working site that you can expand really easily so that makes setup super simple.
Just don't use redux. Maybe one day there will be a decent, ergonomic framework on top of the flux architecture, but redux ain't it.
Try mobx state tree for all the benefits that redux has without the pain.
Vuej seems nice enough (especially for migrating server side tech apps), but I'm still not digging the templating engine. I've seen the way you can use JSX in Vuej, and I don't like it.
it's cultural/human; debian/fedora/archlinux are all nothing but linux distro.. yet I cant fathom the first two, while arch mindset and wiki suit me in ways that never fails. I think vue is just like that. It's readable, efficient, does 90% of react. For some people it's the right fit.
No, the pro is that is not supported by one of tech giants with infinite resources for the sole reason “to have larger footprint on the web”, basically to increase their spying capabilities across the web.
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
People hate having a build step and will go to great lengths to get rid of it. To add on top of that, the situation with writing modular code in JavaScript/HTML/CSS is such a total disaster - even with a build step.
Of course, the problem is not quite solved by not having a build step. It just means that things will bite you later, once you have enough components that just loading them one by one wont do. (at least not yet - we need smart HTTP/2 servers for that).
Then you add a simple build step in the form of bundling. This is a happy medium and most apps will survive very well with this sort of setup (a single bundle).
But another point might come where the single bundle is too large to be served in one piece. At that point you need code splitting. And now if you're using one of the custom framework module systems (which work by defining global named "injectables"), you might regret it, since code splitting bundlers rarely understand the dependencies between them. Not sure what the situation in Vue land is, but if you're using the asset pipeline you'll likely have to manage two sets of dependencies per file (your requires and your vue components) and then last time I checked, Sprokets does not support code splitting.
This entire situation is caused by two major problems with the web platform:
1. The ES6 module system is not yet available in browsers, and servers and browsers are not taking advantage of HTTP/2 push to ensure efficient module loading. You can create a service worker to support this browser-side (https://mariusgundersen.net/module-pusher/), but then there is Safari - and dammit, this stuff should be built in and commonplace everywhere!
2. You can't use the ES6 module system to modularise the rest of the assets like CSS and HTML. An ES6 module can't request for a CSS file, templates or other assets to get loaded via push. (Well actually it can via loader hooks I suppose, but there is the CSS modularity problem). There is another way to do this called HTML imports (which combined together with Shadow DOM finally gives CSS some modularity), but its a whole different thing form ES6 modules and its unclear how to make those work together. So to use that you kinda have to throw ES6 modules with the bathwater too.
3. IE11.
Someone on those standards bodies should get their act together and fix this dire situation. Until then, I'm excited about Parcel's way of handling this, with its async imports support making code splitting quite transparent. In general the ES6 module system has the best bundler support thus far, so JSX and css-in-JS (or at least css-modules) make sense to me for the foreseeable future.
p.s. One other reason why this isn't fixed is probably because the big companies that have the most say in standards bodies and browsers don't care. Preliminary research showed (can't find the link) that HTTP/2 push would have about 5-10% overhead over current optimal bundling and code splitting solutions, and these companies have their own developed infrastructure to optimise every last bit of performance - they can't afford 1% drop, let alone 5%. So there is no incentive to help the rest of the web.
I don't think there's anything wrong witha build step as long as a) it's simple and b) there are distinct advantages.
Most of the js ecosystem fails miserably at a). And for b) the advantages of es6 and / or jsx aren't universally appreciated.
A good example of a build that IMO delivers both a) and b) is Elm. The build is simple (like compiling anything, but you can get all webpack complicated if you really want) and the syntax, static typing, and compile time errors add enormous value.
> Everything just makes a lot of sense without a lot of fluff added to it. It does everything React does and I'd say does a lot more using less codes.
This is also why I'm positive about Vue having a good 'place' in the ecosystem. React can be a bit overkill for smaller projects.
That said, I feel about it a bit like I do about testing. It might not be necessary for a lot of stuff, and it can feel tedious to do, but as projects grow, I often find myself wishing I'd added tests from the start.
In general I find myself leaning towards preferring too much 'boilerplate' over too little, at least as rule of thumb.
I tried to use Vue.js recently, but found that there's a huge set of idiomatic coding principles, as opposed to a small set of primitives. Which basically makes it not for me.
What I also disliked was how they don't explain how to get it working without a build-environment like webpack. That makes it really a "framework" in the sense that it's all-or-nothing. Again, not my style. I prefer self-contained libraries.
I disagree with the assertion that it has "huge set of idiomatic coding principles", but I think that's a matter of opinion.
However:
> What I also disliked was how they don't explain how to get it working without a build-environment like webpack.
This doesn't make sense. The official website includes a way to use it by just including a script from the CDN, on the "Get Started" page. It even discourages using the build tools if you don't have prior experience: https://vuejs.org/v2/guide/
I have developed a production vue js app without any building tools.(!) Keep in mind that you should not do so. Some community vue component expect babel helps to transform their es6 code for IE11. Besides, you cant do code splitting, which is an issue when you have many small components to be loaded in the same time.
I suggest create your actual project with vue-cli once you get familiar with the vue syntax.
> I also disliked was how they don't explain how to get it working without a build-environment like webpack
Your comment is a bit mystifying. Go to https://vuejs.org/. Click "Get Started". There is literally an example right there on the page, the first thing they show you is a frameworkless Vuejs app with nothing but a script tag.
if anything this is one of VueJS's advantages over most other similar frameworks.
> What I also disliked was how they don't explain how to get it working without a build-environment like webpack. That makes it really a "framework" in the sense that it's all-or-nothing.
That's weird you think VueJS is weak on this feature, because this is basically VueJS's most significant competitive advantage over react and one thing it does extremely well and has tons of documentation and tutorials for.
Try Polymer 2.0 + lit-html/hyperHtml, it's jQuery for web components basicly + `react-like` templating but based on WHATWG standards. And your code will be small and will work in the future because of web components being part of browser API.
I keep waiting on fully commiting to either Vue or React, to see which might end up dominating so I don't have to waste a lot of time on the one that will likely end up wilting. I've been doing the equivalent of full-stack web development non-stop since 1995 or so. My tolerance for going with the loser has declined persistently toward zero year by year, due to two decades of randomly eating shit when going with the wrong platform/library/tool/whatever (wrong, meaning, the one that loses the popularity contest and ends up practically disappearing).
I've spent a modest amount of time with both. I find myself repeatedly drawn back to Vue every time I work with the two. I like it dramatically more than React. HN seems to love Vue, I can't decide if that's primarily due to its underdog non-FB position. HN loves the underdog, as most forums made up of people will. Whatever the case, React is winning the popularity contest at the moment. I'm pulling for Vue.
Readit News
- https://github.com/ServiceStack/Gistlyn
Vue's nicer to use without any build tools using just vanilla JavaScript:
- https://github.com/NetCoreWebApps/Redis
Vue's also nicer for "page-based" Websites that are converted into Single Page Apps. Nuxt.js really shines here which lets you develop complete Websites using Vue's Single File Components and takes care of routing by following a conventional page structure. Nuxt.js + Vuetify will be my goto for many traditional Website style Apps (implemented as SPAs) going forward. It imposes an opinionated convention but saves you a lot of effort having to manually configure and integrate different libraries together.
Vuex is more pragmatic and requires less effort/code to use than Redux, but Redux is great when you need to access previous states, e.g. it makes it effortless to capture "Snapshots" of the entire current state of the App that you can send to someone else so they load your App exactly as you see it:
- https://github.com/ServiceStack/Gistlyn#snapshots
Or when you need to sync state changes between network apps:
- https://github.com/ServiceStackApps/typescript-redux
But if you don't need these features, in general Vuex/Mobx is easier and requires less effort to develop with.
I watched a video about Vuex last night, and with mutations, it seemed more convoluted than mobx state tree.
You can even use Jest's snapshot testing for Vue components. Time travel also exists in Vue developer tools, and there are plenty of undo/redo plugins available.
Especially when I saw things like @click, @submit, etc, I said Vue is not for me.
However, you quickly realize it's not like Angular where those declarations can at times be overwhelming. In Vue, there are not that many and it is actually much more simpler and even intuitive.
Also, when coming from React, being able to use certain things like v-model makes you not want to go back to React, and has shrunk the code and simplified it quite a bit.
Could you explain that further? I definitely see Vue as an improvement over Angular, but React still is much better for me than Vue, so I'm curious what you mean.
React doesn’t allow two-way binding, or at least heavily discourages it. The downside of two-way bindings is that they can make it hard to track and understand state changes. The upside is that they drastically cut down on boilerplate for things like forms.
However, getting used to the React ecosystem really does have huge benefits (code clarity, minimization of bugs, ease of creating complex interactions) and I do recommend that those interested really just dive in and build something simple to see for themselves.
If you're new, ignore [babel, redux, (insert buzz lib here)] and just build something. Checkout https://medium.com/@clmyles/react-without-npm-babel-or-webpa... on how to create something with just React.
All the extra libs and tools are helpful and make your job easier in most cases. But they can be phased in as you get a deeper understanding of the ecosystem.
The ecosystem is standardizing now. And I don't see webpack or React going away anytime soon.
Vue 2.0 was a complete rewrite and their "long-term-support" for v1 was 9 months of security updates.
I'm not trying to single out Vue, but I wonder how many job posting are for someone to maintain a legacy framework code base. (Legacy meaning 6 months old.)
This whole idealistic fantasy that this time around "we're going to get it right" - whether it's because we're smarter than those who came before, or we have better tooling, or a better framework, or better languages, or whatever specious reason is given - is just that: fantasy.
In the face of changing business and product requirements, and evolving markets and technologies, you have to accept the fact that almost every piece of software you build has a shelf life, and that shelf life is often surprisingly short.
Therefore, rather than try to guess the future (and get it wrong, because most people do, most of the time) you're much better to focus on the problems you have to solve right now. Sure, don't code yourself into a corner by building some sort of tightly coupled ball of spaghetti, because that's always going to turn out badly, but to think that's what you're resigning yourself to by focussing only on problems you need to solve right now is to conflate two entirely separate issues.
I'm glad smart people before me have decided that they're going to try and get stuff right or at least more right. Say what you will about Java or C# enterprise software, but I can't imagine COBOL was any more fun.
What makes React both nice and complicated is that it's really pretty bare-bones (even with Redux), and as a consequence a lot of the stuff you learn with either be useful for JS programming in general, functional programming, and UI building in general.
For example, I've been working on a little command-line tool in Elixir, and a lot of what I do in the view/render code is very much like React and what I learned by using React.
EDIT: I realize now Vue does have optional support for JSX and you are not forced to use a templating language.
Try mobx state tree for all the benefits that redux has without the pain.
Vuej seems nice enough (especially for migrating server side tech apps), but I'm still not digging the templating engine. I've seen the way you can use JSX in Vuej, and I don't like it.
The CSS styling for a component is handled much more cleanly than React does.
The lifecycle methods are named more sensibly.
You can add as little or as much Vue as you like, very easily, using no build system or going as far as to only use the build system.
Instead, vue was built by one guy, and it’s en par if not even better than react/angular.
You can even use JSX if you want.
Of course, the problem is not quite solved by not having a build step. It just means that things will bite you later, once you have enough components that just loading them one by one wont do. (at least not yet - we need smart HTTP/2 servers for that).
Then you add a simple build step in the form of bundling. This is a happy medium and most apps will survive very well with this sort of setup (a single bundle).
But another point might come where the single bundle is too large to be served in one piece. At that point you need code splitting. And now if you're using one of the custom framework module systems (which work by defining global named "injectables"), you might regret it, since code splitting bundlers rarely understand the dependencies between them. Not sure what the situation in Vue land is, but if you're using the asset pipeline you'll likely have to manage two sets of dependencies per file (your requires and your vue components) and then last time I checked, Sprokets does not support code splitting.
This entire situation is caused by two major problems with the web platform:
1. The ES6 module system is not yet available in browsers, and servers and browsers are not taking advantage of HTTP/2 push to ensure efficient module loading. You can create a service worker to support this browser-side (https://mariusgundersen.net/module-pusher/), but then there is Safari - and dammit, this stuff should be built in and commonplace everywhere!
2. You can't use the ES6 module system to modularise the rest of the assets like CSS and HTML. An ES6 module can't request for a CSS file, templates or other assets to get loaded via push. (Well actually it can via loader hooks I suppose, but there is the CSS modularity problem). There is another way to do this called HTML imports (which combined together with Shadow DOM finally gives CSS some modularity), but its a whole different thing form ES6 modules and its unclear how to make those work together. So to use that you kinda have to throw ES6 modules with the bathwater too.
3. IE11.
Someone on those standards bodies should get their act together and fix this dire situation. Until then, I'm excited about Parcel's way of handling this, with its async imports support making code splitting quite transparent. In general the ES6 module system has the best bundler support thus far, so JSX and css-in-JS (or at least css-modules) make sense to me for the foreseeable future.
p.s. One other reason why this isn't fixed is probably because the big companies that have the most say in standards bodies and browsers don't care. Preliminary research showed (can't find the link) that HTTP/2 push would have about 5-10% overhead over current optimal bundling and code splitting solutions, and these companies have their own developed infrastructure to optimise every last bit of performance - they can't afford 1% drop, let alone 5%. So there is no incentive to help the rest of the web.
Most of the js ecosystem fails miserably at a). And for b) the advantages of es6 and / or jsx aren't universally appreciated.
A good example of a build that IMO delivers both a) and b) is Elm. The build is simple (like compiling anything, but you can get all webpack complicated if you really want) and the syntax, static typing, and compile time errors add enormous value.
This is not a pro for me, I much prefer using the templates of Vue.js than JSX.
Everything just makes a lot of sense without a lot of fluff added to it. It does everything React does and I'd say does a lot more using less codes.
When choosing a framework, simplicity, performance, and support are the main things you should look for and Vue is a hands-down winner here.
This is also why I'm positive about Vue having a good 'place' in the ecosystem. React can be a bit overkill for smaller projects.
That said, I feel about it a bit like I do about testing. It might not be necessary for a lot of stuff, and it can feel tedious to do, but as projects grow, I often find myself wishing I'd added tests from the start.
In general I find myself leaning towards preferring too much 'boilerplate' over too little, at least as rule of thumb.
React is the simplest, most powerful library I've used in my life. It's the community that (often misguidedly) adds the complexity.
What I also disliked was how they don't explain how to get it working without a build-environment like webpack. That makes it really a "framework" in the sense that it's all-or-nothing. Again, not my style. I prefer self-contained libraries.
However:
> What I also disliked was how they don't explain how to get it working without a build-environment like webpack.
This doesn't make sense. The official website includes a way to use it by just including a script from the CDN, on the "Get Started" page. It even discourages using the build tools if you don't have prior experience: https://vuejs.org/v2/guide/
But how about an explanation of how to compile the .vue files (used in the examples) to JS? Or how to do without them?
I suggest create your actual project with vue-cli once you get familiar with the vue syntax.
Your comment is a bit mystifying. Go to https://vuejs.org/. Click "Get Started". There is literally an example right there on the page, the first thing they show you is a frameworkless Vuejs app with nothing but a script tag.
if anything this is one of VueJS's advantages over most other similar frameworks.
That's weird you think VueJS is weak on this feature, because this is basically VueJS's most significant competitive advantage over react and one thing it does extremely well and has tons of documentation and tutorials for.
I've spent a modest amount of time with both. I find myself repeatedly drawn back to Vue every time I work with the two. I like it dramatically more than React. HN seems to love Vue, I can't decide if that's primarily due to its underdog non-FB position. HN loves the underdog, as most forums made up of people will. Whatever the case, React is winning the popularity contest at the moment. I'm pulling for Vue.