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!