SlideShare a Scribd company logo

All about that reactive ui

•Download as PPTX, PDF•
•
P
Paul van Zyl

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

Related slideshows

DevOps: Automate all the things
DevOps: Automate all the thingsDevOps: Automate all the things
DevOps: Automate all the things
 
React Native and the future of web technology (Mark Wilcox) - GreeceJS #15
React Native and the future of web technology (Mark Wilcox) - GreeceJS #15React Native and the future of web technology (Mark Wilcox) - GreeceJS #15
React Native and the future of web technology (Mark Wilcox) - GreeceJS #15
 
React. Flux. Redux. by Andrey Kolodnitskiy
React. Flux. Redux. by Andrey KolodnitskiyReact. Flux. Redux. by Andrey Kolodnitskiy
React. Flux. Redux. by Andrey Kolodnitskiy
 
1 of 40
ALL ABOUT THAT reactive UI Performance in Meteor
Paul van Zyl CTO at Nona Creative, @pushplaybang, pushplaybang on GitHub paul@nonacreative.com
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.
What we’ll cover • Reactivity and Connected Client Apps • Why Meteor • What is Performance? • UI Performance Tips for in Meteor • Mobile Patterns for Performance
Reactivity, & connected client apps
In computing, reactive programming is a programming paradigm orientated around data flows and the propagation of change. -wikipedia
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.
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.
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
UI Frameworks
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.
Why Meteor
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
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).
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
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
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
time for code a common approach to reactive UI’s with Blaze https://github.com/Pushplaybang/pomodoro-timer-prototype
What is Performance
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?
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?
Building Performance Orientated UI’s in Meteor
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
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”.
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!
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.
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
How fat is too fat? • WAIT! Wont Xwalk and WKwebview bloat the app? • https://gist.github.com/Pushplaybang/21780c8d535 92f082b59
Mobile UI Patterns We’re not the first people to try figure this out.
All about that reactive ui
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
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.
Delaying Activity • use setTimeout or TransitionEnd if you can. • setTimeout is 60% slower than using the transition end event.
Micro Optimisations That Mattered To Me
getElementById
Classname vs Style
Offset vs getBoundingRect
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
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
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.

More Related Content

All about that reactive ui

  • 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
  • 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
  • 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.
  • 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
  • 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?
  • 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.
  • 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.