Alexander Blom Isle of Code Overview Some people consider responsive design to be cross-platform, and responsive design to be resizing for containers. However, this misses the distinction of fluid design & often leads to slow and bad programmatic implementations. This talk will cover the distinction and provide pointers on how to implement responsive apps that are also performant. Attendees should understand a differing view on how to build cross-platform apps, and the difference between fluid & responsive design. Target Audience Programmers, designers & cssers who think a single page with lots of media queries is a good idea. Five Things Audience Members Will Learn What is fluid design? The difference between responsive & fluid design Why are responsive designs often slow? How to implement responsive designs that are performant Bonus points to be revealed in talk!

2. whoami
@alexblom
alex@isleofcode.com

3. Isle of Code
• Toronto + Chicago based development;
• Focused on Ember/Cordova;

4. Our Goal
• After a preamble;
• Use a single Ember app, and render desktop +
mobile;
• Re-use the same Ember App for native
applications;

5. • Using one code base for multiple platforms;
• vs. building custom code bases for each
platform;
• Also handle mobile desktop/web sizing;

6. Wrapped Apps are
everywhere

7. ember-cordova
https://github.com/isleofcode/ember-cordova

8. Good Code == Good Hybrid
• Much of making effective mobile is simply
writing good code.
• Desktops let us be lazier;

9. WKWebView

10. A note on deviceready
• You probably need to use it for any custom
initializers;
• Has special handling. Even if you register the
handler after deviceready fires, it will still be
triggered.

11. Smoke & Mirrors
https://github.com/runspired/smoke-and-mirrors

12. Flexi
https://github.com/runspired/flexi

13. Responsive v Fluid

14. • Bootstrap's .col-md-push-* and .col-md-pull-* classes are classic
examples of using reflow design. Reflow utilizes floats and positioning to
re-arrange portions of your DOM (in this case columns) for different
viewport sizes. Reflow includes the use of classes like .offset-xs-6 to
adjust margins and spacing.
• Reorder design is similar to reflow, but it accomplished by using the CSS
order property to alter the position of items displayed using flexbox for
layout. Reorder is "cleaner" than reflow, but both suffer from significant
browser layout and paint time performance issues
• http://blog.isleofcode.com/modern-responsive-design/

15. Manage Reflows
• “Reflow is the process by which the geometry of the
layout engine's formatting objects are computed. The
HTML formatting objects are called frames: a frame
corresponds to the geometric information for (roughly) a
single element in the content model; the frames are
arranged into a hierarchy that parallels the containment
hierarchy in the content model. A frame is rectangular,
with width, height, and an offset from the parent frame
that contains it.”
• http://www-archive.mozilla.org/newlayout/doc/
reflow.html

16. What causes Reflow?
• Resizing the browser window;
• using JavaScript methods involving computed
styles;
• adding or removing elements from the DOM; and
• changing an element's classes.
• https://developers.google.com/speed/articles/
reflow

17. What causes reflow?
• http://csstriggers.com

18. Use CSS Transforms

19. visibility:hidden

20. <link href="disabled.css" rel="stylesheet" disabled>
• often end up downloading 2-3 sets of assets;

21. TouchBase

24. Standard Ember Structure

25. Standard Ember Structure

27. Taps
• Tap targets should be ~48px;

28. Hammer Example

30. Our components are the
same
• We can re-use the same logic, routes &
components. The templates are only visually
different;

31. Media Queries

32. media queries

33. Media Queries
• # of different css files matter?
• # of media-queries matter?
• Inline vs separate?
• http://aaronjensen.github.io/media_query_test/

34. Problems
• Expensive reflow;
• Code gets confusing & hard to follow quickly;
• Can’t do anything complex;

36. Same Problems

38. Problems
• Still hard to maintain;
• Canonically don’t know where to find mobile vs
desktop;
• Components either need classes, or containers
need selective classes;
• We’re introducing a lot of complexity that is not
needed;

39. • "fluid" only understands viewport boundaries, but often needs to know
about the boundaries of some smaller container
• "reveal" slows down renders by weighing down the DOM tree
• "reflow" and "reorder" cause expensive layouts and paints.
• "reveal", "reflow", and "reorder" can be hard to see and reason about.
• "restructuring" is just as messy, and likely less performant.
• layout CSS you can't see makes maintenance hard and adds a taxing
mental overhead to every project developer.
• layout CSS you can see (via layout classes) is overly verbose, and
often difficult to wade through.

40. When looking at just the
layout, it differs the most.

42. Layouts change.
Components are fluid.

43. Flexi

44. desktop.hbs

45. mobile.hbs

46. • Ditches reflow & reorder patterns;

47. Already easier to
follow

48. Elements
• screen: 100% width, min-height of 100vh;
• page: 100vw & 100 vh;
• fill / fill block: fills parent;
• centered:
• box: grows to match other items, but not container;
• hbox/vbox: fills remaining space, align horizontal/
vertical

50. For Emberists: sustain

51. Further Optimization
• In guaranteed mobile only environments, try not
to download desktop assets;
• Images can be resized per platform;
• Use fingerprinting to expire older assets;