Ember is fast. Ember Core is working hard to make Ember even faster. So why does your app drag?

The performance of a single-page app is impacted by the performance characteristics of its foundational parts: Network, Rendering, and JavaScript. Ember provides tools to manage these cornerstones, but with the tradeoff of introducing its own characteristics.

In this talk, we will use the source of real, shipped Ember apps (and of Ember itself) to diagnose, understand, and improve slow interactions. The Chrome developer tools will help us understand slow code paths and identify opportunities for improvement. Along the way, we will learn how parts of Ember work at the macro and micro level and learn how the framework helps us manage performance challenges in a browser environment.

At EmberConf, I spoke on web application performance and Ember.js. The message of this talk is that application performance is bigger than Ember performance. As authors of many of the more ambitious single-page web applications out there, we need to understand the tools and techniques used in analyzing and bettering the a user’s experience.

The slides above are accompanied by two live-coding sessions:

I also mentioned several tools in the slides and videos:

Additionally there are a few documentation resources I strongly encourage you to read:

Let me know if you have feedback on the presentation, and thanks to those who attended. In such a short talk it would have been difficult to comprehensively cover all the possible performance hangups in an Ember application, so instead these slides focus on giving you a new and better understanding of the tools available for gathering data, analyzing issues, and asserting the success of a change. With some practice, you will be using them every day.

Thanks to everyone at EmberConf for a fantastic week!

Correction: setProperties does not cause observers to coalesce

In my presentation at EmberConf, I stated that setting multiple properties with setProperties would cause an observer to only fire once. This is incorrect. The observer will fire for each property changed. See an illustration of the behavior in this jsbin. Thanks to @krisselden for the catch.

In September, I took a break from blogging here at madhatted.com to publish three posts with the Safari Books Online Blog.

  • Rendering with named outlets - After talking about complex architectures with Ember in late August, I realized the outlet API was unknown to many Ember users. This knowledge gap made the core ideas in that talk harder to understand. If you haven’t used named outlets or explicit render calls in your apps, this post is an excellent place to start.
  • Introducing Ember App Kit - EAK has been my build pipeline of choice for a several months, and the core concepts behind it are amazingly powerful. The number of tooling options for Ember is growing rapidly now, but EAK has the most interesting ideas and, I think, the brightest path moving forward. Give it a look.
  • Ember.js, À La Carte: Examining Feature Libraries - Over the summer there were several blog posts disparaging single page JavaScript apps, and frameworks in general. Several set Ember.js up as a straw-man. They complained about file-size, then demonstrated a solution to their specific problem without using a framework. Ember isn’t the right tool for every job, and it doesn’t claim to be. Its file-size is a trivial issue for an ambitious and reasonably complex client-side app. Regardless, Ember.js is built of several more focused libraries, many of which are best-of-breed solutions for their respective problem spaces. These libraries can be used alone, and in this post I introduce each with explanations and examples.

Working with the Safari staff to publish these posts and get them read was a pleasure.

On Friday I gave a presentation at EmberFest. The talk was framed by having worked on several Ember codebases, including one for almost 9 months. I’ve found that new Ember developers (or even experienced ones!) tend to lean heavily on feature-rich controllers to architect their applications- this works for a time, but as a codebase grows in complexity the controllers become unwieldy and confusing.

The fantastic Luke Melia must be thinking the same thing, because in RC8 he landed a change of the events hash to be called actions. This cosmetic change is almost a distraction from the real change: A refactoring of how controllers, routes, and views handle actions.

There is now an Ember.ActionHandler mixin that unifies the behavior. Check it out:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var Actionable = Ember.Object.extend(Ember.ActionHandler);
 
var secondTarget = Actionable.extend({
  actions: {
    "Wie Ghet's": function(){
     console.log("Und dir?");
    }
  }
}).create();
 
var firstTarget = Actionable.extend({
  target: secondTarget,
  actions: {
    "Wie Ghet's": function(){  // If actions was undefined or this action didn't exist, only secondTarget would handle it.
      console.log("Danke gut");
      return true; // If you return true, the event will continue to bubble.
    }
  }
}).create();
 
firstTarget.send("Wie Ghet's");

 
// Danke gut
// Und dir?

Having this behavior consistent, especially the logic behind when to bubble an action or not, is incredibly important. Thanks Luke!

I find that most successful Ember projects follow a simple pattern for application design:

  • Controllers present information to templates. And not much else, ideally.
  • Actions are handled on routes. This makes routes (which can access models and arbitrary controllers via controllerFor) and controllers each responsible for a different set of concerns.

The result is better and more maintainable code. Here are the slides from the talk:

Rumor has it that we may have video soon, I’ll update this post when they are published.

Update: Many thanks to Luke Melia for catching a few bugs in the code samples!

Update 2: Now with video from the NYC meetup.


← All Articles