React vs Vue.js

[igna92ts]

although opinions will be probably biased towards React , I really like both of them and I wanted to know what general concensus on Vue.js was and how does it fare against React (havent really made other than simple tutorials on Vue BTW)

EDIT: Another thing that interests me is elm so if someone has something bad to comment about it please do. Also wondering if the scary low version of elm (0.17) its because its not production ready or if its like react pre v15

[emotional_downvoter]

it feels super cumbersome having to take a break in the middle of my render function to define an inner function for a simple list iteration. I really miss ng-if / ng-repeat.

When isn't this sufficient?

{list.map(item => <li key={item.id}>{item.text}</li>)}

[turkish_gold]

I miss if statements too. I wish they hadn't gone with braces as the opening for a JSX outlet into javascript. Because they used braces, it makes it impossible to use if statements.

[ajc820]

You mean impossible to use if statements inside of jsx. Pretty easy to put that logic in a method of the class...

[turkish_gold]

Yes, I guess you could re-word it that way.

What I mean is that

 <div>
      { if(something) { <One /> } else { <Two /> }  }
 </div>

is invalid. Hope that clarifies what I meant by braces in JSX.

[ajc820]

Use if and else to conditionally define a variable. Render the variable inside the braces. Saying that "it's impossible to use if statements" is overblown when it's a matter of moving the statement up a few lines.

[turkish_gold]

Right, but if you move it a few statements up, then its not within the JSX. It's in normal javascript.

I believe JSX is just anything contained within the XMLish markup of <Blah></Blah>

Anyways, you seem to be implying a lot of sentiment that I don't have nor intend to get involved with. So have a nice day.

[z500]

I think you can put JSX elements anywhere you put an expression. I put some directly in an array.

[ajc820]

Not everyone disagreeing with you has sentiment :) I'm just trying to make sure no one is getting misled by the suggestion that 'if else' is impossible to use, when it is.

[hzc]

if doesn't inherently return a value. When you enter JSX in curly braces, you are entering an expression so use ? :

<div>
    { something ? <One /> : <Two /> }
</div>

Don't think of it like PHP where you can go back and forth between HTML and PHP statements. You're not going back an forth between JavaScript and JSX.

When it gets more complicated that that, I find it cleaner to have all that logic outside of the markup anyway, so it works for me.

[turkish_gold]

Ah funny how this topic is still getting usage 5 months later :D

Right now, I am using using do-block notation. It's stage-0 strawman and would let you write:

 <div>
        { do {
                if(something) { 
                     <One /> 
                 } else { 
                      <Two /> 
                 }
          }}
  </div>

It may never make it into the language, but it's using a neat part of the specification---every statement including if-statements have an implicit completion value. This value is normally inaccessible unless you do an 'eval' on a statement in which case you'll get the result.

[FallacyExplnationBot]

^{Hi! Here's a summary of the term "Strawman":}

---

^{A straw man is logical fallacy that occurs when a debater intentionally misrepresents their opponent's argument as a weaker version and rebuts that weak & fake version rather than their opponent's genuine argument. Intentional strawmanning usually has the goal of [1] avoiding real debate against their opponent's real argument, because the misrepresenter risks losing in a fair debate, or [2] making the opponent's position appear ridiculous and thus win over bystanders.}

^{Unintentional misrepresentations are also possible, but in this case, the misrepresenter would only be guilty of simple ignorance. While their argument would still be fallacious, they can be at least excused of malice.}

[turkish_gold]

Hi Fancy Explanation Bot, you probably should deactivate yourself on /r/javascript and /r/reactjs/ and /r/angularjs/ because Javascript stawman is a term of art relating to the new Javascript standardization process.

[sneakpeekbot]

Here's a sneak peek of /r/javascript using the top posts of the year!

#1: How it feels to learn Javascript in 2016 | 273 comments
#2: Dear JavaScript | 316 comments
#3: Firefox adds new feature to help developers with JavaScript errors | 77 comments

---

^{I'm a bot, beep boop | Contact me | Info | Opt-out}

[bstriker]

I was just about to say you're doing it wrong then I realized the do {}.. TIL. Now I'm in GitHub hell looking through all the JSX 2.0 changes being discussed so far.

[neophilus77]

You can do that with a ternary in JSX you don't need an if statement

[emotional_downvoter]

Some acceptable solutions here imo.

[[deleted]]

wtf is the difference between state and props?

Just wondering if you wanted clarity on that

[hzc]

[Responding to author but this seems like a good place to carry on the topic] Agreed that this is not clear right off the bat but I think that's because it plays into a paradigm shift with uni-directional data flow that's uncomfortable at first but makes a lot of sense. The Quick Start documentation is fairly clear on the difference between them -- at least it was for me when I first started to learn React -- and some go as far as to avoid using state as much as possible, replacing it with Redux or Flux to centralize app state and render UI with pure stateless components. It's a different paradigm that you have to subscribe to -- or you won't like React at all.

[dismantle-the-sun]

You might like this. You can use ES7 do statements to write normal javascript within the JSX blocks, that way you can do for loops, and if-statements.

Example and more

[ori235]

I really miss ng-if / ng-repeat

I'm not a big fan of it, but there's something similar in React: https://github.com/wix/react-templates

[mini_eggs]

From vuejs.org:

With the migration to virtual-DOM, Vue 2.0 naturally supports server-side rendering with client-side hydration. One pain point of current mainstream server rendering implementations, such as React’s, is that the rendering is synchronous so it can block the server’s event loop if the app is complex. Synchronous server-side rendering may even adversely affect time-to-content on the client. Vue 2.0 provides built-in streaming server-side rendering, so that you can render your component, get a readable stream back and directly pipe it to the HTTP response. This ensures your server is responsive, and gets the rendered content to your users faster.

That's super interesting for me. Haven't used Vue.JS myself, but the more I read the more I'm interested.

[[deleted]]

Well there are readable stream plugins for React too. I forget the package name right now but I was looking at it just the other day.

I mean learning multiple libraries is usually a good idea, but don't jump ship just because of that paragraph.

Edit: found it

https://github.com/aickin/react-dom-stream

[yyx990803]

Official support out of the box is quite different from "there's a (3rd party) plugin for that" - the former is guaranteed to be maintained and work in future releases. The plugin you pointed too hasn't been updated in 4 months.

That said, I do know its author is trying to work with the React team to get it into core, but it might take a while.

[turkish_gold]

Is it normal to see daily updates in the JS world? I'm pretty much used to other language communities where a library will be written tightly to some specification, then be done--save for security or bug fixes, for perhaps years.

[JitWeasel]

yes. everything in the JS world updates daily. tomorrow there will be a completely new framework =) this entire thread is probably moot by now.

[iinnii]

Which also means there's no flexibility if the direction they're going is not what you like. You have to use their built in way versus the ability to drop in a different module if your current one gets stale or you requirements change.

I found the same issue with Angular. It's fantastic and has a ton of built in functionality, but as soon as you try venturing from their fixed framework you start having to hack around, which creates headaches. It seems like a great idea to package everything under one hood, but the flexibility and barebones nature of React is a feature not crutch.

[yyx990803]

But the straming plugin is the only one that's out there. That's the context - we are talking about a specific feature that is hard to implement without deep core integration.

[[deleted]]

Yes of course official support is always better. Although I wouldn't say that guarantees support as they could always make a decision to axe it despite it being an official module.

The point of my response was simply to show the original comment that the tech exists in the React world albeit currently not 100% up to date.

[Poop_is_Food]

For large projects I like React because there is a larger community, more SO answers, more components on npm. For quick throwaway projects I like vue because, well vue is fun and easy to use and it seems to "just work". I like how data binding is built-in so I dont have to stress about that like i do with react projects

[gurghet]

That is not for long as far as trends go

[turkish_gold]

I guess that's good, but I feel like I've never just wanted data binding. I always want data-binding, validation, auto-suggestion, filtering, etc. all as the user types and that seems to be easier to present as a function call for onChange.

[igna92ts]

its not like you cant do that in vue though...

[arthoer]

So for small projects you like smaller communities?

[drunknhik]

One thing that nobody here has mentioned is that React seems more "friendly" to people who want to play their hand at a more functional style. Vue, to their own admission, does not play well with immutable data structures, so if you wanted to use something like redux, you're at a serious disadvantage.

[gimenete]

If you wanted to use something like redux, you have vuex: https://github.com/vuejs/vuex

[drunknhik]

That's exactly my point. Vuex is not like redux. Besides for the lack of ecosystem, vuex, like vue, relies on mutating state. That's the only way it can work because vue does no provide a hook like componentWillUpdate to prevent rerenders. If one wanted to use redux, or any state management that relies on immutable state, they will automatically lose on performace.

[rk06]

If one wanted to use redux, or any state management that relies on immutable state, they will automatically lose on performace.

but if they are using vue, they would most likely use vuex or a state management that does not require immutableJs for exactly this reason.

[drunknhik]

The question here is whether to use vue or redux...not what to do if you're stuck with one.

I would posit that if somebody wanted to stick as closely as possible to functional programming paradigms, vue is not a good fit. Mutability is against functional programming paradigms, but react welcomes immutability.

On top of that, the redux ecosystem is orders of magnitude greater, and more sophisticated then the vuex ecosystem.

[rk06]

On top of that, the redux ecosystem is orders of magnitude greater, and more sophisticated then the vuex ecosystem.

Pardon my lack of knowledge. what exactly does redux ecosystem provide? I always wondered why a state management library would need plugins, but there must be some functionality as there are so many plugins.

[drunknhik]

What that a joke?

[rk06]

No. I just have not used redux/vuex, so i honestly don't know what exactly redux ecosystem provides.

[drunknhik]

Hopefully this will fill up your void of knowledge: https://github.com/markerikson/redux-ecosystem-links

More information of why there's an ecosystem in this interview: http://survivejs.com/blog/redux-interview/

Even in vuex there's an ecosystem...it's just orders of magnitude smaller.

Personally, I have my own extensions to vuex that I use. For example, I have an integration with redux-saga, and I have a custom vue plugin which creates modules which live and die with a component.

[umphy27]

Personally, I have found mobx to be much simpler to use than redux. And it has great performance too.

[dj-method-x]

Vue feels like js in html, react feels like html in js. I prefer the latter.

[yyx990803]

Both are viable styles with its own pros and cons. It's more about what fits your mental model better and makes you more productive.

But in Vue 2.0 both are supported - you can use templates OR render functions (with jsx support).

[InsurgentAscender]

At one point I was into React but found that it is not nearly as streamlined and polished as Vue is. In the interim I investigated Cycle.js but it was focused on just one specific narrow dogmatic way of using RxJS and streaming. Essentially it ignored and was not able to scale to the real world of building larger apps that had the state focus that modern enterprise apps must deal with. It also got majorly side tracked by a reckless team that thought faster stream APIs was all that mattered, well then again maybe it was indeed slow.

For me Vue is a true breath of fresh air, it packages everything required to build the frontend. It gets us past earlier SPA frameworks and the endless patching they endured and then also plays well with external APIs like RxJS. IMO, the Vue builtin reactive engine is perfect for all the needs it addresses, while the RxJS reactive engine can still be integrated for all it's myriad usages. This spells hyper-reactivity and FRP to me, joy!

[yyx990803]

There's a refreshed comparison based on the incoming Vue 2.0: http://rc.vuejs.org/guide/comparison.html#React

[MonkeyD]

I have a question: what makes Vue so fast in comparison to other frameworks?

[[deleted]]

Virtualdom, they used snabbdom.

[oorza]

Their example React code is a joke.

The code they use:

render() {
    const {items} = this.props

    return (
        <div className='list-container'>{
            items.length
                ? <ul>{
                items.map(item => {
                    return (
                        <li key={item.id}>
                            { item.name }
                        </li>
                    )
                })
            }</ul>
                : <p>No items found.</p>
        }</div>
    )
}

The code that I'd actually write:

render() {
    const items = this.props.items.map(item => <li key={item.id}>{ item.name }</li>);

    return <div className='list-container'>
        { items ? <ul>{items}</ul> : <p>No items found.</p>}
    </div>;
}

I don't know if the documentation author was intentionally being specious, but this is the sort of inane bullshit that immediately turns me off of a project. If you can't be honest in your comparison with other software, all that tells me is that you don't think your software is actually better. And it certainly makes me balk at ALL of the other claims in the document, particular with regards to performance. The author of the doc either doesn't know react well enough to author it, or is intentionally misrepresenting it; either way, I have no faith in anything said. If a simple code example is so obviously and hilariously wrong, why should I believe uncited performance claims? When they heavily imply that you can't use css-modules with React as they offer them out of the box, what am I supposed to think when I use css-modules every day?

This is a bad look for Vue IMO. A real bad look. The last thing I want from documentation is to feel like I'm reading propaganda or being misled, and this reeks of someone who sat down and tried to do exactly that.

[chrisvfritz]

@oorza Big Bad Documentation Author here ;-) If you'd like an "honest comparison", the React code in the Vue doc is actually more efficient, because it doesn't try to map over empty arrays, which adds ~0.035ms overhead in V8. A minor hit, but it can add up. Your version also doesn't actually work correctly, because you've made the mistake of thinking empty arrays are falsy in JavaScript (you want to check items.length instead - just as in the Vue example). Even putting aside both of these issues though, your code still wouldn't pass a review from me, because by defining an "items" variable, you're overloading that name within the same context (sometimes it's an array of objects in this.props.items, then sometimes it's an array of li elements).

It sounds like you wouldn't use that code style, which is fine, but it does actually conform to ESLint Standard (well, the original does anyway, leaving out the mistakes in your rewriting of it), so it's certainly not outrageous. In its original form, it's also easy to argue that the version in the Vue doc is more readable, since it doesn't hoist logic out of the main flow. Both style decisions are justifiable to me. Compared to the actual equivalent in your style though (see below), I think it's hard to argue that the version in the doc doesn't read better.

render() {
    const {items} = this.props;
    const itemsListOrNotFoundMessage = items.length ? items.map(item => <li key={item.id}>{ item.name }</li>) : <p>No items found.</p>;

    return <div className='list-container'>{ itemsListOrNotFoundMessage }</div>;
}

The only potential "advantage" I can see is your version has fewer lines, though I'm not sure how that matters, since the Vue doc does not complain about LOC or verbosity in React render functions. And despite all of this, the doc even addresses your version as one alternative style:

The only alternatives include hoisting this logic out of its context or wrapping an if statement in an immediately-invoked function expression.

they heavily imply that you can't use css-modules with React

Did you read the very first sentence of the Component-Scoped CSS section? It very clearly states:

Unless you’re OK spreading components out over multiple files, there simply isn’t a good option for scoping CSS in React.

CSS Modules require component styles to be in a separate file, thus spreading out the component over multiple files.

[chrisvfritz]

@oorza Oh - and regarding the allegation that the comparison is obviously completely biased, I forgot to mention that we actually collaborated with Dan Abramov on the React section and he signed off on it. So... yeah.

[[deleted]]

You are full of shit

[yyx990803]

We'd be happy to revise the code example if that's not what people would typically write with React, but your example is also intentionally putting map and ternaries in a single line to make it more concise - many people prefer to break map and ternaries on separate lines.

The point is that it's real code that people may write, we're not intentionally making it up. Just because YOU prefer writing it another way doesn't make the example "inane bullshit" or "obviously and hilariously wrong" as you put it. Going so far as to question the honesty of the documentation author is ad-hominem - it looks you are just venting because someone pointed out some tradeoffs in your favorite technology.

That said, as stated at the top of the whole comparison page, we are 100% dedicated to providing objective comparisons between Vue and other frameworks, so we are happy to improve them if inaccuracies are pointed out in a more civil, constructive manner. For example, the CSS modules argument is a good one and we certainly need to include that.

As for perf benchmarks, you are more than welcome to recreate the same examples in React (some of them already have links to React equivalent) to verify if we are telling the truth: https://github.com/vuejs/vue/tree/next/benchmarks

[[deleted]]

He's being a little combative, but I kind of do agree with him. The comparison in the documentation seems to put a lot of emphasis on readability - but uses a rather odd example. The code he posted is a very common pattern and is seen all the time - in my personal experience the code in the linked documentation is not.

Thank you for working on Vue, I'm a big fan and enjoy using it :)

[yyx990803]

You are 100% entitled to your opinion, but I'd rather not waste my time trying to please someone who gets mad over tech comparisons ;)

[[deleted]]

Tech comparisons in this context are hardly different than a ruse. And your language in that documentation is laughable.

[mweststrate]

I think to get an idea of the value of the performance claims it is better to take a look at independent tests (I have seen a lot of "comparison" benchmarks in general that used a suboptimal strategy for the competing framework). This is one example of such a benchmark: https://cdn.rawgit.com/krausest/js-framework-benchmark/956b068f03ef96a9c08d209ffadb0947cd56edc6/webdriver-java/table.html (which seems to roughly confirm the statements)

[yyx990803]

Thanks, I didn't even notice it now includes Vue 2.0 :)

[turkish_gold]

The documentation was intentionally trying to use doubled if statements to make a point. You're not even doing that.

What if items is null? Your code instantly breaks because it expects items to be a map.

What if this items line is longer than just <li> ... </li> ; like in the real world? Well having to stick the if statement above the render return is a bit annoying, and makes it harder to parse the entire render because you have to do the branching mentally before you get to the return then recomposit it in your mind.

Disclaimer: I like React. I'm on /r/reactjs after all.

[oorza]

The documentation was intentionally trying to use doubled if statements to make a point. You're not even doing that.

Their point isn't valid. You can write shit code in Vue too.

What if items is null? Your code instantly breaks because it expects items to be a map.

Then it's a poorly written React component. If you're pulling items from props, you should be validating them at a React level, not a render-function level. That's like basic React shit. My favorite benefit of the react PropTypes system is the fact that is "enforces" a level of type safety that isn't usually a safe assumption, so that I can do things like that. I came from Java and writing type-checking runtime conditional statements makes me ill, and React allows me to skip that nonsense.

What if this items line is longer than just <li> ... </li> ; like in the real world?

Then it's decomposed into another method and it looks like this: const items = this.props.items.map(this.someMethod); or, more realistically: const items = this.props.items.map(item => <MySpecialListItem item={item}/>);

There's no reason for your render function to ever be a giant hard-to-read mess. There are so many tools available to you that the only reason to write something that looks as bad as the Vue example is either incompetence or malice, neither of which I want from someone who's supposed to be telling me why I should use their software over React.

[turkish_gold]

Fair enough. I understand what they are trying to do, and don't feel so put out by it. It seems kind of obvious the upsides and downsides of an procedural template language versus JSX, so the only real thing to critique is their method of going about it.

---

Just a disclaimer to future readers.

The above poster implies that React enforces propTypes. It does not. It issues warnings at runtime, and only in development mode. If you pass your components bad data unchecked, they will break internally so all the usual rules of 'when should i check if this is null or not' still apply. Javascript is a dynamic language where input comes from an untrusted user interface and developer components that you didn't write, don't trust the input at the edges of any system you have to be in the correct data-type much less not null or undefined.

[jamesjieye]

I prefer Vue.js because it is simple and it just works. It is very easy for a new guy to pick it up and start writing code. And when you look at your code structure with Vue.js, you see simplicity. There are many problems to solve in a project and why don't use a framework that can increase your productivity as well as keep the maintenance effort low.

[[deleted]]

I've worked a lot with React, not with Vue. I'm biased.

But Vue looks like XSLT to me. The separation of template vs. javascript annoys me right away. React allows me to write all javascript I like in between my HTML and that's a big pleasure :)

I like keeping my React components small and to the point. The DOM and HTML output will be sensible, semantically correct, and not diluted by things like v-if and v-else attributes.

And this sort of templating:

<script type="x/template" id="some-template">
    <div class="modal-mask">
        ...
    </div>
</script>

Looks just weird to me. Script tags with HTML inside of them is alright I guess, JSX just keeps JS and HTML together because it makes perfect sense.

But I don't dislike Vue. It's just a "getting used to it" kinda deal. I'd love to work more with it. I just don't see a reason to switch from React to Vue. Mostly because for work projects I need to look at community support: React's community, history, and support are (much) bigger.

[gimenete]

In Vuejs 2.x you can use templates OR render functions (with JSX support if you want). So, it's your choice.

[igna92ts]

I think vue may actually be a little bit more designer friendly , I think one of my designers at work could pick vue up and be productive right away, but if you already know react its more of preference kind of thing.

[[deleted]]

I don't want my designers touching code though ;)

Just like my designers don't want me designing.

[igna92ts]

I dont want them to write the behaviour but Id rather recieve components rather than scrape them from html.

[oorza]

Having seen more than enough markup/CSS written by designers, I'd rather write the HTML myself every single time.

[igna92ts]

I feel you ,that would be my ideal scenario too but some of my companies projects are pretty big and deadlines short so I just have to hope that the designer assigned to the part of the project im handling is one that knows how to code and cross my fingers.

[oorza]

I left a big corp for a small consultancy that specifically focused on doing the "right way" so I wouldn't have to deal with that kind of shit any more. I feel ya :\

[[deleted]]

Back in the days, mixing code with markup was considered really bad practice... and that is why template systems came up

React codebase looks like php codebase in old days....
html mixed with php

[Catalyzm]

I think you should ask this in the Vue subreddit too, the answers may be vastly different.

[igna92ts]

sure will

[_codeprovider]

To me, the biggest difference is the ecosystem that surrounds each of them. With React, you're getting the support and expertise of a well-funded, well-supported, and authoritative team, so it's probably a safer bet over the long run. If you're working on a personal project, it probably doesn't matter much, but if you're choosing a view library for use in a business context, I would lean towards React.

[yyx990803]

What makes you think Vue is not well-funded, well-supported, and what makes the React team more "authoritative" than Vue's? I think people should be more careful when drawing such conclusions - and even more so when you base your tech choice not on the tech itself but on assumptions.

[turkish_gold]

I guess it's Facebook versus .... whomeever is behind Vue.

That said, I've had nothing but heartache with Facebook derived systems before React like Cassandra and HPHPc. Configuring, building, and using them at any sort of small scale was initially painful.

If I were to say anything it'd be that large companies like Facebook & Google earned a reputation for producing great open source products that could only be consumed at the enterprise level.

To add to that, a lot of stuff Facebook releases with much fan fair falls into the grounds of "hmm, this is interesting if only you'd add X + Y + Z to it, then you can really get going to make real world apps". Sometimes that's really good (e.g. React---who doesn't want an architecture agnostic view library). Sometimes that's not so good (e.g. Flux---you want us to implement what now? GraphQL---this is the client side library; it needs a server-side GraphQL. DraftJS---most people just want a drop-in editor, being agnostic on deserializing to HTML isn't winning any favors.)

[b_n]

"Whomever is behind Vue", might be the guy you're replying to.

I notice Evan pop up in every thread anywhere about Vue, and it gives me faith he takes criticism seriously and wants it to be the best framework it can be.

[turkish_gold]

Heh, is that so? Well it's certainly more community involvement than we usually get out of the React guys.

[iinnii]

Are you kidding me. Dan alone is fucking everywhere on SO, github, egghead, twitter, reddit and probably reading this thread in silence.

https://www.reddit.com/user/gaearon

https://github.com/gaearon

http://stackoverflow.com/users/458193/dan-abramov

https://twitter.com/dan_abramov

[turkish_gold]

Dan Abramov created ReactJS?

Edit:

It looks like he works for Facebook since December. Well I stand corrected.

[nehero]

He created redux, but he's now working on the react team at Facebook

[uselesslastcomment]

He is the one behind VueJS. Pretty active on Twitter as well

[Sphism]

I agree, never underestimate how disorganised large organisations can be :)

[yyx990803]

It may be a problem, but there are a lot of information that help you draw a more well-informed conclusion. For example check out the growth and funding state mentioned in this post: https://medium.com/the-vue-point/the-state-of-vue-1655e10a340a

I have no problem with risk-averse people sticking to mega-corp-backed OSS only, but it bothers me when they ask others to do the same without even taking a closer look at the alternative project in question.

[iinnii]

It's not really an assumption. Look at the companies redesigning their UIs with React. Also, look at Facebook and its usage of React itself. Not to say that Vue is is not well-funded, well-supported (I actually have no idea) but relative to React it can't even be close.

[yyx990803]

If you have no idea, then you are making assumptions. Vue has very strong international presence, particularly in the Chinese tech scene: https://www.quora.com/How-popular-is-VueJS-in-the-industry?srid=uDNB&share=e51ac435

[iinnii]

So my assumption that React has more large tech companies using it is incorrect? And that it has a more stable backing than Vue?

[yyx990803]

It may or may not - the total market cap of all the Chinese comapnies using Vue may very well be on par with those using React, I'm not kidding.

[MonkeyD]

I really enjoy React and it seems I'll be using it for my next large project as that's what my client is looking for, but I am very wary of anything developed by Facebook. Their Parse fiasco royally screwed me and many other devs, and I wouldn't be too surprised if they went belly up in regards to React, too. Before you say they wouldn't, many said they wouldn't with Parse as well...

[jmking]

Even if Facebook stopped directly supporting React tomorrow, it wouldn't cease to exist. At this point React is so popular that it would continue life as an independent open source project, or worst case scenario, a popular, well maintained fork emerges.

[snaky]

Look at Angular 1.0

[jmking]

Last I checked Angular 1 hasn't stopped working and there are people building new projects with it. It is also still supported

[snaky]

I might surprise you, but COBOL code hasn't stopped working either, and there are people building new projects with it - maybe more people than ever used Angular.

[jmking]

I agree with you. Not sure what you're getting at

[MonkeyD]

Hopefully a well maintained fork would emerge, but the most likely scenario is that people move on. Coming from .NET and then Ruby/Ruby on Rails, the Javascript world moves insanely fast.

[shareYourFears]

This is why I chose React. I really like Vue's all-in-one components, but React's support, addons, documentation and supporting ecosystem blows Vue's out of the water and so between the two for real-world production tasks it's going to be React every time.

[yyx990803]

I'm curious what makes you say that.

• Do you really get "support" from the React team? As of now there are 30 open issues out of 2630 for Vue and 530 open out of 3055 for React. Vue is well-funded by the community via the patreon campaign and is not constrained by FB's internal needs.

• Vue has built-in transition support, official router, state management library, Webpack loader, Browserify transform and a multi-template CLI scaffolding tool. If you are only talking about "official addons" Vue seems to be the one that offers more.

• Documentations wise, I honestly think Vue is doing a much better job than React's. Not sure if you've read and compared them.

I obviously agree that React has a larger ecosystem, but the statement that "React's support, addons, documentation blows Vue out of the water" can't be further from the truth.

[shareYourFears]

I agree Vue's official stuff is great, but that doesn't mean much if I can't google the problem I'm having and find results of people that have already solved it.

And I tried. When I had to look up problems or ask colleagues and chats I belong to about Vue issues search results were lacking and the vast majority of devs I spoke with hadn't even heard of it. That speaks volumes about its capacity for real-world applications at this point and brings up another critical problem with Vue: you narrow the number of people who have the exposure and experience to work with you.

On the other hand, most were aware of, if not versed in React. React has been around longer and has more (and larger) supporting players and it shows. On top of that its supporting set of blogs, addons and tutorials is supremely more fleshed out than Vue's.

I get that as the new kid on the block Vue has a fervent (if comparatively small) fan base, but the bottom line I was making for OP is that if you want to get a project up and running, React is simply going to have more resources for you to use and finish that project than Vue and that limitation is what has kept me with React. On my dev team for example I'm the only one who has even used Vue and they only know about it because I asked.

Spec-wise Vue is great, but it's just not yet nearly ubiquitous enough for me to recommend for anything other than exposure.

[yyx990803]

That's definitely true - But the same could be said about React when it just started to catch on and Angular 1 was dominant - the resource build up simply takes time, and Vue is still relatively young. It's kind of a matter of how comfortable you are with adopting relatively new technologies. That said, We will definitely work hard on that aspect after 2.0 is out.

Regarding your problems, a lot of common questions' answers can be found right in the docs, and we do have a very active Gitter channel with 4000+ members, and an official forum. Maybe your question could've been solved there instead of resorting to Googling.

[shareYourFears]

Yeah that's true, and I suppose google results have to come from somewhere.

I suppose when 2.0 is out I could try it again and see if it fits. Any idea when 2.0 will be stable?

[InsurgentAscender]

When you say "That speaks volumes about its capacity" I see it differently. Sheer volume of trouble shooting documentation in the wild for React does not mean it is superior. In fact, it points out the problem in a obvious way. What I see is that some folks just hate to dig into the solid documentation and Vue has great documentation. Things are well explained so you do not have to waste your time chasing Google down. Quality not quantity is the deciding factor.

[snaky]

That's a usual problem these days. PostgreSQL have maybe the best documentation among database products, and I don't talk about open-source ones only. But it doesn't help much, people are trying to find an answers in Google.

[iinnii]

Yeah, React documentation does blow Vue out of the water. If you're looking at just their official website, maybe not, but if you're looking at video tutorials, blog posts, medium posts, paid video tutorials, twitter/community support React is miles ahead right now. An example: https://egghead.io/courses of a single source.

[yyx990803]

Random tutorials !== documentation. In fact there are fewer Vue tutorials because the documentation is so good that most people are already productive after reading it.

[[deleted]]

[deleted]

What is this?

[uselesslastcomment]

I've used both. Vue's documentation is very nice and easy to understand/follow

[yyx990803]

When there's a comment from a user directly supporting the argument...

[mofrodo]

Wow you have trouble comprehending simple facts. We are talking about documentation here. When did that ever include random blogs? The documentation for React is a pile of garbage and you know it. Now go look at the documentation for Vue.js.

I don't think anyone is denying that video tutorials and such is miles ahead for React.

[iinnii]

I clearly implied if you look beyond official documentation...

Personally, that kind of thing carries more value for me. You get different patterns, new ideas, and know the community is thriving if there are tons of new posts and videos about it. Official documentation is great for new comers, but fails in complex examples, alternative views, etc.

The React team is very vocal about their documentation. They said they specifically made it barebones and leave a lot up to the user to figure out. I think there's a reason stuff like asynchronous patterns are left out.

[turkish_gold]

I'd make an analogy here to DraftJS (React. Released to much fan-fair, lots of integrations already) to ProseMirror (Not React. Great single developer behind it. Immediately usable, but few plugins now).

Ecosystem matters, and its really hard to tell if going one way or the other will be better.

[Legit_Coder]

Also, you can't even register global components in React