Can someone explain why someone would choose Vue over React (or one of the clones)? When I looked at the docs for Vue it reminded me of my Backbone days.
I'm mostly a backend Rails developer, but I've spent the last 3 months developing stuff with Vue, Elm, React, and Angular 2 in an effort to see which of the front-end frameworks I would like best (I messed with Ember a year ago but haven't had a chance to revisit since). To me it seems like React is about putting logic in code instead of templates/markup. Vue is more in the vein of Angular, where you have logic in your templates/markup. So it's sort of a question of what you feel more comfortable with, the style of Vue or the style of React.
Instead of Vue or React, you might choose Angular 2. Vue is sort of touted as "Angular done right". I did enjoy working with Vue (I actually enjoyed working with all of them), but I think Angular 2 may be "Angular done right". However, Vue seems to try to be more lightweight and less of a framework than Angular (1 or 2). It has this in common with React. I think both Vue and React would be easier to start introducing into an existing app incrementally. Angular 2 seems like it's more of a framework/holistic choice. It has this in common with Ember, although this is true of Ember to an even larger degree.
I was really excited about Elm after listening to The Changelog episode #218 (https://changelog.com/podcast/218). Elm is in the style of React, but the flavor of Haskell. For my part, I had a hard time with the syntax and functional approach of it from the get-go. It was very new and awkward to me, which was a speed bump to my adoption. However, I felt like it held the promise of allowing potentially better/ more maintainable code. Evan Czaplicki (the creator) and Richard Feldman (a prominent evangelist) both talk about how the Elm language and style led to more effortless refactorings in larger front-end codebases they were working on. Sounded really good to me! But, I eventually ended up leaving my Elm journey and starting my Vue journey because the Vue documentation was so good (comparatively) and the style of Vue felt more natural to me. It kind of came down to the question "how do I do CRUD with this?". For me, the story was easier and more fleshed out with Vue. Currently, I'm working with Angular 2 mostly because it had a more definite answer to this question than Vue. And, the testing situation seemed way more fleshed out than Vue's (at least at this point). But, I plan to check back in on both Vue and Elm in the next year or so to see where they've landed. I understand what people are saying about JavaScript fatigue, but there's also so much exciting and cool stuff happening in this space right now. It's hard not to love all this innovation.
Elm is a language, but it's sort of automatically a framework as well. There's a function in the standard library called Html.program that takes four functions as arguments and returns a React+Redux style application from them. The Elm runtime exists solely in the browser and expects your main function to return some HTML, which it will display using a virtual DOM. They call this pattern 'the Elm Architecture' (TEA) and recommend that everyone use it. So it's like having a really lightweight framework baked into the standard library and indistinguishable from it.
Those four functions are view (take a model and return some HTML, like a React top-level component's render method), update (take a model and a msg/action and return a new model, like a Redux reducer), init (an initial state) and subscriptions (a list of things to watch for changes and automatically create msgs/actions from, like mouse movement or websockets). When you run a program, it feeds the initial model into the view, and renders it. HTML elements can create messages (dispatch actions) based on DOM events, and subscribed things (like websockets) can also create messages. Every time a message is created, it gets fed into the update function with the existing state, and you branch on the message type to figure out what the new state should be. Then that new state is fed into the view function again and the result is diffed against the virtual DOM and the optimal update made.
The biggest differences between React and Elm are that you don't mess with lifecycle hooks and that you don't repeat this pattern for every sub-component. Instead, you just write lots of small functions that take a model and return some HTML, and you can call those from your top-level view function -- a bit like building everything out of React stateless components.
Writing any Elm code feels a lot like writing React, but with much less boilerplate, reduced complexity, excellent error-catching, and static typing.
Oh, thank you for the detailed answer. I'm a bit ashamed to say that I really hate JS the language, but Elm sounds like a very nice alternative and potentially very interesting to play with.
Elm is a language, but it also dictates a very specific way of structuring your front-end application. This style is very similar to Redux and other such immutable state -> render -> actions -> reducer -> state flows. I can absolutely see why someone would compare it with front-end frameworks.
So, I'm still a noob with this stuff, but it's my take that Elm is both a language and a front-end framework. It's a language that compiles down to JavaScript that also gives you a React-like toolset to develop front-end code with.
The most annoying thing in Elm, not the language itself but their community. People complain about openness, elm packages can't grow as fast as contributors want to see.
I do not want to write a long story of composability and fancy types that haskellers want it and Elm doesn't have. But thoes are also big blockers
If you already know react and are happy using it, then there's no reason to use Vue.
But if (like me) you were never quite able to figure out how to use React (especially all the build tooling that's suggested in every tutorial), then Vue is worth a look as it's incredibly simple to get started with and easier to learn.
I find it especially appeals to people coming from a place of familiarity with html and css (whereas react seems to appeal to people with more of a straight-up programming background). YMMV
I think this is problematic because people don't differentiate between React and the React ecosystem. Plain old React is just as easy (probably easier) than learning Vue. I always recommend the official React tutorial (https://facebook.github.io/react/tutorial/tutorial.html) before even thinking about Redux or Webpack or whatever.
Of course it's subjective, and different people coming from different backgrounds / experience levels find different things easier than others.
But... that tutorial you say you like to show people utilizes jsx, which needs to be compiled with something (right? Or does react do the compilation automatically at runtime now and I missed that memo?).
And for people coming from a place where they are very comfortable and familiar with html and css, and maybe a light sprinkling of jquery on top, Vue is way more approachable than the tutorial you linked to.
create-react-app is our recommended way to build simple React apps (and some complex ones). It has no configuration and is designed to be very easy to set up.
(My understanding is that Vue templates also need to be compiled -- is that incorrect?)
I wrote the tutorial. Could you give any suggestions on how I could make it easier to get into?
Not the OP, but I'll state the obvious on their behalf.
The number one thing that you (and Facebook) could do to help people learn React, and combat the perception that it requires overly complex tooling, is write a tutorial that shows how to use React entirely in-browser without any build toolchain. A static HTML file, some <script> tags pointing at a CDN — done. No distractions, nothing to download, nothing to install, nothing to run, just a JavaScript library that makes it easier to write view templates.
It would make it even easier to get into if that tutorial were written entirely in ES5, but you could use babel-standalone if you felt that JSX and ES6 were important enough.
Thanks for replying! Our official tutorial was actually exactly that for _years_, but it didn't seem to help much. I get the sentiment though and maybe we can find another way to make it work.
Offering an alternative point of view: I would really like if the tutorial at least pointed towards documentation on what do I need and why, and the right way to set these things up between Babel and Webpack, as well as Typescript.
Maybe my use case is rarer, I don't know, but if I want to do things right, I want to understand what I'm setting up. Do I really need babel? If I use Typescript, do I still need it? etc...
I understand this doesn't have much to do with React per se but if these components are a definitive part of the ecosystem people work with, there is value in at least telling people where to find a high quality explanation for how they fit together.
I think this post is spot on. I remember having a quick exploratory play with React back when the tutorial was like that and I thought it was great. Then when I came back to actually use React in a project the tutorial had changed and all of the sudden it felt like a big learning curve. Vue had just been adopted by Laravel and I was able to get everything I wanted to do by just including some scripts.
I've since learned more about compiling and including other resources so could probably handle the React tooling and requirements now but back when I started it was a big stumbling block.
This is why I am using Vue and never gave React a second thought. Everyone "says" JSX is optional but there is no practical way to invest in React without having to deal with it.
JSX is a breeze though. The trial-by-fire for me was handing a bunch of ugly components to our designer who only knew HTML/CSS/JS. He picked it up no problem.
And to me using JSX is infinitely better than have to use opaque template directives like Angular and Vue.
To get started with Vue, all you need is to include 1 javascript file, and it works with plain old javascript, all the way back to IE9. As one gets more advanced, there is the ability to compile templates, but that is an optional thing that no beginner needs to worry themselves about.
I took a closer look at your tutorial. It's really very good! And I like that you link to a codepen which gets people up and running without having to even create their own html file.
Tutorials speak differently to different audiences -- I imagine people used to building more traditional "apps" get a lot out of this one.
But speaking from the perspective of someone who spent years making html+css pages that had data piped into them from the back-end (PHP, Rails, etc)... the scope of the tutorial is somewhat overwhelming to me :)
It goes right into components, shared state, immutability, functional programming, history... to some people that is a lot of concepts at once. I think the appeal of Vue (to a certain slice of people) is that you can just add it as a "light touch" onto an existing html page. For example, show me one textbox who's value gets displayed in a div somewhere else on the page as I type, or one button that toggles the visibility of one image. Just super duper basic stuff, in very isolated and limited-scope chunks, and in the context of "easy dom manipulation" (as opposed to "building a game or app").
Both frameworks are the same with regards to compilation.
JSX can be used at runtime by including the babel browser compilation script. This is only recommended for development, not production. React can also just use plain javascript, although JSX is a much cleaner and easier to use with the rest of the framework.
I have a theory that every project eventually approaches a level of complexity reflecting the level at which a moderately intelligent person can't understand it any more. I think of it as a "complexity budget". So if you start with something simple (say, React) then people will just invent more layers of complexity around it to solve whatever the next layer of problems is (Redux, Webpack, etc). And they won't stop until the complexity budget is all used up.
I had the same problem, couldn't figure out how to use React, I started learning VueJS and in a week I had built a fully working app, https://github.com/thewhitetulip/Tasks-vue
Then you should look at Polymer. It is just DOM nodes (custom elements_, you can however compose complex applications with it without any trouble.
I feel its very straightforward way to build applications and most parts of it are handled by browser API's. It seems like a perfect middle ground between react/angular 2/vue - and you can still throw in redux or uniflow-polymer if you want.
whats the problem with using bower (apart being "legacy"), it suddenly stopped working?
Not all packages are on npm, i use mix of npm and bower without issues. When the JS community comes up with better npm will people stop using packages on npm?
It's like the ideal mixture of React and Angular. You can use more the template approach than in React (where everything tends to be a component). Footprint (size of libs) is also smaller than React while still having VirtualDOM and speed of React. What I also experienced: It's much simpler to add Vue to existing HTML code without the need of bundlers and build tools like Webpack etc. Also keep in mind that Vue ecosystem is more from one hand: Vue itself, the store (Vuex), the router... all from one single source and team and not cluttered from various teams like in React ecosystem.
React has no templates which is an advantage until it hits you with large bundle sizes. Every line of JSX is transformed into a longer JavaScript program.
I love that React makes developers more productive with JSX but there should be a way of outputting HTML for large template like React components. Browser are much happier dealing with HTML.
I've tried out both. I like Vue because I can work with standard HTML and augment it with Vue, whereas React requires using JSX. JSX is proprietary and HTML is kind of hidden. There's an additional mental translation when writing JSX.
Backbone is a structural JS library/framework. It gives your app a backbone. Vue provides data binding so your View(Vue) gets automatically updated when data changes. Completely different.
Backbone implements 1-way binding via model:change event + render(). Vue/React/Angular do various forms of diffing, which makes their incremental rendering more efficient than Backbone's.
