Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be.
React can appears complicated when beginning, but it pays off on complex apps.
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.
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.
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.
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).
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.
slowclap
If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).
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.
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...
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!
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 ;)
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
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
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.
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 :)
It doesn’t even work on Chromium, in the same version as Chrome. There is literally no excuse for that, it’s literally the same browser engine.
On top of that, even back in the "best viewed on netscape navigator 4.0" era there was a solution for this: Show a message that it was only tested with browser X, and that your client was too cheap to pay for anything else, but at least allow the user to bypass that.
As said, the excuses convinced me even more to never do business with you.
Moreover, you failed to acknowledge the points they made in response!
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 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).
so does Angular
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...