README.md

App client-side performance plan

Two pronged approach

1. Create the illusion of speed
2. Increase speed

Illusion of speed

Instead of issuing UI feedback after the rendering cycle, we should push feedback into the UI immediately and then begin the rendering cycle. This creates the illusion of speed as the satisfied that their input has been received. Patch UI directly with jQuery (no Tracker invalidations). Review Google's RAIL Performance Guidelines: https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en

Increase speed

1. Reduce computation time spent when changing routes
2. Reduce time spent drawing templates to the screen
3. Optimise codebase for runtime JIT

Plan

1. Move subscriptions from routing layer into parent templates (that manage top level data state)
2. Migrate from iron:router to kadira:flow-router
3. Start building new UI components in React instead of Blaze
4. Slowly migrate all UI over to React (have targets for this to ensure it happens)
5. Use Typescript/Flowtype for JIT compilation optimisation
6. In the long term, consider ReactNative (at which point we'll be well placed to consider given use of React)

iron -> flow router considerations

1. Rendering with blaze-layout and react-layout
2. Largely simple API translation
3. Biggest challenges will come from lack of reactivity, and the assumptions that were made when building with iron:router

Problems with Blaze

• Rendering performance is not as high as it could be (vs React/Angular 2)
• Hierarchical data flow (good pattern) causes cascading template re-renders (potential solution https://kadira.io/blog/meteor/introducing-blaze-plus-the-next-generation-of-blaze)
• Largely Meteor specific, which makes hiring more difficult for company

Problems with React

• Learning curve for JSX (but, for devs in team, higher employability, and for company, easier to hire React devs)
• Implementation of getMeteorData mixin is suboptimal right now, resulting in lowered performance particularly around each. Notes (https://forums.meteor.com/t/can-we-solve-react-cursor-inefficiency-vs-blaze/10590) and solution (https://www.npmjs.com/package/meteor-immutable-observer).

But

• MDG is building Blaze 2 as a wrapper around React as the rendering engine, so support will only get better
• Pure React is also an officially supported rendering framework

Interesting links

• Profiling Telescope (Blaze) and visualising with flame graphs: https://youtu.be/JD2MI7sDIuM
• Blaze 1 API rendered with React: https://github.com/timbrandin/blaze-react
• Blaze Templates to React markup (separation of template/logic): https://atmospherejs.com/thereactivestack/blazetoreact
• Airbnb React Style Guide: https://github.com/airbnb/javascript/blob/master/react/README.md
• Blaze non-reactive render: https://github.com/Konecty/meteor-nrr
• Kadira experiment with keeping Blaze templates in memory, but removing from DOM: https://gist.github.com/arunoda/9e3997d9c8d8d73a16f7