Agreed! I meant that zeit costs $15 a month, handles everything but I don't actually want that - as I have to manage other stuff on AWS already. I prefer the flexibility of arc.codes! Also thanks for dogfooding so heavily with begin, it mades a great product (arc.codes I mean, haven't used begin)! :D

Since I wrote this, I've seen good things on both. I'd be surprised if it's faster then react 16 - as it's a re-write but I've also seen some people come out in favour of Vue since then. I'll be spending a bit of time checking it out in depth soon! :-) I still believe what I'll find is that Vue is better for smaller/less complex applications whereas React is really tailored towards webscale. (Facebook, Instagram, and thousands of more complicated UI's)

Thanks for making arc.codes - it's so great when you're already managing DNS and such. Also you can add on to previous subscriptions you have, unlike arc where it requires a monthly $ value - but it'd be hard to beat if all you were doing was node applications/static apps.

TL;DR of @Lucas' article: first blaze has been more public than react for longer. But Blaze is a drain on Meteor resources, and react is more mature. They will start transitioning to using React underneath Blaze 2.0. React is more mature, advanced, but also takes longer to learn than Blaze. They recommend if you can take the time to learn React, do so. If you can't, then use Blaze but change how you use the templating. Don't reply on the implicit context of the template, instead . But implying 'we already have react', blaze has been around for longer - changing the coupling of a whole framework takes time. I'm surprised that meteor is acting as fast as they are! Good job meteor team.

@DanJavia I just want to step in, though I don't usually feel I have anything to add. React and Vue are very different ways of solving the same problem . From my looking at Vue.js it is a very different model of solving the UI problem. It's 'reactive' in a different way that React. I'll explain more below (based on my short lived impression.) Vue looks like Blaze which is Meteors templating engine (which I believe can be used on it's own). https://www.meteor.com/blaze React tries to bridge the gap between Functional Reactive Programming and normal Javascript - which is good. It aims to reduce the amount of 'touching the dom' that is done, and it aims to be traceable and easy to reason about. My bold claim: This just can't happen when you can change state whenever, wherever - which is what Blaze and Vue enable. Vue doesn't have that as a goal, I'd be interested in hearing Evan respond if he's interested. I think one of the main pulls of reactive programming is 'it just works' and it responds to data changes immediately. I believe this requires 2 way data binding which can be slow, which Evan disagrees with - but either way he can't argue that it's harder to debug and reason about. After all that, my issue with Vue is: why would I use it over Meteor? - Reactivity is great, but you have to define a good enough API which also supports it. Meteor is tightly coupled to it's UI framework (for good reason), and the best non-coupled frameworks I've seen are Falcor, and Relay (for reactive programming). Both are Node JS frameworks - so why not just go with Meteor, take advantage of it automatically making your Javascript Asyncronous and take advantage of it's write once run everywhere model of programming. Or have an easy to reason about front end, using react and some version of flux (because once you understand the paradigm it is the right way to go). Then use some API you create, or use Relay or falcor to do the server fetching. React has a lot of awesome optimization that most people don't know about. You are not comparing apples to apples by looking at the library size. React is as battle proven as any framework , Facebook and Netflix are using for (I believe) all their front ends. Vue isn't. To be convinced Vue is a good model , I'd need to see: * Some perf testing between Vue.js and React with very large Dom trees > 10,000 elements, both with few changes and with lots of changes * Specific use cases it can handle - which are not fixed better by meteor Let me finish with a thank you to Evan, I really appreciate you putting time into building a cool framework - I really am not trying to put you down. I'm just coming at this from my personal point of view - if you have some suggestions with better ways to critique let me know :-)