Hacker News new | ask | show | jobs
by badbanana 3102 days ago
Having used both React (with Typescript and Redux) and the latest Vue (with es6 and Vuex) I prefer React, and I don't even use React Native.

Vue is better for onboarding people more in tune with "classic" html + js development; and that's where the advantages end as far as I'm concerned. This might be a big win for some people.

The way I reason about it is that React is simple, Vue is easy. When you take into account Vue's templating language, React's api is small in comparison. A beginner won't know how to do some common use cases reading React's docs, when Vue might have a something built-in in its templating language (e.g. slots, or the component tag for dynamic components).

Slightly annoyed with Vuex too because of its slightly leaky abstraction. You have to remember to setup the properties you mutate so the reactivity will detect a change; and also remember not use array indexes arrays cause it can't detect changes otherwise. The array index thing will be fixed in the next version when they drop support for some older IE. Using Typescript would probably help a bit here, although Typescript being useless for checking Vue templates really feels like a huge chunk of its value is wasted.

Typescript is not currently available in the official blessed boilerplate which greatly affects its uptake in the Vue community.

Anyway, if you already know React, there is zero advantage in investing time in Vue.

4 comments

I have already moved to using React for my larger projects and Mithril for my smaller ones instead of Vue because of the lack of typescript support.

That and when you add JSX to mithril, the api just feels so simple and i rarely find myself checking the docs for something.

Glad to see Mithril mentioned. I like it better than React when comparing the APIs, It just seems simpler. But React obviously has the mind share. I'd love to see Mithril gain momentum.

I especially like the fact that I can easily include it as a script, like Vue, and don't have to have a build chain. That really decreases complexity for smaller projects.

FWIW, you can absolutely use React as just a pair of script tags - see the "React Single-File Example" template [0].

It's certainly common to use React in a larger application that uses a build chain, and that's the recommended approach, but it's not required.

[0] https://raw.githubusercontent.com/reactjs/reactjs.org/master...

> You have to remember to setup the properties you mutate so the reactivity will detect a change

This is a positive thing imo. It's a declaration of your data schema. You can reference it to remember what kind of data you're working with. This gets rid of unproductive moments like "What was the name of this property again? Is this property an object or an array? Is it nested inside this object or that object?"

We maintain Vue and TypeScript Single Page App templates for Vue and TypeScript for .NET Core [0] and and .NET Framework [1].

[0] https://github.com/NetCoreTemplates/vue-spa

[1] https://github.com/NetFrameworkTemplates/vue-spa-netfx

Vue is also currently our most popular .NET Core 2.0 SPA Template, followed by React.

If anyone wants to try out React SSR + TypeScript, I have a working example here:

https://github.com/styfle/react-server-example-tsx

One of the reasons I picked up React is that views could be type checked at compile time which was not possible with Handlebars a few years ago.

I believe there is work being done to the TS language service to get type checking in other template languages at some point.