Slides from my last presentation at the Cape Town Meteor meetup, on optimising the UI, specifically for Hybrid apps and for Meteor JS hybrid apps. The main thrust is really more about design patterns, and carefully controlling data management in your mobile app, with great examples of these patterns out in the real world. see the mobile patterns video here : https://www.youtube.com/watch?v=e6WWX4TF3UI

1. ALL ABOUT THAT
reactive
UI Performance in Meteor

2. Paul van Zyl
CTO at Nona Creative,
@pushplaybang,
pushplaybang on GitHub
paul@nonacreative.com

3. Origins
• First Hybrid attempts where underwhelming to say the
least.
• Wanted to understand performance throughout the meteor
stack. The UI seemed to be one of the largest challenges
• Wanted to use the default view layer, as a) I’m not
experienced enough with React / Angular2 and b) these
both should perform better
• Pushing performance with Blaze would allow me to find its
limits and compare when moving to react etc.

4. What we’ll cover
• Reactivity and Connected Client Apps
• Why Meteor
• What is Performance?
• UI Performance Tips for in Meteor
• Mobile Patterns for Performance

5. Reactivity, &
connected client apps

6. In computing, reactive programming is a
programming paradigm orientated around
data flows and the propagation of change.
-wikipedia

7. Meeting User Expectations
Reacting to user input, and the input of other
connected users is an essential component of SPA’s
(single page applications), connected clients and
social or collaborative apps, and how we expect them
to work, and respond to us.

8. Connected Clients Gone Wild
• Gmail automatically replenishing your inbox
• Trello Shows live changes across users and devices
• Google docs collaborative writing and editing
• Facebook twitter and Instagram updating new posts
and notifications.
• Whats app logs you into its web client after scanning
a QR code with your phone.

9. Typical UI Interactions
• instant user feedback (think the like button on any
social network)
• Notifications, comments & newsfeed updates
• live validation of forms against the server (this
username doesn’t / does exist)
• Real time chat

10. UI Frameworks

11. Not Just a UI Problem
• Requires a new kind of approach
• There are tools libraries and frameworks across
popular web languages to support this. (action-
cable in rails5, vert for the JVM, phoenix on erlang
VM, tornado for python)
• And a number of hosted services including pusher,
pubnub, firebase etc.

12. Why Meteor

13. The Business Case
• MIT Licensed and Vendor Benefits
• Backed by the smartest money in tech (Andreessen
Horowitz, Matrix Partners, Trinity Ventures, Y
Combinator), with at $31m in series A & B funding.
• All Star Team Behind the technology.
• Professional Support and an end-to-end vision for
cross platform app built with JS
• Huge, active community

14. For Developers
• Easy to Start With & Easy to Learn
• Isomorphic - Javascript on the client and the server.
• Supports ES6 out the box
• Ever increasing its integration with the somewhat fragmented
greater JS eco-system
• Large Friendly Community, with a huge selection of packages
and pre-built modules
• One of the most advanced build tools, targeting multiple
platforms. (Web, Android & iOS).

15. Built for a New Paradigm
• Full Stack Reactivity
• Optimistic UI
• Client Side Cache
• Real-Time by default with WebSockets
• First Class support for Angular and React
• Obscures the complexities of futures and fibres with a very
approachable synchronous API
• transparent reactivity with tracker

16. Challenges
• Obscuring complexity gives us a “magic box” and
removes some control
• not everything needs to be real-time or reactive
• Some lock-in / tight coupling
• Its sometimes challenging coming from other
platforms

17. The Future
• Native NPM support
• ES6 modules for controlling load order and
managing dependancies
• Extensive Built in Testing Framework
• Meteor Guide is centralising common patterns and
best practices
• Apollo will liberate us with GraphQL

18. time for code
a common approach to reactive UI’s with Blaze
https://github.com/Pushplaybang/pomodoro-timer-prototype

19. What is Performance

20. Most of the time we’re
asking “how fast is it?”
• How fast does it load?
• How fast is data Retrieved?
• How fast are things calculated, processed or
parsed?
• How fast are things rendered or removed?

21. How fast does it feel?
• Is the experience fluid and smooth?
• Does the interface respond to the user when they
engage it?
• How appropriate is the response?

22. Building Performance
Orientated UI’s in Meteor

23. What We Get Free
• Minified JS and CSS
• Templates in JS with Blaze
• Gzip + local storage, and caching with appcache
• lightening fast data transfer over web sockets

24. Measuring Stuff
• Kadina Debug to understand the whole system.
• Chrome Developer Tools
• Network tab for “how fast it loads”
• Timeline (and FPS specifically) will start to show
you “how fast it feels”, and whats “in play”.

25. Simplify first
• Move as much processing onto the server
• consider what really needs to be reactive
• sacrifice load time for execution time
• know your weapons & use vanilla JS
• Don’t guess, measure!

26. Animation
• Tasteful UI animation is part of the modern user
expectation
• Animation adds fluidity to the interface
• Only Animate opacity and 3d transforms
• Aiming for 60fps means an execution time of
16.666666667ms per frame.

27. Going Mobile
• Consider the constraints of underpowered devices
• Animate carefully, and consider physical models of
interaction
• patch the webview with crossWalk for Android (iOS
gets WKWebview by default in 1.3)
• Use strategic patterns to manage activity.
• Test Everything Constantly

28. How fat is too fat?
• WAIT! Wont Xwalk and WKwebview bloat the app?
• https://gist.github.com/Pushplaybang/21780c8d535
92f082b59

29. Mobile UI Patterns
We’re not the first people to try figure this out.

31. Mobile UI Patterns
• Don’t do it All Together
• Pre-Render Templates
• Re-use and patch cached data
• Carefully control loading of data and assets
• Pre-Load and render for quick switching
• lock down unnecessary interactions
• Don’t always tear down cached data

32. Blaze Specific
• Don’t always do reactive, use events for performance sensitive
interactions over reactive computations
• Use Native events
• Don’t just grab packages - you don’t always need the whole
jungle.
• cache everything from the DOM, and avoid expensive
calculations
• use native JS for _uihook animations.
• Pre-render where ever possible, and re-use data.

33. Delaying Activity
• use setTimeout or TransitionEnd if you can.
• setTimeout is 60% slower than using the transition
end event.

34. Micro Optimisations
That Mattered To Me

35. getElementById

36. Classname vs Style

37. Offset vs getBoundingRect

38. A few more I didn’t get
graphs for.
• requestAnimationFrame
• scope & ‘this’
• cache ‘el.style’
• if you have to loop, you a reversed decrementing for
loop.
• Bind close to the element

39. What we didn’t cover
• In Depth look at developer tools
• optimisations throughout the stack
• Rendering optimisations (Layout thrashing,
continuous paint, composite layers etc)
• What affect angular 2 or React might have

40. General Good Practice
• Optimise for the most common use case
• limit work to the task at hand
• Solve, Measure, Optimise - repeat
• Acknowledge and accept constraints & trade-offs
• Consider the whole system, experience and needs.