I bit the bullet and started learning React this weekend, so that I could work my through the todos app to compare and contrast Meteor with Blaze, Angular, and React. I have been learning and working with Meteor for awhile so Blaze is rather a natural thing. I should also say that it is quite straight-forward and easy to learn. I have been programming in Angular even before I started working with Meteor so Angular poses no big problems, plus Uri has done a great job of integrating Angular with Meteor. So my question is more due to my experience with Angular and Blaze, and inexperience with React.
Why do the queries have to be resolved to an array in React, i.e., find.fetch() as against cursors for both Blaze and Angular where only find() is needed? Pros and Cons?
React feels positively weird and somewhat ‘primitive’ compared to both Blaze and Angular. What are benefits of embedding HTML markup in Javascript code? How is the debugging story in Meteor React?
I know that which is better is a subjective opinion. Are there any deeper and more technical reasons? Architectural reasons? I will put in more time in Meteor React if there are solid practical reasons to do so, otherwise Blaze and Angular work fine for me. What is great is that you can mix and match both Blaze and Angular which is very nice.
Oh, by the way, checking out the ECMAScript2015 features was another motivation in doing Todos in Meteor React. I am up to step 8, and things work great. The integration of ECMAScript2015 into Meteor is totally transparent, which is how it should be. Great work, Meteor team.
The reason why getMeteorData() needs .fetch after .find() is because it is supporting reactive variables (not just collections). This means when this data will be updated (no matter if it comes from mongodb or anything else), it will update the DOM.
If you want to know why React is awesome, here is a few of them:
You build small reusable components
You can communicate easily between your components
They are easy to debug and easy to unit test
You can get server-rendering out of the box with reactrouter-react-router-ssr
You can get a hot-reload without having to refresh the page (10x faster than Meteor). You can get this kickstart project if you want to try it. There is a nice Todo example inside with a few goodies like unit tests
And one of the best in my opinion: JSX. I know it feels weird at first, we were not used to XML in javascript. I dare you to try it for a few weeks and you will love it.
It makes more sense to have your view logic with your business logic
You don’t need to learn new templating stuff. if, else, for, … are all javascript and you already know that
The virtual DOM is making sure you don’t need to tell the browser what to change. Only what you want and it will figure out what he should change. MUCH easier to maintain than jQuery stuff.
React might have an edge over Blaze on the Componentization (maintainable for sure). On the contrary, when it comes to speed. React seems to be sluggish.
I have used the tutorial projects from https://github.com/meteor/tutorials/tree/master/repos
Pre-loaded the projects with 1000 (incremented to 2000 in subsequent rounds), Todo tasks. To my surprise, Blaze was blazing fast, and React kept reacting with chokes. Consciously, made sure the environment was consistent for both the tests, to curb any other parameter being different, but for the code itself.
I didn’t get into the nitty grittes of the source code, but from an obvious point of view, it is a standard functionality with mostly same server code for both the approaches.
The showdown comes down to the client-side part of it, how can the USP of react (of being performant with volumes), turn on its head?
