Which view layer performs better? Blaze vs React

@sanjo are you using Flux with Blaze? I assume Flux can be implemented in any framework right? (Still wrapping my head around it)

1 Like

Yes, I use it with Blaze templates. I use a fork of https://github.com/CodeAdventure/space-ui.

2 Likes

Interesting! With React the views wonā€™t update when the data does so I donā€™t that would work well for a full React app? At any rate how is it working out, do you find it to be easier to reason about the data flow?

This is totally normal! Checkout these articles, I have found them helpful :thumbsup:

http://tylermcginnis.com/reactjs-tutorial-pt-3-architecting-react-js-apps-with-flux/
http://blog.mgechev.com/2015/05/15/flux-in-depth-overview-components
http://blog.andrewray.me/flux-for-stupid-people/ (not implying anything here of course :smiley: )

@SkinnyGeek1010 Thanks! Iā€™ll check them out. I have only really been developing since Fall of 2014 so Iā€™m looking at Flux and thinking, ā€œThis seems like a lot of unnecessary complexity.ā€ haha. Iā€™m sure it will make more sense to me as I build bigger projects.

Yep I think thatā€™s a fair point! :thumbsup: It also doesnā€™t help that the app is so small so it looks like overkill.

If you think about an app being over 30k lines of code, hundreds of components, and lots of components needing to share/know about the same state, it seems like a dream come true. The perk is that you can reason about whatā€™s happening with data, even though there are hundreds of components. Something like the Spotify app or the Squarespace website editor would be prime candidates.

Also I didnā€™t really think flux was necessary until I was wallowing in the tangle of code of a large React Native app :slight_smile:

For small apps itā€™s prob. best to keep it simple and do something like this instead. Separate the view from mutating (easier to test), but still keep it organized in a domain (area of the app).


``` Template.leaderboard.events({ 'click .inc'() { var playerId = Session.get("selectedPlayer"); PlayersDomain.incrementScore(playerId, 5); } }); ```
PlayersDomain = {
  // returns cursor of players
  getAll: function() {
    return Players.find({}, { sort: { score: -1, name: 1 } });
  },

  getSelectedName: function() {
    var selectedId = Session.get("selectedPlayer");
    var player = Players.findOne({_id: selectedId});
    return player && player.name;
  },

  // returns number of docs updated
  incrementScore: function(docId, amount) {
    return Players.update({_id: docId}, {$inc: {score: amount}});
  }
};

For community adoption Blaze will never have the same footprint as React

@SkinnyGeek1010 Iā€™ve been building a huge app that is in the 30k lines of code range (maybe more) and Iā€™ve started to hit all kinds of maintainability issues. Iā€™m excited about learning Flux! Hopefully itā€™ll solve my problems when I figure it out. I was furiously working on another react app last night so that I could try to learn it. Iā€™ll start implementing the domain example you recommended. Thanks for sharing!

1 Like

Personally I find it faster to hack something up in blaze than in react.

For a large team though, it might be easier to work in react.

Overall, discarding the reality distortion field around react, I find react to be sluggish compared to blaze.

Also, looking at the virtual-dom benchmarks here, it insā€™t the topmost in terms of speed. http://vdom-benchmark.github.io/vdom-benchmark/

What do I know though. If Facebook created it, it must be holy and thy must not question.

2 Likes

I am currently in the Blaze hell you are referring to. A single page displays a TON of information, and all the underlying information changes independently of each other - like a user profile. My following count will go up, but my location will not change, nor will my follower count, etc.

So, I wrap many different segments of the single visible page into very many templates. Templates within templates within templates, separated by logic. If X, then render this sub-template, which in turn renders several of its sub-templates, etc., which have their own Blaze control flow. End up having order 10^2 files for a single route. This is what I am working with atm.

If Iā€™m not mistaken everything in React by default is already broken up into individual independent pieces. So I feel like my usage of templates is telling me I should switch to react, because that structure is what I am converging to by nature. Seriously consider using React once official-official support is out.

Yea it sounds like your app might be a prime candidate. Also, if you feel like you would like more structure regarding to ā€˜control flowā€™ of the app, iā€™ve found that flux helped me dig myself out. It helps eliminate the problem of ā€˜ok a user clicks this button and now what else is happening from this chain reactionā€™. Meteor doesnā€™t give you any architecture out of the box and I find that, with React at least, flux helps solve that and gives me an easy ā€˜mental modelā€™ of whatā€™s happening.

If you wanted to dip your toes in the water, this boilerplate repo will help you test it out, add some stuff, and experiment. I also have other complex examples up too. This video explains how to refactor an existing app really well.


Youā€™re right, itā€™s going to be faster to hack on with Blaze. Itā€™s very light and terse (as much as HTML can be). However I have a long list of ā€˜tab triggersā€™ that helps get me out of thisā€¦ reactm scaffolds out a base component setup for Meteor, etcā€¦


[quote="bhoot, post:28, topic:6921"] For a large team though, it might be easier to work in react. [/quote] Again I think this is a really valid point. The larger the team the more benefits. Things like propTypes, and the 'pure function' methodology of the view help you reason about the view that you might not have built. I think these are also helpful for 1 person teams where you're going back to your codebase months later.
[quote="bhoot, post:28, topic:6921"] Overall, discarding the reality distortion field around react, I find react to be sluggish compared to blaze. [/quote] I think this is going to happen with any new framework. Everything is slower when you're bumbling around and skimming docs. I had this experience with Angular even though experienced Angular devs proclaimed it was so easy.
[quote="bhoot, post:28, topic:6921"] Also, looking at the virtual-dom benchmarks here, it ins't the topmost in terms of speed. [/quote] To me speed is one of the least appealing things about React. Blaze is very fast too. However this virtual diffing allows you to do things like 'when a query param changes, re-render the entire app'. With this philosophy you don't have an issue of parts of the app not updating.

The perks for me are:

  • thinking of views as ā€˜pure functionsā€™
  • virtually re-rendering the entire app on any change
  • re-usability
  • composability (like the column, row ex. above)

Just my $0.02! I think Blaze is really cool too. For my needs React solves a lot pain points.

1 Like