[ElatedOwl]

We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works.

TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen.

There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design varies pretty wildly. I think this is just the reality of a young framework casting a wide net, we'll see what the future brings.

It's not perfect, but like the author, Vue was a great decision for my team.

[heisenbergs]

vue 3 will be entirely rewritten in typescript.

https://github.com/vuejs/roadmap

[sheeshkebab]

And that will probably be the end of vue...

[exwizzard]

Why? The page clearly states:

Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.

[shados]

I haven't used Vue (and definitely not TS with Vue), but considering how easy it is to create type definitions for libraries written in ES6, if using Vue + TS is awkward (assuming its not because no one wrote a type definition for it), the only way it could make things better for TS users is with some refactorings to make sure types "follow along", and that totally would affect ES6 users. Anything that does not affect ES6 users would not affect TS users either.

An example of this is how in Redux, anything that uses the state in TS needs to add an annotation to type the store, because its completely decoupled (and thus theres no way for the state type to "follow"). Any way to make it follow requires some API changes (eg: creating mapStateToProp functions by calling a method on the store)

[blencdr]

have you even tried to use TypeScript on a real project to say something like that ?

[Ronsenshi]

He's possibly meaning that if you completely rewrite framework it would lead to something like what happened to Angular when it was rewritten and promptly lost huge number of followers/users?

[davedx]

Angular didn't lose mindshare because of TypeScript, it lost mindshare because they completely changed the API of Angular, meaning a bunch of companies had to do expensive ports/complete rewrites/switch to new tech. A lot of companies are still stuck on Angular 1 for this reason.

Most Angular devs I know are happy to use TypeScript. (In fact going out on a limb, most JS devs I know).

[darkerside]

In this particular case, with a BDFL in Evan, there's probably a much higher chance of maintaining sanity between major releases. People were worried about the change to Vue 2.0, but it mostly sunsetted features that complicated the framework and doubled down on an elegant component system. Seems obvious to say, but frameworks probably get fractured in geometric proportion to the number of powerful authors working on them.

[nightski]

That is amusing because Vue was already rewritten for V2 when they introduced the shadow Dom.

[SZJX]

Typescript is very similar to plain JS. The type annotation is purely optional. I really bought into the optional type annotation pattern when I learned and used Julia for a project. Typescript is also like that. It's extremely unintrusive to use and I'm quite sure such a huge shift as the one that happened in Angular won't happen.

[Fifer82]

Was that really a thing though? People cried because they didn't understand the offer of better tooling.

[rraghur]

I agree - the Typescript support isn't great... I was taking a look at vue + typescript and cobbled together something that worked but there was unpleasant weirdness.

I wasn't aware that vue3 was going to be written in Typescript - that is very welcome news.

[m_fayer]

Yes the weirdness introduced by TS, especially around vuex, is really jarring. But then again, last time I tried a new medium-sized Vue project in plain old ES6, I went running back to TS, weirdnesses and all. And bit by bit, especially with the evolution of vscode, vetur, and TS itself, the weirdnesses are getting better.

[ilovecaching]

I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?

[ppseafield]

For one: vue, vuex (centralized state library) and vue-router are stewarted by roughly the same people, which has a few benefits. The documentation is all pretty decent and uniform. I never sit for very long wondering how to do something.

Changes that break backwards compatibility are reflected across all three at the same time, and the correct versions are installed by vue-cli. I had several starts with react, react-router, and redux, and on almost every occasion something from my last attempt was broken because the api had changed, and the documentation changed with it (in the span of 3-4 months). That lead to several WTF moments. IIRC there was a period where react-router made some breaking changes from v2 to v3, and then less than a year later made more breaking changes for v4.

Vue is also a lot simpler to drop into an existing application. The .vue single-file component is very approachable, albeit a bit magic but about as magic as JSX. You can add a vue-loader for sass/less/etc. and simply specify lang="less" in these as well.

Vuex was a little easier for me to grok, although I had the advantage of trying out redux first. It has the advantage again of sharing documentation with the rest of the project.

Also, because react has worked for big companies as you mentioned, does not mean vue couldn't work for them as well. React gained a lot of momentum early among western programmers. Vue first gained traction in Asia - Evan You, the creator of vue, is from there. Also you might remember the massive amount of confusion for early React adopters regarding how to manage state. People liked react, but it only really had the view part ready out of the gate. Facebook's explanation of what the early-best-practice flux model entailed was vague, and there were several slightly different implementations.

[ilovecaching]

I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything. It's always been a library, not a framework, to give people to freedom of choice to choose or omit other libraries or frameworks.

I remember working on Angular 1 projects, where literally everything from loops to http calls was mandated by the framework. Then everything suddenly became legacy. Angular was going to be completely rewritten, and everything I had learned was going to be tossed away. I still, to this day, have to work with projects that are Angular 1 code rot hell.

I think that's probably why I have never had the problem's you have had, because I never wanted to use React Router or Redux. Those pieces of functionality were easy to implement on my own. (Redux itself is incredibly small)

Personally, I think it's silly to use Vue. Angular had serious deficiencies and project mismanagement, and React was a real solution to those problems. I mostly hear either minor grievances from the Vue crowd, or no response at all as to why they switched (hype train most likely).

I also don't think Flux was vague, it just lacked an implementation. Again, there just seems to be a big fear in the JS community about writing code instead of pulling in a framework. React itself is just reactive functional programming. The sell of not writing it yourself is that you get to work with a nicer API while the React team improves the backend for you (a la Fiber).

[zmmmmm]

> I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything.

You can't really have it both ways though: if you're going to say React doesn't do all those things then you have to accept that people who want something more streamlined and comprehensive should legitimately look somewhere else, and React is only for people who want to spend the time assembling their own solution (for some acknowledged benefits). Vue has taken the more comprehensive approach while still being pretty flexible, and therefore suits a slightly different (but I would argue, broader) set of people.

[ppseafield]

> I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything.

Ok, but people learning React - with no guidance from the library or its maintainers, as you said it's only the view - are going to search for "react how to route" or the like. They end up using things like react-router, and some of them run into problems like I did. You did ask originally what makes one easier to learn than the other.

> to give people to freedom of choice to choose or omit other libraries or frameworks. [...] Those pieces of functionality were easy to implement on my own.

And I listed some problems that I had using those other frameworks which were recommended to me. "Just do it yourself" isn't exactly helpful.

> (Redux itself is incredibly small)

Ok, but it has had some API churn as well - EDIT: I was wrong about this. See replies.

There's definitely boilerplate that goes along with it. There are libraries that deal with that to an extent, but there are many. Which one does someone learning choose?

> I remember working on Angular 1 projects...

What's that got to do with Vue? Vue isn't Angular.

> Personally, I think it's silly to use Vue. I mostly hear either minor grievances from the Vue crowd

I gave you my examples. You seem to compare only the view layer functionality. I'm examining the ecosystem and preexisting examples of how to implement functionality, which is going to be important for someone new to the library. Of course you can write this yourself, but for people trying to learn React, only having the view layer makes it more difficult to figure out how to "implement it on your own".

> I also don't think Flux was vague, it just lacked an implementation.

Not having any public implementation is pretty vague!

> There just seems to be a big fear in the JS community about writing code instead of pulling in a framework

Well, again, my response was from the perspective of someone learning React and how one might architect a SPA using it. As stated, there was no official flux implementation in the beginning, just a diagram from Facebook and some hand-waving documentation. Vue has official and router library and state management library which are linked to from the official documentation.

> React itself is just reactive functional programming. The sell of not writing it yourself is that you get to work with a nicer API while the React team improves the backend for you (a la Fiber).

You can apply this your own argument. React is just reactive functional programming. Why just pull in a view library when you can just render using functions? Why not write it yourself, if you're writing everything else yourself? Are you afraid to? Why include a 240kb library to render functional components?

What do you get out of using React over Vue, which also uses the virtual DOM and has functional components?

[acemarke]

> Redux has had some API churn as well

Uh... what API churn? The Redux store API hasn't changed meaningfully since about a month after its 1.0 release. 3.0 came out around September 2015, and it's been the same since.

React-Redux has stayed API-consistent too, even though we rewrote the internals for 5.0.

[ppseafield]

Ah, It seems I was very unlucky as I started learning it right before 3.0 and tried to pick it up after 3.0. Upgrading my previous project gave me strange errors, and the documentation had changed with it, leaving me to puzzle over what had happened.

[ElatedOwl]

Netflix, Walmart, etc. solve a much different set of problems than most shops. I'm proud to work for a small company with simple (but rapidly changing) requirements. :)

[ilovecaching]

That doesn't answer my question. What about Vue actually made it a better choice for those requirements? In my experience, the fact that React is a simple view library makes it the perfect choice for small shops. You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.

[ipntu]

> In my experience, the fact that React is a simple view library makes it the perfect choice for small shops.

Vue is also a simple view library.

You keep bringing up Angular, as if Vue has something to do with it. Vue is so much closer to React than to Angular.

> You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.

Sorry, but that sounds a lot like rationalization and wishful thinking, written purely to make React look good and anything else look bad.

Vue also has backers that contribute financially, a large community using it and sustained development. The fact that it isn't as big as React doesn't make it unworthy of existing or unable to provide the same technical benefits as React.

[mmargerum]

I evaluated react/redux and vue/vuex for a project . I wrote a small poc in both. This is why I chose vue

1. Js doesn’t support immutable data structures so trying to return a deeply nested model using spread and other things was ugly. The answer seems to be “flatten your data”. I didn’t have to flatten my model with vuex. Vuex uses mutations when I can keep a flat model of observable but also keep my pristine model that I can send back over the wire with no changes . I suspect mobx may do the same sort of thing for vue. I feel like the react pattern would work better with a language like clojurescript that actually has immutable data structures.

2. Prefer html to Jsx although vue does support jsx. Admittedly this is just a preference thing.

3. Less boilerplate. I felt like I was writing more code that didn’t really do anything useful in react/redux. Vue seemed to have the smallest ceremony to code ratio.

4. Vuetify seemed a lot easier to use and was more polished than the react counterparts. I know it’s just a widget library but I found it fantastic and the docs were great. Vue slots are a great idea

5. Documentation . Vue has second to none documentation and this is important when you are starting out

I build a medium sized app in vue and was astounded that I literally did not run into one issue. That has never happened to me in 30 years. Kudos to that team.

6. React router was on its 4th rewrite. I can’t deal with constant breaking changes

7. Router and vuex felt more cohesive and integrated into vue

Whatever you choose please do support these guys on patreon!

[darkerside]

> You're taking on considerable risk when you use a technology without a vested backer

I hear this line a lot, and it reminds me of Warren Buffett's line about finding out who's swimming naked when the tide goes out. He's referring to unprofitable companies that get exposed during economic recessions, when their stock prices are no longer boosted by generalized positive sentiment (I'm oversimplifying).

In this context, I think frameworks get exposed when big company support gets withdrawn. Angular didn't always look like an abandoned beached whale. Initially, having the backing of Google made it look like a de facto obvious choice. But when support from a large backer wanes, it quickly accelerates the demise of a framework as what the halo effect previously presented as well-considered design choices are suddenly recast as clear mistakes in hindsight.

This might never happen with React. But if it does, it will be swift and loom with unmistakable signs in the rearview mirror.

[RussianCow]

That doesn't really answer the question. :) How does Vue let you deal with "simple (but rapidly changing) requirements" better than React?

[linkmotif]

Not really. It’s all the same set of problems.

[jgrpf]

Apart from anecdotal experience telling me that fresh JS devs have a much easier time with Vue than React, I love to still have the option to use it through a simple embed without a build system but can switch to a Webpack/any module bundler if the requirements demand it.

The JS ecosystem really has a problem with bloat in my opinion and Vue trumps React in the regard (react eject anyone?).

[acemarke]

It's worth noting that React has _always_ been something you could add to an application with just one or two script tags, and the docs were recently updated to emphasize that use case: https://reactjs.org/docs/add-react-to-a-website.html

[jgrpf]

But writing React without JSX is really not that great in my opinion whereas writing Vue without any preprocessor is totally fine. I know there's the option to use a JSX browser compiler but it's not recommended for production.

[Kihashi]

Coming from back-end dev, I looked at both. React looked hard to learn because I (thought) had to pick up a huge amount of tooling knowledge. Vue looked easy to learn because its docs promoted a very incremental and piecemeal approach. I didn't need to learn about front-end tooling to build something useful. I started learning Vue. It was easy to learn. I haven't had a compelling reason to try React since then.

[keerthiko]

Our company used React when starting a new project, but we still had an existing project with a vanilla HTML/CSS/js website, which really needed a rewrite. I had a talk with my cofounder about the strengths and value of React, but hadn't dived deep yet - I wasn't working actively in the codebase of the new project. I tried to, and all the moving parts were monstrous to wrap my head around - states, redux, actions, whatever, even though I thought I understood the fundamentals of the reactive paradigm.

My cofounder suggested I check out vue for the rewrite of our legacy project, and I was able to onramp SO easily. I can easily hand off components to other team members to write, and it rarely broke stuff in the rest of the project. On the whole, vue feels a bit less powerful but a LOT simpler to wrap your head around while subscribing to the reactive UI paradigm.

[ilovecaching]

You're talking about Redux, not React. Your website would have probably been fine with just React. React gives you the choice to avoid needless frameworks and choose the level of abstraction that best fits your project.

[keerthiko]

Nope, I'm talking about react. I'm aware redux is just another step in the "level of abstraction you may want to use". And the problem is that every level you want is a challenge to get started with in React.

For example, JSX is an abstraction level I'd like to use. It requires an npm install to set up to contribute to production code. It has already crossed the threshold of an easy on-ramp for say, an intern -- because if this involves a first-time npm set-up on their machine, there goes the rest of the week.

With Vue to start using another feature/abstraction layer, you never have to do additional setup (your html file includes the vuejs script already), you just read the syntax docs and get going.

Additionally, React (and redux even more, yes) involves much more boilerplate than Vue does for every new feature you want to use, which is often more verbose/obtuse and hard to parse for a junior web developer.

[acemarke]

Looking at the Vue docs at https://vuejs.org/v2/guide/render-function.html#JSX , it specifically says using JSX with Vue requires a Babel plugin. How is that any different than React?

[ilovecaching]

Your interns take a week to install npm? Good lord.

Sorry, in your last post you specifically mentioned only terms that apply to Redux. React has no concept of actions, reducers, etc.

If you read my top comment I specifically talk about React’s function component, which is the least verbose way to describe an interface across any framework. Unless you can think of something easier than (props) => <h1>{props.name}</h1>

Honestly you just need new interns.

[mcintyre1994]

> it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering.

I'm curious whether Facebook actually have any endpoints where exceedingly fast rendering is necessary because it'd be the bottleneck. Facebook tends to be really slow for me but I figure that's down to it being really slow fetching data.

[dangerbird2]

Typescript support has gotten much better in the past few months. In particular, the vue-cli scaffold provides the correct stubs so typescript doesn't freak out when importing single-file components.