The give-a-shit factor from Evan (the creator) is extremely high and was key to its success.
Inspiration for anyone building a product in an established market: there's almost always room for better.
The truth is, the majority of the work I've done in React for my job on the web would have been much better off written in Vue. React gives plenty of rope to hang yourself with if code quality isn't kept, especially when working with developers who've done nothing but jQuery for the past 10 years.
Vue.js (which, TBH, I haven't used yet - I'm still on the React hype train) looks great when you're working on a project that is complex enough to warrant looking for something more than jQuery, but not big enough to warrant the abstractions presented by React.
I've also found that the paradigm shift from jQuery apps to React is difficult for a lot of people at first, and Vue.js looks like a nice middle ground of "still looks like plain javascript-in-the-browser" while also nurturing some of the same ideas: components, event-driven model, one way data flow.
It also requires no transpilation and has a small footprint.
All of these are IMO a great plus when working in a team environment on sites that require lots of interactivity but don't quite fit into the "SPA" bucket.
When I first started dabbling in web programming a few years ago, I quickly learned about jQuery from SO while looking up common patterns to create the behaviors I wanted in the browser. But even accounting for my unfamiliarity with the browser paradigm, jQuery always rubbed me the wrong way because of how loosely structured it allowed you to be and the amount of leaky scope it encouraged.
I finally decided earlier this year it was probably worth my time learning a framework just to get some structure in my code, so I asked a webdev friend if he had any recommendations for a JS framework I should try; he pointed me towards Vue. I had never heard of it and was skeptical, but I started working through the quickstart guide (Vue docs are great, another +1 to Evan!) and I was hooked before I finished the third example. It was night and day from jQuery, but easy to learn. My experience so far is that Vue (in contrast to jQuery) is astoundingly flexible for how terse it is. My code was probably bad, but rewriting a jQuery page in Vue usually halved my linecount.
>no transpilation
This is huge to people who just want enough JS to get their proposed feature working and don't want their whole site to be JS, and to beginners. True, at this point I have started getting comfortable with the npm/webpack/babel/es6 stack and I enjoy the things it makes convenient - but at the beginning it's a pretty nontrivial learning curve and delayed benefit for a dev team that have probably been doing most things on the server with python or php.
>Vue.js looks like a nice middle ground... while also nurturing some of [React's] ideas
YES. My first three tries in Vue were basically little calculators that hit some APIs and got some user input and displayed data. I had no idea what "components" were and my calculators were quick to write and worked great. I figured that if I ever needed to use components, there was time enough to learn about them later.
A month later, I decided to dig in and grok React. After a couple of good tutorials, I finally get components and why they can be great. I've never used Vue's component system, but now I have faith that they are as much a pleasure to use as the rest of it.
The great thing about Vue is that it's modular. It can be as simple or as powerful as you need. If you just want to define some behavior and have an object with standardized access to hold the state of your page, you can do that. If you want to use portable components to reduce duplication of effort, you can do that. If you want to enforce Flux design, vuex[0] is there for you. If you want to write a full SPA and need a router, vue-router[1] will do it. If you want to use JSX, there's a Babel plugin[2] for that. None of these are around to complicate your understanding of things when you're learning, but they are easy to plug in when you need them. This is in pretty strong contrast to my experience with React, where you get hit with a lot all at once. Admittedly, I jumped quickly into using Redux and websockets because I was using that one great tutorial that everyone links[3] - so maybe React by itself isn't too overwhelming. I won't hold my breath though.
[0]: https://github.com/vuejs/vuex
[1]: https://github.com/vuejs/vue-router
[2]: https://github.com/vuejs/babel-plugin-transform-vue-jsx
[3]: https://teropa.info/blog/2015/09/10/full-stack-redux-tutoria...
Once components click, everything becomes a component.
That's not a two-bit attempt at Javascript zen, what I mean is that components are basically reusable building blocks of functionality. Mastering them provides an excellent way to reason about your app's structure.
What happened when you were using jQuery, is you created your own homegrown "framework" on top of it. Thats what you should be comparing Vue with, not jQuery.
In my experience elsewhere it's usually the other way around. Like learning how to use Python's Requests vs. learning how to use Python's Flask.
When it comes to simple solutions that do no require a build step, the field is not that crowded. A built step should be optional, not necessary to use a front-end library. With Angular you start with the CLI, with React you need to compile JSX files, ...
Angular 1 didn't succeed because it needed a build step or a third party language, it succeeded because it provided a smooth upgrade path from jQuery based apps. The Angular team forgot what made Angular popular with their "enterprise framework".
Angular and React want you to do things their way and therefore get in the way, and then make you do a bunch of work to make things work their way. I have a PHP app that I rigged up using Vue.js. Took two days to do. Had to change nothing in the app, instead of rendering views with PHP they are output using JSON simple enough. Powerful. Can't do that with Angular for sure. Don't have time to deal with react and its nuances.
React on the other hand, whilst it gets described as 'just the view', but I haven't seen a single tutorial that uses anything other than React/Redux to drive it.
To even get started in React, you need a babel, npm, gulp or webpack, node and a data-store of your choice. On top of this, any of the tutorials you can find from a full-stack perspective get made obsolete within months. This is javascript fatigue, all you have to do is look at this recent article.
https://www.fullstackreact.com/articles/react-tutorial-cloni...
It makes me wonder how many 'npm install' developers actually understand what is happening under the hood. This is not worse than the DOM ignorance that jQuery causes IMHO.
This is patently not true. You don't need any of that to make a React app -- you can just download the min.js files and get coding. React is perfectly capable of handling it's own state management and webpack/babel/npm are just to make your life easy. The problem is people follow full-stack, real-world tutorials like the one you linked without first just learning React.
As a former Angular dev gone React, I've been able to accomplish 90% of what I could do in Angular, using React, React Router and Fetch API.
> To even get started in React, you need a babel, npm, gulp or webpack, node and a data-store of your choice.
Create React App allow you to forget about that stuff and just worry about your app. Same with Next by Zeit, and there are plenty of other things including a couple of CDN backed script tags you can throw on any html page and start using React right away to get started.
> On top of this, any of the tutorials you can find from a full-stack perspective get made obsolete within months.
That's because all these boilerplates or tutorials are pushing a style of developing React apps in which that specific person finds the best way.
> This is javascript fatigue, all you have to do is look at this recent article.
JavaScript fatigue is result of lacking knowledge of the basis of the JavaScript language and feeling you need to use the next greatest shiny framework and misunderstood boilerplate to "get up and running quickly" with said new shiny without a grasp of the tools used causing them to break and you not knowing how to fix it.
React uses JavaScript that everyone should know and be able to apply to anything else to do stuff.
You're not extending a special snowflake "class" system that requires you to do things drastically different from previous "class extending libs"
Because of this, tools like Inferno and Preact can prosper and allow users to literally swap out using React for Preact in production just by setting an alias in Webpack.
There's no special snowflake syndrome, JSX is just a syntax ontop of JavaScript to make it feel like we're writing HTML (with a couple caveats), but you don't need to use JSX. You can accomplish the same thing writing React.creatElement calls, as it's just props all the way down.
JSX is also compiled at build time, and not at runtime. You may think this is a problem, but lets be perfectly honest, most people already use tools like SASS/LESS and have a build step in their workflow already, adding another one isn't complicated.
Link for lazy & curious: https://alibaba.github.io/weex/
> we have started an official collaboration to make Vue 2.0 the actual JavaScript runtime framework for Weex. This will enable users to write universal Vue components that can be reused across Web, iOS and Android! The collaboration is still in early stages, but it will be a big focus for us now that 2.0 is out, so stay tuned!
https://medium.com/the-vue-point/vue-2-0-is-here-ef1f26acf4b...
Vuejs seems like what React could've been if it was thought out a Bit more. It just feels a lot more polished.
Honestly I think Vue is so far ahead of the curve it isn't a surprise to see more people switch away from React.
That said, when an SPA is called for I'd far rather use Ember and get routing, state and a hundred other things for free, without needing to bolt together an entire front-end framework from parts each time.
It's great, and I'm grateful for it being around and for Evan's contribution but I think it was pretty lucky timing wise.
Star counts don't tell us everything but they're an OK heuristic of how many people are invested in a library at a point in time. Had Vue.js been in anyway meh it wouldn't have made such a dent in people's attention.
Timing luck, insofar as it exists, is probably weighted towards arriving later. Vue had a chance to listen to the market and solve some of the headaches that developers were voicing about incumbents. V2.0 is basically the best bits of Angular and React.
Again, lots of lessons for product creators.
That makes it pretty old. This is JavaScript we're talking about. :)
And Angular 2 is different enough from Angular 1 that it might as well be brand new. So I think the OP's comment is valid.
Vue is, in its core, very similar to Knockout (which I think is pretty swell). I think coupled with a better DOM abstraction (like React) it can do great thing - that's what MobX does and why I like it.
I sympathize with the post's sentiment of giving UI people work.