People keep on saying this, but I've written complex apps with both Vue and React (using state stores) and there don't to be any apparent scaling differences. They even use the same component model (virtual DOM, props down, events up).

There are some claims that Vue uses two-way-binding which is unmaintainable, but v-model isn't true two way binding and is just syntax sugar for builtin tags: https://v1.vuejs.org/guide/forms.html With React, you would have to explicitly write the event handler/setter out, and some may prefer explicitness (but again, there's nothing stopping you from doing the same with Vue).

Vue just has some nice features (computed properties, better style scoping, etc) and different methods for inheritance/templating (but you can use ES6 classes and JSX if you want to), and like somebody else mentioned, is plug and play (yes, you can technically write React render functions without a transpiler, but do you want to?) while Vue (with the template compiler bundled) lets you write templates with HTML attributes using just a script embed.

There are a bunch of other arguments that are more nuanced (ecosystem, bus factor, etc..) but from what I've experienced, Vue is no worse at scaling than React simply because they share the same conceptual model.

Sounds like I'll have to try it out! Definitely don't want to put all my eggs in the React basket with all the patent stuff right now so would like some experience of the alternatives.

> lets you write templates with HTML attributes

that's somewhat bothersome... does it typecheck on compile time? hope vue works on typescript-language-specs compliant plugin...

As for react, there's TSX (typescript-jsx) that works great (typechecks on props, state, etc.), but I haven't tried it with vue.

If you use single file components, there are some common compile time checks by default for the render function, but I'd argue that type checks are not as necessary as in JSX (which you can use with full type checking in Vue) due to separation being encouraged.

Type checking for props and state inside the <script> tags is fully supported: https://vuejs.org/v2/guide/typescript.html

If you want type checks for inline <template> code (which isn't suitable for anything non-trivial, you should use computed properties or methods instead), see https://github.com/DanielRosenwasser/typescript-vue-tutorial

If you are using uncompiled components (newbies using script embeds) with no build step at all, there are clearly no compile time checks. IMO this is why Vue is significantly more newbie friendly.

This is totally not true. It depends on how you structure your project. Vue is good for simple things but it scales way better for large complex apps than React. Why? Less boilerplate. And less boilerplate = less code to maintain. Vue HTML template functions are really well designed with just enough functionality to make your life easier but also encouraging you to build custom components when you need something custom :)

My only suggestion for people starting with Vue is to not be afraid of directives (Vue directives are nice and have nothing to do with Angular directives), group your .vue components into directories and don't jump into Vuex right away (same goes for React beginners, don't force yourself to learn Redux for your 1 page app).

you should try mobx + react for 'local' state management. mobx provides something similar to vue (MVVM), and the amount boilerplate becomes somewhat like vue's

Sorry but that's not true. We have a pretty heavy VueJS application in production with like 500 components and it's a pleasure to work with, and is still quite performant.

This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.

I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.

For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): http://f37foundry.com (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.

It's just the type tester element which is not accessible with browsers other than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to make it work which didn't work in Firefox.

As mentioned in my other comment, due to the target audience it was decided that it wasn't worth the investment to get it working on other browsers right now, but the rest of the site should still work.

Not React's fault, just a lack of time/budget and a lack of native browser support for advanced typography.

False dichotomy. OP could have tested for FF if he wanted to, irrespective of the framework he has chosen.

Personally, I develop Firefox-first and then work on compatibility for lesser browsers like Chrome and Safari.

Of course things have been complicated a bit now that Firefox Focus is out and uses Webkit...

What is complex about the site?

I didn't think it was complex until I clicked on Jagger on the first page. It gave no indication of being editable, or I just missed the clues.

Once you do click it, I'd say the complexity of the site becomes more clear.

Or maybe my reference point for "complexity" is just low.

Regardless, very cool site. Nice work!

Ah yes, I was referring to the type tester specifically :) Thanks, was a lot of work but a good fun project!

Managing the state and rendering of all the text items as the user manipulates them (this is on the desktop "type tester" homepage, not mobile) - essentially trying to build a "desktop-class" (to some degree!) experience à la Adobe Illustrator.

The rest of the site is pretty basic granted. Maybe it's not a great example, but it's the sort of thing that could have easily become unmaintainable in the old days as features were added quickly, but React and the component model (and MobX) made it much more manageable even as I hacked things in last minute ;)

There's a plugin for Vue named Vuex which serves as a single state store just like Redux. It's simple to use and makes things a lot more manageable.

Cheers, I intend to try it out. Curious to see how their React Native equivalent works, huge selling point for React IMO but I should try the alternatives!

what seems overkill in reactjs?

I mean for the simple use cases like adding some validation to a form or a simple widget on a site. But in my experience, these projects usually grow to the point where you are glad you went with React. Personally I'm a huge fan and build things with it I couldn't have imagined doing a few years ago, so I hope all this patent stuff gets resolved/blows over.

I’m curious, how did you manage to build a website that claims to work in Chrome, but not in Chromium? In Safari, but not in Firefox?

And worst of all, it actually obviously works in Chromium and Firefox, but you just check the UA.

Works:

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Doesn’t work:

    Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/60.0.3112.90 Chrome/60.0.3112.90 Safari/537.36

I mean, sure, if you want to build a site that relies on ridiculous UA testing, and breaks everywhere, sure.

But not even in the "works best in Netscape" era did people actually intentionally break their pages in browsers where it actually worked. This is a new low. This is completely ridiculous.

Proof: http://i.imgur.com/YlPE77b.jpg Oh, and as you can see, if I spoof the UA in FF; it actually works fine. This is completely bullshit, and I’m sure I’ll never do business with you. This is completely ridiculous, leaving out major browsers (and, for example, over 40% of the desktop browsing market in Germany) intentionally and unnecessarily.

Ultimately this was a client project with a fixed budget and timeline so a decision had to be made between extending browser support and adding more features.

Given the target audience (graphic designers, the vast majority of whom are on Mac and will use Safari or Chrome, as I validated from stats on other sites I've built), the decision was made to focus work on the type tester on those browsers.

The rest of the site should still be accessible with any browser, but we decided it was better to not show the type tester at all than have a broken experience (which was the situation with Firefox).

Anyway, hopefully that justifies it somewhat - I think it was the right decision all things factored in. There's a lot of CSS trickery/hackery to make the type tester work (native support for advanced typography stuff is poor) so making it x-browser wasn't easy. The messaging to users of other browsers could probably be improved though :)

Go grind your axe somewhere else... Why would you go off on some random person on the internet when obviously didn't have the relevant context?

Moreover, you failed to acknowledge the points they made in response!

This is behaviour that's harmful to the web as a whole.

The loop of "everyone only uses chrome" → "I only need to support chrome with my website" → "nothing works on firefox, I'll switch ti Chrome" is harmful to the entire internet industry, and the startuo economy.

It is harmful to all of us, and hurts all of our future.

I agree with with you that this is an important issue. However, your aggressive comments that ignore what the other person said may not be helping.

I am getting more aggressive because the other person completely ignores the effects on the surrounding ecosystem, and does not even consider a solution that would provide a compromise, as the "optimized for chrome and safari, ignore and use anyway" button would provide.

I see their situation, and their limits, but this is a very egocentric opinion that completely ignores the effects on the rest of society, which is an issue that's just all too common (see also monopolistic effects, or environmental effects, etc).

Fair enough. I will say, from a strategic standpoint, my hunch is that presenting your case in a less hostile manner will bring you more success.

Good point about Chromium, I'll change that - it wasn't deliberately excluded. But disagree about the messaging, in this case it was more important to the client that the feature worked as smoothly as possible than that everyone could see it. In some cases I'd disagree, but given the narrow target demographic (and their browser choices) here, I think it was a reasonable choice.

How you scale your apps is related to how you architecture your project, not what library you use.

i'd say it's quite the opposite. vue makes complex apps easy to write, where react makes it look complex all the time.

Agreed, the learning curve to build more complex, larger applications in vuejs was considerably less than with react.

> but it pays off on complex apps.

so does Angular

This.

How much simpler than functions as components, that get their props as parameters could it get?

Every example of Vue components I have seen was more complicated...