Filtering by Category: javascript

EmberConf 2016 - Opening Keynote by Tom Dale and Yehuda Katz

Tom Dale (@tomdale) and Yehuda Katz (@wycatz), the Batman and Superman of Ember, did a stand-up job proclaiming the state of the union in Ember land.

They covered a lot of ground! Here I want to highlight the stuff that excited me. and capture some of the big ideas for my colleagues back home actually working! Note, my own observations and paraphrasing are liberally mixed in. 

The Growth of Ember

The community, influence, and use of Ember is growing significantly. Last year there were 600ish in attendance at EmberConf, and this year that number has grown to 950+. Last month, there were nearly 340K downloads of ember-cli. There are now 70.8K users of the Ember Chrome extension.

Of note, is the surging adoption of Ember 2.0+ and Ember CLI. Through survey, the Ember team learned that ~75% of the Ember community has moved to Ember 2.0+.

There are some notable companies that are betting big on Ember, including LinkedIn, the Dollar Shave Club, and PlayStation. Of course, you can also look at the list of EmberConf sponsors and see more big names. And just walking around I've met devs from recognized names in varying industries, such as Microsoft and American Eagle. 

Ember is impacting the wider development ecosystem. The Angular project is now implementing a CLI that is based on Ember's CLI.

Support for Ember is Diverse

Ember is not the work of a single, large company. There are real resources behind Ember from multiple companies such as LinkedIn, Yahoo!, CardStack, and Bustle. 

The Ember Core Team is diverse, and growing through the creation of area-specific sub-teams for Ember Data, Ember CLI, and learning. Each of these sub-teams will be guided by a core team member. In particular, I'm thrilled to hear that a team will be dedicated to learning Ember! 

Lessons Learned from 1.13

In my opinion, though at times eye-rolling and head-spinning, the Ember progression from 1.0 to 2.0 was capably managed, and in my own work, the experience of moving my project app over time from 1.7 to 1.13 was good. 

"Stability without stagnation." - Yehuda & Tom

Nevertheless, as Yehuda mentioned, mistakes were made, and lessons were learned on their side in this process. So, of note, is that Ember has implemented a Long Term Support system of releases. 

  • LTS versions will be every fourth release, so new LTS released every 24 weeks.
  • LTS will have bug fixes for 36 weeks.
  • LTS will have security fixes for 60 weeks.
  • The first LTS release was 2.4.

Ember Add-Ons

It is becoming easier to contribute to Ember and to use the contributions others are making. The ember add-on system is making this possible. The plugin APIs are being improved significantly and it is possible to impact Ember from the outside rather than having to contribute directly to Ember itself. is the place to dive in to ember addons.

ember-concurrency is an example of the great add-ons now being built for Ember.

A "jsbin" for Ember has been given to the world, ember-twiddle,  so that you can write your Ember bins with ES6 modules. That's pretty cool (and handy)!!

Onwards to the Web!

After addressing the growth of Ember and lessons learned from the past, they turned to address the current state of the web, and the problems affecting all of us as we build our apps.

"The web has clearly won on the desktop." - Tom Dale

So the web is victorious on our desktops. However, mobile devices reside in unconquered territory ruled by native apps. And some of these chunky, beastly things are aggravating to install. They have a high number of steps and back-and-forth screens to get from first browse to actual use. Pride of place on the scale of annoyance goes to Pinterest. Just go try it.

It was quoted that according to a Google study, 69% of users quit mobile web apps at the interstitial page forcing users to install a native app. Nevertheless, native apps are still the preferred way we are building for mobile. Web on the mobile sucks, and so it goes. 

The question then is, what is the way forward? How to do we change the prevailing practice? And how do we do that without the same amount of space for our web apps that native apps are able to utilize (the Pinterest app is something like 40MB)?

"How do we deliver native caliber features without giving up 'instant'?" - Yehuda 

There are many features already in mobile web browsers that we can use to our advantage, but using them is challenging. Many developers don't have time to utilize them, let alone master them. Examples include service workers, geolocation, app cache, camera, WebGL, IndexedDB, etc.

Ember to the Rescue!

Ember wants to make that easy by responding with the following solutions.

FastBoot will allow your app to render initially on the server allowing users to see content before JavaScript loads. This will mitigate all but the largest payload sizes. Ember FastBoot 1.0 and Ember 2.7 will ship at the same time. The Ember team is working hard with Heroku to make a great experience of getting an Ember app up and running, fast and and easy.

Project Svelte (mentioned way bay here and here)  will focus on reducing the framework size by removing deprecated features, and shipping Ember as ES6 modules. This will allow for the removal of unused modules and the ability to use only the modules you need.

Engines will allow users to split up their application code into separate bundles, and only load code for the part of the app when required.

String loading will allow users to ship JavaScript modules as strings, and only pay the evaluation cost for modules that are actually used.

Service workers will allow users to make their application available offline, give precise control over network requests, and preemptively fetch resources.


The Glimmer rendering engine shipped with Ember 1.13, and greatly improved rendering stuff in large arrays. However, there was significant regression in the rendering of components. The Ember 2.x releases have been addressing that problem, but there is a lot more room for improvement.

Glimmer 2.0 attacks this problem of rendering components. Yehuda here gave several demos (created by others) to demonstrate the significant improvement. The first demonstrated that Glimmer 2 is about 2x faster than Glimmer. And the second demonstrated rather amazing improvements in speeds from ~15 fps in Glimmer 1, to ~35 fps in Glimmer 2. Compare this to React which is about ~25 fps.

However, render speeds can still be way better, according to Katz. And he demonstrated the use of a new optimization that yielded speeds of ~ 60 fps. 

These improvements have been made by optimizing object models, and l templates in Glimmer 2 that are 5x smaller than Glimmer 1.

And there is more to be done, as the team knows how to improve speeds yet another 2-3x, but the work just needs to be done. 

Erik Bryn has provided the Ember conference web app, a demonstration of much of the above.

Ember to Change the Web

As mentioned before, there are many great technologies available today on web and mobile web which are simply not utilized well. Ease of use is key, and that's why many of these technologies remain ignored.

"Ease of use is key." - Yehuda

The duo declared that the goal is to make Ember the MacGyver of the web. Of course, not for folks to build things to blow crap up (ember-toothpaste-bomb)  ;-). Rather,  to attack the existing problems in using web, particularly in mobile, and revolutionize their use the same way Ajax made XHR easy and rocked the web a decade ago.

Ember: "An SDK for the Web" - Tom & Yehuda

Underlying this approach is the Unix philosophy of having a system which allows developers to build small apps that do one thing really well. That is a great analogy, and I hope that happens.

Thanks to Yehuda and Tom for a great opening keynote. Their leadership is appreciated both for pushing Ember onwards and for listening to the community.

Thanks to DockYard for a running, live bulleted list here. Tom and Yehuda have provided their slide deck here. · Copyright © · Caveat Lector