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.
more web apps. With technologies like Service Worker and push notiﬁcations, the mobile web is becoming a ﬁrst 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.
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.
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.
experience. Here's a real example from just a couple of days ago. I sent Yehuda a link from my Foursquare app to the coﬀee 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 coﬀee 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 ﬁrst time! So what was the point of installing this app? This whole ﬂow 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 notiﬁcations—that it was worth interfering with that instant gratiﬁcation. But… what if we could somehow design a programming model that didn't force us to make this tradeoﬀ?
production build development build FastBoot build template The beneﬁt 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 diﬀerent versions of your app from the same code. 3 examples of diﬀerent "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, ﬁngerprint assets, and more. 3. FastBoot, where we produce a Node.js-compatible build.
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 ﬁgure 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 deﬁnitely check out to get a taste of the experimentation going on in the community right now.
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 speciﬁc 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 diﬀerent requirements. Ember is gcc -O3 for the web.
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.
what is Ember.js for? There's an age-old argument about the diﬀerence 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.
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.
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 signiﬁcantly 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.
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."
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.
ﬂag 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.
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.
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 conﬁgured 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.
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.
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.
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.
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, ﬁrst 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 ﬁle size optimizations to be made to Glimmer 2 as well.
I was done setting up the infrastructure, we had an experience that—while signiﬁcantly 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.
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 ﬁle 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 beneﬁt from these improvements.
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.
room, though. Even if we make the ﬁle 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 ﬁghting against it.
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 ﬁrst! But it has some real shortcomings. First, you have to integrate the disparate pieces yourself. The "glue code" that bridges two diﬀerent 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 diﬀerent ways. It would be like asking gcc to compile and optimize your program when everyone app was written in diﬀerent 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.
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.
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.
js single Ember codebase Being able to deliver these diﬀerent versions of your app at diﬀerent times—to bend the curve of tradeoﬀs 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 conﬁdent 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.
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 retroﬁtting older server-side web apps that cannot be rewritten.
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.
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.