This is a general question as I have been out of the Meteor scene for a few years now. I have developed a few web apps in Meteor and Blaze (pre React etc) and have a large project to work on that I would like to develop with Meteor.
Should I move from Blaze to React now? and if so does Meteor/React still have the reactiveness that Blaze has (live updates to UI)?
Also, should I use look into using Apollo for the project?
Would really appreciate your expert advice on this.
Thanks
JB
Hi @funcoder: I would definitely recommend to go for React. It has quite some learning curve, but itās worth it. And yes, you can have the same reactiveness with React as you had with Blaze:
Regarding Apollo: This seems pretty interesting to me, so Iād recommend to have a look into it as well. Iām not using it yet, but I plan to. It makes you more independent from the Meteor framework, and it allows to define how the result set of a query should look like pretty easily.
@funcoder I also transitioned from Blaze to React, and would not move back. I find that a React code base is much easier to understand and maintain than the equivalent one in Blaze.
To help you figure out what you want to do, maybe spend a couple of hours going through the React tutorial:
If you want to play around with a simple React+Meteor application meant for beginners, you can look at my meteor-application-template-react:
I also highly recommend using Uniforms for forms; hereās a sample system for that:
These all use Semantic UI React as the CSS framework (https://react.semantic-ui.com/) but there are lots of reasonable alternatives to pick.
There are other boilerplate templates for React+Meteor which might be better suited for you once you start actual development. The ones I developed are designed for learning the tech stack. So you might consider using mine just to help you figure out what you want to do.
Philip
ā¦if you are setting up a greenfield project, I would skip React altogether and opt for something nice instead (ducks for cover! 
)
(Unless you have other goals, like entering the massive job market for React devs)
Depends, I would definitely look into both. Good thing is that you can adopt both incrementally. So I would use Apollo in parts where you donāt need reactivity. For React try it out, but Blaze is still going to work and it might not be feasible to rewrite a big app in React unless you are planning to make improvements and changes across the app.
Agree with @arggh! My recommendation for āsomething niceā - give vue.js a try. Much easier to work with than React, and just as powerful. Wouldnāt touch React again, given the choice!
I personally really enjoy React, itās pure JS as far as Iām concerned, which is very appealing to me, also the ecosystem is really rich.
With that said, both React and Vue enjoy a strong ecosystems and enable building complex front-ends. The way I see it is that the key innovation that drove the front-end industry forward (beyond the jQuery/templates era) was the implementation of web components pattern in the JS frameworks (which was pioneered by React ), thus any front-end library that support creating complex hierarchical components is a good choics, in my opinion. Also, Blaze (handlebars) is great if you want something simpler and easier to start with, but I personally struggled to manage the code with the growing complexity, something that React solved well.
However, the choice really depends on the dev experience, preferences, use cases etc. And given how subjective this choice can be, Iām really glad that Meteor is a front-end agonistic framework at this point.
Having used all 3 extensively:
Blaze is very slow, but especially with Viewmodel it rocks in developer speed and happiness. But no hot reload, itās getting ancient.
Vue has its own template syntax like Blaze, or Angular. If youāre into that pick it. I like Vuex much better than Redux because itās simpler to setup and use, with less code. But in my experience, Vue provides less control than React (without doing hacks) and feels more āblack-boxyā, becauseā¦
Once you go React, which is āpureā JS, all those other frameworks feel somewhat limiting. The learning curve is def a bit harder but it aināt rocket science either.
Also note that Vue dev tools are way behind Reactās.
In the end it all doesnāt matter that much. Pick what youāre comfortable with. But my suggestion is to avoid Blaze, thereās no future there (still, props to the community effort!)
Mobx plus React for the win!
Honestly, I think one can still go pretty darn far with Blaze. Meteor + Blaze was what got me so excited about a new paradigm of reactive web dev. But if I had to start over today with my 3+ year-old Meteor app, Iād probably venture to Vue instead of Blaze.
Vue is extremely performant and the learning curve is lower than Reactās. From everything Iāve experimented with and read, it doesnāt appear that there is a need to opt for the higher learning curve React demands. Vue is extremely capable, constantly evolving, performant, plus it still allows for separation of concerns (I still like coding HTML in HTML, not JS 
Not wanting to start a war here, Iām just curious, but what extra control does React give you that you canāt achieve in Vue with v-for (with a filtered computed property if necessary), v-if / v-else-if / v-else? What āhacksā do you have to use?
IMHO those are tidier than JSX with its intertwined html/js with {...map(item => <lots of html>)} and {ifSomething ? <multiple lines of code> : <lots more lines of code>}
One more recommendation from me: I start all new components/projects with PUG instead of vanilla HTML. PUG is much more concise than HTML, compiles into templates with zero superfluous white space (smaller bundle) and works really well with Vue:
<template lang="pug">
div#my-component
h2.message(v-if="!subsReady") Loading...
template(v-else)
h1.main-heading This is a heading
div Hello {{user.profile.name}}
...
</template>
btw, hereās my experiences and results from webpagetest.org in converting one of my Meteor projects from React+ViewModel to Vue.js:
its misconception, that JSX is intertwining html into js. JSX is syntactic sugar for function call which help compose function calls. You can use not only to generate dom-trees, but also native-views (react-native), pdf, command line apps, 3d-scenes, etc. Anything that looks tree-like.
<Component property="yeah"><Child /></Component> is exactly the same as
React.createElement(Component, {property: "yeah"}, React.createElement(Child))
Itās true, that ternary (if-else with the ?) or map does not look so great in jsx, but itās just what javascript offers (js has no if-else expression, only statements), but the big plus is, that you donāt have to learn a template language, you can just focus on coding in the language you know best. You can do exactly the same with your components as you could do with any other piece of code. I would say, itās the most ācanonicalā way of expressing UI there is and once you understand that, it gives you much power.
by the way, people who are turned away by the supposed overhead and boilerplate of redux:
try this awesome library: https://github.com/ctrlplusb/easy-peasy
Wow. Quite surprised. My post (which was even liked a few times, and agreed with in later posts) about recommending something nicer than React was flagged as inappropriate by (multiple?) members and is now therefore hidden 
Iām sorry, but you peeps seem overly sensitive to me 
I think the question of frontend has been answered by many folks. Iād just say go with what youāre comfortable with. I personally found the move to Vue way more comfortable than React as it felt very similar to Blaze.
With regards to Apollo, Iād say it depends on what your intended use-case is. Apollo being a GraphQL layer still needs a DB layer and such. AFAIK, it might make sense for a larger application that involves legacy/third-party systems, and a more formal architectural scope.
IMO, for small, fast, and not necessarily dirty applications, Mongo is more than enough, especially if you use packages like Grapher and Redis-Oplog. These two packages have made working with Mongo a breeze, and Grapher esp has been a revelation in how easily you can construct relational queries and applications built on those kinds of relationships.
Hope this helps.
Although I disagree wholeheartly with your recommendation to avoid React given my own epxerience with it has been largely positive and Iāve bene using it for few years, but you simply stated your opinion so that post should not have been flagged.
Thereās no reason to use apollo unless you donāt want to use mongo. If you intend to use a relational database, then go for it, but otherwise it adds a tremendous overhead, complexity, and learning curve to your project. I love apollo, but for a mongo meteor project - I donāt see the need.
Regarding a front-end, you canāt go wrong with react or vue. I wouldnāt use blaze. Itās simply not up to date. However, youāre also familiar with it. If youāre comfortable with it, then I see that as a very good reason to use it. However, Iād recommend learning a different frontend framework. Iām familiar with react, and like it quite a bit.
I stepped out of the box a little bit and used svelte for my first meteor project. So thatās another option, if youāre so inclined. You can check that source here. I found svelte just an absolute joy to work with, but itās also not nearly as popular as vue or react, so you wonāt find nearly as many libraries to do things for you.
Svelte looks pretty awesome. Have you run into any major issues or downsides when using with Meteor?
Curious, what libraries do you think it should have that it doesnāt currently?
This is a 404 for me. Would be interested in checking it out. 
Fixed the link.
React has a massive amount of libraries. Libraries that do everything for you. Thereās no svelte equivalent to the material-ui library, for example. Thereās no react-select equivalent, thereās no react-table equivalent, thereās no formik equivalent. Even the routing libraries are very young compared to react-router.
Thatās entirely down to popularity, and really isnāt a big deal. Itās not difficult to write things yourself. The autocomplete component in the repository I linked was my solution to a lack of mobile friendly select boxes, for example.
It does play fine with plain JS libraries though. The Timepicker component uses a plain JS library.
Regarding meteor - no, not really. Between svelteās reactive-ness, and meteorās Tracker + ReactiveDeps, everything ājust worksā. When I first started the project, I had a mismatch between the svelte-compiler version, and my version of svelte which threw some wonderfully confusing errors that took a second to track down. I also havenāt gotten SSR working yet because Iām importing CSS directly from my components, which isnāt playing nice with the server-render package. Havenāt really looked into it very much, though. Other than that, everythingās been peachy-keen.
For meteor itself, I really enjoyed working with it. Itās not perfect, I really disagree with their decision to make strings the default ID type. Had to spend a lot of time switching my models to ObjectIDs when I used the mongo driver directly to create some records, but now I know.
That said, it was really quite a lot of fun working with. Usually when Iām working on a project, I spend a lot of time working out kinks with the framework, and getting things running. Everything ājust workedā with meteor, most of the time.
I really donāt understand the bad rap it gets. When I mentioned to my peers I was working on something in meteor, I was met with derision. After working it with it on this project, meteor would be my first pick for any project.
Svelte user here 
The only āgotchasā so far have been remembering to sync the version of svelte:compiler with the version of Svelte you include in your appās package.json. If you forget this, weird things start to happen! This basically means forking svelte:compiler and running your own version of the compiler package, if you intend to use the latest and greatest Svelte version.
Also, as the v3 was only recently published, Iāve bumped into a few bugs, or more like 10, but luckily most of the time you can fiddle your way around them until Rich and his gang release a fix. Just remember to submit an issue 
You can setup Storybook with Svelte, but Iāve also used the Svelte REPL to build things rapidly - no need to wait for my Meteor app to reload on every change! Once Iām finished with a component, I just copy it over to my project.
= Itās an absolute joy to use. So far, no regrets!