[girvo]

I've written large apps in both; interestingly, I've built the same app twice as well: once in Vue.js and once in React. I'm also in the process of building another very large front-end in Vue.js at the moment.

The big thing is that while I personally adore React, it does require ceremony to get stock-standard behaviour. We recently onboarded a new developer (a friend of mine), and teaching him React + Flux (Alt.js) was infinitely more difficult than teaching him Vue.js -- the "thicker" API (which is still an order of magnitude thinner than Angular or Ember) means you don't need to either reach out to other libraries to achieve tasks that you otherwise would need to in React.

Now, that's not a bad thing on React's side; it's a view-layer, not much more. That's okay, and a good thing! For building components rapidly in a regular "client -> designer -> cut-up -> development" workflow, Vue.js is streets ahead of React in terms of code required. But for building very large applications, React's smaller API means that you can guarantee behaviour, and things are consistent.

Basically, they are both brilliant libraries. I highly recommend both. React and Vue.js are similar in a lot of ways: they're both tiny little view layers that are component focused and have modern, ecosystem aware build tooling. They differ in that Vue.js is "classical" (though not really, it's far nicer than the older systems) MVVM which has been proven time and time again to be a good architectural choice, whereas React.js takes a more functional (as in programming) approach to the problem -- though I'd argue not far enough down the functional side, which is why I've been enjoying Cycle.js so much!

unless you get bitten by event pooling...

[RobertoG]

"and teaching him React + Flux (Alt.js) "

Can I ask what do you use for routing and if you have good results with that mix?

[girvo]

Interestingly, we're using our "own" router that I wrote in a fit of frustration; it's tiny, not particularly well documented and has the interesting design choice of handing the route matching on to the user of the library; give each <Route /> component a name and have your route matcher callback return that name and you're good to go.

The reason why I went down that route (pun intended) was that we built a rather large, isomorphic/universal web application that for SEO reasons had to act like a website vs a web app most of the time; until it started up the client side JS anyway. "react-router-component" was so close to what we wanted, but because it used React's somewhat undocumented "context" feature, it didn't play nicely with our Flux implementation at the time (Flummox).

For that reason, my tiny router came into being, and for some reason it keeps sticking around despite my best efforts...

https://github.com/studionone/react-isorouter

Ps. I just found out that the README links to non-existent documentation, I really should fix that...

[RobertoG]

Thanks.

I'm trying to find my way around flux but until now has been a little frustrating experience.

I wish something like Elm was mature enough.

[girvo]

> I wish something like Elm was mature enough.

So do I :)

If you're not 100% up on Flux, I recommend having a play with Hoverboard[0] -- it's a tiny implementation of the Flux architecture, with some interesting choices itself. It's a single function, too, which is pretty neat!

I've been using it to implement the "Flux Challenge" in combination with domChanger[1] instead of React: https://github.com/girvo/domchanger-hoverboard-flux-challeng...

And here's a partial TodoMVC implementation I wrote in Hoverboard and domChanger: https://github.com/studionone/todomvc-domchanger-hoverboard

---

[0] https://github.com/jesseskinner/hoverboard

[1] https://github.com/creationix/domchanger

[girvo]

Apologies for the formatting, I forgot about the rather greedy behaviour of italics on HN!