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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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."
• 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.
• 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.
• 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.
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.
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.
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.
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.
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.
• 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.
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.
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.
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.
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.
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.
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.
• 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.
• 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.
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.
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.
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.
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.
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.
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.
…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.
“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.
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.
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.
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.
tomdale
azukiazusa1
nearme_tech
syossan27
77web
rinchsan
horie1024
treastrain
shoheihosaka
alli83
ayaka1230
beberlei
pineapplecandy
jlugia
caitiem20
mthomps
matthewcrist
smashingmag
mraible
cromwellryan
skipperchong
rasmusluckow
hursman
afnizarnur
jasonvnalue