$30 off During Our Annual Pro Sale. View Details »

EmberCamp London Keynote 2016

EmberCamp London Keynote 2016

Keynote presentation from EmberCamp London 2016 discussing the evolution of Ember and the mobile web. Presented by myself and Yehuda Katz.

tomdale

July 12, 2016
Tweet

More Decks by tomdale

Other Decks in Programming

Transcript

  1. View Slide

  2. Community
    Let's talk about community first. We've heard you loud and clear: Ember's stability without stagnation policy is not very exciting. Our RFC process gives you too much
    insight into changes.

    That's why I'm excited today to announce the newest member of the core team.

    View Slide

  3. AMBITIOUS
    WEB APPLICATIONS
    We think the trend is clearly towards more web apps. With technologies like Service Worker and push notifications, the mobile web is becoming a first class app platform
    in its own right. As we saw happen on the desktop web, once you reach a certain critical mass of functionality, users tend to prefer shareable, installation-free web apps.
    They're just a better user experience.

    View Slide

  4. SDK FOR
    THE WEB
    We think of Ember as being the SDK for the web; it's all the tools you need to build these kind of great web experiences.

    We don't need to be the platform. We don't need to port a native platform to the web. What the web is missing—and what native platforms have—is an SDK that helps
    you manage complexity as your app grows, and helps you package and distribute your app optimally to your users.

    We want to build a solution that doubles down on the web's strengths. Focus from the bottom up on building a world-class web application.

    Web apps are not just "good enough"—they have real advantages for users.

    View Slide

  5. We say that Ember is a "framework for building ambitious web applications." Let's talk about what "ambitious web application" means in the context of the mobile web.

    On the desktop, "ambitious" usually means a long-lived "workspace app". People are willing to wait for a few seconds because using this app is their primary activity at
    the moment. They'll accept a little load time if it gets them a snappy, productive UI.

    But the idea of a "long-lived app" basically doesn't exist on mobile. Mobile is for quick interactions. Very few people are sitting down to work for an hour on their Android
    phone, even on native apps.

    This fact should give the web an advantage, because it already places a premium on instant interactions. You get what you're after, without an install step.

    View Slide

  6. content interaction resilience
    1 2 3
    html critical js all js
    An optimal mobile web app loads in these phases. First, we deliver the raw content, ensuring those on slow connections or without JavaScript get what they're after as
    soon as possible. Next, we load the minimum set of JavaScript needed to add interactivity for that page, keeping transfer time and parsing time low.

    Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data. Subsequent visits and
    interactions are therefore nearly instantaneous, because they don't rely on the network.

    Unfortunately, building an app that actually takes this optimal approach has historically been very difficult.

    View Slide

  7. content interaction resilience
    1 2 3
    html critical js all js
    progressive enhancement
    Progressive enhancement, if done correctly, gets you the first two phases. But this approach inherently relies on server-side rendering, meaning any kind of network
    flakiness makes interacting with the app feel slow, if it works at all. You also have to manually separate the behavior and presentation, rendering HTML and then manually
    wiring up the JavaScript after the fact.

    Because of this complexity, many developers prefer the experience of using frameworks like Ember, Angular and React to writing progressively enhanced applications.
    It's just too many details you have to get right by hand.

    View Slide

  8. content interaction resilience
    1 2 3
    html critical js all js
    SPA / native app
    Phase 3 on desktop means having your workspace app up and running. On mobile, this means making subsequent interactions as fast as possible by running them right
    on the device, rather than having to communicate over the (often unavailable or slow) network.

    Phase 1 and 2 and Phase 3 both have real benefits, but getting both is tricky and very few people have the time and resources to pull it off.

    This has caused the world to become polarized into two camps: the "lightweight JavaScript" people who say instant load times are paramount (often ignoring the bad-
    network scenario), and people who favor developing native apps, taking a hit on initial load with multi-megabyte app downloads, but guaranteed functionality even when
    totally offline.

    View Slide

  9. What you often end up with is a very compromised experience. Here's a real example from just a couple of days ago.

    I sent Yehuda a link from my Foursquare app to the coffee shop I wanted him to meet me at. He opened it to get walking directions.

    But before showing him the information he needed, it pops up an interstitial prompting him to install the native application. OK, let's go ahead and do what they suggest.
    We'll open the App Store and sit and wait while the app is installed. Next we open the app, but of course, it's lost the intent of wanting to look at this particular coffee
    shop.

    So we'll go back and tap the link, and of course, it takes us right back to the web app—only now it's not hiding the information we needed all along! I tap the address
    and it opens my native Google Maps app, and I quickly get the walking directions. This is what should have happened the first time! So what was the point of installing
    this app?

    This whole flow wastes valuable user time, and for what? Someone believed that the fact that the native app was such a superior experience—particularly for re-
    engagement features like being on the home screen and push notifications—that it was worth interfering with that instant gratification.

    But… what if we could somehow design a programming model that didn't force us to make this tradeoff?

    View Slide

  10. component
    component initializer
    route
    route
    route
    model
    adapter
    helper
    ember-cli
    production
    build
    development
    build
    FastBoot
    build
    template
    The benefit of an SDK for the web is that it knows how your app works, top to bottom. You write your app once in a declarative way, so Ember can create different
    versions of your app from the same code.

    3 examples of different "versions" of the app that we build today:

    1. Development mode, where we don't minify and include extra code for debugging.

    2. Production mode, where we strip out assertions, turn optimizations on, minify, concatenate, gzip, fingerprint assets, and more.

    3. FastBoot, where we produce a Node.js-compatible build.

    View Slide

  11. fastboot-app-server
    FastBoot
    build
    We can then take that build of your app bundled with Node.js dependencies, and run the exact same codebase for server-rendered apps. And that's just by installing a
    single addon.

    View Slide

  12. component
    component initializer
    route
    route
    route
    model
    adapter
    helper
    ember-cli
    critical JS critical CSS
    Service
    Worker
    template
    http server
    We're working on even more sophisticated slicing and dicing. For example, we can examine precisely what features you use and automatically trim code for features you
    don't use. We can also figure out what code is needed for a particular route, and stream in code for all of the other routes only once the user has a fully-interactive page.

    We could also determine what CSS is needed by the components on that page, and generate the critical CSS automatically.

    Later today, Marten is giving a talk on Service Worker that you should definitely check out to get a taste of the experimentation going on in the community right now.

    View Slide

  13. gcc -O3 for the web
    We need a tool that takes a single codebase and can produce optimized versions for you—because you're compiling ahead of time, it can take a little bit longer.

    If you're familiar with native app development, you know that you can take a single codebase and tell gcc to optimize it for specific requirements. Debug symbols and
    assertions for development, maximum performance (but slow builds) for release, and maybe even optimized for size.

    On the web, we need a shared understanding of your entire app, but then Ember serves the same role: from a single codebase we can produce many optimized builds
    for different requirements. Ember is gcc -O3 for the web.

    View Slide

  14. content interaction resilience
    1 2 3
    html critical js all js
    single Ember codebase
    By giving developers a single, modular programming model, you get all three modes from the same codebase. Because we have a conventional structure for how apps
    boot to how they're torn down, we can break your app into pieces and serve it to the browser just-in-time. That means you don't have to manually split your code up or
    write any of this infrastructure yourself. It also means we can run it in other environments like Node.js easily.

    View Slide

  15. What is Ember For?

    View Slide

  16. App
    Page
    When it comes to building desktop web apps, what is Ember.js for? There's an age-old argument about the difference between "web pages" and "web apps." In reality,
    there's a continuum between the two.

    Take a landing page, for example. You don't have multiple pages so you don't need a router. You probably don't need services, and Ember Data may not get you much.
    Most people would say Ember would be overkill for a landing page.

    On the other hand, for things that are unquestionably "apps", people tend to use Ember a lot. They know they are building a sophisticated app and they're going to need
    everything Ember gives you.

    View Slide

  17. Heroku
    Dashboard
    Square
    Dashboard
    Travis CI
    On the desktop, we see Ember used a lot in workspace apps. A workspace app has the following characteristics:

    1. It's typically behind some sort of authentication, not indexed by search engines.

    2. Usually used for more than a few minutes at a time. Load time can be a little bit longer because it's amortized over a half hour.

    3. Visitors tend to be repeat visitors; you can count on many of your users having the JS assets in their cache.

    4. Because of they have so much functionality, they tend to be worked on by larger teams.

    We win a lot here! But unless you know that you are building something like this, people tend to view Ember as overkill.

    View Slide

  18. View Slide

  19. App
    Page
    On mobile, this phenomenon is exacerbated because of significantly tighter hardware constraints. And because there's no such thing as a "workspace" app on mobile,
    the opportunities people get to use Ember are diminished.

    View Slide

  20. DISQUALIFIED
    On mobile, Ember often gets disqualified for "pages" simply because of payload size. Even for apps, because of of the importance of load time on a mobile, large file
    sizes can disqualify you out of the gate.

    View Slide

  21. View Slide

  22. So what can we do to mitigate this, and make Ember apps load instantly on mobile devices?

    View Slide

  23. Today

    View Slide

  24. • Glimmer 1
    • Engines
    • JavaScript modules
    • FastBoot
    We've mostly been laying the infrastructural groundwork.

    - Glimmer 1

    - Engines - props to Dan Gebhardt

    - ES6 modules

    - FastBoot

    View Slide

  25. LinkedIn decided to build a mobile app about a year ago

    1. Dozens of engineers working on it at any one time, so it has to have strong conventions

    2. Replacing an existing Backbone app, while significantly adding functionality. Backbone app hit a wall in terms of features and number of engineers they could add, but
    set a good performance baseline.

    There was no framework that was both fast and designed to scale to big teams.

    So they decided that the best path was to start with Ember and make Ember competitive from a performance perspective.

    View Slide

  26. 95th
    Percentile
    Samsung Galaxy S3
    2012
    This is a phone you can still buy from Wal-Mart, or Tesco or Carphone Warehouse or whatever. The point is you can still buy it in a store.

    LinkedIn tests frequently on this device, so we have a real-world understanding of how Ember performs on "real hardware."

    View Slide

  27. • String loading
    • Eagerly load common modules
    • Net 25% real-world improvement
    Improving Mobile Load Times
    As part of getting this app into production, the LinkedIn team has made several changes to the way they package and deliver their Ember app.

    These are spikes that they're looking forward to bringing to Ember CLI by default.

    All of this takes advantage of the work we've been doing to standardize on JavaScript modules.

    View Slide

  28. • Glimmer 1 ➞ Glimmer2
    • Engines ➞ Lazy Loading
    • JavaScript modules ➞ Svelte
    • FastBoot ➞ BigPipe
    All of these investments we've made unlock future optimizations that are being worked on to deploy to production at LinkedIn now.

    View Slide

  29. Glimmer 2
    The thing I've been spending most of my time on the past year has been a ground-up rewrite of the rendering engine, called Glimmer 2.

    View Slide

  30. • JavaScript
    • Small core
    • Components implemented
    in Ember
    Glimmer 1 Glimmer 2
    • TypeScript
    • “Rendering engine engine”
    • Components implemented
    in Glimmer
    Glimmer 1 had a fast, small core. But as we started implementing features on top of it, we lost many of the initial performance gains.

    View Slide

  31. Glimmer 1
    Ember
    View Layer Core
    Glimmer 1 was the smallest set of primitives. For example, Glimmer 1 itself did not have any notion of a "component." Many of the view layer APIs you use in your Ember
    app were still implemented in Ember itself.

    View Slide

  32. Ember
    Glimmer 2 View Layer Core
    With Glimmer 2, we push much more of the view API into Glimmer, allowing it to optimize much better.

    View Slide

  33. Work is all happening on Canary, so feel free to check it out at your convenience.

    Make sure to run a production build if you're testing performance.

    View Slide

  34. github.com/
    emberjs/
    ember.js/
    issues/13644
    Track Glimmer 2 Progress
    The feature flag will not be “go”-ed until after the 2.8 LTS release at the earliest. Probably not a good idea to land a major rewrite in an LTS release!

    Glimmer 2 is very exciting in terms of the rendering performance it gives us, but it has some other exciting implications.

    View Slide

  35. Future
    Let's show you a project that Tom's been working on for the last few weeks. This is an app that he's building at the company he work for, Monegraph, designed to be
    shared on social media by celebrities, politicians, and other people with a social media following.

    View Slide

  36. hillary.monegraph.com
    We call it an mCast, and it is designed to deliver an instant-loading, native-feeling app on the web. You can try it out yourself at this URL to get a sense of just how fast it
    loads.

    - This is an example of an mCast configured to collect donations for the Hillary campaign, and we're talking to the campaign in the hopes they will use it.

    - This app has only one page, so a router is overkill. The only data in is a streaming video and the only data out is via analytics libraries and the Stripe API, so Ember
    Data and other services are overkill.

    View Slide

  37. hillary.monegraph.com
    - Designed to go where native apps can't: inside a Twitter or Facebook Web View.

    View Slide

  38. We knew that the most important constraint for this app was load time. It had to be as close to instant as possible. Ember is too big for this use case, but at the same
    time, we didn't want to give up the productivity we were used to. As many of you have probably experienced, once you've gotten used to the Ember ecosystem, going
    back to roll-your-own feels very painful.

    View Slide

  39. • Ember CLI
    • Glimmer 2
    • No Ember.js
    • No jQuery
    So here's how we built it.

    View Slide

  40. • Sass
    • App Cache
    • TypeScript
    Because we leaned heavily on Ember CLI, tapping into the ecosystem was easy. We were able to take advantage of performance work that had already been done for us.

    For example, in this app, we used broccoli-app-cache to automatically generate an App Cache manifest—literally one line of code.

    We added Sass compilation, App Cache support, and TypeScript in just a few lines of code.

    View Slide

  41. Nexus 7, Chrome, Mobile 3G
    Because it was so slimmed down, we get good time-to-first-paint time even on older Android devices.

    View Slide

  42. To give you a visceral sense of what this feels like, here's a video from webpagetest.org. Remember that this is a few-years-old Android device on a simulated 3G
    connection. We see usable UI in about a second, fully rendered in under 3—and this is without server-side rendering, which is an additional optimization we're interested
    in exploring.

    View Slide

  43. 0
    11
    22
    33
    44
    kilobytes, min + gzip
    React
    44kb
    Glimmer 2
    39kb
    App +
    So I told my boss that I wanted to use Glimmer 2 for this project, but I knew it was risky. Glimmer 2 was designed, first and foremost, to speed up existing Ember apps. I
    told him that if I couldn't build a working prototype within a week, we would abandon it and use something else.

    After a week of hacking, I had something working. I was pleasantly surprised to discover that not only was it fast, we hit our payload size target (click).

    One thing to note is that a big part of React is event handling, which we don't need for this app. Yehuda and Godfrey are working on further file size optimizations to be
    made to Glimmer 2 as well.

    View Slide

  44. One of the coolest things about this is that once I was done setting up the infrastructure, we had an experience that—while significantly pared down—would feel very
    familiar to any Ember developer. My teammates Will Bagby and Hassan Abdel-Rahman were able to quickly add additional functionality, like Apple Pay support in iOS 10.
    Web Payments is going to be HUGE for mobile apps. It's almost too easy to spend money.

    View Slide

  45. When I say an Ember-like experience, for example, I think this Handlebars template would look to familiar to most people in the audience.

    View Slide

  46. What’s Next
    So we've both been working hard on real apps that have to run on mobile devices. Tom's experience extracting Glimmer from Ember was a manual process, but this
    shows that smart enough build tools should be able to do that kind of code elimination for you, producing smaller file sizes if you use fewer features. Over time, Ember
    will become more Pay As You Go.

    So let's talk about the steps we're taking to ensure that all of the apps you've got today can benefit from these improvements.

    View Slide

  47. content interaction resilience
    1 2 3
    html critical js all js
    Remember, our goal is to let you write one Ember app (a single codebase), and let Ember create optimized versions of the app: the initial content without any JavaScript
    at all, the smallest JavaScript payload needed to start up interactions, and background load your entire application for better network resilience.

    Here are some of the steps to get there.

    View Slide

  48. JavaScript Modules
    First of all, we need a way for every unit of JavaScript to clearly state its dependencies in order to reliably "tree shake" that initial load.

    View Slide

  49. • router.js
    • route-recognizer
    • rsvp
    • simple-dom
    • simple-html-tokenizer
    • glimmer
    • backburner
    • dag
    • container
    • morph-range
    In order to take maximum advantage of this technique, we have to use JavaScript module everywhere throughout the ecosystem, such as these packages we used
    internally in Ember. The work to transition Ember's core and dependent modules is ongoing and proceeding quickly.

    View Slide

  50. TypeScript
    Glimmer 2 was the first Ember project written in TypeScript, and it really demonstrated its value.

    View Slide

  51. • Catches bugs
    • Improves performance
    • Helps enforce static code for
    modern JavaScript VMs
    TypeScript
    TypeScript gave us two major advantages for Glimmer:

    - The type system made it a lot easier to define clear, public interfaces as an API, while still retaining the ability to quickly iterate and refactor as we went.

    - The type system is pretty aligned with the requirements of modern JavaScript VMs, making it easier for us to encode requirements into the types that cause us to avoid
    common deoptimization footguns.

    We want people to be able to use TypeScript in their apps, but we will continue to design JavaScript-first, and JavaScript is the happy path for Ember users.

    View Slide

  52. The Object Model
    I've been working very hard to standardize classes and decorators in JavaScript.

    View Slide

  53. For example, here's what a component looks like today in Ember.

    View Slide

  54. And here's a hypothetical version refactored to use JavaScript classes and decorators to write the same thing.

    View Slide

  55. By moving this into the language, not only do we get to delete huge swaths of code once you migrate to the new syntax, it also means developers new to Ember are
    more likely to be familiar with it already.

    Note that this will be an incremental change, we will not break your apps and give you a story for moving piecemeal to the new syntax.

    View Slide

  56. Ember is Overwhelming
    There's kind of an elephant in the room, though. Even if we make the file size of a simple app tiny, people feel overwhelmed just learning Ember. If they succeed in
    learning it, they usually love it—but a lot of people don't try because it feels intimidating.

    They get dropped in to the deep end of API surface area, and feel like they need to understand everything just to get something simple done.

    When you give someone an abstraction and they don't understand why they need it, it's worse than useless: it makes it harder to learn, and they often feel like they're
    fighting against it.

    View Slide

  57. Build Your Own Framework?
    The proposed alternative to this is BYO Framework. You start with a small core (like Backbone or React), then layer on the abstractions you need, as you need them.

    This feels really great at first! But it has some real shortcomings.

    First, you have to integrate the disparate pieces yourself. The "glue code" that bridges two different libraries can really add up when they aren't designed to work
    together, and it gets worse the more libraries you throw into the mix.

    Second, when you have too much variation in how apps are architected, you can't build automated tools that slice and dice and optimize your application in different
    ways. It would be like asking gcc to compile and optimize your program when everyone app was written in different syntax.

    React is obviously in use by more sites than Ember. But I would bet that Ember is more popular than any particular permutation of React/Redux/Flux/MobX/etc.

    For example, let's look at one hypothetical web app built using the BYO framework approach.

    View Slide

  58. raven-js
    shortid
    sass
    gulp
    gulp-real-favicon
    autoprefixer
    mocha
    bluebird
    validator.js
    webpack-isomorphic-tools
    react-helmet
    react
    redux
    redux-storage
    babeljs
    immutablejs
    react-router
    react-router-redux
    react-intl
    webpack
    express eslint
    formatjs
    (describe packages)

    And I know what you're thinking—I'm just trolling. No real app would do this.

    View Slide

  59. But actually this is based on a real React boilerplate called Este.

    View Slide

  60. But if that's not to your liking, I found a list aggregating all of the React boilerplates available. The list is actually longer, but Keynote has a maximum animation distance
    of 10,000 pixels.

    This critique isn't intended to pick on anyone. The bottom line is just that it's nearly impossible to build tools that can optimize the delivery of an app when you have this
    much fragmentation in how they're architected.

    View Slide

  61. content interaction resilience
    1 2 3
    html critical js all js
    single Ember codebase
    Being able to deliver these different versions of your app at different times—to bend the curve of tradeoffs between progressively enhanced web apps and native apps—
    requires that the tools understand everything needed to make your app tick, from rendering to app initialization to data fetching.

    This is why the all of the work we've done as a community to build shared solutions is so important. Because any of us can improve a piece of Ember and be confident
    that that change will reach the rest of the community, we can build higher together. Instead of technical debt, it's like technical compound interest.

    View Slide

  62. Standalone Glimmer
    But we understand that not everyone wants to start with the full Ember stack.

    It's a major goal for Godfrey and Yehuda to make Glimmer easy to use as a standalone library, optionally with Ember CLI.

    There are many use cases for this, from writing reusable components, cross-framework UI components, to incrementally retrofitting older server-side web apps that
    cannot be rewritten.

    View Slide

  63. …With a Path to Ember
    We can let people enjoy the benefits of Glimmer. But most importantly, as your app grows, we'll have a cohesive, community-supported path from "standalone
    component" to "page" to "app" every step of the way.

    View Slide

  64. “V in MVC” “Platform of Capabilities”
    So there's an interesting thing happening. React is focused on radical simplicity. In fact, I hear people describe React as not even being a library for building web apps.
    Instead, it's a library for describing UI components that happens to have a DOM adapter.

    On the other end of the spectrum, Angular 2 describes itself as a "Platform of Capabilities," supporting JavaScript, TypeScript and Dart, cross-platform development with
    React Native and NativeScript, a new CLI tool, a new data library, a new router, RxJS built-in, and more.

    View Slide

  65. For the first time, Ember is positioned in the middle of the field. We're not trying to solve the problem of cross-platform app development. We're trying to give developers
    the most pragmatic solution for building apps on the web.

    View Slide

  66. SDK FOR
    THE WEB
    We think of Ember as being the SDK for the web; it's all the tools you need to build great web experiences.

    We don't want to be a platform. We want to be an SDK for the platform you already love; an SDK that helps you manage complexity and helps you deliver the instant-on
    experience users expect.

    In other words, we want to build a solution that doubles down on the web's strengths. We believe that web apps are not just "good enough"—they have real advantages
    over App Store-encumbered apps.

    View Slide

  67. App
    Page
    Glimmer Ember
    We have a productive, well-thought-out framework with a vibrant community. We don't need radical change, or try to turn Ember into the dominant paradigm for writing
    apps for all platforms.

    What we need now is to focus on speed, size, getting new developers started, and reaching new audiences that couldn't use Ember before.

    We always said we wanted to build a framework that would last a decade or more. We're about half a decade in now, and we could not be more excited about the future
    of Ember, and the future of the web.

    View Slide

  68. Thank You!

    View Slide