Ember 2.0 landed in August, and with it came the first major shift in application architecture since Ember left its SproutCore roots. The Ember-CLI team made massive improvements to the speed and quality of our build tooling several times over, all while continuing to be the foundation for a growing addon community now topping 2000 projects. Ember-Data stabilized its public API for the first time in the project's history, and continues to contend for the title of most complete client-side JavaScript data layer.

Other projects, under the official umbrella and outside it, continue to innovate and mature.

With 2015 in the rear-view mirror, we should take a moment to check our assumptions about who is in the Ember community and how they work with the framework. To that end, we're pleased to announce the official 2016 Ember Community Survey!

Survey Landing Page

Completing the survey should take about fifteen minutes. We will be accepting submissions until March 21st.

Please help us spread the word by sharing the above link on your social network feeds, at meetups and around your office and other communities.

With your answers (all anonymous), we will create some visuals and write up our insights to share at EmberConf 2016 (March 29th-30th). If you have any immediate questions, feel free to email Ryan (@RyanLaBouve) and Matthew (@mixonic) via survey@201-created.com.

We look forward to your participation!

• Ember.js completed eight backward-compatible minor version releases in the last year, 2.4 through 2.11. Included were the framework's first two Long-Term Support (LTS) releases.
• Glimmer 2, a major rewrite of Ember's rendering system, landed in Ember.js 2.10.
• Framework support for Ember Engines landed in in Ember.js 2.8.
• Support for Ember FastBoot stabilized in Ember.js 2.4.
• The Ember.js addon community grew from 2,000 to over 3,500 publicly available addons!

With 2017 already under way, we would like your help to learn about who is in the Ember community and how they work with the framework. To that end, we're pleased to announce the official 2017 Ember Community Survey.

Survey Landing Page

This is our third year learning about the community's makeup and interests, and we're looking forward to sharing the results at EmberConf 2017 on March 28th. The number of survey participants grew from 900 in 2015 (2015 survey results) to over 1,800 in 2016 (2016 survey results).

Completing the survey should take about fifteen minutes. Submissions will be accepted until March 21st.

Please help us spread the word by sharing the survey landing page on your social network feeds, at meetups and around your office and other communities.

We look forward to your participation! If you have any immediate questions, feel free to email Tom (@tzellman) and the survey team via survey@201-created.com.

• Ember.js completed seven backward-compatible minor version releases in the last year: 2.12 through 2.18. Included were three Long-Term Support (LTS) releases. Version 2.18 was declared as an LTS and is the final release of the project's 2.x series.
• Ember 3.0 and 3.1 beta versions also came into existence, marking the beginning of the 3.x series. 3.0 removes public API deprecated in Ember 2.x releases.
• Ember FastBoot, a server-side rendering solution for Ember apps, reached 1.0.
• The Glimmer VM, Ember's rendering system, also experienced a lot progress. This includes implementations of <Capital />-style component syntax, compiled binary byte-code, incremental rendering, and SSR with incremental rehydration. The October Glimmer Progress Report is a good place to look for details.
• The Ember.js addon community grew from 3500 to almost 4500 publicly available addons!

With 2018 already under way, we would like your help to learn about who is in the Ember community and how they work with the framework. To that end, we're pleased to announce the official 2018 Ember Community Survey.

Survey Landing Page

This is our fourth year learning about the community's makeup and interests, and we're looking forward to sharing the results at EmberConf 2018 on March 13th. A vast number of people, nearly 1600 participants, took part in the survey in 2017 (2017 survey results)

Completing the survey should take about 11 minutes. We've shortened the survey compared to last year, and created opportunities for you to share feedback as free-form text. All submissions are completely anonymous, and demographic data about the community is not released in the same raw data files as the free-form text and other answers.

Submissions will be accepted until March 7th.

Please help us spread the word by sharing the survey landing page on your social network feeds, at meetups and around your office and other communities.

We look forward to your participation! If you have any immediate questions, feel free to email Akanksha Dharkar (@AkankshaKana) and the survey team via survey@201-created.com.

Since the Ember community cannot predict the future, we cannot be sure that we will achieve all of the individual items enumerated here. Instead, the purpose of this document is to give the community a common purpose to aspire towards.

This year our two headline priorities are:

• Polish the practical and conceptual details of Octane (tracked properties, Glimmer components, related tooling, accessibility, performance and payload improvements).
• Make Ember easier to try and adopt, but also lower barriers for Ember developers when collaborating with the greater JavaScript project. We will do this through improvements and simplifications to the framework, and through focused communication with the greater JavaScript community.

This document was started in fall 2019. It is a distillation of multiple sources:

1. The 2019 Community Survey.
2. Community #EmberJS2019 blog posts authored in response to our call for posts.
3. Discussion on https://discuss.emberjs.com, Discord, Twitter, and other public venues (see the community page for how to access these communnities).
4. Deliberations among the Ember core teams.
5. Your comments and feedback on this document via the RFC process.

The goal of the roadmap is to align the Ember community around a set of shared, achievable goals that balance the needs of existing users with the need to grow and support new users.

Our Roadmap

Now that Ember Octane has shipped, it’s time to turn our attention to new efforts in 2020. Our goal is to build on Octane's release and capitalize on that cutting-edge foundation.

• Invest in Octane. Octane's mental model and basic components are complete, but a number of practical and conceptual gaps remain. We will close these gaps with work on tooling, by deprecating classic APIs to simplify Ember for new users, and by introducing additional functionality where appropriate.
• Modernize our build system. This year we will prioritize improvements to the Ember application build pipeline, and to Ember itself, which will bring modern optimizations like tree shaking and code splitting to both new applications and existing codebases.
• Better a11y by default. We will better support assistive technologies via updates to the router. Additionally we will provide developers more tools for understanding and improving the accessibility of their Ember applications. Our goal is a great "out of the box" experience with Ember and assistive technologies.
• Share Octane outside our community. Octane's release put Ember in front of a lot of new eyes. We will continue that trend through 2020 by talking about the latest edition of Ember in front of new audiences.

Invest in Octane

Ember Octane put the framework on a strong footing by modernizing its most foundational APIs. Teams are already productive using Octane, and from their experience have provided a torrent of real-world feedback. We will continue improving the developer experience (DX) of Octane throughout 2020.

Many of the rough edges in Octane aren't on the features themselves, but in the supporting tooling. The usefulness of stack traces from Glimmer, the ability to use TypeScript with Ember templates, how tracked properties and Glimmer components are reflected in the Ember Inspector, and the build speed of our application pipelines are all important parts of Octane's DX. We will invest in these areas of work.

For developers who are new to Ember, the presence of classic non-Octane APIs can be disorienting. We will look for creative solutions that make those features trivial for existing apps to continue using while also making them less expensive (in payload, performance, and mental model) for new adopters.

Finally there are some areas of Octane features which can still benefit from new feature work:

• The @tracked system, for example, limits the expression of state in an application to defined properties on an object. Real-world codebases often want to maintain state as a list or a map, and we can extend on the well-designed internals of Ember's reactivity model to support these cases.
• Modifiers provide a hook into the DOM rendering lifecycle, but Octane has no APIs for hooking into other lifecycles in the rendering and object system. We will create these APIs.
• We will continue a push to make Ember templates better analyzable at build time by introducing a strict-mode template and static imports.
• We will make it easier to build ergonomic, reusable components by shipping named blocks.

We will introduce new features in Ember which improve Octane in these and other areas.

Modernize our build system

Last year, we started work on Embroider, an overhaul of the Ember CLI compilation pipeline. This year, we will put the finishing touches on Embroider and start migrating the Ember ecosystem to this modernized build.

Embroider integrates Ember CLI with popular packagers like webpack and rollup. It allows Ember apps to trivially import from any dependency published as standard JavaScript modules, and will unblock shipping Ember itself as npm packages in the @ember namespace.

This new approach, through its foundation on common packaging libraries, will also unlock new build time optimizations. These optimizations, like tree-shaking and route-based code-splitting, will allow Embroider to produce smaller asset payloads.

Additionally, we will introduce a system into Ember which allows apps to drop framework code supporting deprecated features unused by an app. This will result in smaller vendor assets for applications which don't rely on deprecated features. For example, a modern Octane application may not require Ember.Component, and can benefit from having the code supporting that API being dropped at build time.

Finally, we will make sure this modernization effort provides benefits to existing applications. If a team has been steadily upgrading their app for years now, they won't need to rewrite it to get the benefits of a modern build packager.

Better a11y by default

Ember applications should be accessible to everyone. Unfortunately, even seemingly small mistakes can make your app difficult or impossible to use with assistive technology like screen readers. We will do more to improve the out-of-the-box accessibility of Ember applications, and provide tools to help applications stay accessible as they grow.

• Fix router accessibility so that page navigation is correctly announced by screen readers, without needing a third-party addon.
• Incorporate accessibility checks into the built-in test helpers.
• Engage with standards bodies to help fill the gaps in existing web accessibility APIs.

To contribute to this effort see RFC Issue 595 which coordinates the Ember A11y Strike Team.

Sharing Octane outside our community

There are more people building web applications than ever, and Ember must adapt to their changing needs and expectations in order to stay relevant. Octane better aligns Ember's API with what new users expect from a modern framework. We need to take advantage of that change.

This year, we’ll share with the world how Ember Octane is modern, productive, and fun. Through blog posts, videos, social media, meetups, and conferences, we will share our knowledge and experiences with the wider JavaScript community and encourage them to give Octane a try.

We will continue to make Octane more attractive to new users with a new documentation approach, more effective website, and with clearer communication about the Glimmer.js project.

Lowering barriers to adoption, and collaboration

Making Ember more attractive to new users doesn't mean compromising on what has made the framework so very successful for existing codebases and teams.

The most basic value of the Ember project is that we solve problems together. While we intend to grow the number of framework users and modernize the framework in many ways, we won't optimize for growth at the expense of our existing community. Instead, we will collaborate on solutions that come with a curated adoption story.

Because we understand and value the power of collaboration, we know we must lower barriers, technical and non-technical, which not only make new users hesitate to adopt Ember but also discourage Ember developers from participating the greater JavaScript community.

A great example of our progress in this is Octane's embrace of native JavaScript classes: A JavaScript developer starting out with Ember today isn't immediately forced to learn a new, Ember-specific class API before they can get to writing code. On the other hand, a developer who starts off with Ember can also contribute to most OSS JavaScript projects without needing to first un-learn the Ember class system.

By sharing common solutions to common problems with other communities we not only make Ember more approachable, we also benefit from the opportunity to exchange more ideas. Everyone wins.

With our efforts to flesh out Octane, improve the build system and align it with the rest of the JavaScript community, raise the baseline support for accessible applications, and to better communicate in 2020 we will lower barriers to adoption of Ember, but also to our own collaboration with the greater JavaScript project.

Want to get involved? Visit our community page and feel free to join us on Discord (chat) or Discourse (forum discussion).

The Strike Team met weekly between March 25 and June 24. We even managed to celebrate Global Accessibility Awareness Day!

There were five items listed in Issue 595:

1. Application Language Support
2. Label/Input Support
3. Page Title Support
4. Support for ...attributes
5. Accessible Routing Support

Active Work

Application Language Support

The goal of application language support was to provide a mechanism for new Ember apps to pass WCAG Success Criteria 3.1.1 - Language of Page. To meet that goal, Joseph Sumner, Jamie White, Ava Wroten and Melanie Sumner authored RFC 635, which proposed a --lang flag for ember-cli. This flag would enable developers to declare the application's language while they were creating the app, allowing them to more easily meet this particular success criteria. This RFC was merged on June 12th; the feature itself, authored by Joseph Sumner with help from Rob Jackson, was merged on August 24th.

To add another layer of support and enhance the overall developer experience, the team also decided that it would be useful to have an interactive way to create new Ember apps. After some discussion, Melanie Sumner authored RFC 638. The RFC was accepted and merged on August 10th. Implementation is still pending.

Additional support came from update to the Ember Guides, in both prose and art, thanks to team members Ava Wroten and Lenora Porter. Melanie Sumner also added a new rule to the Ember Template Lint addon called require-lang. It checks to make sure that the lang attribute is present on the <html> attribute. This rule will be effective in v3.0 of the addon, thanks to Alex Kanunnikov adding the ability to lint .html files in PR 1232.

Label and Input Support

There were 3 things the team decided to do in this area:

• Update the guides to provide more explicit guidance
• Provide an addon that would help provide ids within a specific context
• Write an RFC to propose a more permanent solution

Benjamin Jegard created the Ember Context Id Helper addon. The {{context-id}} generates a unique id for a given context. Because it uses Ember's guidFor function under the hood, it will always return the same id for the same context. A use case for context-id helper is to programmatically associate <label>s and <input> element using the <label> for attribute and the <input>s id attribute.

This addon took inspiration from the pre-RFC for the guid-for helper, which resulted in RFC 659, which proposes a new built-in template helper, authored by Steve Szczecina.

Rajasegar Chandran and Jen Weber updated the Official Ember Guides with more explicit information for how to associate <label> and <input> elements. Melanie Sumner also authored ember-component-patterns that reflect best practices for <input> fields.

Finally, support has been added to the Ember Template Lint addon with rules that require <input> elements to have valid labels and that there are no duplicate labels. Additional work is now being done to check that there are no duplicate ids as well as valid use of form groups.

Page Title Support

In our April 8th meeting, the team discussed how we thought we should approach page title support. More discussion throughout the month led us to support the template-driven support for page titles in Ember apps.

Benjamin Jegard, Melanie Sumner and Ricardo Mendes authored RFC 645, which proposes that the Ember Page Title addon be added to the blueprints for new Ember apps. After Framework Core Team discussion, it was decided that the addon needed some work before the RFC could be accepted. That work was outlined in an issue and is currently underway, thanks to community member Raido Kuli!

Back to the Drawing Board

After discussion and some analysis, it was determined that some issues required the attention of the Framework Core Team to resolve. These issues will likely require re-thinking of significant Ember features, so some workarounds should be expected until they are resolved.

Support for ...attributes

As outlined in Ember Issue 19026, ...attributes does not have a guaranteed merge order. This is problematic for 5 ARIA attributes because they can have multiple values in the form of an ID reference list and the order of these values matters.

This is likely to lead to some additional discussion about how Ember handles properties and attributes, and rethinking that approach to better support attributes.

Accessible Routing

There is an ongoing discussion for how to best resolve this issue in a permanent way. Despite a significant amount of research into the issue and an RFC that attempts to solve the issue, no resolution has been agreed upon yet. However, the Framework Core Team has accepted that accessibility is a design constraint for any new router work.

Until then, developers are encouraged to review the accessibility section of the Ember guides, and consider one of the routing-related addons for use. Options include ember-self-focused, a11y-announcer, ember-a11y, and ember-a11y-refocus.

A11y Working Group

At the final Strike Team meeting, we decided to continue the accessibility work in Ember and became the Ember A11y Working Group. We coordinate in the #dev-ember-a11y channel on Ember's Discord server and meet as needed. Anyone who is interested is welcome to join in!

Work is also underway to upscale the addons in the Ember-A11y GitHub org! We are also continuing to add first-class accessibility support to ember-template-lint; coming soon is support for users to be able to specifically only run the accessibility-related linting rules on a codebase.

Thank You

A huge thank you to all of the community members who participated in the Ember A11y Strike Team: Abhilash Ramesh, Amy Lam, Ava Wroten, Benjamin Jegard, Emmanuel Patrick, Eric Kelly, Frédéric Soumaré, Jamie White, Jen Weber, John Costanzo, Joseph Sumner, Lennex Zinyando, Lenora Porter, Melanie Sumner, Praskovia Root, Rajasegar Chandran, Robert Jackson, Steve Szczecina, and Seema Shariat.

Ember 2.4 will be the first LTS release of the core framework, and will continue every four releases thereafter. Additionally, we've updated the emberjs.com/builds page with better guidance about when and how to use each of the channels.

For our users, LTS releases allow you to upgrade less frequently while still getting support from the Ember project and the wider ecosystem.

For addon authors, LTS releases allow you to know which versions of Ember to focus effort on.

As a project, Ember will provide security and critical bugfixes for the most recent LTS release, in addition to the most recent release (as we do today). We will also avoid breaking heavily used private APIs without first deprecating them in a previous LTS release.

You can read more about the problems we tried to solve and details about how it works in RFC #56.

The LTS Release Process

The existing release channels allow you to make a tradeoff. On canary, you get features as quickly as they land, but get no guarantees about those features. On the stable release channel, you have to wait 12 weeks for features to stabilize and make their way through the beta process, but you are rewarded with semver guarantees.

While this provides all the flexibility you need to make stability vs. features tradeoff, there is another orthogonal dimension: how often you can schedule time to upgrade. LTS releases give the community an alternative, sanctioned schedule that works better for users who prefer a slower pace.

By synchronizing the timing that these users upgrade, the community can decide to focus energy on specific versions, rather than a scattershot attempt to support every possible combination. This should result in more consistent support and easier upgrades for users on the LTS channel.

The Ember 2.4 branch will be moved into the LTS release channel six weeks after Ember 2.4.0. In other words, Ember 2.4 LTS will ship at the same time as Ember 2.5.0. This means that features begin on Canary, spend six weeks on beta before making it into the stable channel, and spend another six weeks on the stable channel before making it into the LTS release channel.

This same process repeats every four releases, meaning that the next release on the LTS channel will be Ember 2.8 LTS, which will ship at the same time as Ember 2.9.0.

For example, the expected release of Ember 2.4 stable (currently in beta) is on February 26th. To give you a sense for the cadence of our release channels, the projected release timeline is as follows.

LTS releases will receive critical bugfixes for 6 release cycles (36 weeks). This means we will support Ember 2.4 LTS with critical bugfixes until Ember 2.10.0 is released, around November 4, 2016.

LTS releases will receive security patches for 10 release cycles (60 weeks). This means we will support Ember 2.4 LTS with security patches at least until Ember 2.14.0 is released, around April 21, 2017.

As you can see in the above diagram, Ember 2.8 LTS is projected to ship around September 23, 2016. This gives you plenty of time to complete the migration to the next LTS release once it comes out. As always, because Ember 2.8 is semver compatible with Ember 2.4, the upgrade should be relatively smooth.

By the time 2.8 rolls around in roughly six months, any addons that make use of the private view APIs should have had a chance to update.

The LTS Guarantees

What makes an LTS release different than a stable Ember release? LTS releases come with guarantees about API stability and security:

• Because each LTS release will receive security fixes for 60 weeks, we will backport them to at least the two most recent LTS releases. Read more about Ember's security policy.

• Release notes for each LTS will contain a summary of features and deprecations added since the previous LTS. This will likely consist of a number of links to documentation, guides, and release notes for stable releases.

• Addons and applications should constrain themselves to using Ember's public APIs. However, in practice we recognize that experimentation and use of "intimate" APIs is a reality. To ensure addons and apps using these intimate APIs have a migration path forward, any change to a heavily used private APIs will receive a deprecation warning in at least one LTS release. This gives LTS users and the addon community about six months to migrate away. For example, the view APIs (private in Ember 2.x) will be marked as deprecated in Ember 2.4 LTS, and removed before Ember 2.8 LTS.

• We encourage addon authors to maintain support for the latest LTS release, in addition to tracking changes in the stable releases.

In practice, since these releases still abide by semantic versioning, upgrading from LTS release to LTS release should not be significantly more work than upgrading along the six-week release cycle.

Upgrading less frequently will mean, of course, that a developer will wait longer to take advantage of new features. Additionally, it means the changes in best practices between releases (and in the number of deprecations) may feel more significant.

Legacy View and Controller Addons

Ember has provided the ember-legacy-views and ember-legacy-controllers addons since Ember 1.13. For large codebases, these addons provide a slower off-ramp for legacy view and controller features. Big apps can move to Ember 2.0 without the complete removal of views.

These addons rely on several private APIs expected to undergo significant refactoring in Ember 2.5 or 2.6. Therefore, the Ember 2.4 LTS will likely be the last LTS to support these addons. They will become unsupported in September or October with the release of Ember 2.8 LTS.

See You Soon

LTS releases are just one of the many things we've been working on; the core team has had a long couple of months and we're excited to share everything. There will be more announcements and plans shared at EmberConf (March 29-30 in Portland), looking forward to seeing so many of you there!

import 'ember-source/types';
import 'ember-source/types/preview';

This will set your app up to start using Ember's preview types now and to automatically benefit as we stabilize our types incrementally over the releases ahead. You won't have to do anything except add these once and then upgrade your app on your normal upgrade cadence!

Note that there are some significant changes to these types compared to the types as they exist on DefinitelyTyped today. All public API remains supported, but in line with RFC 0800, we intentionally provide only minimal support for Ember Classic APIs around class definitions. Accordingly, you should migrate to native classes before attempting to adopt these types if you have not already done so!

The rest of this post is broken into four sections:

• How the preview period will work
• Migrating from DefinitelyTyped
• New TypeScript users
• What's next on Ember’s road to TypeScript?

If you’re curious about the details of how this approach to publishing TypeScript types for Ember works, check out the PR which introduced support!

How the preview period will work

There are two type-only modules you import: 'ember-source/types' and 'ember-source/types/preview'. These represent the stable and preview types respectively. At the start of the preview period, there is nothing at all in the stable module: all the types are in the preview module.

The key difference between the stable and preview types is: our stable types must be generated from Ember's own TypeScript source code, while the preview types are hand-written type definitions. The hand-written definitions match up closely to the actual code, but small gaps are inevitable. Types published directly from Ember's own source code will not have that problem!

Over the course of the preview period, we will be doing two things:

1. We will be fixing bugs in these types as they are identified, and releasing bug fix releases the same way we would for runtime errors. (This will be the new normal for Ember: fixes to types are exactly like fixes to runtime errors, because both are bugs!)

2. We will be working on Ember's build infrastructure and the structure of its internals to make it possible to publish types directly from the source, instead of using hand-authored types. These are the types which will be exposed via the import 'ember-source/types'; statement.

Once we are fully cut over to publishing types from Ember's source code, we will declare them "stable" and therefore subject to Ember's normal SemVer policy. For details on how we are handling SemVer for TypeScript, check out the relevant section of RFC 0800 and the Semantic Versioning for TypeScript spec we authored and follow. We’ll also be updating the website with those details in the next few weeks.

We will make a best effort to avoid breaking changes in the types during the preview period, but the transition to the stable types will inevitably involve many bug fixes which may feel like breaking changes!

Also, given that these are preview types, we will continue to maintain the types on DefinitelyTyped until we stabilize these. If you try them out and hit issues you cannot resolve, that’s totally fine! There are two things we think you should do in that case:

1. File an issue on the ember.js repo with a report about the issue you had.
2. Switch back to the @types packages!

We will make sure there are no blocking bugs before stabilizing.

Migrating from DefinitelyTyped

This section only applies if you are an existing Ember TypeScript user who has been using the @types packages from DefinitelyTyped. If you're trying out TypeScript for the first time now, you can skip it!

There are four steps involved in switching from the existing types published on DefinitelyTyped to these preview types.

1. Remove the following packages from your package.json:

   • @types/ember
   • @types/ember__application
   • @types/ember__array
   • @types/ember__component
   • @types/ember__controller
   • @types/ember__debug
   • @types/ember__destroyable
   • @types/ember__engine
   • @types/ember__error
   • @types/ember__helper
   • @types/ember__modifier
   • @types/ember__object
   • @types/ember__owner
   • @types/ember__polyfills
   • @types/ember__routing
   • @types/ember__runloop
   • @types/ember__service
   • @types/ember__string
   • @types/ember__template
   • @types/ember__test
   • @types/ember__utils

2. Install a version of ember-source greater than 4.8.0-beta.2. You should pick the latest beta of 4.8 or any stable version starting with 4.8.0 once it's out!

3. In the types/<your-app>/index.d.ts file generated for you automatically by ember-cli-typescript, add the new imports as the first items in the file, and remove the array prototype extensions support from the file. With the defaults generated for you, the result would look like this:

   +import 'ember-source/types';
   +import 'ember-source/types/preview';
   -import Ember from 'ember';
   -
   -declare global {
   - // Prevents ESLint from "fixing" this via its auto-fix to turn it into a type
   - // alias (e.g. after running any Ember CLI generator)
   - // eslint-disable-next-line @typescript-eslint/no-empty-interface
   - interface Array<T> extends Ember.ArrayPrototypeExtensions<T> {}
   - // interface Function extends Ember.FunctionPrototypeExtensions {}
   -}
   
   export {};
   

4. Account for the differences between the preview types and the definitions on DefinitelyTyped. These differences all fall into one of these broad categories:

   • Fixes to problems in the existing definitions.
   • Removal of our (poor!) support for Ember Classic class features in favor of native classes.
   • Changes to type registry handling
   • Removal of legacy (private) routing APIs

Fixes to problems in the existing definitions

For the preview types, we started by copying over the community-maintained type definitions from DefinitelyTyped. We then updated them to use more robust type testing tools that DefinitelyTyped allows, which exposed a bunch of bugs to fix. We also did a basic comparison of the types we are publishing with the corresponding types in Ember's own code, which has been written in TypeScript for years and got a huge improvement from @wagenet earlier this year.

As a result, you may find some differences when you switch over. In every case, these represent bug fixes, but we recognize they may involve some work!

Introducing a Resolver type

The types on DefinitelyTyped supply a definition of Resolver from ember-resolver, which is where most Ember users get their resolver. However, ember-resolver and other resolvers work because they implement Ember’s contract for what a resolver is. A future RFC will introduce a public type import for this. (It was missed during the work on RFC 0821 because the type presently does not come from Ember!)

For now, the type exists at @ember/-internals/resolver, and is introduced to be type-compatible with the type for ember-resolver on DefinitelyTyped. (See this issue for an issue tracking publishing types from ember-resolver, which is likely gated on a public type import from Ember, but until we ship stable types, can be managed via careful types work on DefinitelyTyped.)

Removing support for Array prototype extensions

This work also exposed a number of errors in the existing types, especially around Array prototype extensions. As a result, these types do not support Array prototype extensions, and it is unlikely that future work will be able to add that support. (The support provided via the types on DefinitelyTyped only worked because the types were defined incorrectly, resulting in a variety of kinds of unsafety.)

Notably, Array prototype extensions are being deprecated, so moving off of them is work you will need to do anyway.

Ember Classic support

As specified in RFC 0800, there are also a number of breaking changes from the types in DefinitelyTyped regarding support for Ember Classic features:

Per the edition support policy, we will provide minimal support for Ember Classic features:

• Ember's classic class system: we will provide minimal definitions for the .create(), .extend(), .reopen(), .reopenClass(), methods, which make no attempt to use them to actually update the types of the items they modify.…

• Ember’s get and set helpers: we will not provide types to make get and set type-safe beyond property lookups on objects—i.e. no support for nested path lookups.…

• Classic computed property handling: we will not provide “safe” types for the classic form of computed properties.

Ember's classic class system

The definitions on DefinitelyTyped attempted to make .create() and .extend() actually create updated types, and tried to make .create(), .extend(), .reopen(), and .reopenClass() have the correct type for this within their bodies. These were always extremely fragile and mostly did not work. Since Ember 3.6, Ember users have been able to use native classes instead of Ember’s classic class system, and this has been the recommended way of writing Ember code since the release of the Octane edition in Ember 3.15.

In the preview types, these methods are present and are safe to use since they are still part of Ember’s public API. However, .create() and .extend() do not create new types. The .create() method does still check that the values you pass match those defined on the class body, but the types do not attempt to make this have the right type within the bodies of .create(), .extend(), .reopen(), or .reopenClass().

To migrate, you should:

• Convert all your own classic classes to native classes.
• Eliminate your use of mixins.

(Most Ember TypeScript users have already done this, because these worked so poorly with TypeScript.)

The .create() call can always be replaced with a normal class definition in JavaScript. For each of the others, you can also use declaration merging to represent the behavior of the method in question.

.extend()

For the case where you are only defining a new class, convert to a native class instead. However, if you have code which still relies on mixins like Evented, you can represent it using interface merging like this:

import EmberObject from '@ember/object';
import Evented from '@ember/object/evented';
import type Owner from '@ember/owner';

// A native class which still applies the Evented mixin
class ExtendsDemo extends EmberObject.extend(Evented) {
  moreStuff = true;

  constructor(owner: Owner) {
    super(owner);
    this.on('custom', this, 'boundMethod');
  }

  willDestroy(): void {
    this.off('custom', this, 'boundMethod');
  }

  boundMethod = () => {
    alert('do something');
  };
}

// Make that work for the *type* by merging the type of the class
// (`interface ExtendsDemo`) with the type of the mixin (`Evented`)
interface ExtendsDemo extends Evented {}

const instance = ExtendsDemo.create({
  moreStuff: false,
});

instance.trigger('custom');

Note: you will have to disable the @typescript-eslint/no-empty-interface ESLint rule for this.

You can do the same for your own mixins while transitioning by defining an interface which represents the type of the mixin:

import Mixin from '@ember/object/mixin';

// Creates the runtime mixin code
const Alertable = Mixin.create({
  alert(value: string) {
    alert(`The value is ${value}`);
  }
})

// Creates the type for TypeScript to see.
interface Alertable extends Mixin {
  alert(value: string): void;
}

// Exports them as a single name in both value and type space.
export default Alertable;

.reopen()

In general, .reopen() is an antipattern, because it makes it very hard to understand where a given part of a class’ state or behavior lives, and you should move away from it! You should prefer to delegate to a class instead of dynamically adding behavior to it, both for maintainability and for performance. However, for the transition, you can represent it using interface merging.

import EmberObject from '@ember/object';

class Foo extends EmberObject {
  someProp = 123;
}

// This is what makes the change work at runtime...
Foo.reopen({
  extra: 'hello',
});

// ...while this is what makes it visible to the type system.
interface Foo {
  extra: string;
}

// Now when calling `Foo.create`, or when working with an instance of the
// class, both `someProp` and `extra` will be checked.
const instance = Foo.create({
  someProp: 456,
  extra: 'goodbye',
});

.reopenClass()

As with .reopen(), the use of .reopenClass() is an antipattern you should move away from over time, preferring to use regular functions in module scope or normal static methods on native classes. In the meantime, you can use namespace merging to represent how it works:

import EmberObject from '@ember/object';

class Foo extends EmberObject {
  static someStatic = true;
}

// This adds the method to the Foo class at runtime...
Foo.reopenClass({
  anotherStatic(): string {
    return 'hello';
  },
});

// ...and this makes it visible to TypeScript as a static method.
declare namespace Foo {
  export function anotherStatic(): string;
}

if (Foo.someStatic) {
  Foo.anotherStatic().length;
}

Note: you will have to disable the @typescript-eslint/no-namespace ESLint rule for this.

Type registries

These types, as a fairly direct extraction from DefinitelyTyped, currently maintain the service and controller type registries. Given the lack of support for classic computed properties, which are the main way to take advantage of those at present, it is fairly likely some or all of these will be removed before stabilizing the types. The major remaining use case is type-safe lookup using the Owner.lookup APIs, so if you have thoughts on that, please reach out in #dev-typescript.

Legacy routing type locations

In line with RFC 0821: Public API for Type-Only Imports, this PR also removes support for importing the types for Transition, RouteInfo, and RouteInfoWithMetadata from the private locations that DefinitelyTyped presently supports for backwards compatibility. Users will need to migrate to using the correct import paths when switching to use these imports.

• import Transition from '@ember/routing/-private/transition' → import Transition from '@ember/routing/transition'
• import RouteInfo from '@ember/routing/-private/route-info' → import RouteInfo from '@ember/routing/route-info'
• import { RouteInfoWithMetadata } from '@ember/routing/-private/route-info-with-metadata' → import { RouteInfoWithMetadata } from '@ember/routing/route-info'

New TypeScript users

This section only applies if you are trying out the types for the first time!

For the moment, the best way to get started with these types is to install ember-cli-typescript and use its generators, then remove a lot of what it does. We will be fixing this in the weeks ahead!

Here’s the process as of today:

1. Set up ember-cli-typescript by running ember install ember-cli-typescript.

2. Remove the following newly-added packages from your package.json:

   • @types/ember
   • @types/ember__application
   • @types/ember__array
   • @types/ember__component
   • @types/ember__controller
   • @types/ember__debug
   • @types/ember__destroyable
   • @types/ember__engine
   • @types/ember__error
   • @types/ember__helper
   • @types/ember__modifier
   • @types/ember__object
   • @types/ember__owner
   • @types/ember__polyfills
   • @types/ember__routing
   • @types/ember__runloop
   • @types/ember__service
   • @types/ember__string
   • @types/ember__template
   • @types/ember__test
   • @types/ember__utils

3. Install a version of ember-source greater than 4.8.0-beta.2. You should pick the latest beta of 4.8 or any stable version starting with 4.8.0 once it's out!

4. In the types/<your-app>/index.d.ts file generated for you automatically by ember-cli-typescript, add the new imports as the first items in the file, and remove the array prototype extensions support from the file. With the defaults generated for you, the result would look like this:

   +import 'ember-source/types';
   +import 'ember-source/types/preview';
   -import Ember from 'ember';
   -
   -declare global {
   - // Prevents ESLint from "fixing" this via its auto-fix to turn it into a type
   - // alias (e.g. after running any Ember CLI generator)
   - // eslint-disable-next-line @typescript-eslint/no-empty-interface
   - interface Array<T> extends Ember.ArrayPrototypeExtensions<T> {}
   - // interface Function extends Ember.FunctionPrototypeExtensions {}
   -}
   
   export {};
   

Known issues

The first beta release has the following known issues (which we will fix during the beta period):

• The @types/ember-data packages are not compatible with these types, because they assume the presence of many of the Ember Classic types we removed in this migration. If you are using Ember Data with TypeScript, you will need to wait for a future update.
• The import file for stable types does not exist yet, so TypeScript will warn you that there is no type for the module. We expect to fix this before releasing 4.8.0-beta.3!

What's next on Ember’s road to TypeScript?

Now that we have these preview types in place, we can begin publishing types in a stable way as soon as our build tooling for Ember itself supports it. As we do so, more and more the types will be provided by the import 'ember-source/types'; import, and fewer from the import 'ember-source/types/preview'; import. That will largely be transparent to you as an end user. Where there are be small differences, we will note them as it happens!

We hope to progressively switch over from these preview types to the stable types in the 4.9–4.11 time frame—that is, before the 4.12 LTS candidate release comes out. As always with software, and especially open source software, there are no guarantees, though!

We are also working on a “quest” issue for getting the rest of RFC 0800 implemented. There are a lot of other core packages which need to publish types for us to get all the way to our goal of having first-class TypeScript support for the ecosystem. We could use your help! If you’d like to pitch in, check out the tracking issue and reach out in #dev-typescript on Discord!

In parallel, there are two other big efforts in flight:

1. The Ember TypeScript team is making steady progress on getting Glint to its 1.0 release.

   • We recently shipped basic support for TypeScript project references, i.e. the --build command, and expect to finish that up by supporting --build --watch mode in the next month or two.

   • We supported Framework Core team member emeritus @chadhietala in landing full support for GlimmerX in Glint.

   • We identified a significant refactor we can make which will let us give much better type errors and eliminate a number of tricky edge cases. (If you’ve hit the “Expected 3 arguments but got 2” error for an item which only has two arguments, this will fix that and a bunch of others as well!)

2. The Ember Learning team is working closely with the Ember TypeScript team and to build out support for TypeScript in our API docs and the Guides. The effort is being led by a community member, @ttbach—and she could also use your help, too! Most of the work here does not require TypeScript expertise, only the ability to work on Node tools, so it’s another great spot to jump in. Reach out to @thaobach in #dev-ember-learning if you would like to contribute!

That’s it for now, but keep your eyes open for further blog posts about the TypeScript effort and other parts of Polaris!

While we're very fortunate to work on an open source project that runs in a sandboxed environment, the browser, we realize that even JavaScript applications can be vulnerable to attacks from malicious third-parties.

Ember.js is designed to mitigate common forms of attack. For example, all values rendered using Handlebars are automatically escaped to prevent XSS attacks, and developers must explicitly opt in to outputting raw HTML.

To ensure that Ember applications stay safe, today we're announcing the Ember.js Security Policy, to help security researchers and developers responsibly disclose potential vulnerabilities in Ember and Ember Data.

We have also set up the Ember.js security announcements mailing list. This is an extremely low-traffic mailing list reserved solely for announcing security releases of the framework. If you're deploying Ember to production, you or your security team may wish to subscribe.

To be clear, there are no vulnerabilities we're aware of at this time and there is not a security release forthcoming. We take security extremely seriously and believe that having a procedure in place ahead of time will allow us to respond most effectively should the worst happen.

If you have any questions or concerns that are not addressed by the new security policy, please email us at security@emberjs.com.

I'd like to thank the Ruby on Rails security team, from whom our security policy was lifted almost wholesale, for serving as a role model for open source projects everywhere.

Lastly, my personal thanks to Aaron "tenderlove" Patterson and Tony "bascule" Arcieri for reviewing our policy and answering many of my ignorant questions.

Let's stay safe out there.

On behalf of all the contributors who have lent a hand along the way, I am very excited to announce that we have released Ember 2.9.0-alpha.1, the first official build with Glimmer 2 included.

🔑 A Key Milestone 🔑

During the alpha testing period, we will publish new alpha builds on a weekly cadence, following the beta releases schedule. The alpha releases will be cut from the master branch, but with all experimental features other than ember-glimmer stripped from the builds.

The purpose of the alpha releases is to enable our community – especially the addon and tooling ecosystem – to start testing the new engine for compatibility and offer feedback. Needless to say, the alpha releases are not intended for production use.

To test your apps with the alpha builds, run bower install --save ember#alpha and follow the prompt to persist the resolution.

From Ember's perspective, integrating Glimmer 2 does not expose any new user-facing features. Even though it is a complete rewrite under the hood, we expect the final release to be a drop-in, completely backwards compatible upgrade for virtually all Ember users. Notably, we will follow our usual SemVer guarantee and ensure all public APIs continue to function as advertised. At this point, we do not expect to introduce any new deprecations along with the initial release.

That being said, despite our best efforts, we might not have gotten every detail right in our very first attempt, hence the alpha releases. We would really appreciate it if you could start testing your applications and report any regressions. You may refer to the GitHub issue for a list of known issues.

It is worth noting that the version number (2.9.0-alpha.1) does not imply the new engine will be automatically included in the 2.9 final release. Like any other changes, the Glimmer 2 integration is subject to the usual rigor and stability requirements of our release process. The core team will make the final decision on when to promote the feature into beta and stable releases based on our learnings from the alpha period.

Based on current information, the 2.8-LTS release (when available) will likely be the final LTS release to include the current-generation rendering engine, which will be supported with critical bugfixes until at least May 2017 and security patches until at least October 2017.

🚀 A Note On Performance 🚀

While one of the overarching goals of Glimmer 2 is to improve performance, the immediate priority in the alpha phase is maximal compatibility. We are barely scratching the surface with the possible optimizations unlocked by the new engine, and once the dust settles there will be ample headroom for further improvements.

That being said, you should start seeing some improvements in rendering performance with each alpha release, as well as reduced download/parsing time thanks to the new templates serialization format.

We are also aware of a few minor bugs that cause performance problems in the first alpha release, which we plan to address quickly. However, it is also possible that we inadvertently regressed performance in certain scenarios. If you noticed certain common patterns have become slower, please report them as bugs.

As always – when running performance benchmarks, please make sure you are using the minified production build (ember.min.js). The debug builds contain a lot of helpful development aids that are known to impact performance negatively.

🎁 A Whole Lot More To Come 🎁

Besides performance, Glimmer 2 has laid a solid foundation for us to build on.

The project originally started when Tom, Yehuda and I spiked on implementing "angle bracket components" in the HTMLBars ("Glimmer 1") engine over a year ago. This exercise highlighted some fundamental misalignments between the current rendering stack and the direction Ember is headed.

While HTMLBars handled basic templating, it left the implementation of many of Ember's view layer features (notably components) up to Ember itself. Not only did it make new features more difficult to implement, it made it hard to implement them efficiently out of the gate.

As Ember has moved towards components and "data-down, actions-up", we wanted to do many optimizations that weren't a good fit for the HTMLBars architecture. The lessons we learned from the spike ultimately leading us down the journey that is now known as the Glimmer 2 architecture. The underlying technologies are very interesting, but I will save those details for another time.

As an Ember user, you can expect the new engine to unlock some long-awaited features, such as FastBoot rehydration and a refreshed approach to components once the initial integration is complete.

❤️ A Big Thank You ❤️

Since forking HTMLBars, the Glimmer repo has received over 700 commits, not to mention the integration effort that happened on the Ember side, all of which would not be possible without the help from our community.

Thank you to every one who helped us get here – from the companies who donated employees' time to the individual contributors who made personal sacrifices to make this happen.

With all of that out of the way – happy alpha testing! 🍾🎊🎉

📚 Further Reading/Watching 📚

• 🔜 Stay tuned for more Inside Glimmer 2 articles from this blog
• 🚧 Glimmer Architecture Guides
• Opening Keynote from EmberConf 2016
• The Future of Ember Templating from EmberConf 2016
• Inside Glimmer 2: What Is A Compiler?
• Glimmer 2 Deep Dive

With all of the focus on Ember 2.0, it's easy to forget that 2.0 is just a six-week release, with the added ability to remove some built-up cruft. Because of the symbolic nature of 2.0, discussions about the future have had an artificial end date of June 12, which is now three weeks away.

This post gives some more details about what cruft will be removed in Ember 2.0 and, since the first features in Ember 2.1 will land in three weeks, what we plan to do in the early releases of Ember 2.x.

It's important to note that we've talked a lot about an improved "Ember 2 programming model" over the past several months, significantly inspired by React. While much of the model will be in place in Ember 2.0, the early releases of Ember 2.x (especially 2.1 and 2.2), will finish up some important features. This blog post details the expected timeline.

Note that the six-week release cycle means that we ship on a train cycle, so the precise versions of specific features may change before they land in a final release.

Removals

While we've spent a lot of time talking about the new features that Ember is getting over the next few months, the 2.0 release itself is more about removals and de-cruft-ification.

Some notable examples:

• Context-shifting helpers (#with item becomes #with item as |i|, #each list becomes #each list as |item|)
• Fake block params versions of helpers (#with foo as bar becomes #with foo as |bar|, #each item in list becomes #each list as |item|)
• The ArrayPolyfills and EnumerableUtils libraries are being pulled out into a library; most apps should prefer lodash or other utility libs.
• In #each, the options itemController, itemViewClass, itemView; superseded by using a component inside the loop
• In #with, the controller option
• The Ember.Handlebars namespace and all of its properties
• bind-attr, superseded by using attributes
• The legacy names bindAttr and linkTo
• The {{collection}} helper
• The {{template}} helper; superseded by {{partial}}
• The {{render}} helper; superseded in most cases by components
• Manually rendering a string into the buffer in a view
• Ember.Deferred; superseded by normal promises
• The globals resolver, which will be moved into an external library; superseded in normal use by the ES6 module resolver

While top-level controllers will not be removed in 2.0 (see more below), we will remove all of the other uses of controllers from templates (such as #with controller=, {{render}}, itemController and others).

In all of these cases, we did significant work in the 1.x series, especially in 1.12 and 1.13, to make sure that the dominant use-cases for these features were addressed by existing or new features.

You can learn about all of the deprecations added in the 1.x era, along with the expected transition to the features that superseded them, in the 1.x deprecations guide.

The Glimmer Engine

The Glimmer engine, with its improved performance and improved support for the "data down, actions up" model, landed in Ember 1.13 beta.

Fast Re-Render

In Ember 1.12, calling rerender() on a component is an extremely expensive operation, and blows away all of the existing DOM (together with its internal state, such as selection, cursor, focus, scroll position and more).

In Ember 1.13, thanks to the Glimmer engine, you can safely invoke rerender() and it will only update the parts of the template that have actually changed.

This allows you to replace an entire data structure with a totally new POJO, rerender the component, and get highly performant updates that preserve the DOM.

New Lifecycle Hooks

Because rerender() is now fast and reliable, any call to component.set() will trigger a re-render on the component. When a component re-renders, that may change the attributes of child components, which likewise are re-rendered.

As a result of the fact that rerender() is now such an important part of the programming model, Ember 1.13 beta got a bunch of new React-inspired lifecycle hooks:

• didUpdateAttrs, invoked when a component's attributes have changed but before the component is rendered.
• willUpdate, invoked before a component will rerender, whether the update was triggered by new attributes or by rerender.
• didUpdate, invoked after a component has been rerendered.
• didReceiveAttrs, invoked when a component gets attributes, either initially or due to an update.
• willRender, invoked before a component will render, either initially or due to an update, and regardless of how the rerender was triggered.
• didRender, invoked after a component has been rendered, either initially or due to an update.

These lifecycle hooks will fire on all components (but not views), regardless of invocation style (both curlies and angle bracket style).

Angle Bracket Components

Angle bracket components (<my-component>) are a very important part of the Ember 2.x programming model. In addition to nicer syntax, they serve as an opt-in for component changes that we could not easily make compatibly, such as default one-way bindings.

We originally thought that angle-bracket components would land in time for Ember 1.13, and they have already landed on Canary, and were included in the first 1.13 beta release.

However, there were some late-breaking concerns, and we have decided to defer this feature so we can write an RFC and go through the regular process. We have already written an implementation of the RFC, which we will land on Canary and keep up to date with the RFC discussions.

Because we are so close to the Ember 2.0 branch point, this feature is likely to land in Ember 2.1.

Routeable Components

The routeable components RFC was first published several months ago, and has been the subject of vigorous discussion. It is one of the most anticipated features of the Ember 2.x programming model.

(the following two paragraphs are a bit of insider baseball)

The primary reason to attempt to land this feature in Ember 2.0, despite the fact that its development is at a relatively early stage, was a desire to deprecate controllers for 2.0. In Ember, in order to deprecate a public API, we require an alternate path for all of the use-cases of the old feature. In order to remove a feature in 2.0, it would have needed to be deprecated in 1.13.

Together, that means that in order to remove controllers in 2.0, we needed to land routeable components, the transition from controllers, in 1.13. During the 1.13 canary cycle, it became apparent that removing controllers in 2.0 would be too aggressive, so the pressure to ship Routeable Components exactly in 2.0.0 is less.

The work on Routeable Components, as well as work to make it possible to move query parameters fully to routes, is ongoing.

There are less than three weeks left until the 2.0-beta branch point, and given that the feature has not yet landed in Canary (and the importance and magnitude of the feature), it will probably land in 2.1 at the earliest.

It is extremely likely to land in 2.1, or 2.2 at the latest.

The Routeable Component feature also includes a change that makes it possible to provide multiple asynchronous attributes to the component you are routing to, rather than just the model attribute. The attrs hook will run on every transition into the route, in contrast to the model hook, which doesn't run again in some cases.

FastBoot

An early version of the FastBoot feature, suitable for SEO, is already available as an Ember addon that works with Ember 1.12. We expect the addon to work with the final release of 1.13.

Work on rehydrating FastBoot will begin very soon, and we hope to land it in Canary early in the 2.x release cycle.

Engines

The Engines feature was first proposed as an RFC last year, and work on the feature itself will likely begin very soon.

We expect the Engines feature to land in Canary early in the 2.x release cycle.

Existing applications are able to continue using baseURL with a deprecation warning. If you are eager to adopt this change, you should note that the removal of the <base> tag may impact how your application is deployed, and if so, will likely require some small migration effort, detailed below.

This is the culmination of a lot of research and work by Tobias Bieniek and we're incredibly grateful for his efforts.

What was it?

baseURL allowed an Ember application and assets to be deployed to a subdirectory without requiring rewriting of asset URLs, instead allowing them to be included relatively. For example given an HTML file:

<head>
  <base href="http://emberapp.example.com/path/to/application/">
  <link rel="stylesheet" href="assets/style.css">
</head>
<body>
  <img src="assets/images/image.png">
</body>

The style would be fetched from http://emberapp.example.com/path/to/application/assets/style.css, and the image from http://emberapp.example.com/path/to/application/assets/images/image.png. If you are curious, here is a good read on the base tag. In short, baseURL is the configuration property Ember CLI used to identify what value to put in the <base href="..." /> tag included in index.html. This determined where assets for the application should be loaded from, including app.js, vendor.js, app.css, and anything else that isn't specified with a fully-qualified path.

Why are we deprecating it?

Variations on the baseURL solution has been Ember CLIs default asset prefixing behavior for two years. There are a number of reasons why we're moving away from this pattern, but a few things really made it unnecessarily complicated.

API Design Bugs

Since we added this feature two years ago apps can have both baseURL and rootURL configuration values. These two names are far too similar and do things which are far too similar. Where baseURL identified the asset prefix of an application, rootURL identifies the path at which an Ember application is served so Ember's router can know which path segments to ignore.

Implicit Behavior

Not only are there two confusing configuration options, but if only one of baseURL or rootURL was set Ember CLI made a best-effort guess at populating the other's value. This implicit behavior violated the principle of least surprise for many people. An explicit requirement for both values always being set and clearer documentation would have averted some of the pain but would have added additional things to the learning curve.

Integration With Other Applications

Not every Ember application is full green field development. If you happened to have legacy user-generated HTML, or other data containing relative links, this didn't play nicely with the <base> tag. Rewriting this content is an option, but incurs cost and bugs that can be avoided by not including the <base> tag.

SVG

Worst of all, and something that we can't code or document around, SVG <use> elements break in an unexpected way when used with a <base> tag. It turns out that the relatively common pattern of <use xlink:xhref="#__SVG_ID__"></use> referencing a fragment identifier doesn't play nicely with the <base> tag. We like to play nicely with the web ecosystem and this fault is the final straw that resulted in the decision of removing the <base> tag.

How Do I Migrate?

Existing applications are able to continue using baseURL with a deprecation warning. For users who do want to migrate, the steps depend primarily on how your application is deployed. It's our goal is to make it easy for you to achieve the same behaviors you've had in the past.

New Applications

If you're starting a new application using an Ember CLI canary (or eventually 2.7 stable) everything should work correctly out of the box. We've been very careful to make sure that the out of the box experience is as smooth as possible. For the built-in development server all assets will be served at the rootURL. Relative URLs will continue to work fine inside of your CSS files and paths to assets included in your templates, index.html, or inserted via {{content-for}} should specify a root-relative path.

Upgrading

If you are upgrading your application to the new version of Ember CLI (canary with this change, or eventually 2.7 stable), you should pay close attention to the configuration changes inside of the modified blueprint files. We have also inserted deprecation warnings which will hopefully guide you through each of these changes.

The primary migration effort is that you should expect to adjust any relative paths which appear in your templates, are inserted via {{content-for}}, or directly present in index.html. Because you will be serving index.html from the server for any arbitrary route in your application you must modify these to be either a fully-qualified path or a root-relative URL.

As an example, given this configuration where you have configured a different rootURL and baseURL:

// config/environment.js
var ENV = {
  /* ... */
  rootURL: '/path/to/application/',
  baseURL: '/assets/go/here/'
  /* ... */
}

You would remove the baseURL option and modify your templates like so:

{{!-- Old: --}}
<img src="images/logo.png" />

{{!-- New: --}}
<img src="/assets/go/here/images/logo.png" />

How To Use a CDN

One of the most common use cases for baseURL was pointing to assets on a CDN. After this change to remove baseURL you should use the prepend option for broccoli-asset-rev which is included with Ember CLI apps by default. For example, in ember-cli-build.js:

// ember-cli-build.js
var app = new EmberApp(defaults, {
  // Add options here
  fingerprint: {
    prepend: 'https://cdn.example.com/'
  }
});

Note that the prepend option only applies when doing production builds via something like ember build --prod. Given the above example, and this input:

// config/environment.js
var ENV = {
  /* ... */
  rootURL: '/path/to/application/'
  /* ... */
}

<!-- Snipped from the <head> of the new `index.html` blueprint.  -->
<link rel="stylesheet" href="{{rootURL}}assets/vendor.css">
<link rel="stylesheet" href="{{rootURL}}assets/app-name.css">

The output for asset paths in index.html would look something like:

<link rel="stylesheet" href="https://cdn.example.com/path/to/application/assets/vendor-e37004361bf9cda2ab3379d96c9eba4b.css">
<link rel="stylesheet" href="https://cdn.example.com/path/to/application/assets/app-name-dc477601773d4043b0c461b2a0ae8aef.css">

Note that rootURL is present as part of the path for the CDN-hosted assets inside of index.html. rootURL is an Ember CLI concept primarily concerned with supporting the behavior of ember server.

Configuring the Router

We also use the setting for rootURL at runtime in the application's router:

// app/router.js
import Ember from 'ember';
import config from './config/environment';

const Router = Ember.Router.extend({
  rootURL: config.rootURL
});

In most cases this does exactly what you want it to do. However, if you wish to mount the application at a different place than the Ember CLI rootURL specifies for its ember serve location, you may add an additional property in your config, routerRootURL, to specify the path that your application will live at runtime.

// config/environment.js
var ENV = {
  /* ... */
  rootURL: '/',
  routerRootURL: '/path/to/application/'
  /* ... */
}

You would then reference that inside of your application's router like so:

const Router = Ember.Router.extend({
  rootURL: config.routerRootURL
});

This provides a method to remove the '/path/to/application/' prefix from assets inside of index.html which will be served from a CDN.

CSS, Fonts, and Other Static Assets

Depending upon how these were included into an application, their paths may need to be adjusted. Assets like these are often handled outside the Ember CLI build pipeline, but do check to make sure that everything is works as expected.

Addon Consumption and Development

It's possible that you have addons which rely on rewriting asset URLs. If there is any impact, it is most likely going to impact users of ember-cli-deploy. Please let us know what you discover during this canary/beta process, we'd like to see what each addon is attempting to accomplish and make sure we can support that use case.

Everything is Broken! Help!

If for some reason removing baseURL and the default <base> tag causes problems, you can still add a <base> tag directly to your index.html file:

<base href="/what/your/baseURL/was/" />

This can be useful to address relative URLs which are being inserted via templates, index.html, or {{content-for}}. For pathing to your built CSS and JS assets use the method described for CDNs.

How Can I Try This?

Using our new release channel setup, you can try this change by upgrading your Ember CLI app to the canary channel:

npm install --save-dev ember-cli/ember-cli#canary

If you discover any problems with this change please file an issue, we'll be paying especially close attention to this topic.

If you've been following along, the Ember issues tracker has grown to over 200 active issues. While this is better than some other large OSS projects, it's still too large for us on the core team to easily keep track of. There are also a number of issues that are over six months old and even a year or two old.

Declaring straight-up issue bankruptcy is appealing, but does a disservice to everyone involved. There's a lot of useful information here for the core team and many of these issues are things we are actively working on solving. So we're attempting to cut down on the number of issues in a bit more targeted way.

In many cases these old issues stuck around because the solution was non-trivial and only a limited set of contributors was qualified to fix them. In some instances, a fix involves considerable internal refactoring that no one has yet had time to do and was hard to justify for one fix.

To help keep things manageable, we'll be consolidating these types of issues into single meta issues. Over time we do intend to refactor and clean up different parts of the internals and knowing what bugs we need to fix while we're at it will be helpful. The original issues will be closed to help reduce overall noise, but we'll still make sure to consider them when doing our refactoring. Please continue to comment on the original issue so we can keep things organized.

In some cases, we may close issues without a meta if there is a clean workaround (we don't want you to have to use hacks) or if the issue is very minor. If you think we miscategorized an issue, please let us know. We're also still happy to receive PRs for these issues, though it's probably wise to double check with us first.

I hope we can make the issue tracker more useful and effective for everyone.

If you've been paying attention in Ember lately you may have heard the term "Octane" floating around here and there recently, and wondered what all the excitement was about. It may seem like a bit of a big deal - and that's because it kind of is! It's Ember's first new edition, proposed in the Ember 2018 Roadmap, and represents a major shift in the mental model behind Ember.js and Ember applications. In this series, I'll be diving into some of the new features that are part of Octane (specifically the ones that are part of the browser side of the framework) and giving a brief overview of how the feature works, and why the feature is being added. The features I'm planning on discussing are:

• Native Classes (+Decorators)
• Angle Bracket Syntax & Named Arguments
• Tracked Properties
• Modifiers
• Glimmer Components

There are more features that are part of Octane, such as Ember's new file system layout (also known as Module Unification), template imports, and other build improvements, but these are a bit out of my scope - I've personally been focused on the story for developers in the browser, writing app and addon code, and how that's going to change.

This series is aimed at existing Ember users, but if you're new to Ember or tried Ember a while ago and want to see how things are changing, I'll be providing context on the existing features as we go along. These posts won't be doing deep dives on all the edge cases of the functionality, they are moreso meant as an overview of what's coming. If you can't already tell, I'm very excited about these new features and the future of Ember with them, and can't wait to see them land! So, let's dive in!

What Are Editions?

Before we move onto Native Classes, let's talk about Ember Editions really quickly. Not many other frameworks have an equivalent for Editions, and they may seem a little confusing at first. So, what are they?

An Edition in Ember represents the culmination of all the changes that have happened in the framework since the last Edition. In a lot of other frameworks, this is like a new major version. It means we have significantly improved things, added new concepts and ideas, updated all the documentation and marketing materials, created new guides, battle-tested everything, and are confident that it is ready for mass adoption. In some ways, it's like a new release of a product version at a company - things have changed, and we're ready to blast out to the world that there's a whole "new" Ember!

You might be asking yourself, why not just use SemVer's major versions to do this? Usually when a framework releases a new major version, there are new APIs and features and there's lots of buzz and excitement about that. So, why not just release Ember v4 and be done with it?

The answer is in the way Ember treats and respects SemVer. We follow SemVer to the letter - patch versions include only bugfixes, minor versions include only new features and improvements, and major versions only remove deprecated APIs. No new features are ever introduced on a major Ember version. This makes updating your app much simpler - there's no need to rewrite a component or service, or update to the new ways of doing things, just remove the deprecated features (which issue console warnings when used) and you should be able to bump the version without problems.

In this model, new features are introduced gradually over the course of a single major version, allowing users to adopt them incrementally. This is amazing for app maintenance - instead of having a new major version be released and having to go update everything all at once, you can do it one piece at a time, as the new things are released.

However, because this is done incrementally it can also sometimes mean that the new experience isn't really all that polished. After all, the docs and guides have to continue supporting the existing features, and remain cohesive. Adding every new feature to them immediately could quickly make them overwhelming for new users. Additionally, sometimes features may be ready and complete in isolation, but really be part of a larger picture of new features that are still in the pipeline, and some folks would prefer to wait for all of the "new world" to land before adopting new features.

Editions are Ember's way to message to the community that the framework has synchronized, that all (or most) of the new features have shipped, and that it's time to update and adopt the new features. It's a tool that allows us to continue to use SemVer to signal compatibility changes exclusively, and have a different tool for signaling major updates and new features. This allows us to keep our core value of stability without stagnation, and be able to show off cool new things at the same time!

Alright, now let's move onto those new features in Octane!

Native Classes (+Decorators)

Native Javascript classes in Ember are near and dear to my heart. I first began exploring them almost 2 years ago now, when I first approached @rwjblue about the state of ember-decorators ("ember-computed-decorators" at the time). I was tasked with building out our documentation internally, and wanted something more ergonomic than YUIDoc/JSDoc style tags and comments that required you to manually name and tag every single method, property, and parameter. I had heard from @runspired some time before that native classes actually mostly worked with Ember already, and just needed a little bit of finagling to get all the way there.

It turned out that was half-true - native classes did work pretty well with Ember's own classes, but there were some pretty major changes we needed to make to get them to be just as ergonomic and usable as Ember's classic class syntax, which was beginning to look more and more dated by the day. These changes were ultimately small, but they were deep in the internals of Ember, and operating on them was an almost surgical process, with little room for error or regression.

Today, native classes are fully supported in Ember, with a rock solid public API and well defined, ergonomic behavior. However, they are one of those features that are part of a larger picture, specifically they require class fields and decorators to be used effectively. Class fields are currently stage 3 in the TC39 process, which is generally supported by Ember for early adoption, but decorators remain at stage 2 after the January 2019 TC39 meeting. As we will discuss, decorators are crucial to using Native Classes effectively because Ember has been using the decorator pattern all along!

We have plans to continue working with TC39, along with the other major users of decorators (TypeScript, Angular, Vue, MobX, etc) to standardize and stabilize the syntax enough for us to land them in the framework, and while that may end up being some time after EmberConf, we already have the behavior of decorators spec'd out and implemented behind a feature flag. They will be available to play around with by EmberConf, so you'll be able to try them out with native classes to see how they work. If you're impatient, you can also always use ember-decorators, which matches the behavior of the proposed decorators exactly.

Enough background, let's move onto some demonstrations!

Classes in Action

Classes have existed since the very earliest versions of Ember, when it was still named SproutCore 2. Back in 2011, ES6 did not yet exist, and a true native class syntax wasn't even a remote possibility. Many frameworks ended up creating their own class-like wrappers around JavaScript's prototypical inheritance, Ember included. It looked very much like it looks today:

// A person class defined in Ember v1
var Person = Ember.Object.extend({
  firstName: 'Steve',
  lastName: 'Rogers',

  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),

  updateName: function(firstName, lastName) {
    this.set('firstName', firstName);
    this.set('lastName', lastName);
  },
});

// Make an instance of the class, overriding default values
let phoenix = Person.create({ firstName: 'Jean', lastName: 'Gray' });

// A person class defined with current class syntax
import EmberObject, { computed } from '@ember/object';

const Person = EmberObject.extend({
  firstName: 'Steve',
  lastName: 'Rogers',

  fullName: computed('firstName', 'lastName', function() {
    return `${this.firstName} ${this.lastName}`;
  }),

  updateName(firstName, lastName) {
    this.set('firstName', firstName);
    this.set('lastName', lastName);
  },
});

// Make an instance of the class, overriding default values
let phoenix = Person.create({ firstName: 'Jean', lastName: 'Gray' });

There are some noticeable differences here, but most of these are unrelated to changes in the class syntax. We now have the niceties of ES2018 such as template strings and object-method syntax, and we no longer need to use get to get values, but we do still need to use set (that's being addressed by a different feature, tracked properties, that I'll be discussing in a later post in this series). The only major change to the mechanics of classes is the change to the way we define computed properties - in the older style, we used the .property() notation which was available because we added it to Function.prototype (very much an antipattern!), and now we just use the computed function to wrap the getter directly.

Let's take a look at what this looks like when converted to native classes:

import EmberObject, { computed } from '@ember/object';

class Person extends EmberObject {
  firstName = 'Steve';
  lastName = 'Rogers';

  @computed('firstName', 'lastName')
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  updateName(firstName, lastName) {
    this.set('firstName', firstName);
    this.set('lastName', lastName);
  }
}

// Make an instance of the class, overriding default values
let phoenix = Person.create({ firstName: 'Jean', lastName: 'Gray' });

Now that's much cleaner! We have far fewer opening and closing brackets, and we're using the native get fullName() syntax to define the getter meaning we don't have to remember that funky computed() syntax. Computed properties are decorators now, and assigned values are class fields. In fact, we can go one step further - we don't even need to extend from EmberObject anymore:

import { computed, set } from '@ember/object';

class Person {
  firstName = 'Steve';
  lastName = 'Rogers';

  constructor(firstName, lastName) {
    this.updateName(firstName, lastName);
  }

  @computed('firstName', 'lastName')
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  updateName(firstName, lastName) {
    set(this, 'firstName', firstName);
    set(this, 'lastName', lastName);
  }
}

// Make an instance of the class, overriding default values
let phoenix = new Person('Jean', 'Gray');

We can completely drop the weight of using Ember's legacy class system and rely solely on native classes this way. This is awesome! In the future this means we'll be able to remove a large chunk of Ember's legacy code and leverage the platform instead, making our apps faster to load and easier to write.

Another thing you may have noticed in the above examples is that we're using the exact same import paths for everything, including computed. At first this may seem like a breaking change! How can computed be a modern class decorator and be used in classic class syntax, without breaking anything? Shouldn't it be imported from a different location or something? In fact, it doesn't need to be at all. computed is fully compatible with both classic classes and native classes, along with all existing computed property macros in Ember and the Ember addon ecosystem! This is perfectly valid syntax that will Just Work™️:

import EmberObject, { computed, set } from '@ember/object';

const ClassicClassPerson = EmberObject.extend({
  firstName: 'Steve',
  lastName: 'Rogers',

  fullName: computed('firstName', 'lastName', function() {
    return `${this.firstName} ${this.lastName}`;
  }),

  updateName(firstName, lastName) {
    this.set('firstName', firstName);
    this.set('lastName', lastName);
  },
});

class NativeClassPerson {
  firstName = 'Steve';
  lastName = 'Rogers';

  constructor(firstName, lastName) {
    this.updateName(firstName, lastName);
  }

  @computed('firstName', 'lastName')
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  updateName(firstName, lastName) {
    set(this, 'firstName', firstName);
    set(this, 'lastName', lastName);
  }
}

// Make an instance of the class, overriding default values
let classicClassSpiderMan = ClassicClassPerson.create({
  firstName: 'Peter',
  lastName: 'Parker',
});

let nativeClassSpiderMan = new NativeClassPerson('Peter', 'Parker');

The reason this is possible is, behind the scenes, computed has always been a decorator.

Decorators Before @Decorators

You may be familiar with the proposed decorator syntax for JavaScript, but if not the basic gist is that you can "decorate" class fields and methods with additional behavior:

class Person {
  constructor(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }

  // memoizes the value, which caches it the first time
  // it is calculated and then always returns the cached value
  @memo
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }
}

There are lots of potential uses for this functionality, such as a @bound decorator that binds a method to the instance (for use in event listeners and such) or an @htmlSafe decorator that sanitizes the return value of a function so it's safe to add it to the DOM.

Javascript is far from the first language to have this sort of functionality however. One great example of it is in Python, and one reason I especially like some examples from their community is they show how you can use decorators without their decorator syntax:

# Given this decorator:
def my_decorator(func):
    def wrapper():
        print("Something is happening before the function is called.")
        func()
        print("Something is happening after the function is called.")
    return wrapper

# This function definition with the decorator syntax:
@my_decorator
def say_whee():
    print("Whee!")

# Is the same as doing this without it:
def say_whee():
    print("Whee!")

say_whee = my_decorator(say_whee)

The "decorator pattern" more generically is about taking an input of some type - a function, a class method, a field - and transforming it into something of the same (or similar) type, adding some extra functionality along the way. You don't need a special syntax to use the decorator pattern, it just makes it a bit more convenient! If you think about it this way, Ember's computed() function is basically a decorator - it adds caching based on dependent keys to a getter function.

Leveraging this similarity, we were able to update that decorator functionality to match JavaScript's newly proposed API, which is how we're able to have it be compatible between both the classic and current syntax. The added side effect is that the entire Ember ecosystem gets this upgrade all at once, with absolutely no extra work required!

Decorators in Ember Octane

The changes proposed in the Decorators RFC boil down to:

• @ember/object#computed is now a decorator
• All of the macros available in @ember/object/computed, such as alias, gte, bool, etc. are decorators
• @ember/service#inject and @ember/controller#inject are decorators
• A new decorator, @action, has been added for function binding.

These cover all of the basic functionality provided by the current classic class syntax, with the exception of classic component customization (there's a mouthful!) and observers/event listeners. Because Ember Octane is introducing a new component class, @glimmer/component, that doesn't require the element/DOM APIs of classic components, it was decided that decorators for that functionality were not needed in the core of the framework. Likewise, observers and event listeners are not a recommended pattern anymore, so adding decorators for them didn't make much sense. Instead, users can rely on existing libraries like ember-decorators which cover these use cases if they need them.

Putting It All Together

Alright, with that in mind, let's take on a bigger, more complete example! This is a component from emberobserver.com, one of the larger components I could find in the application (source here):

import { inject as service } from '@ember/service';
import Component from '@ember/component';
import { computed } from '@ember/object';
import { isEmpty } from '@ember/utils';
import { task } from 'ember-concurrency';

export default Component.extend({
  visibleUsageCount: 25,

  showUsages: false,

  usages: null,

  regex: false,

  fileFilter: null,

  codeSearch: service(),

  visibleUsages: computed('visibleUsageCount', 'usages', function() {
    return this.usages.slice(0, this.visibleUsageCount);
  }),

  moreUsages: computed('visibleUsageCount', 'usages', function() {
    return this.visibleUsageCount < this.usages.length;
  }),

  fetchUsages: task(function*() {
    let usages = yield this.codeSearch.usages.perform(
      this.addon.id,
      this.query,
      this.regex
    );
    this.set('usages', filterByFilePath(usages, this.fileFilter));
  }).drop(),

  actions: {
    toggleUsages() {
      this.toggleProperty('showUsages');
      if (this.showUsages && this.usages === null) {
        this.fetchUsages.perform();
      }
    },

    viewMore() {
      this.set('visibleUsageCount', this.visibleUsageCount + 25);
    },
  },
});

function filterByFilePath(usages, filterTerm) {
  if (isEmpty(filterTerm)) {
    return usages;
  }
  let filterRegex;
  try {
    filterRegex = new RegExp(filterTerm);
  } catch (e) {
    return [];
  }
  return usages.filter(usage => {
    return usage.filename.match(filterRegex);
  });
}

And here is the same component, fully converted to native classes using Ember's built-in decorators and the and ember-concurrency-decorators library:

import { inject as service } from '@ember/service';
import Component from '@ember/component';
import { action, computed } from '@ember/object';
import { isEmpty } from '@ember/utils';
import { dropTask } from 'ember-concurrency-decorators';

export default class AddonSourceUsagesComponent extends Component {
  visibleUsageCount = 25;
  showUsages = false;
  usages = null;
  regex = false;
  fileFilter = null;

  @service codeSearch;

  @computed('visibleUsageCount', 'usages')
  get visibleUsages() {
    return this.usages.slice(0, this.visibleUsageCount);
  }

  @computed('visibleUsageCount', 'usages')
  get moreUsages() {
    return this.visibleUsageCount < this.usages.length;
  }

  @dropTask
  *fetchUsages() {
    let usages = yield this.codeSearch.usages.perform(
      this.addon.id,
      this.query,
      this.regex
    );
    this.set('usages', filterByFilePath(usages, this.fileFilter));
  }

  @action
  toggleUsages() {
    this.toggleProperty('showUsages');
    if (this.showUsages && this.usages === null) {
      this.fetchUsages.perform();
    }
  }

  @action
  viewMore() {
    this.set('visibleUsageCount', this.visibleUsageCount + 25);
  }
}

function filterByFilePath(usages, filterTerm) {
  if (isEmpty(filterTerm)) {
    return usages;
  }
  let filterRegex;
  try {
    filterRegex = new RegExp(filterTerm);
  } catch (e) {
    return [];
  }
  return usages.filter(usage => {
    return usage.filename.match(filterRegex);
  });
}

This is subjectively much cleaner and easier to read, but should still look pretty familiar to long-time Ember users.

Native Class Benefits

Maybe you're not convinced by the new syntax - after all, it's not that much different than what we have today. There are many other benefits that'll be coming thanks to native classes, and I'd like to touch on them briefly here:

Speed and performance enhancements

Relying on native features means that we can drop a significant chunk of Ember's internal framework code, meaning Ember will be that much lighter overall. In addition, since classes are easier to statically analyze, there may be more benefits unlocked by the VMs themselves in the future, increasing the speedup as time goes on.

Shared documentation and tooling

The rest of the JavaScript ecosystem is beginning to adopt classes as well, meaning we'll have a much larger community of shared libraries, documentation, and tooling to rely on. Today, new Ember users have to be taught the details of Ember's class system, but in the future JavaScript classes will be one of the first chapters in every JS manual, how-to-guide, and bootcamp. This means less time ramping developers up to speed.

In addition, tooling like IDEs (WebStorm, VSCode), typecheckers (Flow, TypeScript), and documentation generators (ESDoc, TypeDoc) will all benefit from the statically analyzable nature of classes. There's already lots of work happening to automate more and more tasks, meaning that writing codebases with classes will be that much easier.

True private state

Native class fields also add private fields, which allow us to have truly private instance state for the first time (without using a WeakMap, which is highly unergonomic):

class Person {
  #firstName;
  #lastName;

  constructor(firstName, lastName) {
    this.#firstName = firstName;
    this.#lastName = lastName;
  }

  get fullName() {
    return `${this.#firstName} ${this.#lastName}`;
  }
}

let person = new Person('Jessica', 'Jones');

console.log(person.fullName); // 'Jessica Jones'
console.log(person.#firstName) // ERROR

Fewer bugs and quirks

There are quite a few quirky behaviors of classic classes:

• Merged and concatenated properties (like classNames on components)
• Shared state between instances (e.g. if you do EmberObject.extend({ foo: [] }))
• Reopening class definitions to define static properties (reopenClass)
• The ability to reopen and redefine class methods and behaviors in general (still possible with native classes, but not nearly as easy)
• Mixin behavior in general, especially inheritance and super

All of these issues have been addressed in native classes. Some functionality was not needed, and other functionality was added to ensure that strange, counterintuitive behavior does not occur.

Conclusion

That's all I have for today, I hope you're looking forward to being able to use native class syntax in Ember as much as I am! Tune in next week for a break down of the changes to Ember's templating syntax, including <AngleBracketInvocation> and @namedArgs!

Hello again, and welcome back! This is the second part of the multipart Coming Soon in Ember Octane series, where we're previewing some of the various features that are landing in Ember's upcoming Octane edition, including:

• Native Classes (+Decorators)
• Angle Brackets & Named Arguments ← this post
• Tracked Properties
• Modifiers
• Glimmer Components

These aren't all of the new features that will be part of Octane, but they're the ones that I'm most familiar with personally, so I can give y'all the low down!

This series is aimed at existing Ember users, but if you're new to Ember or tried Ember a while ago and want to see how things are changing, I'll be providing context on the existing features as we go along. These posts won't be doing deep dives on all the edge cases of the functionality, they are moreso meant as an overview of what's coming. If you're curious about what an edition is exactly, you can check out a quick break down in the first post in the series.

Ember Templates: HTML++

One of the things that sets Ember apart from other component based frameworks is its strong focus on templates that extend HTML with a declarative, LISP-like syntax. Unlike JSX, which allows direct usage of Javascript wherever you want, or other framework's templating languages like Vue or Angular that lean heavily on HTML, Ember's syntax balances a mix of expressiveness and declarativeness that keeps template code relatively simple and easy to read, but doesn't prevent you from accomplishing your goals with artificial constraints.

Ember templates draw their roots from the Handlebars templating language which used {{doubleCurly}} syntax to insert values into templates. For the first version of Ember, this templating language remained pretty basic. You could reference values in templates, render components, and use specialized helpers like {{outlet}} for routing, {{if}} for branching, and {{each}} for looping:

Hello, {{fullName}}!

{{#if hasTodos}}
  <ul>
    {{#each todos as |todo index|}}
      <li>
        {{todo-item-component todo=todo index=index}}
      </li>
    {{/each}}
  </ul>
{{else}}
  No todos!
{{/if}}

Things got more interesting as that language evolved, particularly when the ability to add nested helpers was added, since this mean that helpers could be composed. Logic that previously had to exist on classes in the form of computed properties could now exist in the template:

Hello, {{join (capitalize firstName) (capitalize lastName)}}!

{{#if (gt todos.length 0)}}
  <ul>
    {{#each todos as |todo index|}}
      <li>
        {{add index 1}}. {{todo-item-component todo=todo}}
      </li>
    {{/each}}
  </ul>
{{else}}
  No todos!
{{/if}}

Another major piece of functionality which was added was the ability for helpers and components to yield, which is similar to calling a callback with some values in Javascript:

<!-- todo-list.hbs -->
<ul>
  {{#each todos as |todo index|}}
    <li>
      {{yield (todo-item-component todo=todo) index}}
    </li>
  {{/each}}
</ul>

<!-- main.hbs -->
Hello, {{join (capitalize firstName) (capitalize lastName)}}!

{{#if (gt todos.length 0)}}
  {{#todo-list todos=todos as |item index|}}
    {{add index 1}}. {{item}}
  {{/todo-list}}
{{else}}
  No todos!
{{/if}}

Between these major improvements and many other minor improvements, Ember templates slowly became a first class language in their own right over the years. They continue to be, however, a language with a specific purpose - to write declarative HTML templates. While it would be possible to write extended business logic in templates directly, there comes a point where it's much more pain than it's worth. For instance, you can add local variables with the {{let}} helper, but since it requires you to yield to add the variable it quickly becomes more of a headache than it's worth, except in targeted circumstances:

{{#let 'Carol' as |firstName|}}
  {{#let 'Danvers' as |lastName|}}
    {{#let (join firstName lastName) as |fullName|}}
      ...
    {{/let}}
  {{/let}}
{{/let}}

You can see how quickly this would become a difficult to work with and reason about if you used it for all of the business logic a large app! In this way, Ember templates guide users to separate concerns when they reach a certain level of complexity, but give them enough freedom to avoid large amounts of boiler plate for small, mundane snippets of logic.

Still there were some nagging issues with this syntax:

• There's so many curlies! It can be hard to distinguish what's what between helpers and components and plain values being put into template, which makes reading template code difficult at times.
• It's so ambiguous! {{fullname}} probably means a variable, but it could be a component or a helper. And even if it's a variable, is it a local variable provided by a yield? Is it a variable on the component instance? Is it an argument (a.k.a. property) provided to the component? Where are all these things coming from anyways?

Some of the ambiguity problem is going to be solved by template imports, which will allow you to directly import helpers and components for use just like you would in JavaScript code, but there are lots of other small issues in there. There are three major changes that are part of Ember Octane that address these issues:

1. Angle bracket syntax for components
2. Named argument syntax
3. Required this in templates

Angle Bracket Syntax

Angle bracket syntax for components draws heavily from other templating languages. You can invoke a component by using the CapitalCase version of the component's name, and using angle brackets instead of curlies, like HTML. Arguments passed to the component must be prefixed with the @ symbol, distinguishing them from HTML attributes which can be applied directly like you would with standard HTML elements:

<!-- main.hbs -->
Hello, {{join (capitalize firstName) (capitalize lastName)}}!

{{#if (gt todos.length 0)}}
  <TodoList role="list" @todos={{todos}} as |Item index|>
    {{add index 1}}. <Item/>
  </TodoList>
{{else}}
  No todos!
{{/if}}

As you can see, this immediately gives the TodoList component some visual distinction from the rest of the template. We can tell that it's a separate type of thing based on a quick glance, instead of having to think about the context we're in, and what helpers and variables exist in the template.

The ability to pass arbitrary HTML attributes directly to components is also a huge time saver. This was a point of brittleness in components previously, since every new attribute required adding a new argument to the component, and binding that argument to the attribute. Another minor pain point was also addressed by this feature: single word component names are now completely allowed. {{todo}} was not a valid component name before, but <Todo> is now!

It's important to note that positional parameters can't be used with angle bracket syntax. That's ok, because curly bracket syntax still exists, and most things that use positional parameters really feel more like helpers than components (e.g. if, each, etc). There are some exceptions, such as link-to, but these will likely be converted to a more angle bracket friendly form in time.

Named Argument Syntax

As mentioned in the previous section, arguments that are passed to components are prefixed with the @ symbol in Angle bracket syntax. Ember Octane leverages this in the component's templates by allowing users to directly refer to an argument using the same prefix:

<!-- todo-list.hbs -->
<ul>
  {{#each @todos as |todo index|}}
    <li>
      {{yield (todo-item-component todo=todo) index}}
    </li>
  {{/each}}
</ul>

We can immediately tell now by looking at this template that @todos is an argument that was passed to the component externally. This is in fact always true - there is no way to modify the value referenced by @todos from the component class, it is the original, unmodified value. If there is some business logic that needs to happen in the class, for instance to filter the items, you can do this in a getter and refer to that instead:

<!-- todo-list.hbs -->
<ul>
  {{#each this.uncompletedTodos as |todo index|}}
    <li>
      {{yield (todo-item-component todo=todo) index}}
    </li>
  {{/each}}
</ul>

// todo-list.js
export default class TodoList extends Component {
  @computed('todos.length')
  get uncompletedTodos() {
    return this.todos.filter(todo => !todo.completed);
  }
}

This is a subtle change, but helps to reduce some of the ambiguity of our templates. Combined with the next change, requiring this, it makes a huge difference.

Required this in Templates

The final major change in Octane-style templates is to require this when referring to the component instance and its state. This includes computed properties and normal properties:

<!-- main.hbs -->
Hello, {{join (capitalize this.firstName) (capitalize this.lastName)}}!

{{#if (gt this.todos.length 0)}}
  <TodoList role="list" @todos={{this.todos}} as |Item index|>
    {{add index 1}}. <Item/>
  </TodoList>
{{else}}
  No todos!
{{/if}}

This change is subtle, but instantly provides much more context in templates. We can now clearly tell what are values provided by the component class, and what are helpers (join, capitalize, gt, add) or local variables provided in yields (Item, index). Combined with named argument syntax, it allows for almost all values in the template to have a clear point-of-origin, so users can follow them back to where they came from easily.

Putting It All Together

Like last time, I'd like to show you a more complete example based on a real-life template, instead of having you just take my word for it based on a few small examples. This is a component from emberobserver.com, one with a fairly verbose template (source here):

<div class="large-search with-default-styling">
  <div class="search">
    <div class="search-wrapper">
      <input type="search"
             placeholder="Search for addons, maintainers and categories"
             autocomplete="off"
             id="search-input"
             spellcheck="false"
             value={{query}}
             oninput={{action (perform search) value="target.value"}}>
      {{#if query}}
        <button
          {{action clearSearch}}
          class="close-button test-clear-search">
          {{svg-icon "close"}}
        </button>
      {{/if}}
    </div>
    <div class="readme-toggle">
      {{input type="checkbox"
              class="test-search-readmes"
              id="search-readmes"
              checked=searchReadmes
              change=(action (perform toggleReadmeSearch))}}
      <label for="search-readmes">Search readmes</label>
    </div>
    <h6 class="no-results {{if hasSearchedAndNoResults 'showing'}}">
      No results found for "{{query}}"
    </h6>
  </div>

  {{#if results.length}}
    <h4 class="result-info test-result-info">
      Results for "{{query}}"
    </h4>
    {{#search-result-set
      results=results.displayingReadmes
      totalCount=results.totalReadmeCount
      fetchMore=fetchMoreReadmes
      title="Readmes"
      resultClass="readme-results"}}
      <ul class="readme-list">
        {{#each results.displayingReadmes as |addon|}}
          <li>
            {{addon-details addon=addon}}
            {{#each (get _results.readmeMatchMap addon.id) as |match|}}
              <div class="test-readme-match text-match">
                ...{{dom-purify match use-profiles=(hash html=true) hook='target-blank'}}...
              </div>
            {{/each}}
          </li>
        {{/each}}
      </ul>
    {{/search-result-set}}
    {{#search-result-set
      results=results.displayingCategories
      totalCount=results.totalCategoriesCount
      fetchMore=fetchMoreCategories
      title="Categories"
      resultClass="category-results"}}
      <ul>
        {{#each results.displayingCategories as |category|}}
          <li>
            {{#link-to "categories.show" category.slug}}
              <span class="bullet">&#9632;</span>
              <div>{{category.name}} ({{category.totalAddonCount}})</div>
            {{/link-to}}
          </li>
        {{/each}}
      </ul>
    {{/search-result-set}}
    {{#search-result-set
      results=results.displayingAddons
      totalCount=results.totalAddonsCount
      fetchMore=fetchMoreAddons
      title="Addons"
      resultClass="addon-results"}}
      {{addon-list addons=results.displayingAddons}}
    {{/search-result-set}}
    {{#search-result-set
      results=results.displayingMaintainers
      totalCount=results.totalMaintainersCount
      fetchMore=fetchMoreMaintainers
      title="Maintainers"
      resultClass="maintainer-results"}}
      <ul>
        {{#each results.displayingMaintainers as |maintainer|}}
          <li>
            {{#link-to "maintainers.show" maintainer.name}}
              <span class="bullet">&#9632;</span>
              <div>{{maintainer.name}}</div>
            {{/link-to}}
          </li>
        {{/each}}
      </ul>
    {{/search-result-set}}
  {{else if search.isRunning}}
    {{dot-spinner}}
  {{/if}}
</div>

And here is the same template rewritten with the various new features added in Octane:

<div class="large-search with-default-styling">
  <div class="search">
    <div class="search-wrapper">
      <input
        type="search"
        placeholder="Search for addons, maintainers and categories"
        autocomplete="off"
        id="search-input"
        spellcheck="false"
        value={{this.query}}
        oninput={{action (perform this.search) value="target.value"}}
      />
      {{#if this.query}}
        <button
          {{action this.clearSearch}}
          class="close-button test-clear-search"
        >
          {{svg-icon "close"}}
        </button>
      {{/if}}
    </div>
    <div class="readme-toggle">
      <Input
        @type="checkbox"
        @checked={{this.searchReadmes}}
        @change={{action (perform this.toggleReadmeSearch)}}

        id="search-readmes"
        class="test-search-readmes"
      />
      <label for="search-readmes">Search readmes</label>
    </div>
    <h6 class="no-results {{if this.hasSearchedAndNoResults 'showing'}}">
      No results found for "{{this.query}}"
    </h6>
  </div>

  {{#if this.results.length}}
    <h4 class="result-info test-result-info">
      Results for "{{this.query}}"
    </h4>

    <SearchResultSet
      @results={{this.results.displayingReadmes}}
      @totalCount={{this.results.totalReadmeCount}}
      @fetchMore={{this.fetchMoreReadmes}}
      @title="Readmes"
      @resultClass="readme-results"
    >
      <ul class="readme-list">
        {{#each this.results.displayingReadmes as |addon|}}
          <li>
            <AddonDetails @addon={{addon}} />

            {{#each (get this._results.readmeMatchMap addon.id) as |match|}}
              <div class="test-readme-match text-match">
                ...{{dom-purify match use-profiles=(hash html=true) hook='target-blank'}}...
              </div>
            {{/each}}
          </li>
        {{/each}}
      </ul>
    </SearchResultSet>

    <SearchResultSet
      @title="Categories"
      @results={{this.results.displayingCategories}}
      @totalCount={{this.results.totalCategoriesCount}}
      @fetchMore={{this.fetchMoreCategories}}
      @resultClass="category-results"
    >
      <ul>
        {{#each this.results.displayingCategories as |category|}}
          <li>
            {{#link-to "categories.show" category.slug}}
              <span class="bullet">&#9632;</span>
              <div>{{category.name}} ({{category.totalAddonCount}})</div>
            {{/link-to}}
          </li>
        {{/each}}
      </ul>
    </SearchResultSet>

    <SearchResultSet
      @title="Addons"
      @results={{this.results.displayingAddons}}
      @totalCount={{this.results.totalAddonsCount}}
      @fetchMore={{this.fetchMoreAddons}}
      @resultClass="addon-results"
    >
      <AddonList @addons={{this.results.displayingAddons}} />
    </SearchResultSet>

    <SearchResultSet
      @title="Maintainers"
      @results={{this.results.displayingMaintainers}}
      @totalCount={{this.results.totalMaintainersCount}}
      @fetchMore={{this.fetchMoreMaintainers}}
      @resultClass="maintainer-results"
    >
      <ul>
        {{#each this.results.displayingMaintainers as |maintainer|}}
          <li>
            {{#link-to "maintainers.show" maintainer.name}}
              <span class="bullet">&#9632;</span>
              <div>{{maintainer.name}}</div>
            {{/link-to}}
          </li>
        {{/each}}
      </ul>
    </SearchResultSet>
  {{else if this.search.isRunning}}
    <DotSpinner/>
  {{/if}}
</div>

In my opinion, this is much easier to skim through and get a general sense of quickly, with clear visual markers for the major different elements (components, helpers, plain HTML, and inserted values). Importantly, the core essence of Handlebars' declarative templating has not been lost - this still reads like HTML, and where there is dynamism it is a declarative sort of dynamism. We aren't reading Javascript, we're reading LISP-y templates!

Available Now

The title of this post is actually inaccurate - all of these features have already landed in Ember, and have been usable for some time! You can try them out now, and they're fully backwards compatible with older features and components.

The nature of Editions is that some of the new features land sooner rather than later, and we just haven't really had a chance to polish up the guides and the DX for learning all of them. Octane gives us a focal point that allows us to sum everything up, and update all of our learning materials and guides, but if you're interested in early adoption things have been landing in master for some time now!

Conclusion

That's all I have for today! I'm sure you're eager to try out <AngleBrackets> in your app/addon now that you've seen it, so I'll wrap this up quick 😄 Next week I'll be posting about Tracked Properties, which are a major update to the way Ember tracks state changes, so be sure to come back then!

Hello again, and welcome back! This is the third entry in the multipart Coming Soon in Ember Octane series, where we're previewing some of the various features that are landing in Ember's upcoming Octane edition, including:

• Native Classes (+Decorators)
• Angle Brackets & Named Arguments
• Tracked Properties ← this post
• Modifiers
• Glimmer Components

These aren't all of the new features that will be part of Octane, just the ones that I'm most familiar with personally. This series is aimed at existing Ember users, but if you're new to Ember or tried Ember a while ago and want to see how things are changing, I'll be providing context on the existing features as we go along. These posts won't be doing deep dives on all the edge cases of the functionality, they are moreso meant as an overview of what's coming. If you're curious about what an edition is exactly, you can check out a quick break down in the first post in the series.

On to tracked properties!

Tracked Properties: Automatic shouldComponentUpdate

For most Ember users, typing out lists of dependencies should be second nature. Ember has never had the equivalent of React's shouldComponentUpdate or React.memo, instead relying on set (roughly equivalent to setState), and explicit property dependencies for computed properties:

// components/clock.js
export default Component.extend({
  init() {
    setInterval(() => {
      this.set('date', new Date());
    }, 1000);
  },

  formattedTime: computed('date', function() {
    return moment(this.get('date')).format('h:mm:ss a');
  }),

  message: computed('formattedTime', function() {
    return `It is currently ${this.get('formattedTime')}!`;
  }),
});

This system means that users don't usually have to think about whether or not a component should update. If any values have updated, they will inform their dependencies, and Ember will know whether or not to rerender the template if something that has been marked as dirty was rendered before. This is similar to to React's new useMemo hook, but is used by default for every value in an Ember app.

Better yet, it also means Ember can minimize the amount that is rerendered - each individual value in the template can know whether or not it has been updated, meaning entire sections of the template (and components within those sections) can be skipped:

<!-- This wrapper component gets ignored completely during rerenders -->
<ClockWrapper theme="dark">
  <!-- This text node is the _only_ thing that gets touched -->
  {{this.message}}
</ClockWrapper>

This is also what enables Ember's dependency injection system. Instead of having to wrap every component in a Context/Provider that is updating the component's props, we can directly inject the instance of a service and passively watch it for changes, reducing a layer of indirection.

However, this all comes at a cost. We have to use set everywhere to ensure that the system picks up changes (up until recently we also had to use get to get them, but thankfully that constraint was mostly removed recently), and we have to type out these lists of dependencies for any derived values in the system. This can take quite a lot of time and effort, and requires diligence to maintain.

So, Ember's current system isn't quite "automatic" either. It's conventional - by following the rules, you get the benefits of shouldComponentUpdate without having to work out the details yourself. It's pretty easy to follow those rules, because they are simple and straightforward, but it still can be tedious and feels like boilerplate, and if there's an unofficial Ember motto it may be "get rid of the boilerplate!"

Flip It Around!

Tracked properties are Ember's next iteration on this system. They address all of the above pain points, and then some. The way they work is by explicitly annotating all trackable properties on a class, instead of annotating the dependencies for every single getter, effectively reversing where the annotation occurs. Trackable properties are any properties which:

1. Change over time and
2. May cause the DOM to update in response to those changes

For example, here's the ClockComponent class from earlier refactored with tracked properties:

// components/clock.js
export default class ClockComponent extends Component {
  @tracked date;

  constructor() {
    setInterval(() => (this.date = new Date()), 1000);
  },

  get formattedTime() {
    return moment(this.date).format('h:mm:ss a');
  }

  get message() {
    return `It is currently ${this.formattedTime}!`;
  }
}

Notice that getters no longer need to be annotated at all, and we only have a single decorated property. This works because when Ember is rendering a value, like {{this.message}}, it watches for accesses to any tracked properties. Later on, if one of those properties changes, it knows it needs to rerender that value and any components or helpers that consume it. No more dependency lists required! Now that is automatic.

But the benefits go beyond just removing all of that boilerplate.

Explicit Field Declarations

We now have an explicit list of all trackable values on a class. This means that we can very quickly look at a class and see where the "important" values are, in a single declarative list:

// components/person.js
export default class PersonComponent extends Component {
  @tracked firstName;
  @tracked lastName;

  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  }

  @action
  updateName(firstName, lastName) {
    this.firstName = firstName;
    this.lastName = lastName;
  }
}

Before, it was not uncommon to have these values be implicit. Somewhere in the code flow, something would use set, and the value would suddenly exist:

// components/person.js
export default Component.extend({
  // This computed property _implies_ that `firstName` and `lastName`
  // exist, but we don't know that without reading it.
  fullName: computed('firstName', 'lastName', function() {
    return `${this.firstName} ${this.lastName}`;
  }),

  actions: {
    // Likewise, this action sets `firstName` and `lastName`
    // which implies that they are used and watched, but we wouldn't
    // have known that unless we actually read the function body.
    updateName(firstName, lastName) {
      this.set('firstName', firstName);
      this.set('lastName', lastName);
    },
  },
});

It was often convention to assign default values to these fields so that they could be seen, but that convention was not enforced in any meaningful way and really just became another small amount of boilerplate.

Enforced Public API

We also have control over what values are trackable. With set, it's possible to "reach" into objects and observe any values you want. This makes the previous problem that much worse!

// utils/person.js

// This might be confusing at first - it looks like an empty class.
// What are its values? What is it used for? Maybe it has a `name`?
// `address`? Who knows!
export default EmberObject.extend({});

// components/person.js
export default Component.extend({
  init() {
    this._super(...arguments);
    this.set('person', Person.create());
  },

  fullName: computed('person.firstName', 'person.lastName', function() {
    return `${this.person.firstName} ${this.person.lastName}`;
  }),

  actions: {
    // Here we can see that set the `firstName` and `lastName`
    // properties, so now we have _some_ sense of what the "shape"
    // of a Person is.
    updateName(firstName, lastName) {
      this.set('person.firstName', firstName);
      this.set('person.lastName', lastName);
    },
  },
});

Because of this effect, any external class can essentially expand a class's public API at any point in time simply because it's convenient. In large codebases, this can lead to the true definition of a class being spread out across many different files, actions, helper functions, and computed properties. In other words, it leads to spaghetti.

By comparison, for this to work at all with tracked properties, firstName and lastName must be annotated:

// utils/person.js

// `firstName` and `lastName` are the only watchable values on
// `Person`. We can't prevent people from adding other properties,
// but they will have no effect on rerenders.
export default class Person {
  @tracked firstName;
  @tracked lastName;
}

// components/person.js
export default class PersonComponent extends Component {
  person = new Person();

  get fullName() {
    return `${this.person.firstName} ${this.person.lastName}`;
  }

  // This works as expected, because the properties are tracked.
  @action
  updateName(firstName, lastName) {
    this.person.firstName = firstName;
    this.person.lastName = lastName;
  }

  // This adds the property, but does not trigger a rerender. If
  // we want it to trigger a rerender, we need to go and add
  // `middleName` as a tracked property to `Person`.
  @action
  updateMiddleName(middleName) {
    this.person.middleName = middleName;
  }
}

This means that we have an enforced "public API" in effect. Users of the class cannot add values that were not intended to exist and then watch them, and this disincentives using the class for anything other than its intended purpose.

Backwards Compatible

You may be looking at these examples and thinking, "This is great in theory, but I have a lot of computed properties in my app! How am I going to update them all?" Unfortunately, we can't just codemod you forward because of the implicit layer of definitions we talked about earlier. It's hard to know where to add tracked properties, on which classes and objects they should be defined.

Luckily, tracked properties are fully backwards compatible with computed properties and the get/set system, and they also work in classic class syntax. You can access a tracked property from a computed, and it will be picked up without having to add the dependency:

// components/person.js
export default Component.extend({
  firstName: tracked(),
  lastName: null,

  // This computed property _implies_ that `firstName` and `lastName`
  // exist, but we don't know that without reading it.
  fullName: computed('lastName', function() {
    return `${this.firstName} ${this.lastName}`;
  }),

  actions: {
    // Likewise, this action sets `firstName` and `lastName`
    // which implies that they are used and watched, but we wouldn't
    // have known that unless we actually read the function body.
    updateName(firstName, lastName) {
      this.firstName = firstName;
      this.set('lastName', lastName);
    },
  },
});

This means you can convert your applications one field at a time, in parts. It may take a while, but computed() isn't going anywhere anytime soon, giving you plenty of time and space to adopt tracked properties at your own pace.

Putting It All Together

Alright, let's once again take the new feature and put it to use! This time I'm going to take an example from the excellent ember-cli-flash addon which is used for showing flash messages. This example is a bit more involved than previous ones, since I really wanted to demonstrate just how much tracked properties can help to clean up not only component code, but utility code as well.

Note: I've also edited down some of the classes to show only the parts relevant to tracked properties, and this is not a full conversion as there may be more tracked values used in other contexts which I did not add.

// ember-cli-flash/addon/flash/object.js
import Evented from '@ember/object/evented';
import EmberObject, { set, get } from '@ember/object';

export default EmberObject.extend(Evented, {
  exitTimer: null,
  exiting: false,
  isExitable: true,
  initializedTime: null,

  // ... class methods
});

// ember-cli-flash/addon/components/flash-message.js
import { htmlSafe, classify } from '@ember/string';
import Component from '@ember/component';
import { isPresent } from '@ember/utils';
import { next, cancel } from '@ember/runloop';
import { computed, set, get, getWithDefault } from '@ember/object';
import { and, bool, readOnly, not } from '@ember/object/computed';
import layout from '../templates/components/flash-message';

export default Component.extend({
  layout,
  active: false,
  messageStyle: 'bootstrap',
  classNames: ['flash-message'],
  classNameBindings: ['alertType', 'active', 'exiting'],
  attributeBindings: ['aria-label', 'aria-describedby', 'role'],

  showProgress: readOnly('flash.showProgress'),
  notExiting: not('exiting'),
  showProgressBar: and('showProgress', 'notExiting'),
  exiting: readOnly('flash.exiting'),
  hasBlock: bool('template').readOnly(),

  alertType: computed('flash.type', {
    get() {
      const flashType = getWithDefault(this, 'flash.type', '');
      const messageStyle = getWithDefault(this, 'messageStyle', '');
      let prefix = 'alert alert-';

      if (messageStyle === 'foundation') {
        prefix = 'alert-box ';
      }

      return `${prefix}${flashType}`;
    },
  }),

  flashType: computed('flash.type', {
    get() {
      const flashType = getWithDefault(this, 'flash.type', '');

      return classify(flashType);
    },
  }),

  didInsertElement() {
    this._super(...arguments);
    const pendingSet = next(this, () => {
      set(this, 'active', true);
    });
    set(this, 'pendingSet', pendingSet);
  },

  progressDuration: computed('flash.showProgress', {
    get() {
      if (!get(this, 'flash.showProgress')) {
        return false;
      }

      const duration = getWithDefault(this, 'flash.timeout', 0);

      return htmlSafe(`transition-duration: ${duration}ms`);
    },
  }),

  click() {
    const destroyOnClick = getWithDefault(this, 'flash.destroyOnClick', true);

    if (destroyOnClick) {
      this._destroyFlashMessage();
    }
  },

  mouseEnter() {
    const flash = get(this, 'flash');
    if (isPresent(flash)) {
      flash.preventExit();
    }
  },

  mouseLeave() {
    const flash = get(this, 'flash');
    if (isPresent(flash) && !get(flash, 'exiting')) {
      flash.allowExit();
    }
  },

  willDestroy() {
    this._super(...arguments);
    this._destroyFlashMessage();
    cancel(get(this, 'pendingSet'));
  },

  // private
  _destroyFlashMessage() {
    const flash = getWithDefault(this, 'flash', false);

    if (flash) {
      flash.destroyMessage();
    }
  },

  actions: {
    close() {
      this._destroyFlashMessage();
    },
  },
});

You can see from this example the implicit state problem I mentioned earlier. We can see from the FlashMessage component that it definitely expects the flash object to have quite a few values on it, but we aren't seeing them here. Let's update it to tracked properties and see how that changes things:

// ember-cli-flash/addon/flash/object.js
import Evented from '@ember/object/evented';
import EmberObject, { set, get } from '@ember/object';

export default class FlashObject extends EmberObject.extend(Evented) {
  @tracked type = '';
  @tracked timeout = 0;
  @tracked showProgress = false;
  @tracked destroyOnClick = true;
  @tracked exiting = false;

  exitTimer = null;
  isExitable = true;
  initializedTime = null;

  // ... class methads
}

// ember-cli-flash/addon/components/flash-message.js
import { htmlSafe, classify } from '@ember/string';
import Component from '@ember/component';
import { next, cancel } from '@ember/runloop';
import { and, bool, readOnly, not } from '@ember/object/computed';
import { layout, classNames, className } from '@ember-decorators/component';
import template from '../templates/components/flash-message';

@layout(template)
@classNames('flash-message')
export default class FlashMessage extends Component {
  // Arguments
  messageStyle = 'bootstrap';

  // Internal state
  @className
  @tracked
  active = false;

  @className
  @readOnly('flash.exiting')
  exiting;

  @not('exiting') notExiting;
  @and('flash.showProgress', 'notExiting') showProgressBar;
  @bool('template') hasBlock;

  #pendingSet;

  @className
  get alertType() {
    let prefix = this.messageStyle === 'foundation' ?
      'alert-box' :
      'alert alert-';

    return `${prefix}${this.flash.type}`;
  }

  get flashType() {
    return classify(this.flash.type);
  }

  get progressDuration() {
    if (!this.flash.showProgress) {
      return false;
    }

    return htmlSafe(`transition-duration: ${this.flash.timeout}ms`);
  }

  didInsertElement() {
    super.didInsertArguments(...arguments);
    this.#pendingSet = next(this, () => this.active = true);
  },

  click() {
    if (this.flash.destroyOnClick) {
      this.#destroyFlashMessage();
    }
  }

  mouseEnter() {
    if (this.flash) {
      this.flash.preventExit();
    }
  }

  mouseLeave() {
    if (this.flash && !this.flashexiting) {
      this.flash.allowExit();
    }
  }

  willDestroy() {
    super.willDestroy(...arguments);
    this.#destroyFlashMessage();
    cancel(this.#pendingSet);
  }

  #destroyFlashMessage() {
    if (this.flash) {
      flash.destroyMessage();
    }
  }

  @action
  close() {
    this.#destroyFlashMessage();
  }
}

This reads much more clearly than before! We can now read the FlashObject class definition and know what properties external consumers, such as the FlashMessage component, will be watching and using. When we dive into the FlashMessage component, it's much less verbose and easier to read. Properties and getters are much more straightforward, and we can easily distinguish between properties that are used for rendering (action, which is tracked) and properties that are not (#pendingSet which is a private property used for tracking a runloop task). Additionally, we can still use computed property macros for convenience, and private fields and methods are a nice bonus here in native class syntax.

Conclusion

That's all I have for today! Tracked properties are currently behind a feature flag on canary, and still being polished up. They should be available soon as we get the Octane preview up and running, I'll be sure to tweet about it when they are! In the meantime, thanks for reading, and stay tuned for next week's post on Element Modifiers!

Hello again, and welcome back! This is the fourth entry in the multipart Coming Soon in Ember Octane series, where we're previewing some of the various features that are landing in Ember's upcoming Octane edition, including:

• Native Classes (+Decorators)
• Angle Brackets & Named Arguments
• Tracked Properties
• Modifiers ← this post
• Glimmer Components

These aren't all of the new features that will be part of Octane, just the ones that I'm most familiar with personally. This series is aimed at existing Ember users, but if you're new to Ember or tried Ember a while ago and want to see how things are changing, I'll be providing context on the existing features as we go along. These posts won't be doing deep dives on all the edge cases of the functionality, they are moreso meant as an overview of what's coming. If you're curious about what an edition is exactly, you can check out a quick break down in the first post in the series.

Alright, now let's talk about modifiers, Ember's new tool for working with the DOM!

What Are "Modifiers"

Modifiers are similar to Handlebars helpers, they are functions or classes that can be used in templates directly using {{double-curlies}}. The major difference with modifiers is that they are applied directly to elements:

<button {{on "click" this.handleClick}}>
  Hello, World!
</button>

Modifiers are used for manipulating or reading from the DOM somehow. For instance, the example above uses the on modifier to add a click handler to the button element it is modifying. In general modifiers act on the element they are modifying, but they could also act on the the subtree of that element.

Modifiers are not an entirely new concept in Ember. In fact, they've existed in some form or another since some of the earliest days of Ember, in the form of the {{action}} modifier, and the {{bind-attr}} modifier from the v1 era of the framework. However, it's never been possible before for users to make their own modifiers. Now they're being given first class support to allow users more fidelity in how they interact with the DOM, and to allow DOM code to be more easily shared across components and other templates.

The New didInsertElement

You may be thinking, don't lifecycle hooks solve the same problem? Can't I put logic like adding event listeners and measuring elements in didInsertElement or didRender on my component class and call it a day? Why do we need a new concept for this kind of logic?

There are a few reasons modifiers end up being a better solution for DOM manipulation in general:

1. They allow targeting specific elements more easily. Lifecycle hooks only allow you to work with the component's root element, if it has one. If you want to target any other element in the component, it can be a lot of work. For instance, to do the same thing as our original example with the on modifier, we would have to use querySelector in our didInsertElement hook to find the button element:

didInsertElement() {
  this.element
    .querySelector('button')
    .addEventListener('click', this.handleClick);
}

This type of code can get even trickier in larger components, where you may have multiple elements that need event listeners, or have elements that only exist conditionally:

<button>Hello, World!</button>

{{#if this.showTutorial}}
  <span class="tooltip">Click the button!</span>
{{/if}}

didInsertElement() {
  this.element
    .querySelector('button')
    .addEventListener('click', this.handleClick);

  let tooltip = this.element.querySelector('.tooltip');

  if (tooltip) {
    tooltip.addEventListener('mouseover', this.toggleTooltip);
  }
}

We could create new components instead, and this may make sense at times - for instance, the tooltip logic is something we'd likely want to reuse across the app. But in many cases, like our "Hello, world!" button, this would be a pretty heavy-handed solution, with a lot of boilerplate being generated for a very small amount of functionality. Compare this to modifiers, which can be applied directly to the elements that they operate on:

<button {{on "click" this.handleClick}}>
  Hello, World!
</button>

{{#if this.showTutorial}}
  <span class="tooltip" {{on "mouseover" this.toggleTooltip}}>
    Click the button!
  </span>
{{/if}}

This cleans things up considerably. We don't have to duplicate logic in the component and the template, only one if statement is needed, and we can easily see what event listeners are applied to which elements. No need to make more components!

2. They allow related code to live in the same place. The above example is even more complicated in actuality, because it's missing its teardown logic. If we aren't careful, we could end up leaking event listeners, or in an inconsistent state when the if statement toggles. Here's what the full logic for our component should look like:

class HelloWorld extends Component {
  addTooltipListener() {
    // save the element so we can remove the listener later
    this._tooltip = this.element.querySelector('.tooltip');

    if (this._tooltip) {
      this._tooltip.addEventListener(
        'mouseover',
        this.toggleTooltip
      );
    }
  }

  removeTooltipListener() {
    if (this._tooltip) {
      this._tooltip.removeEventListener(
        'mouseover',
        this.toggleTooltip
      );
    }
  }

  didInsertElement() {
    this.element
      .querySelector('button')
      .addEventListener('click', this.handleClick);

    this.addTooltipListener();
  }

  didUpdate() {
    this.removeTooltipListener();
    this.addTooltipListener();
  }

  willDestroyElement() {
    this.element
      .querySelector('button')
      .removeEventListener('click', this.handleClick);

    this.removeTooltipListener();
  }

  // ...
}

As you can see, this is just a bit convoluted. We have a lot of conditional code all over the place, and we have mixing of concerns between the logic for the tooltip and the logic for the button. By contrast, modifiers have their own setup and teardown logic, completely self-contained. They also run on the insertion and destruction of the element they are modifying, not the component, so we don't need to check for the element's existence to see if we should be doing anything. The modifier will run when showTutorial switches to true, and it'll be torn down when showTutorial switches to false.

3. They make sharing code between components much easier. Often times the same types of DOM manipulations need to be used in many components throughout an app, and usually it isn't easy or natural to share them via class inheritance. On the other hand, utility functions generally feel very bloated and boilerplate heavy to use for these purposes, since they must use state from the component and be integrated into its hooks. Addons like ember-lifeline do a good job at reducing the boilerplate, but it's still not ideal.

This is one of the remaining use cases for Ember's mixin functionality, and arguably modifiers solve it even more cleanly since the modifications are applied where they happen.

4. They work with template-only components. Currently you must always create a component class to do even simple DOM manipulation. With modifiers that's no longer necessary. In the future, this will mean more performance wins for simpler components, since they won't need a class instance.

5. They work with tag-less components and Glimmer components. Currently, tag-less components (components with tagName: '') have lifecycle hooks, but they don't have the this.element property since they don't have a wrapping element. This means that manipulating the DOM in them is pretty hard, you generally have to add a unique id to an element and select by that. Glimmer components also don't have this.element since they don't have a wrapping element either (more on that next time), and on top of that, they also don't have any lifecycle hooks beyond the constructor and willDestroy.

Modifiers disconnect the component class definition from DOM manipulation, which means that they work even without these APIs. In fact, they will work with any component API. This allows more thorough separation concerns, and makes transitioning forward from classic components to Glimmer components even easier.

These benefits are the reasoning behind introducing a new concept. We also aren't the only framework to have noticed the benefits of this pattern, most recently React's new Hooks API is accomplishing a lot of the same goals in a similar manner, especially the useLayoutEffect hook which is specifically for running side-effecting layout code. Ember modifiers fill a similar gap.

So What Do They Look Like?

The usage side of modifiers has been defined since Ember v1. A modifier is the same syntax as a helper, but applied directly to an element instead of to an attribute:

<div
  {{my-modifier 'hello' 'world!'}}
  role={{my-helper 'some' 'value'}}
></div>

Notably, there is an {{action}} helper and an {{action}} modifier, which is why it appears like the action helper can be used in both places:

<!-- this is the action modifier -->
<div {{action this.handleClick}}></div>

<!-- this is the action helper -->
<div onclick={{action this.handleClick}}></div>

Modifiers run whenever the element is inserted or destroyed, and whenever any of arguments to them change.

User defined modifiers haven't been finalized just yet. Instead, Ember has created a low level API, the Modifier Manager. This allows us to experiment with different APIs for modifiers in the addon ecosystem before committing to a specific API. There are two major design proposals (and many variations on them) for modifiers that have been floated around at the moment.

NOTE: These are NOT actual Ember APIs. They can currently be implemented in addons (and definitely should be!), but they may change in the future before Ember picks recommended/standard APIs!

1. Class Based Modifiers

These modifiers would be more fully featured, with an instance and state, and the ability to control each lifecycle event:

export default class DarkMode extends Modifier {
  @service userSettings;

  didInsert(element, [darkModeClass]) {
    if (this.userSettings.darkModeEnabled) {
      this._previousDarkModeClass = darkModeClass;
      element.classList.add(darkModeClass);
    }
  }

  willDestroy(element) {
    element.classList.remove(this._previousDarkModeClass);
  }

  didUpdate() {
    this.willDestroy(...arguments);
    this.didInsert(...arguments);
  }
}

<!-- usage -->
<div {{dark-mode 'ui-dark'}}></div>

This API gives users the ability to have fine grained control over how they update the element each time the arguments change. In some cases, this level of control will be very useful for fine tuning performance, but in many cases (including this one) it may be more complicated than is necessary.

2. Functional Modifiers

These modifiers would use a functional API, similar to useLayoutEffect in React, where they would consist of a single function that returns a cleanup function (if needed):

function darkMode(userSettings, element, [darkModeClass]) {
  if (userSettings.darkModeEnabled) {
    element.classList.add(darkModeClass);

    return () => {
      element.classList.remove(darkModeClass);
    };
  }
}

export default modifier(
  { services: ['userSettings'] },
  darkMode
);

<!-- usage -->
<div {{dark-mode 'ui-dark'}}></div>

The cleanup function would run every time the modifier updates, so in some cases this won't be performant enough. In many cases though, like this one, the increased ergonomics of it will be worth the extra cost. This version would also clean up very nicely in the future if decorators are made available to functions and function parameters:

@modifier
function darkMode(
  @service userSettings,
  element,
  [darkModeClass]
) {
  if (userSettings.darkModeEnabled) {
    element.classList.add(darkModeClass);

    return () => {
      element.classList.remove(darkModeClass);
    }
  }
}

In the end, it's likely that a couple different modifier APIs will be recommended for most use-cases. Custom modifier APIs that are created will also continue to be supported indefinitely, part of the power and flexibility of the manager pattern that Ember is now using for userland APIs.

So, What Can I Use Now?

There are several addons that have created modifiers that you can use in your apps today, including:

• @ember/render-modifiers, an official Ember addon that includes:

1. {{did-insert}}
2. {{did-update}}
3. {{will-destroy}}

These modifiers are meant to be simple primitives that allow you to run code on each of the major lifecycle events that modifiers (and modifier managers) can have. They're also meant to help users refactor from classic components forward to Glimmer components, since Glimmer components don't have their own lifecycle hooks, though there are still some differences - notably, {{did-update}} does not update every time the component rerenders, only when its arguments change.

• ember-on-modifier, created by Jan Buschtöns, allows you to add event listeners of any kind directly to elements. This means you can cleanup any ember-lifeline code you have lying around and switch on over!
• ember-ref-modifier, created by Alex Kanunnikov, mimics React's "ref" system for storing references to elements. This allows you to use them on your component directly if you need to, for more complicated component use cases.

If you're willing to work at a lower level and experiment with new APIs, you can also check out the modifier-manager-polyfill, but be warned that it is meant for low level infrastructure, and shouldn't generally be used to write modifiers directly. The Modifier Manager API is still very new, and it'll take some time to solidify the userland APIs, but they'll be available soon!

Putting It All Together

As always, we'll end with an example of a component before and after, to see how this new feature impacts real applications. This time we'll use an example from ember-paper, the Material UI addon for Ember, specifically the paper-toast-inner component, which uses the Hammer.js library for recognizing touch events.

We'll also be using theoretical user APIs this time around, because the details of writing a component manager are definitely not ergonomic.

NOTE: These examples contain PROPOSED APIs that have not been finalized, and could change in the future.

Starting out, this is what our component looks like:

import Component from '@ember/component';

import { run } from '@ember/runloop';
import { computed } from '@ember/object';
import { htmlSafe } from '@ember/string';
import layout from '../templates/components/paper-toast-inner';
import TransitionMixin from 'ember-css-transitions/mixins/transition-mixin';
import { invokeAction } from 'ember-invoke-action';

/**
 * @class PaperToastInner
 * @extends Ember.Component
 */
export default Component.extend(TransitionMixin, {
  layout,
  tagName: 'md-toast',

  // ...

  _setupHammer() {
    // Enable dragging the slider
    let containerManager = new Hammer.Manager(this.element, {
      dragLockToAxis: true,
      dragBlockHorizontal: true,
    });
    let swipe = new Hammer.Swipe({
      direction: Hammer.DIRECTION_ALL,
      threshold: 10,
    });
    let pan = new Hammer.Pan({
      direction: Hammer.DIRECTION_ALL,
      threshold: 10,
    });
    containerManager.add(swipe);
    containerManager.add(pan);
    containerManager
      .on('panstart', run.bind(this, this.dragStart))
      .on('panmove', run.bind(this, this.drag))
      .on('panend', run.bind(this, this.dragEnd))
      .on('swiperight swipeleft', run.bind(this, this.dragEnd));
    this._hammer = containerManager;
  },

  didInsertElement() {
    this._super(...arguments);
    if (this.get('swipeToClose')) {
      this._setupHammer();
    }
  },

  didUpdateAttrs() {
    this._super(...arguments);

    if (this.get('swipeToClose') && !this._hammer) {
      // if it is enabled and we didn't init hammer yet
      this._setupHammer();
    } else if (!this.get('swipeToClose') && this._hammer) {
      // if it is disabled and we did init hammer already
      this._teardownHammer();
    }
  },

  willDestroyElement() {
    this._super(...arguments);
    if (this._hammer) {
      this._teardownHammer();
    }
  },

  _teardownHammer() {
    this._hammer.destroy();
    delete this._hammer;
  },

  dragStart(event) {
    // ...
  },

  drag(event) {
    // ...
  },

  dragEnd() {
    // ...
  },
});

You'll notice that I've omitted some of the implementation details of the component so we can focus on the parts we're going to replace with modifiers. The same functionality can be refactored with two different functional modifiers - if and hammer:

// /addon/modifiers/if.js
function _if(
  element,
  [conditional, modifier, ...rest],
  named) {
  if (Boolean(conditional)) {
    return modifier(element, rest, named);
  }
}

export default modifier(_if);

// /addon/modifiers/hammer.js
const HAMMER_TYPE = {
  swipe: Hammer.Swipe,
  pan: Hammer.Pan,
  // remaining types...
};

const HAMMER_DIRECTION = {
  all: Hammer.DIRECTION_ALL,
  // remaining directions...
};

function hammer(element, positional, {
  recognizers = [],
  options = {},
  ...events
}) {
  let hammer = new Hammer.Manager(element, options);

  for (let { type, direction, ...rest } of recognizers) {
    let Recognizer = HAMMER_TYPE[type];
    direction = HAMMER_DIRECTION[direction];

    hammer.add(new Recognizer({ direction, ...rest }));
  }

  for (let event in events) {
    hammer.on(event, events[event]);
  }

  return () => {
    hammer.destroy();
  };
}

export default modifier(hammer);

The if modifier conditionally applies another modifier based on the the value passed to it, and the hammer modifier is a general purpose wrapper around the Hammer library. We can now use these modifiers without writing any component code:

import Component from '@ember/component';
import template from '../templates/components/paper-toast-inner';
import TransitionMixin from 'ember-css-transitions/mixins/transition-mixin';

import { layout, tagName } from '@ember-decorators/component';

/**
 * @class PaperToastInner
 * @extends Ember.Component
 */
@tagName('')
@layout(template)
export default class PaperToastInner extends Component.extend(TransitionMixin) {
  // ...

  dragStart(event) {
    // ...
  }

  drag(event) {
    // ...
  }

  dragEnd() {
    // ...
  }
}

<md-toast
  {{if @swipeToClose hammer

    panstart=this.dragStart
    panmove=this.drag
    panend=this.dragEnd
    swiperight=this.dragEnd
    swipeleft=this.dragEnd

    recognizers=(arr
      (hash type="swipe" direction="all" threshold=10)
      (hash type="pan" direction="all" threshold=10)
    )

    options=(hash
      dragLockToAxis=true
      dragBlockHorizontal=true
    )
  }}
>
  ...
</md-toast>

As you can see, this is a fair amount less code overall. It's also code that is very easy to reuse now, since all of the implementation concerns for Hammer have been extracted. We could also pre-apply some of the modifiers options directly, for instance if the horizontal-swipe settings are used commonly in the app:

// /addon/modifiers/horizontal-swipe.js
import hammer from './hammer';

export default modifier((element, positional, named) => {
  return hammer(element, positional, {
    ...named,

    recognizers: [
      { type: 'swipe', direction: 'all', threshold: 10 }
      { type: 'pan', direction: 'all', threshold: 10 }
    ],

    options: {
      dragLockToAxis: true,
      dragBlockHorizontal: true,
    },
  });
});

<md-toast
  {{if @swipeToClose horizontalSwipe

    panstart=this.dragStart
    panmove=this.drag
    panend=this.dragEnd
    swiperight=this.dragEnd
    swipeleft=this.dragEnd
  }}
>
  ...
</md-toast>

Conclusion

Modifiers are one of the most exciting features landing in Octane to me. They definitely are a shift in the mental model for DOM and lifecycle hooks, but in my experience so far the component's I've refactored with them are much easier to reason about, and much more composable. Nailing down the userland APIs is going to be an exciting and interesting part of the design, and I'm hoping we get some interesting new ideas from the community (and if anyone wants to implement either of the managers I've described, please do! The class based one has even been mostly spec'd out in Chad Hietala's RFC. Ping me in Discord if you want help!) Overall, I'm looking forward to seeing how they turn out 😄

That's all I have for this week! Next Friday will be the last post in this series - Glimmer components, the next generation of components in Ember.

Hello again, and welcome back! This is the fifth and final entry in the multipart Coming Soon in Ember Octane series, where we're previewing some of the various features that are landing in Ember's upcoming Octane edition, including:

• Native Classes (+Decorators)
• Angle Brackets & Named Arguments
• Tracked Properties
• Modifiers
• Glimmer Components ← this post

These aren't all of the new features that will be part of Octane, just the ones that I'm most familiar with personally. This series is aimed at existing Ember users, but if you're new to Ember or tried Ember a while ago and want to see how things are changing, I'll be providing context on the existing features as we go along. These posts won't be doing deep dives on all the edge cases of the functionality, they are moreso meant as an overview of what's coming. If you're curious about what an edition is exactly, you can check out a quick break down in the first post in the series.

Now, let's move onto Glimmer Components!

A Better Component API

Near the end of the Ember@v1 cycle, the community started noticing some pain points around Ember's component API. While components were a big hit overall, and quickly overtook views to become the default rendering primitive in Ember, there were a few paper cuts here and there that made them feel more difficult to use than they should have. In particular:

1. Syntax: The fact that components required the same {{double-curly}} syntax as helpers and bindings in templates could sometimes make them hard to parse out. There was a lot of visual clutter, and it could be hard to figure out what was being invoked where:

{{#modal-dialog}}
  {{#power-select
    options=names
    onchange=(action "foo")
    as |name|}}
    {{capitalize name}}
  {{/power-select}}
{{/modal-dialog}}

2. Wrapper Element: Components had an implicit wrapper element that always wrapped the template, and required creating a class to customize:

import Component from '@ember/component';

export default Component.extend({
  tagName: 'button',
  classNames: ['btn'],
});

This meant that the template was not the only source-of-truth for the final output of the component - users had to read the component class to know if it had customized the template in some way. It also meant users would oftentimes have to create a class just to customize this element, in what would otherwise be a Template-Only component.

3. Arguments: Arguments to a component were assigned directly as properties on the component's instance. This would often lead to conflicts between arguments and properties or methods on a component, and make it difficult to tell the two apart:

import Component from '@ember/component';

export default Component.extend({
  init() {
    this._super(...arguments);

    // You may wonder where this magic `filter`
    // value came from. Is it a method on the
    // superclass? Actually, it's an argument
    // that was passed to the component, a callback.
    this.filter('').then((results) => {
      return this.set('results', results);
    });
  },
});

4. Two-Way Bindings: Ember started off at a time when two-way data binding was the standard in frontend frameworks, but as time went on it became clear, both from a performance standpoint, and from a code organization standpoint, that one-way data flow made the most sense. Ember components can still currently modify values bound in the parent class's template, but this behavior tends to be buggy and error prone.

These, along with many other small paper cuts along the way, led the core team to a rethink of the component API. Along the way, parts of that rethink were broken out into individual pieces that we've already covered in this series, such as <AngleBracket> syntax, and the infrastructure was put in place to rationalize Ember's component API internally so that an entirely new API could be added, side-by-side to the original. Components are foundational to an Ember app, usually containing by and large the most code in the app, so being able to upgrade one component at a time rather than through a massive rewrite was incredibly important.

Glimmer Components are the final result of all that hard work. They're lighter, simpler, more ergonomic, and address all of these issues and more.

Less is More

More than anything, Glimmer Components are a dramatic simplification of Ember's component API, which is now being referred to as Classic Components in the community. Classic Components have built up a lot of cruft over the years, including:

• 13 Standard lifecycle hooks, such as didInsertElement/willDestroyElement and didUpdate.
• 29 Event handlers, such as click, mouseEnter, and dragStart.
• 9 element/element customization properties, such as element and tagName.
• 21 standard framework functions, such as get/set, addObserver/removeObserver and toggleProperty.

By comparison, Glimmer Components have just 2 lifecycle hooks and 3 properties. They don't have any element or DOM based properties, hooks, or event handler functions, whose responsibilities have been passed on to element modifiers. This dramatically simplifies what you need to learn in order to start using the bread-and-butter class of Ember, allowing you to focus on productivity out of the box.

The other major differences include:

• Outer HTML Semantics
• Namespaced Arguments
• Unidirectional Dataflow
• Stateless Template-Only Components

And last, but certainly not least, the namesake of Glimmer Components - compatibility with Glimmer.js, the minimal component framework that complements Ember.

Lifecycle Hooks & Modifiers

As mentioned above, Glimmer Components have just two lifecycle hooks - the constructor function for setting up the component, and the willDestroy function for tearing it down. It also has just 3 properties: isDestroying, isDestroyed, and args (which we'll go over later on).

interface GlimmerComponent<T = object> {
  args: T;

  isDestroying: boolean;
  isDestroyed: boolean;

  constructor(owner: Opaque, args: T): void;
  willDestroy(): void;
}

You may be wondering how you can replace hooks like didInsertElement and didUpdateAttrs, or properties like this.element. After all, there were 13 hooks, and that has to cover a lot of functionality right? In actuality, our case studies showed that many of these hooks had significant overlap with each other, and that most of their functionality could either be replaced by getters and derived state, or by Modifiers. I discussed Modifiers in depth in my last post, but the gist is that they're the new primitive for DOM manipulation, and with Glimmer Components they'll be the only method for accessing the DOM.

Reducing the number of lifecycle hooks makes designing a component that much simpler. There's no longer debating about which hooks to use, the benefits and tradeoffs and timing differences between didRender and didReceiveAttrs, when to use willDestroyElement and didDestroyElement. Instead, as much business logic should be pushed into getters and tracked properties as possible, with modifiers being used for any advanced side-effecting DOM logic.

Outer HTML

In Glimmer Components, what you see in the template is what you get in the output. There is no wrapping element around the template - the template represents the "outer edge" of the component, instead of being just the "inside". This means that you don't have to use APIs like tagName, classNames, or attributeBindings to customize your template, ever. This component:

// app/templates/hello-button.js
import Component from '@ember/component';

export default Component.extend({
  tagName: 'button',
  classNames: ['btn'],
  attributeBindings: ['role'],
  role: 'button',
});

<!-- app/templates/components/hello-button.hbs -->
Hello, world!

Can be rewritten as:

<!-- app/templates/components/hello-button.hbs -->
<button class="btn" role="button">
  Hello, world!
</button>

This makes templates much easier to reason about, since the full definition is no longer split between two different files. You no longer have to remember that there is an outer element of some kind, and that it may-or-may-not-be-but-usually-is a div.

This does bring up the question of attribute reflection though. As we learned about in the post on Angle Bracket syntax, attributes that are added to a component when used with angle brackets will be reflected onto the main element:

<MyButton class="custom-btn" aria-labelledby="my-label"/>

With Classic Components, the main component is the wrapper element. In Glimmer Components, there is no clear main element - there could be multiple top level elements, or there could be no elements, just text. This is what the special ...attributes syntax is used for:

<!-- app/templates/components/hello-button.hbs -->
<button ...attributes class="btn" role="button">
  Hello, world!
</button>

This syntax allows you to choose which element(s) the attributes get applied to. It can be applied multiple times, or not at all, in which case using attributes on the component will throw an error. This allows us to see clearly where element attributes are getting applied, and also to control it more easily. You could, for instance, use it on a nested element instead of a top level one.

Another cool feature of this syntax is that the order it is applied in can be used to determine how it overrides attributes. Attributes that come before ...attributes will be overridden, but attributes that come after will not. For example, given these two possibilities:

<div data-foo="inner" ...attributes></div>
<div ...attributes data-foo="inner"></div>

With this invocation:

<Foo data-foo="outer" />

We would get this result:

<div data-foo="outer"></div>
<div data-foo="inner"></div>

This system is much more flexible overall, and means we can write easier to understand components with cleaner, more readable and self-explanatory templates!

Namespaced Arguments

Arguments in Glimmer Components are placed on the args property, instead of directly on component properties. This makes it much more clear what values are arguments that are passed to the component, and which are properties that the component uses itself internally. Revisiting our example from the introduction, this:

import Component from '@ember/component';

export default Component.extend({
  init() {
    this._super(...arguments);

    this.filter('').then((results) => {
      return this.set('results', results);
    });
  },
});

Becomes this:

import Component from '@glimmer/component';
import { tracked } from '@glimmer/tracking';

export default class FilterComponent extends Component {
  @tracked results;

  constructor() {
    super(...arguments);

    this.args.filter('').then((results) => {
      this.results = results;
    });
  }
}

And we can now clearly see that filter is an argument, and not some API function that came out of nowhere.

The args object is also immutable (though the arguments themselves are not). This enforces unidirectional dataflow, from parent components to child components, and prevents two-way data binding in general. It also means that when you see an argument, you know that it is a value passed down by the parent, and not something managed internally by the component. This distinction also helps with reasoning about component code.

Stateless Template-Only Components

Template-Only components are useful for extracting bits and pieces of functionality from other components quickly, without bringing along business logic. They keep things simpler by only having one file, and by keeping it focussed on presentation. However, with Classic Components they had two major issues:

1. There was no way to control the wrapping element, and oftentimes a class would have to be made just for that. Glimmer Components solve this with Outer HTML semantics, like we discussed above.
2. Even though Template-Only components didn't have any logic, with Classic Components they did have state. They needed an instance to hold their argument values, and it was possible, albeit somewhat difficult, to assign values to that instance and make them stateful using built-in helpers.

With Template-Only Glimmer Components, components are completely stateless. They have no backing instance at all, making them much faster, and they have no way to set or access any state except for their arguments, making them much easier to reason about in general.

Glimmer.js Compatibility

Glimmer.js has been the proving ground for a lot of the ideas that have made it into Ember over the past few years. It is a thin wrapper on top of the Glimmer VM, the rendering engine that both Glimmer.js and Ember share. While Ember is an all in solution for ambitious applications, Glimmer.js seeks to be a minimal, component-only framework that allows users to build up functionality as they need it. Eventually, the idea is that we'll be able to install our way to Ember, one package at a time.

Glimmer Components being cross-compatible means that Ember users can share code with a more minimal framework, that can better serve targeted use cases. In time, it'll mean that the ecosystem can work with both, and we'll be able to unify the two as we split apart the monolith one piece at a time.

Putting It All Together

Like always, I'd like to end on a high note. Here's an example from the popular ember-toggle addon, which provides a nice toggle component, the x-toggle-label component:

import { readOnly } from '@ember/object/computed';
import Component from '@ember/component';
import { computed } from '@ember/object';
import layout from './template';

export default Component.extend({
  layout,
  tagName: 'label',
  attributeBindings: ['for'],
  classNames: ['toggle-text', 'toggle-prefix'],
  classNameBindings: ['labelType'],
  for: readOnly('switchId'),
  isVisible: readOnly('show'),

  labelType: computed('type', function() {
    let type = this.get('type');

    return `${type}-label`;
  }),

  type: computed('value', {
    get() {
      return this.get('value') ? 'on' : 'off';
    }
  }),

  click(e) {
    e.stopPropagation();
    e.preventDefault();
    this.sendToggle(this.get('value'));
  }
});

{{#if hasBlock}}
  {{yield label}}
{{else}}
  {{label}}
{{/if}}

As you can see, the component code is really heavy, and most of that is customization of the element. Converting it over to a Glimmer component, along with all the other improvements from Octane, we have:

import Component from '@glimmer/component';
import { action } from '@ember/object';

export default class XToggleLabel extends Component {
  get type() {
    return this.args.value ? 'on' : 'off';
  }

  @action
  handleClick(e) {
    e.stopPropagation();
    e.preventDefault();
    this.args.sendToggle(this.args.value);
  }
}

<label
  for="{{@switchId}}"
  onclick={{this.handleClick}}

  class="
    toggle-text
    toggle-prefix
    {{this.type}}-label
    {{if @show 'is-visible' 'is-hidden'}}
  "
>
  {{#if hasBlock}}
    {{yield label}}
  {{else}}
    {{label}}
  {{/if}}
</label>

The class definition here is much smaller overall because we're able to strip out all of the logic for setting up the template, and we're able to put that where it really belongs: the template! This is much easier to read overall, since we don't have to jump back and forth between the template and the class definition to understand what the final HTML will look like. It's all in one place.

Conclusion

Glimmer Components are a long-overdue refinement of Ember's component system, and I'm really excited to see how they clean up our code. The design process for this API took a very long time, but in the end I think we came up with the best possible component API for Ember, and I think it'll serve us well for years to come. I'm also very excited to see how Glimmer.js evolves now that users will be able to write components for both!

This wraps up this blog series! I hope you've enjoyed these posts, and look forward to the preview launching in the coming weeks! Ember in 2019 is going to be a very different framework 😄

This year we're making an effort to move much of the survey process to the ember-learn/annual-community-survey GitHub repo. Please review the the list of 2019 survey questions this before February 17th and submit feedback as an issues on that repo.

201 Created began this annual survey of the Ember community in 2015. Over the past four years, data from the survey has helped us measure progress on issues as wide ranging as diversity and browser support. In 2017, free text responses were permitted for the first time, giving community participants a way to provide feedback to the project and project leadership a new way to hear their voices. As 201 Created steps away, it is time to promote the annual survey to an official project of the Ember Learning Team. Thank you 201 Created team (and interns who worked on this) for our first four years!

In 2019 the Ember community is more vibrant than ever, with over 3000 members having joined the official Discord server (join via the Ember Community page) that launched last September. We're eager to hear how people are using Ember and what they plan for the future.

Here are the key dates for this year's survey:

• 02/16 - 02/17 : Survey question feedback
• 02/18 - 03/08 : Survey open to the public for responses
• 03/19 : Results distributed in time for the EmberConf 2019 keynote!

Please join us in #dev-ember-learning on Discord if you have any questions or other feedback for this year's survey.

You can read last year's survey results here.

A big thank you to Code All Day for sponsoring Joseph Temple to work on this year's survey. You can learn more about Code All Day's Ember.js development and consulting services at their website codeallday.com.

The HTMLBars API is evolving and not 1.0.0 yet, so to ensure that templates are compiled compatibly with your Ember version we have updated the Ember build system to generate a ember-template-compiler.js file alongside every build of Ember. This template compiler can be used server-side for precompilation or in the browser to compile templates on the fly. If you do not need to compile templates at runtime (in the browser) the ember.debug.js or ember.prod.js file alone is sufficient. There is no need to include a runtime dependency. This is a departure from previous versions, where you would always include either handlebars.js or handlebars.runtime.js.

Most of the time you will use a third party library like ember-cli, ember-cli-htmlbars, or grunt-ember-templates to precompile templates, but this post will discuss how libraries like this should work internally.

Server Side Compilation

If possible, it is definitely a best practice to compile your templates server side. This is much faster due to less total size (you don't need the compiler on the client) and less work that the app needs to do.

Ember 1.0 through 1.9

In prior versions, you would typically use the ember-template-compiler NPM package that corresponded to your Ember version to precompile your templates. That might look something like the following:

var fs = require('fs');
var compiler = require('ember-template-compiler');
var input = fs.readFileSync('path/to/template.hbs', { encoding: 'utf8' });
var template = compiler.precompile(input, false);
var output = 'export default Ember.Handlebars.template(' + template + ');';

fs.writeFileSync('path/to/output.js', output, { encoding: 'utf8' });

You would also need to include handlebars.runtime.js in your final build

Ember 1.10+

With Ember 1.10, you will use the ember-template-compiler.js file that is paired with your Ember version. If you use our Bower repo or RubyGem, or download Ember from our builds site, there is a ember-template-compiler.js in the same path as ember.debug.js and ember.prod.js.

You can use this template compiler directly and without additional requirements. For example:

var fs = require('fs');
var compiler = require('./bower_components/ember/ember-template-compiler');
var input = fs.readFileSync('path/to/template.hbs', { encoding: 'utf8' });
var template = compiler.precompile(input, false);
var output = 'export default Ember.HTMLBars.template(' + template + ');';

fs.writeFileSync('path/to/output.js', output, { encoding: 'utf8' });

As you will notice, the new API for server-side compilation is nearly identical to that of prior versions. The main change is the usage of the local bower_components/ember/ember-template-compiler.js file as opposed to the NPM module.

Client Side Compilation

Generally speaking, you should avoid compiling templates on the client, but there are times that you cannot avoid this. Live demo apps like JSBin are one example.

Ember 1.0 through 1.9

In prior versions of Ember you would need to ensure that the full version of Handlebars.js was present to allow compiling of templates. Perhaps something like the following in your index.html:

<script src="assets/handlebars.js"></script>
<script src="assets/ember.prod.js"></script>

Ember 1.10+

With Ember 1.10, you will include the ember-template-compiler.js for your specific Ember version. Something like the following:

<script src="assets/ember-template-compiler.js"></script>
<script src="assets/ember.prod.js"></script>

If you include the ember.debug.js file instead of a production file the compiler is still required.

Template Compilation Build Tools

There are any number of build tool libraries that are intended to make the server side compilation of templates easier. Here are a few (please let us know of others):

• ember-cli-htmlbars - Can be used either as a standalone Broccoli plugin, or as an ember-cli addon.
• grunt-ember-templates - Works as a Grunt plugin. To precompile HTMLBars templates, you must supply specific parameters to your task definition as mentioned in this PR.
• mimosa-ember-htmbars - A plugin for the mimosa build tool.
• ember-rails - The Rails Asset Pipeline plugin supports HTMLBars templates.

That said, every quarter the Ember core team likes to meet face-to-face for a high-bandwidth, high-intensity discussion about the future of the framework. We focus on high priority issues, ways we can improve our process, and setting the long-term vision for Ember.

A week ago, the core team descended on beautiful Spicewood, Texas (about an hour outside of Austin) for two days of hand to hand combat technical discussion.

Below, in no particular order, are summaries of the topics we discussed. Nothing here should be considered final, and all decisions are subject to change as we receive community feedback.

Subteams

Ember includes everything you need to create a modern web application, from build tools to a lightning fast rendering engine to comprehensive documentation. Because of its scope, it can be difficult for any one core team member to keep everything in their head (except maybe Yehuda).

As we've taken on new initiatives, we've often bootstrapped ad hoc subteams to help carry out the day-to-day work. For example, Ember Data, Ember CLI and the documentation subteams all have their own set of committers who meet regularly to discuss their area of focus.

At the face-to-face, we discussed formalizing the subteams and granting them more autonomy. Primarily, this increased autonomy will be achieved through refinements to the RFC process, largely inspired by the Rust governance model.

To quote the Rust governance RFC:

The basic idea is to supplement the core team with several "subteams". Each subteam is focused on a specific area, e.g., language design or libraries. Most of the RFC review process will take place within the relevant subteam, scaling up our ability to make decisions while involving a larger group of people in that process. To ensure global coordination and a strong, coherent vision for the project as a whole, each subteam is led by a member of the core team.

Subteams are responsible for shepherding RFCs along, helping submitters identify open or unresolved issues. Once a subteam deems an RFC complete, it enters a week-long final comment period. This serves as a warning to community members that the time to get their feedback in is coming to a close. After the week is up, the subteam will make a decision about whether the RFC should be accepted or not.

For more information, see the Rust governance RFC, where the process and the motivation behind it is outlined in detail. We will have more information about the subteams soon.

RFC Improvements

In addition to the changes noted above about subteams managing the RFC process, we are also making several tweaks to the existing RFC format:

1. All RFCs must include Drawbacks and Alternatives sections. (N/A will no longer be accepted.)
2. We are introducing a new section to discuss naming and terminology.
3. We are introducing a new section that asks how the RFC changes the programming model, if at all. This is critical for ensuring the guides stay up-to-date with best practices.

More details on the RFC improvements will be posted soon.

Documentation

We had a wide-ranging discussion about documentation. Generally, documentation has been significantly improved but we always want to do more to make sure developers have a great experience.

We discussed several relatively easy-to-do improvements that would be high value:

1. Encourage more core team members to join in on the documentation subteam calls, particularly those shepherding new features that impact the programming model.
2. Suppress private classes from the API docs, which can feel overwhelming to new users.
3. Offer better cross-linking between API docs and guides.
4. Ensure that Google only indexes the latest version, so intrepid searchers do not end up on stale documents.

We also have some exciting improvements to the getting started experience being worked on.

Engines

As Ember adoption increases, one common question we get is: how can multiple teams work on an Ember app without stepping on each others' toes?

The answer to that question is engines. A little over a year ago, Yehuda and I submitted RFC #10: Engines, describing a way to break apart a large Ember app into several, smaller apps that can be merged together into a cohesive whole.

Engines have taken a while to get right, because they touch almost every part of Ember. Dan Gebhardt and Robert Jackson have been working tirelessly on this, and recently released the experimental ember-engines addon that you can begin using today.

The addon currently relies on monkey-patching several private Ember classes. Now that the addon is out, we plan to upstream these changes back into Ember itself. Our hope is to get the these building blocks into Ember (and stable) as fast as possible, so the addon will work with non-Canary releases. After that, we will continue to iterate on the design and user-facing API in the addon.

For more about engines, see the slides from Dan's talk at Boston Ember introducing the ember-engines addon.

Better App Componentization

Developers love Ember components because they help break up your UI into small pieces that you can reason about.

On the other end of the spectrum, engines allow you to break up monolithic apps into a smaller set of apps that you can develop individually, then compose together into one large app.

But what about medium-size apps? These apps may not have enough people working on them that they'd want to break it apart using engines, but they are starting to accumulate many UI components. Reasoning about which components are used where is getting difficult.

The answer to this problem is something that we've called the pods architecture. It allows you to organize your app by feature, rather than by type, so you can quickly see all of the pieces that bring a feature to life.

We have several significant improvements to pods coming soon, including the ability to scope UI components to a single pod. Stay tuned for more details.

Universal Event Dispatch

This is still a pie-in-the-sky idea, but we discussed whether it would be possible to create a universal event dispatch engine.

To understand what an event dispatch engine is, you should first understand the idea of event delegation.

The basic idea is this: as your app runs, many components will be added and removed from the DOM. Those components have event handlers: functions that get run when the user clicks on the component, for example.

Rather than setting up a listener for each component, then tearing it down when the component is removed, Ember installs a single listener for each possible event on the root document.

Then, when the user interacts with a component, we rely on the fact that the DOM event will eventually bubble up to the document, and thus and the event handler Ember has installed. Once there, we reverse-engineer which component the bubbled event originated from. Once we've found the component, we invoke its event handler.

This works well but there's one problem for people that embed multiple Ember apps on the same page: each Ember app installs its own set of event listeners. We can optimize startup performance for these cases by having a set of event listeners that each Ember app instance can share.

But it's not Ember that would benefit only. Other libraries like React use event delegation as well. We discussed whether it would be possible to create a dispatch engine that was low-level enough that all of the React, Ember, etc. apps running on a single page could share it, and only pay the cost of installing event listeners once.

We don't have anything concrete here yet but want to put together a plan and start socializing it with other library implementors. Even if we don't get their buy-in, at least we can improve the boot performance of multiple Ember apps on a single page.

Smoothing the 1.x to 2.0 Upgrade

The strength of Ember is in its community and in its ecosystem. We increase the vibrancy of both by doing everything in our power to smooth the upgrade process and ensure the vast majority of apps can make the transition to new versions of the framework.

The 1.13 to 2.0 transition was our first time managing a community migration across major version boundaries. We had a long discussion about what went right and what went wrong, and what we can learn as we begin to think about what an Ember 3.0 might look like.

More importantly, we discussed what factors are still keeping some apps on 1.12 and 1.13, and what we can do to address them.

Some teams may stick with a 1.x version that works for them; we won't be able to get everyone to upgrade to 2.x, at least right away. Rather, our goal is that anyone on 1.12 or 1.13 who wants to be on 2.x should have a way to get there.

One of the biggest issues we've heard reported is that, while the new Glimmer engine in 1.13 is much faster in some scenarios, there are several performance regressions in other scenarios.

Naturally, teams are hesistant to upgrade if their app is impacted by a performance regression. But if they cannot upgrade to 1.13, which contains the deprecation warnings needed to make a smooth transition to 2.x, how can they ever get there?

The answer is to use 1.12 for deploying to production, but switch to 1.13 temporarily while developing to get the list of deprecations to fix.

Unfortunately, 1.13 introduced several new public APIs to replace private APIs for things like registering Handlebars helpers. Despite being private, those APIs were nonetheless in use by apps and addons. This can make it difficult to switch between versions: 1.12 has private APIs for something 1.13 has public APIs for, but no version has both.

To remedy this situation, we're taking a two-pronged approach:

1. For commonly used private APIs that were removed in 1.13, we will backport their public API versions to a 1.12 patch release.
2. We will continue to investigate performance regressions in 1.13.

Note that many of the initial performance regressions have already been fixed in the 1.13.x series. We encourage teams that tested under early 1.13 releases to run their performance analysis again with the latest patch release.

Ideally, most teams should be able to move to 1.13 on the way to 2.0. If that's not possible, we'll at least make it possible for an app to switch seamlessly between 1.12 and 1.13. Core team member Erik Bryn has also committed to writing an upgrade guide based on his real-world experiences upgrading several large apps, and we look forward to seeing that.

Long-Term Support Release

Developers on the bleeding edge love the rhythm of Ember's six week release cycle. That cadence leads to a steady pace of new features, while also taking the pressure off contributors; they don't feel the need to rush features because there's always a new release on the horizon.

That said, we've heard from developers at more conservative organizations that the pace of new releases can feel overwhelming. Those developers are happy with the features they have, but are apprehensive about not upgrading because they don't want to be left behind.

To help those developers, we announced in the Ember 2.0 release blog post that we would be introducing Long-Term Support (LTS) releases. We are gearing up for our first LTS release and hammered out some more details at the face-to-face meeting. You should expect to see the first LTS release in the next few months.

For more details on the LTS release process, see RFC #56: Release Cycle Improvements.

Ember 3.0 Deprecations

One of the mistakes we made during the 2.0 transition was rushing last-minute deprecations into 1.13. We felt a sense of urgency, since not getting a deprecation in meant it couldn't be removed for at least another year, or whenever Ember 3.0 was released.

Unfortunately, this created a feeling of significant churn, and the list of deprecations to fix became overwhelming. For many apps, the promise that they could fix all of the deprecations in a single sprint rang hollow.

To make up for the 1.13 deprecation onslaught, we've held off introducing major new deprecations into any of the 2.x releases so far.

Enough time has now passed that we feel comfortable starting to think about introducing new deprecations. That said, we've learned several important lessons from Deprecationocalypse and we will do our best to avoid a repeat of the situation.

At the face-to-face, we agreed on the following policies to reduce pain for developers:

1. Now that we have a plan for major version releases and have lived through one such transition, we will start implementing deprecations earlier in the cycle rather than rushing them in at the last minute.
2. We will try to only introduce a handful of deprecations per release, so that no one release feels overwhelming and the upgrade cost can be paid over the entire major version cycle.
3. Deprecations will not be merged into master until a deprecation guide has been written.
4. Deprecation guides will be more holistic and include more than one example. Ideally, deprecation guides would contain code snippets from open source Ember apps and addons that show how to make the change in a real-world context.
5. We will collaborate with the docs team early on to ensure that deprecated features are not being used in the guides.

FastBoot

FastBoot development continues at a rapid pace and we hope to have a stable release soon.

As anyone who's attempted to do server-side rendering of client-side JavaScript knows, being able to render a component's HTML on the server is a critical but very small part of the overall story. While we've had server rendering of Handlebars templates working for the better part of a year, integrating server-side rendering into the application architecture and ecosystem takes a lot of work.

Our hope with FastBoot is that it's so easy to use, the majority of Ember users enable it. We don't want server-side rendering to be something you can kind of do with weeks and weeks of work; we want it to be as simple as installing an addon via npm. It's going to take the support of the entire community to do that.

Expect more updates from us about FastBoot soon, particularly about how you can start making sure your addons are FastBoot-compatible.

Performance

One topic that touched almost all of the other conversations was performance. We continue to make improved boot, rendering, and build performance our top priority.

In addition to creating a performance subteam, we are beginning the infrastructure work to allow Svelte Builds—builds of Ember that have all code related to deprecated features removed. This allows developers who have eliminated the deprecation warnings in their code to benefit from a significantly reduced file size.

We also have several on-going initiatives to improve the Glimmer rendering engine that we hope will start paying dividends soon.

Ember as a Stable Core

If there was one thing that became apparent to me at this meeting, it is that Ember has become a stable core on top of which developers can build amazing web applications—without fearing they will be left behind.

The key to Stability without Stagnation is the ability to experiment outside of the core framework. Because of the addon ecosystem, unified community and our strong shared conventions, new features can start off as addons that are free to boldly experiment. Once the experiments have been proven, they can be incorporated back into the mainstream developer experience.

The thinking behind the Extensible Web Manifesto has influenced us greatly. The key idea of the EWM is that browser vendors should focus on exposing the smallest set of raw capabilities—the DOM, geolocation, background workers, the camera, bytes and buffers—then let the open source community iterate on libraries and frameworks that make those raw capabilities easier to use for a broader audience.

While low-level API gives you maximum flexibility, it doesn't always make it pleasant to build large apps. However, these unpleasant building blocks have unlocked frameworks and libraries like jQuery, Ember, Angular and React.

By focusing first on raw capabilities before ease-of-use, you keep the scope constrained. You can ship features faster, and by exposing only the building blocks, you can let experimentation and competition in the ecosystem find an API that developers love—without breaking backwards compatibility.

The same thing is starting to happen in Ember. Two illustrative examples are FastBoot and Engines. With FastBoot, we made only the minimum set of changes needed to the core framework. Primarily, that was cleaning up application boot and introducing ApplicationInstance, and adding a low-level API for programmatically routing and rendering an app (the visit() API).

Despite the fact that FastBoot 1.0 has not yet shipped, because of their small scope, the low-level framework features needed to make it work are already in release versions of Ember. This means that FastBoot will work with any release of the framework that has the visit() API, starting with Ember 2.3.

And because the majority of FastBoot's developer-facing API lives in an addon, we can rapidly iterate separate from Ember's typical six week release cycle.

And, as described in the above Engines section, the ember-engines addon is taking a similar approach. We'll figure out the minimum set of changes needed to the core framework to make them work, then rapidly incorporate them into a stable release. The bulk of the code will live in a separate addon, making it easy to add or remove. And if someone doesn't like how engines work, they too will have access to the low-level building blocks that are needed to create a competitor.

None of this would be possible without a community and framework that rallies behind finding shared solutions as much as possible. Early adopters of Ember experienced significant churn as we were figuring out what the stable core was. Now we are reaping the benefits of that experimentation in a big way, as we can now build even higher on top of the solid foundation we've built together.

A common refrain in the JavaScript ecosystem is that opinionated software boxes you in, and that you're better off spending weeks picking the set of libraries that fit the particular needs of your application. But it has been our experience that building a strong community around a shared set of solutions leads to applications that are more maintainable over the long run, and don't leave you itching to throw away everything and rewrite it in a year or two.

As the set of things needed to build a modern web app grows—Service Workers, Web Workers, offline sync, push notifications, OS integration, server-side rendering, fast re-rendering, WebSockets, reliable deployment, CSS postprocessing, and animation, to name only a few—we think Ember will be better positioned than ever to help developers build amazing things. Soon, it will flat out not be feasible to do everything yourself.

Thank you for being a part of the Ember community. It's going to be a very exciting 2016.

We want to ensure that our process and thinking is totally transparent to the Ember.js community so we're going to start publishing meeting notes here.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats

Topics

Transparency

We've heard a few comments that people would like greater Core Team transparency. Since the weekly meetings are the only significant group communication that isn't public, we'll be posting notes from these meetings.

Resolutions:

• @trek publish core team meeting notes
• @trek post weekly reminders that the core team meeting occurs and invite people to contact individual core team members if they have issued they’d like raised.

HTMLBars

@wycats says it’s ready to hand off to someone else.

Resolutions:

• @krisselden will come a bit early to the face to face to get mind-dumped. @machty is already familiar with writing Handlebars runtime compatible template languages from his work on Emblem.js so can also help get this over the last few hurdles.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats

Topics

Build Tools

@wycats has been communicating with @jo_liss about using broccoli as the basis for a build tools package.

Ember Data

Ember data is now less of an ORM and more of a pluggable framework for assembling your own data communication layer for Ember.js applications (with some nice defaults for people's whose APIs follow common patterns). However, the interface – especially on the "normal form" of return values – isn't well documented so people aren't able to easily jump in, try it, and offer feedback.

Resolutions:

• @trek will start working on docs.
• @tomdale, @wycats will publish an ember data update blog post.

Query Params

Some debate about the correct location for defining and handling query parameters (controller vs route).

Resolutions:

• a smaller group will handle that discussion

Pods

During the face-to-face we floated the idea of organizing an application's files in a "pod" structure. Feedback has been positive, but we want to get more real world stories about the pros and cons of this structure.

Resolutions:

• @trek will reach out to people said they've built in this style.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @trek, @wagenet, @wycats

Go/No-Go for 1.4

It's that time in the beta release cycle where the core team gives a "go" or "no-go" vote to feature-flagged beta functionality.

query-params-new: no-go

• needs more people trying this
• doc/guides need to be updated.

with-controller: go

• make sure to add parentController immediately after merge (@kselden)

• address https://github.com/emberjs/ember.js/issues/4050 (@stefanpenner)

• ensure lookupFactory and creates with content

  {{#with foo controller=someController}}
  

ember-metal-with-proxy: go

• rename to Ember.run.bind and merge (@stefanpenner)

ember-metal-run-method: no-go

• @krisselden and @wycats are worried that this will be used inappropriately
• people should use .run at the root of a frame, not randomly throughout it

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats, @wifelette

Pending Go/No-Go

We received feedback that too many flagged features in canary were not getting enough discussion from the core team early in the release cycle.

This was delaying useful features making it into scheduled beta releases.

To tighten up the feedback loop, the core team will regularly review features on our canary builds and work with authors sooner to address concerns.

The current list of features on master but not enabled in the 1.4 family of beta builds can be found on this Github issue: https://github.com/emberjs/ember.js/issues/4052

The following features look good in their current incarnation and will likely receive a "go" vote:

• ember-testing-routing-helpers
• computed-read-only
• ember-metal-is-blank
• ember-eager-url-update

string-humanize and string-parameterize

There is a concern that this increases the surface area of API and the size of the framework without providing enough benefit that is unique to Ember.js. If the package manager ecosystem for browser JavaScript were more mature, these would clear cases for community contribution. String inflection is notoriously hard to get correct, especially with internationalization, and the common case is already handled by existing libraries. @trek even maintains one

Resolutions:

• Revert.

ember-handlebars-caps-lookup

A bare capitalized word in Handlebars should look up on current scope. {{CONSTANT}} and {{#each CONSTANT}} did global lookup mostly by side effect, this was not intended API, but we need to think through backwards compatibility issues for people who used this as part of their app design.

Some proposed ideas:

• try local lookup first
• try global lookup and issue a deprecation warning ("will be removed in 2.0")

Resolutions:

• Revert.
• @wycats will talk to the author about a revert and our preferred way forward for this behavior

ember-testing-triggerEvent-helper

Looks good but needs some revision:

• Needs mechanism for customizing event with additional data (i.e. which key is being pressed)
• Possibly have keyEvent event helper use triggerEvent internally

Resolutions:

• @ebryn will provide feedback on the PR

composable-computed-properties

Possibly still needs some work (there some unhandled todos)? Will be a "go" when these are addressed.

Resolutions:

• @trek will ask about the status of remaining todos

query-params-new

@wycats and @machty chatted about some last minute issues. This PR should be good soon. The removal of query prefixing should provide a nicer query string (the [] prefixing only happens if two controllers in same hierarchy have the same parameter name).

Resolutions:

• @machty will keep chugging along

ember-routing-loading-error-substates

Currently state/loading and state_loading both reify into StateLoading under the current resolver. Custom resolvers (like those in EmberAppKit) don't have this issue, but the global resolver does. We can't make this work until modularization is done.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

This week's core team meeting was rescheduled from Friday, January 24 to Monday, January 27 due to the Google outage that affected Google Hangouts.

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats

Topics

Issues Discussion:

The core team discussed the following Github Issues

• ember-routing-auto-location #3725.

  resolution:

  • assign @stefanpenner
  • should be good for the next beta.
  • needs someone to audit + try for real
  • is it ok if we have /#/foo and /foo in the wild? How does this affect SEO
  • document that backend support is needed and that your app will not have canonical URLs (i.e. every URL will have two versions in the wild: /#/foo and /foo)

• Bound Action Lookup #3936

  We added default fall back to allow a static string action name if a property isn't found, but it is possible that this will break things if you have a property AND an action named the same thing. This could be enabled similar to the ember-routing-drop-deprecated-action-style feature which will need to have a null value in features.json (which will allow folks to opt-in via EmberENV) until 2.0 if we are concerned with the SemVer implications.

  resolution: Ensure docs are updated so unquoted style is not used before shipping.

• ember-views-bindable-attributes #4170

  We like the idea generally but there are doubts having a a separate API, we should explore pushing it into a single API. Differences between this and attributeBindings are too subtle, we should not fragment

  This has been converted to a Mixin that is only used for Ember.TextField and Ember.TextArea currently. It allows for us to use all HTML5 attributes, but only actually setup observers/bindings for the ones that are present at the first render. This has a significant developer happiness impact, and we hope that we can get comfortable with it enough to enable in 1.5 beta series.

  resolution: @ebryn will talk to Robert

• Replace module with something else. #3838

  This is due to an issue under Node (since module is a reserved word). It ultimately doesn't matter what we decide on, but if we want the test suite to run under Node (for ember-runtime and ember-metal specifically, but also possibly ember-data) we need to use something that isn't a keyword.

  resolution: QUnit.module, but check for prior art. (@stefanpenner)

• Update Backburner (and Docs). #4120

  Contains potentially breaking change to throttle to default to running immediately (from ebryn/backburner.js#55 ).

  resolution: it was a bug, breaking it is fine.

• https://github.com/emberjs/ember.js/issues/3256

  resolution: bindingPaths to globals should be canned, so we won't support additional features built on on this behavior.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @wifelette, @wycats

Go/No-Go Feature Listing

• ember-routing-named-substates #3655

  @krisselden: likes the feature a lot (we should do it) @wycats: naming with globals is totally unsolvable. @machty: If FooLoading is ambiguous, we should warn that global mode is not supported for this feature @tomdale: we need a separate task force for thinking about module mode only features.

  resolution: Tom and Stef will review

• ember-handlebars-caps-lookup #3218

  resolution: check local first, warn and fallback to global seems like a good strategy

• ember-testing-simple-setup #3785

  resolution: Tom and Stef will review

• version api docs

  Often asked for. We should work with community, see if robert can own, and help delegate.

• query-params-new #4008

  misleading bug reports, but eager loader of controllers was the original pain point that kept this a "No go"

• composable-computed-properties #3696

  @wycats: aliased to short words in the examples, should be documented to match this? @ebryn:: new CP work may have issues, @wycats and @ebryn and David should talk.

  resolution: @ebryn will talk to David about blocking

• ember-routing-auto-location #3725

  resolution: Alex will make sure docs are good, then this becomes a "Go"

• ember-routing-bound-action-name #3936

  resolution: "Go" but we need an intermediate release issuing deprecation warnings, a future release will have break. This future release may contain some helpful warning, and the release notes will contain this info.

PR's/Issues To Review

• FEATURE ember-routing-consistent-resources

  Adds .index, .loading, and .error sub-routes for resources created even if no callback was provided.

  For example:

  App.Router.map(function() {
    this.resource("home");
  });
  

  Prior to this feature home.index route would not be created for the above resource. It is possible that the current situation was intentional.

  resolution: "No go"

• FEATURE ember-routing-inherits-parent-model

  App.Router.map(function() {
    this.resource('thing', { path: '/thing/:thing_id' }, function() {
      this.route('edit');
    });
  });
  

  If you wanted the Edit route's model to be the Thing loaded in the Thing route, you have to define a model hook on the Edit route to call this.modelFor('thing'), which is pretty repetitive and cumbersome.

  For this.route() routes that don't specify a model hook, the model for that route should default to the parent resource's model.

  This should be totally backwards compatible unless someone is doing something extremely strange.

  resolution: make this work only for routes, not resources for now. The interim solution.

• FEATURE ember-document-title

  Examples from @machty:

  • Single static title
  • Basic example of titleToken + title
  • Basic example of titleToken + title (reversed)
  • titleToken bound to controller/model properties
  • Overriding doc.title format in deeper routes

  resolution: pause, until @wycats and @tomdale can review tokens behavior. Its getting close and we want this.

• Convert Checkbox and Select to Components.

  resolution: "No go", this is a breaking change.

• Use QUnit.module instead of module.

  Let's confirm what to use as a prefix. Is QUnit.module OK, or should we create our own (perhaps EmberDev.module or something)?

  resolution: "Go"

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats

Topics

Features pending 'Go' decision.

The core team reviewed the following pull requests for inclusion in the 1.5.x beta series:

• ember-routing-named-substates #3655

  Tom and Stef still need to discuss how to handle module mode + new semantics next week.

  Resolution: Tom and Stef will discuss this week. No, for real this time.

• ember-handlebars-caps-lookup #3218

  Needs follow up from @xtian.

  Resolution: Ping @xtian

• ember-testing-simple-setup #3785

  Tom and Stef still need to review.

  Resolution: Tom and Stef will review.

• query-params-new #4008

  There are still some decisions around lazy loading code and query params.

  resolution: Alex and Stef will discuss lazy stuff.

• composable-computed-properties #3696

  resolution: stefan will work with David monday or tuesday to get this in. A "Go" then.

• ember-routing-inherits-parent-model #4246

  resolution: "Go", already in beta

• ember-handlebars-log-primitives #4252

  resolution: "Go"

• ember-document-title #3689

  Examples from @machty of current behavior:

  • Single static title
  • Basic example of titleToken + title
  • Basic example of titleToken + title (reversed)
  • titleToken bound to controller/model properties
  • Overriding doc.title format in deeper routes

  resolution: Still "No go", tokenization needs some polish related to nested resources

Features currently slated for 1.5.0 beta series

The core team reviewed the following pull requests for already enabled in canary builds for inclusion in the 1.5.x beta series. All still have a "Go" vote.

• ember-testing-routing-helpers #3711
• ember-testing-triggerEvent-helper #3792
• computed-read-only #3879
• ember-metal-is-blank #4049
• ember-eager-url-update #4122
• ember-routing-auto-location #3725
• ember-routing-bound-action-name #3936

Feature Process

We reviewed the a proposed change to the process for adding features. This isn't a major departure, but an iteration on what we are currently doing:

Process:

• Feature is submitted via PR.
  • Confirm features.json and FEATURES.md have entries.
  • That PR is reviewed, and generally confirmed to be a solid idea
  • PR is merged so makes it into a canary build
• Feature is added to Features Pending 'Go' Decision Issue
• New Issue is created with a check-list of items to be completed prior to receiving a 'Go' vote.
  • This should include at least the following entries:
    • Security Audit
    • Core Team Sign-off
  • Should be given a special tag (to make it easy to find later)
  • Should be assigned to the original feature contributor
  • This can serve as the proper place to ask for changes/fixes to the feature
  • Once the feature has gotten a 'Go' decision
    • The issue is closed.
    • It is added to features.json with a value of true.

resolution: "Go" and CONTRIBUTOR.md should be update accordingly.

Security Process

Currently we do security releases all the way back to 1.0.x. At some point that will be untenable (not yet though). There was some discussions about Long Term Support release structures: every odd/even becomes LTS, or even 5th release, or we only support previous three revisions (which would be all releases in the last 4.5 months with our current release model).

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats

Topics

ES6ifying core

Last month we completed the migration of ember-data to the ES6 module syntax. This lets us use clearer dependency declarations, stay clear of module syntax battles (you can export to whichever module format best conforms to your deeply held beliefs on JavaScript modules), and continues our pattern of bringing future JavaScript features to you today.

Work has started on the porting Ember.js to ES6 module syntax as well!.

Thanks to @thomasABoyt and @Square for work on the ES6 Module Transpiler, @fivetanley for converting ember-data, and @rwjblue for starting the process in Ember.js core.

Resolution: @rwjblue hands off the grunt work to @trek and @fivetanley so he's not overextended. @rwjblue says "you're good to start with ember-metal"

Ghost.js Admin

The fine folks at Ghost have hit a complexity ceiling with their current admin interface (a mixed client/server rendering solution with Backbone tossed in). They're discussing various solutions for a rewrite and Ember.js is among the options.

The core team discussed devoting some time to helping the Ghost team evaluate Ember.js as a possible solution. If you'd like to help or weigh in – especially if you're a current Ghost user or developer – please go comment: https://github.com/TryGhost/Ghost/issues/2144

Resolution: @trek will devote some time to helping the Ghost team. Possibly on a small spike.

Getting rid of old Stack Overflow questions/answers

We frequently get comments about older Stack Overflow questions and answers. Answers related to pre-release versions of Ember have a high likelihood of no longer being valid. Stack Overflow has a policy of not deleting questions related to older versions of software, but we think pre-release software is exceptional for a few reasons:

• pre-release software is often undocumented and unfinished, leading people to use Stack Overflow as a place to find answers at higher rates than for relased software
• people should not continue using pre-release software for long after an official release, so there is little value in having those answers around for future reference
• good questions might have wildly different answers before and after a 1.0 release but there's no way for a new user to know
• some questions themselves will no longer make sense as features are added or removed

An example of a question that should be deleted is this question related to Ember.Button. Ember.Button has long been deprecated and removed. The pattern for actions has changed significantly since that question was asked in December 2011. However, someone wondering how to handle buttons in Ember who searches for "ember and buttons stackoverflow" will get this question as a top result.

We're working to do some form of cleanup for questions like these. The first step is to compile a list of ones the community feels should be removed. With that list we'll apply some form of cleanup.

Resolution: @trek will get this list created somehow.

Features pending 'Go' decision.

The core team reviewed the following pull requests for future inclusion in the 1.6.x beta series:

• ember-routing-named-substates #3655

  @stefanpenner and @tomdale still need to discuss this.

  Resolution: @stefanpenner and @tomdale will speak.

• ember-testing-simple-setup #3785

  @stefanpenner and @tomdale still need to discuss this.

  Resolution: @stefanpenner and @tomdale will speak.

• query-params-new #4008

  @wycats and @machty continued discussion on lazy loading. Goal is to get it in during this beta cycle

  Resolution: @machty & @stefanpenner have a man-date to discuss lazy loading.

• composable-computed-properties #3696

  Still blocked on computed.literal

  Resolution: The original behavior wasn't intended. Changing now might be breaking change in some people's apps. We'll put it through a multi-cycle deprecation/removal path.

• ember-metal-computed-empty-array #4219

  Resolution: "Go". Upgrade to a Bugfix is it doesn't require a flag.

• ember-runtime-test-friendly-promises #4176

  Resolution: Peter will try in Skylight's tests and offer feedback

• ember-routing-inherits-parent-model #4246

  Resolution: Already conceptually a "Go". @machty will make nestable routes in the next week or so so this can be merged.

• BUGFIX beta Still update HTML5 history if the previous state was null

  iframes may set null values onto the HTML5 history state. The router will sometimes pick up the null value as current instead of the window's nominal state (which was set by Ember). The old logic required that a prior state be present, this logic allows a null state to be replaced or pushed over.

  Resolution: A clear "Go".

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @tomdale, @trek, @wagenet, @wycats

Topics

Old Stack Overflow questions

Last week we started the process of cleaning up old questions on Stack Overflow by collecting a list of questions and evaluating whether the question still made sense and, if so, whether selected answer was still the best available answer.

Initially we were using Stack Overflow's existing tagging functionality to collect this list but the Stack Overflow admins suggested that we find some other way. They didn't have any suggestions for using Stack Overflow to speed this process, so we created a list of all Ember.js questions to date with some minimal semantics around correctness.

If you're looking to help, please check out this document and give us feedback on some older Stack Overflow questions and answers!

ES6ifying core

This work continues here.

Features pending 'Go' decision.

The core team reviewed the following pull requests for future inclusion in the 1.6.x beta series:

• ember-testing-simple-setup #3785

  While its heart is in the right place, we think this is a bandaid on top of a testing infrastructure that needs a bottoms-up rethink.

  While we don't think the implementation needs to change dramatically, per se, someone needs to sit down and write a proposal for how the testing infrastructure should work.

  Resolution: Revert.

• query-params-new #4008

  @stefanpenner and @machty met in person on Tuesday to discuss an API that supported lazy loading of routes and will continue the conversation as these changes are made.

  Resolution: Not ready yet. We don’t want to serialize default values into the URL. False params should be represented as “=false”, rather than merely being absent from URL (which was ambiguous). So, this example JSBin from the docs is wrong: http://emberjs.jsbin.com/ucanam/2708.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @stefanpenner, @tomdale, @trek, @wycats

Topics

Hello, Ghost

A few weeks ago @jacob4u2 reached out over twitter to let us know the popular Node.js-based blogging platform Ghost was looking to reinvent their admin interface and were discussing various browser JavaScript libraries. The ensuing discussion is a great read.

This week the Ghost team announced they'd be rebuilding in Ember.js. We're super geeked to see Ghost join Balanced, TravisCI, Discourse, and the rest of the great community of open source projects adopting Ember.js.

Thanks to everyone who chimed in on the discussion and the Ember.js community members who helped with advice, feedback, and tender loving care on Github, Twitter, and IRC.

Resolution:

• @ebryn is going to do a video walkthrough of how he'd organize Ghost's admin interface
• @rwjblue and @trek have been in #Ghost IRC and will keep that up
• We'll ask the Ghost to team to draw our attention to PRs/Issues related to the migration

ES6ifying core

The migration of ember-metal, ember-runtime, and ember-debug to ES6-style modules is completed but not yet merged. In making large changes we're always especially cautious about accidentally breaking existing features, reducing performance, or increasing file size. Modularizing doesn't appear to have an effect on build speed or runtime performance, but did lead to a 5k min/gzip size increase that we're not happy with.

We're currently tracking down the various causes of size bloat and doing some cleanup to bring build size back to its previous size.

Resolution:

• @rwjblue is going to do some cleanup and work with the transpiler maintainers to add some output improvements.

Features pending 'Go' decision.

The core team reviewed the following pull requests for future inclusion in the 1.6.x beta series:

• ember-routing-named-substates #3655 Still blocked on module vs global object lookup form, which causes naming collisions.

  Resolution: will remain on canary until we've moved to modules and have a modular loader.

• ember-handlebars-caps-lookup #3218 The original author has become unresponsive.

  Resolution: approach @mixonic to take over.

• ember-routing-add-model-option #4293

  Resolution: It’s a go.

PR's/Issues To Review

• Do not setup listeners for destroyed Arrays

  Sometimes due to timing in test suites, an array that has become destroyed (most likely due to a call to DS.Store#unloadAll in Ember Data) is assigned to an array proxy. This leads to an intermittent problem where an assertion is raised due to a destroyed array-like object no longer being considered an array by Ember.

  The root cause is that Ember.isArray relies on Ember.Array.detect to determine "Array-ness", and when Ember.Array.detect is used on a destroyed object false is returned because the meta information has been removed.

  Resolution: this error is the symptom, needs further investigation. @stefanpenner will investigate, and consult @krisselden and @ebryn

• Resolve target issue on actions and with-controller

  Fixes issues where actions inside a {{with controller='foo'}} block bypass the FooController's action handling.

  Resolution: @ebryn, @krisselden, @wycats should review. Future changes that touch scope manipulation must be reviewed by @ebryn, @krisselden, @wycats.

• The each helper checks that the metamorph tags have the same parent.

  In some cases, the browser may add or fix tags, which change the parentage of metamorph tags. This problem happens frequently when the developer doesn't not include the TBODY tag inside a table for example. This prevents the framework to update or clean the underlying DOM elements.

  This helps to detect the issue described in #4273.

  Resolution: @trek will offer some feedback on wording. This should be a total non-issue once we can emit HTMLBars.

• Expose asObject to Ember.Handlebars.precompile

  Resolution: This belongs in handlebars, so reopen on Handlebars repo

• FEATURE ember-handlebars-radio-buttons Implement radio buttons

  Resolution: hold off and talk about this at the next face to face.

• Deprecate edge-case get and normalizeTuple behavior before fixes

  PR #3852 changes some edge case behavior for get and normalizeTuple. Ahead of those changes, this commit introduces deprecation notices.

  Resolution:

  • Deprecate get for local paths on global contexts, only if they return data.
  • Deprecate normalizeTuple calls that return a non-global context and a simple global path.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @stefanpenner, @tomdale, @trek, @wycats

Topics

Features pending 'Go' decision. Tracking Issue

• ember-routing-add-model-option #4293 Resolution: Go

PR's/Issues To Review

• Query Params New - Sticky Params?

  Should query paramters remain on route change? When do we want it? All the time? How do we disable it? Proposals thus far:

  /r?sort=asc ← keep
  /r/ios?sort=hot ← keep? “model specific state”
  /r/gonewild ← keep? “model specific state”
  /r/foo?name=’something related to foo’
  

  or

  /blog/somepost?comments=true
  then navigate to
  /blog/someOtherPost?comments=true ← keep?
  /blog/someOtherPostthen ← don’t keep?
  // then navigate to
  /blog/somepost?comments=true ← kept from before? kept from last route? gone from last route?
  

  Possible opt-out via helper?

  {{link-to ‘Home’ ‘home’ (query-params sort=null)}}
  

  some options:

  • Preserve stickiness as the default, but add a (query-params-reset) subexpression helper (in addition to query-params) that can take 0 or more args and will reset any query params not explicitly specified in the helper invocation. The puts the stickiness in the control of the caller (the link-to helper).

  • Add a sticky option to the route query params config hash, which defaults to true. If set to false, any links into that route will reset (unless QP values are explicitly provided in the link-to helper), but any links to that route from within that route hierarchy will be sticky, which effectively makes it so that if you leave a route and come back into it via a link-to, the QPs specified as sticky:false will be reset. Keep in mind though that leaving a route and pressing the back button will be "sticky" since the previous values on the controller will be restored based on the previous URL.

    Example JSBin: http://emberjs.jsbin.com/ucanam/4102

    Resolution: Sticky by default, with appropriate escape valves to opt out per route change

• ES6 ember-metal, ember-runtime, ember-debug

  Work is currently being done (by @thomasaboyt amongst others) on the es6-module-transpiler to remove the need for intermediate variables. This will both reduce filesize (less total output), and enable cycles support (since it is evaluated lazily).

  We believe there is more file size savings to be had in the way the view layer, and would like to be able to progress in the ES6 effort. Currently rebasing upon any change to ember-metal, ember-runtime, and ember-debug (rare) is difficult. I believe that we cannot maintain the long running pull-request branch for much longer and would like time to process/deal-with any issues that crop up from the swap (missing global exports for example) before branching the next beta series (2 weeks).

  RESOLUTION: Merge (pending specific issues that have already been noted), but before shipping another globals build we should deal with the file size issue. We have ~7 weeks until the 1.6 release.

• The each helper checks that the metamorph tags have the same parent.

  This was generally approved in the 2014-02-28 meeting once some verbiage tweaks were made. @trek's suggested changes have been made, this is ready to go.

  Resolution: merge.

• FEATURE Ember.computed.instance

  A computed property that creates a new instance of source. source can be any Class constructor, object, array, or a path to a local property. Optionally you can specify the initial value(s), if only initialValue is given and if it is a string, it is treated as a local path.

  Resolution: make it an add on that’s not core. CPM.

• Deprecate edge-case get and normalizeTuple behavior before fixes

  PR #3852 changes some edge case behavior for get and normalizeTuple. Ahead of those changes, this commit introduces deprecation notices.

  • Deprecate get for local paths on global contexts, only if they return data.
  • Deprecate normalizeTuple calls that return a non-global contenxt and a simple global path.

• Deprecate global access from templates

  PR by @mixonic:

  Replaces #4358. These deprecations are narrow in scope, and only impact {{Global}} and {{#each Global}}. They do not deprecate any other global access in templates. Deprecating all global access from templates would a) need to be done helper-by-helper or b) would impact the get and binding code at a lower level.

  @xtian I'm rewritten your first commit but preserved it here.

  @ebryn yo.

• Container throws if injection registered for already instantiated type

  Prior to this commit, the container would happily allow you to register an injection for a type that had already been instantiated. This led to confusing-to-debug situations where an injection is registered but a container-created instance doesn't have the injection applied.

  Comment from @stefanpenner

  As you know I'm all for this change, but it may cause people some inconvenience. I personally consider it a bugfix, but i would like @tomdale or @wycats's +1/-1.

  Resolution: @stefanpenner & @wycats will chat.

• Expose asObject to Ember.Handlebars.precompile

  Comment from @rwjblue:

  This was mentioned in the core team meeting on 2014-02-28. It was mentioned that this should be changed upstream (in Handlebars itself), but as I reviewed (to let you know where that change would be needed) I realized that this PR is only exposing the functionality that already exists within Handlebars, but is not exposed to Ember.Handlebars.precompile. As such, I think that we should likely re-evaluate the prior decision.

  Resolution. Ship it. This passes from Handlebars to Ember.Handlebars

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @stefanpenner, @tomdale, @trek, @wycats

Topics

Go/No-Go Feature Listing

• query-params-new #4008 Still a no-go, while @machty and @wycats hash out the specifics

PR's/Issues To Review

• canSetInnerHTML: IE cannot set innerHTML on several tags

  IE doesn't support .innerHTML = on COL, COLGROUP, FRAMESET, HTML, STYLE, TABLE, TBODY, TFOOT, THEAD, TITLE, or TR.

  Resolution: definitely a bug, but this will be fixed with HTMLbars so we'd rather wait for that to land instead of fixing now

• Overwrite observers and listeners in Ember.CoreObject.create().

  Modifies mixin inclusion code in makeCtor to remove any observers/listeners setup on the property or key prior to adding the property.

  My concern is the modification in this particular code path.

  Resolution: this used to be how create worked, but we moved away with this for performance reasons. .extend is intended for design-time use, not runtime: use .extend().create() or .createWithMixins()

• Use injected test helpers instead of local functions.

  Since we are injecting the application with our helpers (into the App.testHelpers hash), we should be using that helper and not calling the function in local scope.

  As the tests show, this allows a user to override the internal helpers with a tailored version for their scenarios.

  Resolution: make it possible but still private API. Assert on attempting to override built-in helpers.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @stefanpenner, @trek, @wycats, @wifelette

Topics

PRs/Issues To Review

We reviewed the following PRs and Issues:

• query-params-new #4008

  Nothing new here. We're working very hard to get this correct the first time and have something to demo at EmberConf.

• Move instanceMetas into object's meta #4559

  InstanceMetas for objects' ReduceComputedPropertys are stored on the RCP instance (ie. on the descriptor) as this._instanceMetas[key] where key = guidOfTheObject + ':' + propertyName (see http://git.io/t9bKxA). The RCP can't know when the object is garbage collected, hence the _instanceMetas array grows unbounded.

  Resolution: if David Hamilton +1’s, we merge as a bugfix.

• Allow multiple arguments to be passed to EmberStringUtils.fmt() #4518

  This allows you to use Ember.String.fmt with the same multi-arg signature as String#fmt:

  Ember.String.fmt('%@ %@', 'John', 'Doe')
  // vs
  Ember.String.fmt(['%@ %@', 'John', 'Doe'])
  

  Resolution: Seems reasonable. Merge

• Deprecate App.Store in favor of App.ApplicationStore #1808

  This makes the application level store lookup much closer to the reset of our conventions (ala App.ApplicationAdapter and App.ApplicationSerializer).

  This change also allows specifying a custom store when using non-global resolver (i.e. EAK/ember-cli). Previously, we were only looking for a property Store hung off of the application instance. Now you can have a module named (in the case of stock EAK setup): app/stores/application or app/application/store.js (pods structure).

  A deprecation warning was added, and the prior technique still works so this is not a breaking change (although I believe that we should remove before the prior lookup prior to 1.0).

  Resolution: Seems reasonable. Merge

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @wagenet, @tomdale

Topics

PR's/Issues To Review

• BUGFIX beta Allow setting of undefined value to a content property

  Fixes setting of undefined value to a content property.

  Still, checking obj[keyName] === value in these lines is bypassed in two cases

  • If the setter value is undefined
  • If the setter property lies inside the proxied content

  Using get(obj, keyName) might resolve. But was quite nervous to do that as it may involve some additional function calls

  +1 by @stefanpenner, but he requests @krisselden to review.

  Resolution:

  Seems good, but @krisselden will review in further detail. Will attempt to have this update in 1.6.0-beta.2.

• BUGFIX beta Ensure context is unchanged when using keywords with itemController.

  Prior to this change the following code would bind this in the template block to the itemController's content (even though the keyword form of {{each}} is used).

  This change sets the child view's _context property to the current context when using the keyword form of {{each}}, and a couple of confirming tests to demonstrate using itemController specified in either the ArrayController or the template directly.

  Failing JSBin | Passing JSBin

  Fixes #4634.

  Resolution

  The intent of the each foo in bar syntax is specifically to preserve the current context. However, using each foo in bar syntax along with an itemController has always changed the inner templates context. This change seems good, but all context related changes require a bit of additional review. @krisselden to review further and +1/-1.

• BUGFIX beta {{view}} helper no longer uses Ember.View global, instead uses container view:default

  During the ES6-ify process @rwjblue left a comment mentioning that the {{view}} helper needs to not look up Ember.View globally. This PR fixes this by looking up view:default from the container (which Ember.View is registered at, by default).

  Resolution

  Looking up view:default in the container is definitely more appropriate than hard-coding to Ember.View.

  Merged.

• BUGFIX beta Add better debugging for DefaultResolver.

  Adds nice log entries if your application was created with LOG_RESOLVER set.

  Example log entries:

  [ ] route:application ..........................................  App.ApplicationRoute
  [✓] route:index ................................................  App.IndexRoute
  [ ] controller:application .....................................  App.ApplicationController

Fixes #4654.

Example JSBin (look at console)

Resolution

This adds good insight into exactly what the resolver is doing and what you need to implement to add custom behavior. In the future, a better API needs to be created to enable these logging options (hanging a bunch of properties off of the application instance is sub-optimal).

Merged (will be in 1.6.0-beta.2).

• FEATURE ember-handlebars-radio-buttons Implement radio buttons

  This updates #1235 to extend component, adds handlebar helpers, updates tests and documentation. I think a lot of people would be pleased to see radio buttons in the core and I see a lot of developers at my company have a hard time with radio buttons when they first get started with Ember, so I think this would be a great addition to the core.

  Resolution

  We would prefer for this to live as an addon for a while to allow the community to test (and influence) the API.

• Transitioning to a globbing route does not work

  I think it's a corner case, so I don't know if this should work, or if you would fix that. Anyway, in my application, I'm defining a notFound route, hit when the user plays with the url and gives something wrong. I also want redirect to this route when the user try to access an unexisting record (ie the backend answer a 404). So I tried to define an error handler in the ApplicationRoute, and transitionTo('notFound'). Unfortunately it does not work. Though if I remove the globbing path, then it works for the redirection, but not when entering unknown url.

  I made a jsbin reproducing it: here

  Resolution

  It is possible to transition to a globbing route, but like any target route with a dynamic segment, you need to provide a object / param, which in this case can be a string of the path you want to use for that globbed segment:

  this.transitionTo('yargle', "MY/COOL/URL");

  JSBin

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @trek, @stefanpenner, @wagenet, @wycats

Topics

Build Tools Redux Progresss

When Ember.js took its first tentative steps into the world there existed no ecosystem of build tools for ambitious applications in the browser. Instead, we needed to build these tools from scratch.

The build tools story is significantly improved from those days! We're fortunate enough to have several competing systems, all JavaScript based, that help streamline this workflow.

Work is in progress to unify our builds and better declare and manage our external dependencies.

PR's/Issues To Review

• ember-routing-linkto-target-attribute #4718

  Resolution: Good to merge into Canary, but not a "Go" yet.

• ember-routing-will-change-hooks #4760

  Resolution: Good to merge into Canary, but not a "Go" yet.

• Fix view keyword in component block

  Fixes #3520 by setting the concreteView of the virtual view created to yield inside a component block.

  Resolution: Don't merge. Not the real fix.

• Cannot use the property name states in views _states

  Resolution: Fix by making states into _states. States is considered private API, so this should not be a breaking change.

• Async Testing Helpers

  1.4 contained bug fixes in the async test helpers that broke plugins relying on the broken behavior (e.g. the third party httpRespond helper)

  Currently, async is not granular enough, so it's not possible to have test helpers that assert while async is working (which httpRespond would need).

  Testing Async helpers need some love. In the past when parts of the ecosystem have needed help we've suggested teams of motivated and capable individuals to investigate and improve our process. Past successful examples of this include the Ember Inspector and the build tools team. We probably need someone to take point on really making the test experience in Ember as great as the rest of the framework.

  Resolution: Assemble a Testing Task Force.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @trek, @stefanpenner, @wagenet, @tomdale

Where have all the minutes gone, long time passing?

Many people have reached out on twitter wondering where the meeting minutes for May have gone. We'd like to apologize: many of us were traveling, attending conferences, and/or handling cross-state moves during May. Meetings have still been taking place, topics discussed, and advanced thought leadership generated, but attendance and note taking have been sporadic.

Ember 1.6/1.7.beta Delayed

We've been delaying the release of Ember 1.6 and the start of the 1.7.beta branch for a few weeks to address outstanding issues that have been reported and to ensure certain features make it into the 1.7.beta cycle.

There are two main concerns:

Module Performance Regression

Despite what the anti-framework crowd might think, Ember.js was written from the start to be composed of many smaller, single purpose modules. Some of these are pulled in from external repositories and some are contained inside the Ember.js repository itself.

Modularity was part of the Ember.js story even when there wasn't a great way to distribute or consume modules for the browser. Today, the landscape is much improved with an official module specification for ES6 and tooling to transpile from this format to the several competing community formats until the browsers gain native support.

A month ago, we completed our migration to the ES6 module format and Square's ES6 module transpiler, transpiling to AMD style modules.

Unfortunately, even with an extremely minimal loader, the number of module load calls adds up: An AMD build of Ember.js accesses the loader ~ 1300 times.

On desktop the performance change is negligible, but on lower power mobile devices can cause a ~300ms addition to load time over previous builds of Ember.js.

Thankfully, the ES6 module transpiler is being augmented to address this concern and we should be able to output a build that does not require a loader for Ember.js internals. Everyone should be sure to thank Brian Donovan and Square for their amazing work on bringing ES6 modules to us today.

Query Parameters

When we released 1.0 we pledged to follow Semantic Versioning and not break public-facing API until 2.0. Because of this, we're hesitant to release extensions to Ember.js's public API until we feel confident supporting it for the foreseeable future. We've taken several stabs at adding query parameters to our router. People have been very happy with the latest incarnation available on canary builds, but there have been a few edge cases we wanted to address. The last of these (providing a hook for overriding parameter resets on route exit) is about to land and we should hopefully include query parameters in the first 1.7.beta release.

If you're thinking "pft, how hard is it to tack a ? to the end of a URL?", there's a great EmberConf presentation about the road to discovering what exactly query parameters are trying to express in a long running, stateful application.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@krisselden, @machty, @rwjblue, @trek, @stefanpenner

Query parameters

This has been enabled by default in beta and nightly builds. Check out Query Parameters Guide for usage details.

Keeping the train moving

In the last meeting we discussed why the release of 1.6 and 1.7.beta was delayed. In this meeting we resolved to not delay releases, because we hope to include a specific feature.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@krisselden, @machty, @rwjblue, @trek, @stefanpenner, @wagenet, @tomdale, @wycats

Features pending 'Go' decisions

• ember-routing-consistent-resources

  This PR adds .index, .loading, and .error sub-routes for resources created even if no callback was provided so this.resource('foo') and this.resource('foo', function(){}) behave identically.

  Resolution: 'Go'.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @rwjblue, @trek, @stefanpenner, @wagenet, @tomdale, @wycats

1.6 and 1.7.beta

We're cutting these today and publishing.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @rwjblue, @trek, @stefanpenner, @wagenet, @tomdale, @wycats

Path to Core

Members of the community who have a sustained and significant contribution to Ember.js are invited to join the core team and help us guide the framework's future direction. Members we'd like to add are put on the "path to core" and given greater autonomy for a trial period before being officially invited.

Contributors on path to core are given commit access to the Ember.js repositories and attend our weekly core team meetings and periodic face to face meetings.

Today we're happy to announce that two Ember.js contributors are on the path to core: Matthew Beale (who most of you will know as @mixonic) and Martin Muñoz (@_mmun). Matthew and Martin have both been pushing hard on htmlbars, the underlying library that will power Ember.js's rewritten view layer.

Features Pending Go/No-Go

• ember-metal-is-present

  Resolution: this is excellent addon material. Revert.

• event-dispatcher-can-disable-event-manager

  Resolution: event dispatcher is being deprecated, but we'll have hooks for libraries like (Hammer.js)[http://hammerjs.github.io/] to integrate with. Revert.

• [ember-routing-linkto-target-attribute]

  Resolution: This is a Go.

Issues for Discussion

• Fix {{#with view.foo as bar}} #5115

  This is a bug. Merged.

• Fix usage of document.body.contains

  This is not required in metal-views, so the problem should go away. The suggested polyfill with feature flag for 1.7 OK until that time.

• Force remove required attribute for IE8

  Scumbag IE. This is merged

• Actions should be looked up via Ember.get

  :-1: as is, need to re-work and add a 're-bubble' phase that checks actionMissing good idea, but seems like it may require a lot of work.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@krisselden, @machty, @mixonic @_mmun, @rwjblue, @trek, @stefanpenner, @wagenet, @wycats

Face to Face July 2014

Last week the core team (and those on path to core) met in New York City for our periodic face to face meeting. Tom and Yehuda will be posting notes from that meeting in the coming weeks. Thank you to our friends at Pivotal Labs for hosting us in their awesome new office.

Built With Ember

A few months ago we began tracking some of the ambitious apps made with Ember.js. The folks at Blimp have turned that document into a curated list of awesome Ember.js applications. Check it out.

ember-cli website

ember-cli, our ES6 module-based build tool has a new site. Give it a browse

Modularizing Ember.js's Repository

We've started moving more external dependencies out of the Ember.js repository and have begun work to turn some infrequently used parts of the framework into their own libraries. These will still be built into the 1.x series of releases, but will not come bundled by default when we have the next major versions release.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@krisselden, @mixonic @_mmun, @trek, @stefanpenner, @wagenet, @tomdale, @wycats

Revamp the Getting Started Guide

We're starting work to revamp our Getting Started Guide. TodoMVC is too small of an app to demonstrate enough topics. We were holding off in hopes that there would be further progress on the successor to TodoMVC but this project has stalled.

We're investigating building a Github Issues viewer. Our goals are to better highlight areas where Ember really shines compared to other frameworks: Deeply nested view and data hierarchies, url-driven applications, intuitive query paramater behaviors.

Deprecating global view lookup from templates

As we move towards a world where ES6 syntax and modules become viable we continue to deprecate some "old style" globals lookup. The following uses will all trigger deprecation warnings:

{{view "App.SomeThing"}}
{{view Oh.ThisToo}}
{{#collection itemViewClass="Some.Wow"}}
{{#collection itemViewClass=Not.Yet}}
{{#each itemView="Ugh.Why"}}
{{#each itemView=Something.Something}}
{{view Ember.Select value=whut}}

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @mixonic @_mmun, @rwjblue, @trek, @stefanpenner, @wagenet, @tomdale, @wycats

Explore using Lodash

We reviewed a PR that replaces Ember builtin array extensions internals with Lodash.

Assuming no performance regressions, we're in favor.

Guides and API versioned and subdomained

Currently the Guides and API are not versioned, which increasingly leads to pain around new feature documentation. The plan is to beging publishing guides and API to a subdomains and version them:

• http://guides.emberjs.com/ (defaults to latest)
• http://guides.emberjs.com/1.8
• http://api.ember.js.com/ (defaults to latest)
• http://api.ember.js.com/1.8

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!

Attendees

@ebryn, @krisselden, @machty, @mixonic @_mmun, @rwjblue, @trek, @stefanpenner, @wagenet, @tomdale,

HTMLBars

Most of this weeks discussion focused on our largest ongoing project: HTMLBars. We're hoping HTMLBars is on track to make it into the 1.9 or 1.10 beta series.

The biggest outstanding issues are general cleanup, fixing behavior around parts of the DOM where a browser will "helpfully" insert "missing" tags (like auto-insertion of tbody into a table), and Internet Explorer bugs and performance

Day 16

For day 16 of our Countdown to The New Year we want to highlight and addon that truly brings the entire Ember community from all locales together: ember-intl!

What It Does

The ember-intl addon is probably one of the most popular addons used in Ember apps today. As the go-to solution for bringing internationalisation to our application, it allows us to manage translations, date, time, number and currency formats in more than 150 languages!

Why I Like It

The rich ember-intl service API and many useful template helpers help us to add new locales to our apps continually as our product's user base grows globally.

For those of us who have lots of languages to support in their application, ember-intl even allows us to load translations asynchronously - making sure that the size of the bundle that determines initial page load time stays small and neat!

Using ember-intl we can build Ember apps that are accessible beyond language barriers - making it more fun to share our app with friends all around the world!

Check out ember-intl on Ember Observer! If you are a fan of multi-locale apps and you're using internationalisation addons yourself, let us know in the comments which ones are your favorite and the most fun to use!

Day 10

Let's talk about ember-a11y-testing.

What It Does

The ember-a11y-testing addon is a wrapper around Deque Labs' axe-core accessibility(a11y) testing engine that helps you identify accessibility issues in your Ember app & provides useful information on how to solve them.

Why I Like It

Like many of you out there, I too developed webapps without realizing the impact that accessible apps can have on users. In fact, I started learning about a11y problems through this addon when I added it to a few apps that I was working on when this addon got released back in 2015.

While there's more to building accessible apps than automated tools (like this addon) can help with, it does help ensure that common a11y violations are captured before they can make their way to users.

The best part about this addon is that it lets you conditionally turn off parts or the entire violation report so that you don't have to feel overwhelmed when you add this to an existing app. In the teams I've worked with, we usually add an environment variable to control that setting so that we can work on addressing those violations whenever we can & run a variation of the nightly test run on CI with the flag enabled to check if the violation count hasn't increased since the previous run.

This addon is Octane-ready. Give it a try today & begin your a11y journey with it.

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 9

Until recently, converting Ember templates to use Angle Bracket invocation was a tiresome and manual task. With the latest version of ember-angle-brackets-codemod, you get a smarter, more complete codemod to change your templates in a flash!

What It Does

Before Angle Bracket invocation, nearly every template construct in Ember was invoked using Handlebars {{doubleCurly}} syntax. This made differentiating between components, helpers, and plain values incredibly difficult. Angle Brackets alleviate most of this ambiguity. But what if you wanted to change every double curly component invocation to Angle Brackets? That task could take forever (especially if you cant reliably tell the difference between everything in your templates)! The Angle Bracket Codemod eases the transition in a few steps:

1. It visits a URL of your app that is supplied as a command line argument
2. A small bit of code is injected into the context of the app.
3. The code identifies the app's components and their properties, as well as all the helpers. This includes those in addons!
4. Given all this information, the codemod quickly changes all the apps templates preserving most of the space and indentation.

Here is an example of typical conversion:

Before

{{site-header user=this.user class=(if this.user.isAdmin "admin")}}

{{#super-select selected=this.user.country as |s|}}
  {{#each this.availableCountries as |country|}}
    {{#s.option value=country}}{{country.name}}{{/s.option}}
  {{/each}}
{{/super-select}}

{{ui/button text="Click me"}}

After

<SiteHeader @user={{this.user}} class={{if this.user.isAdmin "admin"}} />
<SuperSelect @selected={{this.user.country}} as |s|>
  {{#each this.availableCountries as |country|}}
    <s.option @value={{country}}>
      {{country.name}}
    </s.option>
  {{/each}}
</SuperSelect>

<Ui::Button @text="Click me" />

Additionally, the codemod has a number of options that can be configured. The codemod can be adjusted to skip certain helpers, avoid changing built-in components {{link-to}}, {{input}} and {{textarea}}, or skipping files for conversion altogether.

Why I Like It

Codemods are the best, especially if they are smart! They save a significant amount of time and they are typically better than manual intervention. Until a few months ago, running this codemod and the changes it made were entirely based on a set of heuristics. The codemod was good but it often made mistakes, requiring an exhaustive amount of human input. Today the codemod can intelligently convert templates to Angle Bracket invocation with exceptional precision, often with few to no errors. This allows teams to opt-in to the future in an instant instead of wasting precious cycles.

Do you use this codemod? Or one like it? We'd love to hear about Ember codemods that bring you joy!

Day 7

According to Wikipedia's History of Animation-

The Roman poet and philosopher Lucretius (c. 99 BCE – c. 55 BCE) wrote in his poem De rerum natura a few lines that come close to the basic principles of animation: "…when the first image perishes and a second is then produced in another position, the former seems to have altered its pose. Of course this must be supposed to take place very swiftly: so great is their velocity, so great the store of particles in any single moment of sensation, to enable the supply to come up."

Today, we write such poems in code, using ember-animated.

What It Does

ember install ember-animated is an invitation for creativity. This addon provides animation primitives and some built-in transitions that help bring interfaces to life! You can animate across route changes, content can flow smoothly when new data arrives, and web interactions can compete with the kinds of interfaces that are usually only seen in native applications.

Why I Like It

I feel like animation helps an app make the leap from beautiful and useful to delightful.

My favorite thing about it is that I do not need to wrap my animation targets in any other elements. This has major benefits for styling and writing semantic, valid HTML. The out-of-the-box motions are helpful, and I also appreciate that I can write my own animations to fit unusual use cases.

This addon is Octane ready, although its documentation needs some Octane code examples added in. Check out the Issues to help out!

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 6

Once upon a time, if Ember developers wanted to use a regular npm package, they needed to jump through some hoops, but ember-auto-import makes it a breeze!

What It Does

The ember-auto-import addon provides a zero-config way to use npm packages in your Ember app, and even lazy-load them.

Why I Like It

One of my wishes for the web is that we can make it easier for new people to learn, participate, and build. Whenever I see this trend happening in Ember, it makes me happy.

I love this addon because it eliminates the need for a beginner (and experienced developer) to understand the differences between AMD and CJS modules, and how they get into the app tree. They don't need to read about how to configure their build. They don't need to know how Ember's build pipeline differs from other build tools. They import what they need, and it works. That's awesome.

I think back to earlier in my career, when I was reliant on other people to make addons that wrapped popular libraries, or I used ember-browserify, which had some drawbacks. Thanks to ember-auto-import, it is a joy to use new libraries directly and even contribute features or bugfixes upstream. I also imagine that it has saved a ton of time across the Ember community, since developers do not need to write and maintain as many wrapper addons.

This addon is Octane-ready!

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 23

For the 23rd edition of Countdown to The New Year we're going to take a look at two great design library addons, ember-bootstrap and ember-paper

Ember Bootstrap - What It Does

The ember-bootstrap addon is for using the Bootstrap design library in Ember applications. This addon provides a native Ember component library for some of the more commonly used Bootstrap components.

The ember-bootstrap addon can help you can integrate Bootstrap into your application quickly, and in an idiomatic Ember manner.

There are many related Ember addons that integrate with Ember Bootstrap to provide additional features on top of Ember Bootstrap, such as form validation and changesets.

Ember Bootstrap - Why I Like It

If you're looking to add Bootstrap to an Ember application, ember-bootstrap makes doing so incredibly straight-foward.

The ember-bootstrap addon's clean API's and native Ember components also provide an ergonomic way to use Bootstrap in your Ember application, and all without using Bootstrap's JavaScript.

Writing forms or modals with these components is a very enjoyable experience and has streamlined the code in several of my projects.

Also, recent versions of ember-bootstrap have added additional support for improving accessibility by using ember-focus-trap to implement focus trap for modals and keyboard navigation of dropdowns. ember-bootstrap has even added ember a11y tests to the addon's test suite!

It gets better, too- ember-bootstrap is Octane ready and has refactored it's own components internally to use native classes and angle bracket syntax.

The ember-bootstrap addon has excellent documentation, which you can read up on here to learn more about how to use the addon.

Ember Paper - What It Does

If you're looking for a solution to add Google's Material design library to an Ember application you can use ember-paper to do so! ember-paper aims to encapsulate everything possible in Material in Ember components.

The ember-paper addon provides an extensive library of components, from buttons and sliders to selects and modal dialogs.

All of ember-paper's components are written in a modular and elegant Ember way.

The ember-paper addon is also extensible and its component coverage is widened by a set of addons that can be used in combination with ember-paper to extend the library's reach (a notable example includes a modal manager).

Ember Paper - Why I Like It

Sometimes you really need an Ember focused solution for Material design and ember-paper provides a super easy-to-use and well built set of Ember components to get you up and running right away.

I've used ember-paper in at least one project my experience was a very smooth one. Components are written with adopted Ember design patterns in mind and they are built to fit into your work flow.

The component API's provide thoughtful touches and I've been able to build out an entire UI without knowing much about Material design because of them.

You can write most components in block-form so it's effortless to wrap what you need with the solutions that ember-paper provides.

Octane support is something that is slated for the future, but is not yet complete as of today.

In keeping with many widely used Ember addons, ember-paper provides a great documentation site that covers the usage and API's for all of its components. You can read up on the details here.

Do you use these addons? Or any like them? We'd love to hear about Ember addons that bring you joy!

Day 28

For the 28th edition of Countdown to The New Year we're going to take a look at ember-changeset.

What It Does

Managing data associated with forms can sometimes be unwieldy. As a result, we have borrowed concepts from the Elixir community to give you the ability to prevent mutating the underlying object until the last possible moment when you have decided to apply the changes and the data is valid. This functional approach to validations has proved to be quite useful.

This addon works in conjunction with ember-changeset-validations to provide you with out of the box validations to validate the format of a certain input, ensure passwords pass a minimum security threshold or even let you build your own custom validator!

Why I Like It

Recently I rewrote ember-changeset to fix long outstanding bugs, support Octane patterns and utilize @tracked. As a result, not only can you validate and apply changes to top level keys (person), nested keys such as person.firstName may also be used. In addition, at the same time @pzuraq's blog post Do You Need EmberObject? came out, we removed EmberObject, giving you a simpler base class to work with. The base functionality has been extracted to validated-changeset for use outside of Ember applications as well! Currently this addon is still in v3 beta. We plan to exit the beta period and do a proper 3.0.0 release in the near future for apps supporting ember-source >= 3.13. .

Ember has further memorialized itself with the OOP community. As a result, a functional approach to mutating state is a good tool to have in your toolbelt!

Do you use ember-changeset or something similar? We'd love to hear about Ember addons you love for DecEmber in the comments below!

Day 2

Today we are going to look at one of our community's most popular addons- ember-cli-mirage.

What It Does

The ember-cli-mirage addon is a client-side server to help you build, test, and demo your Ember app. It helps developers be more productive by providing ways to generate fake data, allowing front-end engineers to spend more time focusing on the UI.

Why I Like It

As I was informally polling the community about their favorite Ember addons, ember-cli-mirage came up A LOT. For good reason, too. It's well-supported by the addon maintainers, there's a dedicated documentation site, and there's support on the Ember Community Discord server in the #ec-mirage channel.

"It’s a part of the ecosystem I dearly miss when I work with other frameworks."

As an extra bonus, EmberMap has generously made their "Mirage Tips and Tricks" video series free to everyone (usually for subscribers only!) for December. Be sure to check it out!

Do you use this addon? Or one like it? We'd love to hear about the Ember addons that bring you joy!

Day 8

ember-cli-sass is an addon that I always install when I work on side projects. It's that amazing / critical / \<add your hype word of choice here>!

In all seriousness, let me tell you why I love Sass and why I encourage you to try out ember-cli-sass today.

What It Does

ember-cli-sass uses Sass to preprocess stylesheets in your Ember app (or addon). That's just a fancy way of saying you will have an easier time expressing how you want to style your app.

The addon also supports common, advanced use cases for Ember projects:

• Source maps by default in development
• Support for outputPaths configuration
• Ability to specify includePaths
• Ability to edit Sass in Chrome Dev Tools

Why I Like It

There are two areas to examine here: (1) why I love Sass, and (2) why I love ember-cli-sass.

Why I Love Sass

Sass (Syntactically Awesome Style Sheets), which builds on top of CSS, provides features that help increase my productivity as designer and developer.

My most favorite feature is nesting, which lets me practice BEM (Block, Element, Modifier). BEM helps me think carefully about how I write components and architect my app. It helps me envision how different components will interact with each other and how I might avoid leaking style.

PS. Variables are awesome too!

Why I Love Ember CLI Sass

ember-cli-sass is a great example of zero-config. In a new Ember app, all you need to do is run ember install ember-cli-sass, then change the file name app/styles/app.css to app/styles/app.scss. You also get live reload with no additional work!

Because there will be developers who are learning Sass for their first time, I believe zero-config is a must-have. When I was in a coding bootcamp, I wanted to try out Sass or Less for a group project. We ended up with plain CSS because we had limited time and had more important things to do than figuring out how to install and configure either. Without access to nesting or variables (i.e. a convention), we didn't have an easy time dividing work and collaborating with one another.

Conclusion

I think Sass is a great tool to help you think about how you want to architect your app. ember-cli-sass helps you try out Sass today!

I also encourage you to try out other tools for styling and discover what's best for your project. This could mean looking at a different framework such as Tailwind, localizing styles using ember-css-modules or ember-component-css, and finding a linter for stylesheets. I think we have made a good progress in bridging design and development, and am looking forward to what the future holds next.

Do you use ember-cli-sass? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 24

Today we are going to take a look at writing apps in TypeScript - using ember-cli-typescript.

What It Does

The ember-cli-typescript addon sets up everything you need to start using TypeScript in your Ember apps and addons. This includes not only configuring Babel to handle TypeScript, but build-time type-checking, in-browser type error reporting, and a whole set of custom blueprints for generating TypeScript versions of everything from routes and controllers to services to components. ember-cli-typescript also helps addon authors write their addons in TypeScript by handling automatic precompilation and type definition generation when publishing.

Why I Like It

Static typing is a lifesaver, especially in ambitious apps with complex structures and many moving parts. It helps speed up development with rich autocompletion and by catching type errors right in your editor and during the build. It provides a saftey net when refactoring or upgrading that I, frankly, wouldn't want to develop without. And addons written in TypeScript are a joy to use because they ship with type definitions that help guarantee you are using them correctly.

I like ember-cli-typescript because it handles all of the Ember + TypeScript integration for you and provides a very good set of defaults. It has great documentation, not only on how to use ember-cli-typescript, but on how to use TypeScript effectively with Ember. And to top it off, an amazing communuty of strong typers has formed around ember-cli-typescript and many of these individuals can be found on the Ember Community Discord in #e-typescript ready to answer your Ember + TypeScript questions!

Do you use ember-cli-typescript? Or something else to use TypeScript (or another language) with Ember? We'd love to hear about Ember addons you love for DecEmber in the comments below!

Day 26

Let's highlight how you can update Ember your projects with ember-cli-update.

What It Does

Besides package updates like ember-source and ember-cli, there are more files that are updated when a new version of Ember releases. Tweaks to testem.js or .eslintrc.js may be missed if you're not tracking those files changes (via something like ember-new-output). ember-cli-update was created to update those kinds of files along with package.json changes for you. It can also run codemods against your newly installed versions.

A new feature is on its way where it can maintain any blueprint, not only the official Ember blueprint. The idea is that you can make one blueprint for your organization, and keep your projects up-to-date like ember-cli-update does today. You could also keep default blueprints that ship with addons (ember-cli-mirage, ember-cli-deploy, etc) up-to-date in the same way. RFC here.

Why I Like It

I maintain countless Ember apps and addons. Without this tool, I would have burnt out long ago!

Day 29

Before I took this assignment, I didn't know anything about ember-code-snippet. Now, I'm glad that I did. This addon surfaced in 2015, has received regular updates, and powers many of my favorite addons. (Can you guess how?)

What It Does

ember-code-snippet lets you render code snippets in your app (or addon). Quite handy if you want to create a technical blog or document your components.

It provides a helper called get-code-snippet so that (1) you can save code snippets in a dedicated folder and (2) create your own component to customize their look.

To illustrate the use, we'll consider a code snippet from the Ember.js Octane vs Classic Cheat Sheet:

// my-app-name/snippets/make-your-own-elementId.js

import Component from '@glimmer/component';
import { guidFor } from '@ember/object/internals';

export default class InputTextComponent extends Component {
  inputId = 'textInput-' + guidFor(this);
}

Why I Like It

ember-code-snippet is designed with composability in mind. It outputs just the right amount of useful data so that you can consume them to build more powerful things.

Starting version 3.0, you can decide what library to use for syntax highlighting. For example, you might like to try out Prism.js:

{{!-- my-app-name/app/components/code-snippet/template.hbs --}}

{{#let (get-code-snippet @fileName) as |snippet|}}
  <CodeBlock
    @code={{snippet.source}}
    @language={{snippet.language}}
  />
{{/let}}

Maybe you want Highlight.js instead:

{{!-- my-app-name/app/components/code-snippet/template.hbs --}}

{{#let (get-code-snippet @fileName) as |snippet|}}
  <pre {{did-insert this.highlightCode}}><code class="language-{{snippet.language}}">{{snippet.source}}</code></pre>
{{/let}}

No matter the styling approach, the invocation remains the same:

{{!-- my-app-name/templates/application.hbs --}}

<CodeSnippet
  @fileName="make-your-own-elementId.js"
/>

I think the fact that many top addons use ember-code-snippet for documentation is a testament to its well-designed API. You may not have realized this (I didn't until today) because each doc has a unique style:

• Ember Bootstrap
• Ember CLI Addon Docs
• Ember Concurrency
• Ember CP Validations
• Ember Power Select
• Liquid Fire
• and many more…

Do you use ember-code-snippet? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 18

Today we are going to look at the 11th most popular addon on Ember Observer: ember-composable-helpers.

What It Does

The ember-composable-helper addon provides composable helpers for Ember apps, which allows for more declarative templating.

Now, the first time I read that sentence, I thought, "huh what?" so I want to break it down a little more.

This addon provides helpers. Useful helpers (like filter-by, repeat, and group-by, to name a few. These helpers can be used together (imagine using group-by in conjunction with filter-by…go ahead, imagine it, I'll wait…).

The declarative bit means that we're telling our template what we want to do, succinctly; ember-composable-helpers tells our app how to do it, saving us time and increasing our productivity.

Why I Like It

I think this addon is the bee's knees. It allows me to write code in the way I wish I could always write code! I love being able to say "here's what I want done, please." I'd rather not have to think too much about the "how", especially not every.single.time. I write code. The team that worked on this addon is known for producing useful addons, too, and I trust their work. Once again, strong community conventions come through for the benefit of all!

Even better, the fantastic team at EmberMap has a video about this addon if you want to learn more!

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 5

Let's talk about ember-concurrency. The experience is part joy, part tragedy.

The joy comes from having elegant, straightforward solutions for things like debouncing. The tragedy is that I have to write this code myself when I am working in a non-Ember setting, but I suppose absence makes the heart grow fonder.

What It Does

The ember-concurrency addon helps you "write concise, robust, and beautiful asynchronous code." For example, think about what should happen if a user rapidly clicks a "submit" button. With this addon, there's a nice way to prevent 30 form submissions. Or, what if an API request takes a long time, and you want to be able to cancel it? Promises won't help you, but ember-concurrency tasks will.

Why I Like It

Without ember-concurrency, it would take a lot of effort to manage starting, interrupting, cancelling, restarting, debouncing, queueing, and checking the status of async operations. Yet in a complex, data-rich application, these things often emerge as necessities. It's a relief to have a concise and readable way of handling these behaviors.

Another thing I like about ember-concurrency is that when I read the documentation, it helps me to evaluate whether the code I have written can withstand deviations from the happy path - impatient users, slow API requests, and interrupted animations.

The joy it brings me is that it keeps my code tidy and resilient. I can spend more of my time working on interfaces and interactions, without littering my code with things like an array of promises and booleans to track their resolved states.

This addon is Octane-ready. For developers who are using Ember Octane or Native Classes, ember-concurrency-decorators provides decorator syntax for tasks, which isn't strictly necessary, but it looks nicer.

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 22

Today we are going to take a look at creating apps with style - using ember-css-modules.

What It Does

With the addon ember-css-modules, styling à la CSS Modules is only one ember install away. CSS Modules allow us to write styles which are scoped to particular parts of our application by default and allow style sharing by explicit opt-in mechanisms. The ember-css-modules addon helps us to co-locate css files next to our components, routes and controllers following Ember's file name conventions.

Why I Like It

Making the apps we are building look awesome can be really fun! But maintaining a growing CSS code base can also be really hard. CSS Modules are a great way to modularise our styles in a way that they apply locally to only the exact component or route we wrote them for by default. This helps us to add new stylish features to our code base with the confidence that the look&feel of other parts of our app is left unchanged. This confidence is helpful for us when editing, adding and deleting CSS even in large web applications.

Using ember-css-modules we can start leveraging CSS modules in our Ember app right away and even benefit from Ember's conventional approach for file arrangement: the co-located CSS files are quick to find right next to our routes and components and blend in nicely into the developer experience that Ember enthusiasts are familiar with.

Do you use ember-css-modules? Or another stylish addon? We'd love to hear about Ember addons you love for DecEmber in the comments below!

Day 30

On the 30th day of our Countdown to The New Year we want to feature an exciting Ember addon to make your test suite fun to work with: ember-exam!

Learn more about ember-exam on Ember Observer.

What It Does

ember-exam is an addon that allows to have more control over running your ember-qunit (Ember's default testing framework) and ember-mocha test suite. It extends from the default Ember CLI test command, allowing you run it as you would ember test.

Why I Like It

ember-exam allows us to run tests in parallel which can greatly reduce the overall run time of our test suite. Using the --random option of this addon, we are able to run tests in random order; this helps us to uncover interdependencies between test cases which would be hard to spot otherwise. And the exam:iterate option allows us to iterate over parts of our test suite repeatedly when tracking down brittle tests.

ember-exam is our side-kick for developing a fast, robust and reliable test suite - which makes our testing workflow in Ember more predictable, more relaxed and therefore also more fun! Check it out for yourself!

And if you already use this addon, we'd love to hear about it or similar addons that bring you joy in the comments section below!

Day 27

For the 27th edition of Countdown to The New Year we're going to take a look at ember-in-viewport.

What It Does

Does your app use scroll event listeners or getBoundingClientRect to determine if an element on your page is in the user's viewport? If so, you have come across the perfect addon for you to observe DOM elements!

Common use cases for ember-in-viewport include lazy loading images, infinite scrolling (see ember-infinity) and/or tracking advertisement impressions. This is a flexible and performant library to give your users the performance they need when visiting your site.

Recent additions have added our own {{in-viewport}} modifier, allowing you to "observe" elements in template only components! See the Modifiers section for more examples.

Why I Like It

ember-in-viewport supports browsers back to IE11 by using either IntersectionObserver or requestAnimationFrame (fallback case) to monitor the elements on your page. Compared to traditional methods of manually observing DOM elements, this addon encapsulates functionality in a much more performant manner. For example, IntersectionObserver happens off the main thread, giving you Observability without the cost. Moreover, by reusing instances of these JavaScript APIs across similar elements on your page, you are free to use this addon for as many elements on your page as you want!

If you are looking for a good example to use this addon with, we have included a somewhat robust, responsive, lazy loaded artwork component for your enjoyment!

Do you use ember-in-viewport or something similar? We'd love to hear about Ember addons you love for DecEmber in the comments below!

Day 17

In the 17th increment of Countdown to The New Year let's take a look at an exciting Ember addon to add maps to our apps: ember-leaflet!

Learn more about ember-leaflet on Ember Observer.

What It Does

With ember-leaflet we can create useful maps for our web applications. This addon helps us to integrate the functionality of Leaflet.js - an open-source JavaScript library for mobile-friendly, interactive maps - into our Ember app.

Why I Like It

Leaflet.js is already a great library built with simplicity, performance and usability in mind. The addon ember-leaflet makes the developer experience even better for us: we can build complex, multi-layered street maps directly in our templates using the useful layer components provided by the addon API. This makes creating interactive map experiences much more straightforward and much more fun!

Build your own map using ember-leaflet by checking out the project description on Ember Observer!

And if you are already a digital cartographer yourself, we'd love to hear about your experiences using ember-leaflet or other map addons in the comments section below!

Day 21

Today we are going to take a look at making maps in Ember with ember-mapbox-gl.

What It Does

Have you ever wondered how to make maps in Ember? No? Okay, but you should!

This post is about adding an interactive map to your Ember project. By the end of this post, you'll have a map of the location of your company's business (provided that it has some physical location in Cartesian space).

(Note: I'm not talking about these kinds of maps, although they're not totally unrelated).

Every time I need to solve a problem in Ember, I do a quick search through the Ember addon ecosystem. Yes, it's satisfying to solve the problem yourself, but it's smarter—and quicker—to use someone else's code. Shoulders of giants, people. Now, web mapping is a pretty complicated suite of technologies, so the temptation to reinvent that wheel isn't as strong as, say, building your own file uploader.

A cursory glance at the available mapping addons show up a few options:

• ember-mapbox-gl (Full disclosure: I'm a contributor, although kturney does most of the work!)
• ember-leaflet
• ember-google-maps

Am I missing any? Let me know. But I'm pretty confident these are the top mapping addons.

How do they work? They all have a one thing in common: declarative templating. Most of the mapping objects you see on screen are managed using template components and helper invocations:

<MapboxGl as |map|>
  <map.source
    @options=(hash type='geojson' data=(hash type='Point' coordinates=(array  -96.7969879, 32.7766642 ))) as |source|
  >
    <source.layer layer=(hash
      type='circle'
      paint=(hash
        circle-color='#007cbf'
        circle-radius=10)
      )
    >
  </map.source>
</MapboxGl>

This makes for a pretty nice experience, especially in terms of long-run maintainence because the visual aspects of your application correspond to a specific part of the template file.

(What would alternative be? I've seen some wild spaghetti monsters and they are not pleasant to deal with because they do not encapsulate lifecycle management).

I'm a little biased because I really only use ember-mapbox-gl. It's powered by WebGL. That means that the graphical output is powered by the things closer to the metal of the machine itself. Plus, mapbox-gl, the underlying library, is highly customizable. It might even be a little too customizable, and that's where ember-leaflet really shines: although it's SVG-based (read: not as fast), it provides more out-of-the-box abstractions at a higher level.

That said, for the sake of brevity, let's stick with ember-mapbox-gl. Once you become a mapping expert, you can make that call later.

Shut up and play the hits

Stop what you're doing right now, open the nearest Ember project, and type this into your terminal:

ember install ember-mapbox-gl

Great. It's installed. But here's the rub: you have to find a provider for the basemap itself, the underlying data showing streets, buildings, and points of interest. Because that data changes quite a lot, there's a lot of work that goes into maintaining it.

There are a few free and paid options out there, but for simplicity, let's use mapbox.com. Make an account there, and head over here to generate a public access token.

Open up your config/environment.js and add this:

'mapbox-gl': {
  accessToken: 'ACCESS TOKEN HERE',
  map: {
    style: 'mapbox://styles/mapbox/basic-v9',
    zoom: 13,
    center: [ -96.7969879, 32.7766642 ]
  }
},

You should swap out 'ACCESS TOKEN HERE' with the access token you generated on mapbox.com.

What are these other things? The map object here sets up the default state of the map when it loads. This means that when you create a map, it needs to know what to show, where to position the camera. This is overridable at template invocation time.

What is this style property? It's the reason we had to grab an API key from Mapbox: this points to the remote resource for loading all the basemap details you need to see for your users to orient themselves on the map. It tells your Mapbox map where to fetch all the roads and bridges and points of interest that fill a delightful, useful map.

Now, add this to one of your templates:

<MapboxGl as |map|>
  <map.source
    @options=(hash type='geojson' data=(hash type='Point' coordinates=(array  -96.7969879, 32.7766642 ))) as |source|
  >
    <source.layer layer=(hash
      type='circle'
      paint=(hash
        circle-color='#007cbf'
        circle-radius=10)
      )
    >
  </map.source>
</MapboxGl>

What is going on? Line by line:

<MapboxGl as |map|>

This instantiates a new map by creating new element in the DOM and binding the map instance to it.

<map.source
  @options=(hash type='geojson' data=(hash type='Point' coordinates=(array  -96.7969879, 32.7766642 ))) as |source|
>

This creates a mapbox-gl source, and passes options to it. What are those options? First, the type describes the kind of source that mapbox should use. What is a GeoJSON? It's a standard for representing geographic information in JSON. That explains the shape of the data property: a GeoJSON object specifies its own type. For our purposes, we're using a point:

For type "Point", the "coordinates" member is a single position.

That's a little far into the weeds, but it's worth mentioning because there actually is an underlying reason for these API choices.

Generally, you'll find that most of the components in ember-mapbox-gl correspond to the various mapbox-gl APIs. That means you can use the MapboxGL documentation site proper when using this addon

    <source.layer layer=(hash
      type='circle'
      paint=(hash
        circle-color='#007cbf'
        circle-radius=10)
      )
    >

Again, we're dealing with another area of the mapbox-gl API: the layer. Like GeoJSON, the shape of this object follows a styling specification. There are many ways to style a map layer.

One-by-one: source.layer invokes the addLayer method of mapbox-gl itself and passes some options. Those options—specifically, the layer property—adhere to the styling specification. Allowed options are type-specific, so there's no saying "this fill type should have a circle-radius of 1000". That doesn't make sense.

All together now

Here's a run-through of what we did:

1. Install the addon
2. Setup a Mapbox.com account and generate an API token
3. Add your configuration to your config/environment.js
4. Invoke your <MapboxGL> map and yield a block parameter
5. Add a <map.source> inside the map block scope.
6. Inside that block scope, add a <source.layer>

Why all this work? Because the addon is dealing with all the "gotchas" that come with lifecycle management. That means you can use these components as you would any other component:

{{#if this.someCondition}}
  <map.layer /> {{!-- show something !}}
{{/if}}

When the someCondition is truthy, it shows the layer. When it's falsey, it triggers the teardown methods inside mapbox-gl so things don't fall out of sync.

Much of ember-mapbox-gl is a bindings layer. It provides a declarative templating API for invoking parts of the mapbox-gl API proper. So, it's hands-off. But the price of customizability is having less of an opinion. As I mentioned earlier, that's where Ember Leaflet really shines, and I encourage you to look at that as well.

Note on map data providers

I'm a little disappointed by the dearth of free and open vector map data providers. That said, if you find that you would like to host your own map tile provider, check out OpenMapTiles. It's a free and open source server that hosts those tile URLs we were using at the beginning. My team uses it and have had no issues.

Thanks for reading! If you have any questions, please message me via the Ember Discord chat (Matt Gardner#6278). I'm more than happy to help!

Do you use this addons? Or any like them? We'd love to hear about Ember addons that bring you joy!

This is the third in our DecEmber series–"Countdown to The New Year: 31 Days of Ember Addons". We plan to highlight a new addon each day until the new year, and we hope you'll join us for the fun!

Today we are going to look at a rising star in our addon ecosystem- ember-modifier.

What It Does

The ember-modifier addon provides an API for authoring element modifiers in Ember. It mirrors Ember's helper API, and has forms for writing both simple functional modifiers and more complicated class modifiers.

A modifier can add customized, automatic behavior to a DOM element, such as tracking scroll position or adding new event listeners. After you write a modifier, you can use it in a template like this:

<div {{my-modifier}}>
  Some more content
</div>

Developers who have tried out the Octane preview might already be familiar with ember-render-modifiers, which provide some modifiers like {{did-insert}} out of the box. With ember-modifiers, you can go beyond the box to build whatever your app needs!

For an in-depth look at modifiers in Ember, check out pzuraq's blog post about modifiers in Ember Octane.

Why I Like It

I think this addon is a really great example of the Ember community coming together and gathering around a single solution that everyone can benefit from.

This addon was originally a few different addons- ember-oo-modifiers, ember-functional-modifiers, and ember-class-based-modifier. The authors came together and worked to create a single approach - once again, giving the community the gift of strong conventions that are so well-loved and known in Ember.

I especially loved Spencer Price's talk about modifiers at EmberCamp Chicago this year- Modifiers: the Good and the Camp. Check it out if you haven't seen it yet. It's an informative and entertaining talk!

Do you use this addon? Or one like it? We'd love to hear about the Ember addons that bring you joy!

Day 11

This addon ember-page-title provides a helper for changing the browser tab title of the page within your application.

What It Does

The ember-page-title addon is helpful for many reasons, but an important reason is that it is a WCAG success criteria (2.4.2) to provide a page title. A quick tip about page titles! The title of each Web page should:

• Identify the subject of the Web page
• Make sense when read out of context, for example by a screen reader or in a site map or list of search results
• Be short

Why I Like It

Thanks to ember-page-title, you can provide users with an HTML browser title tag so they know where they are within your single-page application (SPA).

How to use it:

1. Run ember install ember-page-title
2. Add {{head-layout}} to your application.hbs file
3. Include the title helper to each page's template. For example, if you had an "About" route, add {{title "About Us"}} to that template. This helper also gives you the ability to add custom separators, for example {{title "About" separator=">"}}. More information can be found at the Ember Page Title Docs Site.

This addon is Octane-ready!

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 14

Today's selection for '31 Days of Ember Addons' is ember-power-select.

What It Does

Ember Power Select provides a powerful select component, built from the ground up for Ember so that it works the way you expect an addon to work in Ember. Exceptionally well-documented, Ember Power Select allows you to create everything from a straightforward list of text items to an asynchronous search driven select which incorporates graphical elements in the list.

The addon's website includes a cookbook for more unusual requirements as well as a list of community provided addons which address functionality outside of the scope of Ember Power Select.

Why I Like It

I have grown to love using Ember Power Select while developing a CRUD-rich web app which benefits from many instances of select elements driven by asynchronous searches. I have made use of the cookbook to debounce those searches and so reduce the load on the server while maintaining a slick feel to the interface. The look of the resulting selects is fine just as they are, but the well-documented API has allowed me to tweak each use of the addon and to provide a better experience to the users.

Although some work has been done to support Octane it appears that as of today this isn't yet complete. If you are interested in helping out with this addon, check the repository to see what issues remain!

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 20

For the 20th edition of Countdown to The New Year we're going to take a look at ember-shepherd which allows you to add tours to your Ember app.

What It Does

The ember-shepherd addon provides an Ember wrapper for the site tour library Shepherd, which allows you to seamlessly configure your site tours with an Ember service.

It allows you to show new users around your app, introduce new features to existing users, or suggest a flow your users might follow to optimally use your app.

It is configurable to show modal overlays or not, and can be hooked up to your existing application flow to conditionally show steps or be controlled manually.

Why I Like It

Tours are an often overlooked feature of apps, and can be crucial to providing a good user experience. Without them, a user may feel lost in your app or do things in a way you did not intend.

The ember-shepherd addon makes adding these useful tours to your Ember app much easier than hand rolling them yourself. With the provided Ember service, you can add steps and interact with your tour in a familiar Ember way.

I really like providing these tours to users to make sure they can quickly get up to speed with my apps, rather than spending a lot of time getting lost in the app and having a less than optimal experience.

You can setup your own tours using ember-shepherd by following the docs here.

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 13

Today we're going to look at ember-simple-auth!

What It Does

The ember-simple-auth addon is a lightweight library that helps you implement authentication and authorization in your Ember applications. It takes care of maintaining a client side session and synchronizing it accross tabs and windows, so you don't have to worry about your user signing out in one tab and remaining signed in in others.

It comes with a set of authentication providers (OAuth, Device, Torri) and can be customized in case you need to support a different authentication mechanism. It also provides a session service and a series of mixins that will aid you in adding authorization information to your requests, defining which routes should be accessible only to signed in users, and controlling the user session.

Why I Like It

Adding authentication and authorization to an Ember application is one of those things that most developers will have to go through, at one time or another. Having a consistent way of doing so, where we don't have to implement the basics every time, is one of the advantages of having an ecosystem of addons. ember-simple-auth is a cool library that covers the most common authentication needs, while at the same time being customizable for specific cases. It's well maintained and has a nice documentation to walk you throughthe integration with your app.

Do you already use ember-simple-auth? Or is there any other addon you love? Let us know!

Day 1

To kick things off, we're going to look at ember-sortable.

What It Does

The ember-sortable addon provides sortable UI primitives for Ember apps- this is super useful in the sense that teams don't have to reinvent this very common pattern every time they need it for their own applications!

Why I Like It

While the ember-sortable addon has been around for some time now, providing a consistent way to add drag and drop functionality to an Ember app, it is the most recent additions that have made this addon especially worth paying attention to. Yicheng Gong, a software engineer at LinkedIn, noticed that the addon was missing accessibility support. He took on the work via the Adopted Ember Addons org, and updated the addon to add the missing features!

The addon now provides a keyboard-only way to sort a group of items-

• Activate the item using ENTER or SPACE
• move the item with the ARROW keys
• confirm the new sort order with ENTER or SPACE
• or cancel the action with the ESC key, and the sort order will be reverted.

I really like the way this existing addon was improved to make it more accessible, and am both encouraged and excited to see accessibility have an increased focus in the Ember community.

Do you use this addon? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 25

I'm not sure there is anyone who knows the ins and outs of Ember and its ecosystem quite as well as Robert Jackson, aka rwjblue. Today, we look at a useful addon he wrote to help make debugging a little simpler - ember-template-invocation-location.

What It Does

The ember-template-invocation-location addon will allow you to debug things such as the location in a template that a given helper, component, or modifier was invoked from; the invocation site of the thing that invoked that template, and so on up to the root most template (generally a route template). Since this is primarily done in development and test builds, it will not work in production by default.

The general goal of this addon is to enable significantly easier debugging. As a result of this, it is expected that the majority of usages of this will not want to modify the source component/helper/modifier but instead be able to gather this info while debugging in the devtools. When you look at the API reference for the addon, you will see that an ember-template-invocation-location module is provided for import, as well as a window._templateInvocationInfo global namespace that you can use in the middle of a debugging session.

Why I Like It

We don't always get to work in a tidy codebase, and sometimes it can be difficult to tell exactly where a helper or component came from. I like this addon because it is yet another way our community members (especially rwjblue) provide solutions to make the developer experience really great.

Do you have another debugging addon that you enjoy using? We'd love to hear about it!

Day 19

Today we are going to look at an addon that is part of every new Ember app. The ember-template-lint addon has many new features added recently, and is worth a close look!

What It Does

As you may guess from the addon title, ember-template-lint is a linter for your template files! It checks for mistakes and advises best practices for the markdown in your component and route templates. Because we work in JavaScript, there are different ways something could be done, but often there is an ideal solution that avoids problems down the line. This is where ember-template-lint shines. It will throw warnings and/or errors when you try to break one of these rules. It's extendable and customizable too, so you can get the right combination of rules for your project.

Why I Like It

The ember-template-lint addon isn't actually an Ember addon, in terms of its file structure (which is why it's not on Ember Observer) but it is an essential ingredient that helps provide accuracy, consistency and best practices in your application.

Recently, I have been contributing to it myself, adding in extra ways that will help Ember developers avoid accessibility pitfalls. Through that work, I have come to deeply appreciate this addon. The linter's contributors have really done an incredible job at helping all of us write better template code.

Recent releases have brought additional linting rules that help avoid common WCAG failures- 16 of which are now preventable through use of ember-template-lint. More accessibility-specific work is planned in the coming months, so checking out the issues in the repository is a great way to figure out how you can contribute!

Do you use this linter? Or one like it? We'd love to hear about Ember addons that bring you joy!

Day 15

On the 15th day of our Countdown to The New Year we want to take a look at a helpful Ember addon which lets us write redesign-proof tests: ember-test-selectors!

What It Does

ember-test-selectors is an addon that allows us to use additional, test-specific markup in the form of data-test attributes in the dev and test environments of our app. This additional, test-specific markup allows us to select elements in our integration and application tests reliably - even if the HTML markup or CSS selectors change during a redesign of our app.

The addon takes care of removing data-test attributes from our production builds automatically, freeing us from the worry that our bundle size might increase as we build and test away.

Why I Like It

If we only rely on CSS selectors or HTML markup to find elements in test cases, changing markup in our templates due to new design specifications can make our tests fail accidentally. Test selectors applied by ember-test-selectors outlive a redesign and make our test suite return fewer false positives.

When we don't have to worry about testing our app after a redesign, we also have more fun tweaking our app's design for a new look!

Check it out for yourself! Do you use this or other fun testing addons? Let us and the Ember community know in the comments below!

Day 4

Today we are going to take a look at ember-tether.

What It Does

The addon ember-tether provides us with a UI component that - once rendered - will render its block to any other target DOM node on the page as configured via the component's attributes. This "tethering" of the component's block to a target somewhere else on the page also retains the component's context - making Ember action handling and data binding possible.

Why I Like It

Even though we have a lot of control over how and where Ember apps render UI using routes and components, it's sometimes difficult to implement less conventional UI patterns such as interactive modal dialogs or tooltips for street maps without writing lots of boilerplate. I enjoy using ember-tether for giving me the freedom to render app content wherever I like, almost whenever I want to.

Do you already use Ember Tether or another addon that allows you to render your UI in a magic way? If so, let us know in the comments below!

What a month it’s been! Over the last thirty days, we have showcased different kinds of addons in the Ember ecosystem. In this final post, we’ll show how an Ember app’s default addons come together to form a great developer experience, and we will reflect on the article series as a whole.

This article series highlights the real spirit of the Ember community, the ways in which we come together to find a way to say yes to good ideas. It started out as a wish: “Wouldn’t it be nice if we had our own advent calendar blog?” Then, it quickly turned into a refined possibility: “Let’s do a countdown to the new year so we can cover more addons.” From there, it grew into actionable steps: “What does an MVP blog post look like? How about a pre-determined format to make it easier to allow other community members to contribute?” This is one example of how many of our favorite open source projects come to life!

Of course, we were only able to highlight a small portion of the addons that so many of us use in our day-to-day lives, and we didn’t even touch on the ones that are included in Ember apps by default…so let's do that now!

If you start to consider the kinds of apps powered by Ember—everything from dairy farm apps to cruise ship line's websites, to the future in open source blockchain—the need for stability becomes urgently and crisply apparent. This is where Ember’s backwards-compatibility guarantee really shines—the new stuff won’t break your old stuff, and you’ll be given both plenty of time and guidance to upgrade.

One of the ways we are able to offer this kind of flexibility and stability is through the work that Rob Jackson, Kris Selden, Godfrey Chan, Ed Faulkner and many others have done to make Ember more flexible by splitting it up into separate addons. This helps the overall maintainability and makes it a lot more convenient when work needs to be done on just one of the addons.

When you type ember new my-app do you know all of the things that you’re getting by default?

You might already be aware of the major things:

• the component library (@glimmer/component )
• the data library (ember-data )
• the granddaddy of all CLI tools (ember-cli)

Those things alone are amazing, and the reason why Ember can provide such a cohesive, robust approach to building apps for developers of all skill levels. But there’s more! Let’s look at a few of the addons that are built into Ember by default, and the usefulness that they provide.

Make it robust

1. @ember/optional-features - who doesn’t love a good feature flag? This is one of the ways Ember allows you to try new features. The added bonus here is that we can test out the compatibility with existing features before making the optional feature permanent. Read more about optional features in Ember: https://guides.emberjs.com/release/configuring-ember/optional-features/.
2. ember-auto-import - we covered this one on day 6, but it’s worth mentioning again. As of Ember v3.15, it is now part of apps by default! Gone are the days when an Ember version of a popular library or package needed to be created (and maintained). It eliminates the need for developers to understand the differences between AMD and CJS modules and how they get into the app tree. They don't need to read about how to configure their build, or how Ember's build pipeline differs from other build tools. They import what they need, and it just works.
3. ember-qunit - Ember’s testing story is unarguably one of its biggest strengths, and built into every app is the ability to write tests that are concise and readable. Read more in the testing section of the guides: https://guides.emberjs.com/release/testing/.

Make it just work

1. ember-cli-dependency-checker automatically checks for missing dependencies before the command even runs! Ember CLI is pure productivity gold; it gives you strong defaults but also ways to customize further, if you want to. Read more here: https://guides.emberjs.com/release/configuring-ember/configuring-ember-cli/.
2. ember-maybe-import-regenerator will import the Regenerator Runtime into your Ember app- but only if you need it. Among other things, it’s useful for apps that want to use ES6 generator functions but don’t want to import the (larger) Babel polyfill package.
3. ember-resolver is probably the real “Ember magic,” if there is such a thing. What template goes with what route? Ember Resolver has your back. Technically speaking, it’s how your code gets converted into the actual classes/functions/templates that Ember needs to resolve it’s dependencies. And you don’t have to think about it, or set it up, it’s just there, working for you. Like magic. Or science.
4. broccoli-asset-rev adds fingerprint checksums and CDN URLs to your assets (things like images, web fonts, etc). Just one more thing you don’t have to think about, but you can customize if desired. In a similar vein, ember-cli-sri ensures sub-resource integrity, a security concept used to check JavaScript and stylesheets are loaded with the correct content when using a CDN.

Make it friendly

1. ember-welcome-page is a friendly way to let you know that you’ve successfully spun up your Ember application. When you’re ready to remove it and replace it with your own app content, removing the addon from package.json and the related template code from app/templates/application.hbs will put you back to a blank slate.
2. ember-cli-inject-live-reload is possibly my favorite developer-friendly feature of Ember. I make changes, and my local developer instance live reloads, with no setup required from me. I’ll say that again - no setup required from me. Absolute bliss.
3. lint, lint, and lint some more - the most developer-friendly thing that Ember provides is a robust set of linters. There are a lot of ways apps can get things wrong, but Ember does what it can for preventable issues. ember-template-lint, eslint-plugin-ember, and ember-cli-eslint are just a few of the ways we try to give you a well-lit path to success.

When I stop to think about all of the things I used to have to do every time I set up a new application, I grow more grateful for the ways Ember makes it easier to focus on what my app should do, and not all the tedium that can so quickly waste developer productivity through human error on tiny details.

On top of all of this, the recent release of the Octane edition of Ember means that now is the perfect time to give Ember a try, no matter what your skill level. EmberObserver is still the go-to place for pre-evaluating Ember addons, and the community chat server is a perfect spot for getting help and advice if you need it- or have some to share!

No matter what your relationship with Ember.js is, there’s a place for you. Haven’t tried Ember yet? Check out the revamped tutorial and give it a go! Regular Ember user? Check out the updated guides, and let us know what you think! Already using Octane (v3.15+)? I bet there are some addons that could use some updates! There’s no time like the present- jump right in and give it a try.

Ember wouldn't be what it is without the community of folks that make it all work. Thank you for being a part of this community and this effort to move the web forward in a way that allows us all to climb the proverbial mountain together. Here's to a happy and healthy 2020!

Day 12

Today we're highlighting ember-svg-jar.

What It Does

There's a reason ember-svg-jar has a 10 out of 10 on Ember Observer! The ember-svg-jar addon enables you to effortlessly use SVG images in Ember apps.

Why We Like It

A common theme in the Ember community is zero configuration. In that vein, with ember-svg-jar, you get a visual workflow out of the box to search and preview icons in one place. Check out the live demo and empower your team with this feature!

The ember-svg-jar addon helps you reduce the size of your assets. Using svgo, SVGs are automatically optimized, which can cut your file size by half or more. So useful!

The addon is flexible and extensible. ember-svg-jar provides an easy-to-use helper {{svg-jar "asset-name"}}, support for both inline and symbol embedding methods, and the ability to copy SVG as CSS background.

The addon webpage and README are a dream to peruse, both well documented and beautiful! And the logo is certainly bringing us joy.

Do you use ember-svg-jar? Or one like it? We'd love to hear about Ember addons you love for DecEmber!

Maybe December is a busy month for you, because of the holidays and family obligations—and that’s totally okay—we hope you have a great time! But for some, December is a time of the year with a lot of downtime. Maybe that’s you! Are you wondering what to do with all your vacation time in December? We’ve got ya covered!

Participation Rules

To qualify for any of our random assortment of thank you goodies (that we’ve delightfully dubbed Embercouragement), you must complete at least five participation activities for repositories in the ember-learn org between December 1-28, 2018.

Participation Activities

• Submitting PRs for issues
  • In the Ember Learn org
  • That have the DecEmber label
• Writing Issues for repositories in the ember-learn org. We will mark them with the DecEmber label if they qualify.
• Creating Illustrations: Maybe you have an artistic side, and illustrating code concepts is fun for you! If that’s the case, there are always illustrations that would enhance the guides, and those are very welcome for this event!
• If you have another idea that you think would help support the Learning Core Team, let us know!

Quality Standards

We don’t think we need to say these things, but just in case…

• The PR counts once it is merged; the issue counts once we have added the label.
• The PR must not be disruptive (i.e., taking someone else’s branch/commits and creating a PR).
• If you participate by writing an issue, the issue should be of respectable quality and not something that appears to be an intent to +1 your participation count.

Support

During the month of December, members of the Learning Core Team will be spending extra time in the December text and voice chat channels on our Discord server! It's a great place to ask questions or chat about the event.

What's Changed Now

Other than bug fixes, there are a few things we've changed that could affect your 1.0.pre apps.

• {{outlet}} now creates a Metamorph rather than a <div>. This makes it less obtrusive, but you may have to change your HTML or CSS if you were relying on the <div>.
• We have removed CP_DEFAULT_CACHEABLE and VIEW_PRESERVES_CONTEXT flags. Both behaviors are now always on.
• Inline Handlebars templates must always be named now. The default name is 'application'. This means that <script type="text/x-handlebars"> behaves exactly the same as <script type="text/x-handlebars" data-template-name="application">.
• Using the {{collection}} helper without a class has been deprecated, use the {{each}} helper instead. The {{each}} helper also now supports itemViewClass which was the main benefit to using {{collection}}.
• Ember.ViewState has been removed.

For more information on what's been changing in Ember, take a look at Bradley Priest's What's New in EmberJS.

What Will Change Later

There are still some things that we want to take care of before we do a beta release. Here are a few of them:

• New Router API: This is mostly finalized but has not yet been implemented.
• New Computed Property API: We're working on a new API for Computed Property getters and setters. Don't worry, we expect to support the existing one for the foreseeable future.
• Asynchronous Observers: Currently observers are fired immediately whereas bindings are synchronized with the RunLoop. In most cases observers can and should be delayed for optimal performance. We plan to change the existing behavior and add a new API for the cases where immediate execution really is needed.

What's New

Router

Ember.js is all about giving you the tools to build ambitious apps on the web. Here's the thing about ambitious apps: they usually have state. Lots of state. And the bigger your app gets, the harder keeping all of it in your head becomes.

Part of being an app on the web is taking advantages of the browser's strengths. In particular, the fact that we have URLs to describe what we see on our screen is an advantage over native applications. Your users want to be able to share that URL on Twitter or Facebook and have their friends see what they're seeing.

Ember 1.0 Prerelease includes what we think is the most advanced tool for modeling your application's state: Ember.Router. The router allows you to describe the state of your application as discrete objects, which means it's impossible for your application to ever get into a "bad state." And because the URL is a serialization of your application's state, you tell us how to build the URL and we'll keep it up-to-date as your users move throughout the application.

We're still making tweaks to the router API to make it as easy as possible for new users to pick up, but we think that modeling your apps as discrete states is the way all apps will be built in the future. It's still new but we believe in a few years it will be as relied on as automated testing for building the most robust applications possible.

View Context Changes

In apps built on earlier version of Ember, the {{#view}} helper created a new context for the view. This meant that you had to explicitly set the context on them. In 1.0, we've made this a bit simpler. The {{#view}} helper no longer changes the context, instead maintaining the parent context by default. Alternatively, we will use the controller property if provided. You may also choose to directly override the context property. The order is as follows:

1. Specified controller
2. Supplied context (usually by Handlebars)
3. parentView's context (for a child of a ContainerView)

In the event that you do need to directly refer to a property on the view, you can use the view keyword, i.e. {{view.myProp}}.

Miscellaneous

• getPath and setPath have been merged into get and set respectively.
• Ember.ObjectProxy - this object proxies to its content property. Along with this comes Ember.ObjectController.
• The #with helper now supports assigning an object to a custom property name using the format {{#with path.to.object as custom}}
• The #each helper also allows for a custom property using the format {{#each custom in path.to.array}}.
• Ember.SortableMixin - this mixin can be added to array-like objects for sorting functionality.
• Ember.Evented#one has been added for one time events.
• Ember.View#classNameBindings and bindAttr class now support the double colon syntax: myProperty:enabledClass:disabledClass.
• Ember.Object#canInvoke, tryInvoke - simplifies checking to see if a method can be invoked on the object.
• jQuery 1.6 is no longer supported. You must use 1.7 or greater.
• Handlebars is no longer bundled with Ember. This allows you to better control your version as well as allowing for the runtime only version to be used.
• ViewStates are now deprecated.
• Binding transforms have been removed in favor of computed properties.
• Async state transitions have been removed in favor of transitional states.
• Ember.StateManager#transitionTo should be used instead of goToState.
• Ember.Evented#fire has been renamed to trigger.
• Ember.Tabs have been deprecated.
• Some existing deprecations have been removed entirely.

For a full list, see the Changelog.

Known Issues

Since this is a prerelease, there are still some important known issues:

• Router - The Router API is not finalized. Conceptually, things are pretty stable, but API details are likely to change.
• Ember.Object.create - We are currently considering changing create to make it behave more like setProperties. If this does happen, we will try to maintain backwards compatibility as far as possible.
• Ember Data - We hope to merge Ember Data into the core Ember project before the final 1.0 release.
• Memory leaks - There are some known memory leaks. We will fix these before the final 1.0 release. Issue #1165
• Browser support - We have only done limited testing on older browsers so far. We will do more comprehensive testing before the final release.
• Dependent Bindings - Bindings that depend on other bindings may fail on initial connect unless properly ordered. Issue #1164
• ContainerView and SortableMixin - Using ContainerView, or its subclass CollectionView (which is used by the #each and #collection helpers), with SortableMixin may cause unexpected rendering errors. Issue #800

This release is all about fixing bugs from the pre4 release, and gets us that much closer to a final 1.0 release. Between this release and the 1.0 final, we will mostly be focusing on stability and documentation.

If you discover any blocking bugs or undocumented areas, please file tickets at the emberjs/ember.js repo on GitHub and consider helping out.

Route Replacement

You can now transition to a new route without creating an entry in the history:

// instead of this, which creates a history entry
router.transitionTo('index');

// do this
router.replaceWith('index');

In the redirect hook, you can use replaceWith and Ember won't create a history entry.

In a controller, you can use replaceRoute (instead of transitionToRoute) to do the same thing.

Item Controller

If you want every item in a {{#each}} to be wrapped in an ObjectController, you can do so:

{{#each posts itemController="post"}}
  {{!-- `this` in here is each post wrapped in an App.PostController --}}
{{/each}}

Register and Inject

Internally, Ember uses a "container" to instantiate your controllers and other objects.

As of Ember 1.0 RC1, you can use App.register to override the default lookup for controllers and other objects. For example:

App.register('controller:post', Ember.ObjectController.extend());

In general, you should use the default naming conventions, which Ember will use to find objects, but you can use this API for advanced usages.

Similarly, you can use App.inject to tell Ember to automatically inject objects into other Ember objects.

App.register('network:main', App.NetworkAdapter);
App.inject('controller', 'network', 'network:main');

This will create a single instance of App.NetworkAdapter and give it to every controller created over the course of building your application. Internally, Ember Data uses this API to give every controller the application's store:

Router Activate and Deactivate

Currently, many people are using the undocumented and private enter and exit hooks to run code whenever Ember activates a route handler or deactivates it.

As of Ember 1.0 RC1, there are public hooks: activate and deactivate. Note that the activate hook will run only when a route handler is activated for the first time. If a route handler's context changes, the setupController hook will run again, but not the activate hook.

App.reset()

If you are trying to run integration tests with Ember, you might have noticed that there is no good way to reset all of an application's state.

No more!

As of Ember 1.0 RC1, you can call App.reset() to destroy all objects created for the application, and bring the application back to /.

Big List of Changes

Since .pre4, we've added these features:

• Added the ability to replace the current route without adding a history entry, using router.replaceWith
• Added support for String literals in {{action}} and {{linkTo}} to differentiate between static String parameters and properties on the current context
• Allow redirection from routes that are not the final resting route
• Fix a bug where using named outlets would confuse where child templates should be rendered into
• Add itemController, which allows a {{#each}} to wrap each iterated element in a controller that can be used to store transient state
• Fix a bug involving {{else}} templates only working a single time
• Add intersection to EnumerableUtils
• Added App.register and App.inject to control the default application's dependency injection container
• Fixes regressions in jQuery 1.9 to address changes made to .attr and .prop
• Add support for {{unbound helper}} where helper is a custom helper registered via Ember.Handlebars.registerBoundHelper
• Added Ember.debug to print debug-level warnings and use it to print the current version of Ember and its dependencies on boot
• Fix a bug where changing the model property passed to {{render}} does not update the rendered template
• Added public activate and deactivate hooks in the router. If you were using the private enter and exit methods, please switch!
• Added Application#reset to help with integration tests
• Several fixes for the Ember Inspector
• Many bug and performance fixes

You can see the full changelog at the official CHANGELOG.

Namespace Lookup for Controllers

It is now possible to look up controllers that are included in a namespace other than the main application namespace.

For example, when using the render helper:

{{render 'posts'}}

This will render the posts template with the controller App.PostsController, where App is the main application namespace.

If you want to use an alternative namespace, you can use a /-separated path.

{{render 'blog/posts'}}

This will render the blog/posts template with the controller Blog.PostsController.

Using Render With Multiple Models

In RC1, you could use {{render 'posts'}} to render the posts template using the app's instance of App.PostsController. Using render in this way will always render the template using the same singleton controller.

In RC2, we are adding the ability to render a template with a particular model: {{render 'post' post}}. When you supply a model, Ember.js will create a new instance of the App.PostController each time it is used.

This allows you to use {{render}} in a loop:

{{#each post in posts}}
  {{render 'post' post}}
{{/each}}

Unwrapping an ObjectController's Model

When passing an ObjectController as a parameter to the action or linkTo helpers, Ember now unwraps the underlying model and passes it through.

Most importantly, this allows you to add an itemController to {{#each}} without affecting action handlers in your controller or router.

If you have a template like this:

{{!-- posts.hbs --}}
<ul>
{{#each controller itemController='postItem'}}
  <li><button {{action 'selectPost' this}}>{{name}}</button></li>
{{/each}}
</ul>

Your App.PostsController would look like this:

App.PostsController = Ember.ArrayController.extend({
  needs: 'currentPost',

  selectPost: function(post) {
    // `post` here is an `App.Post`, not an
    // `App.PostItemController`
    this.set('controllers.currentPost.model', post);
  }
});

This should make using itemController less gotcha-prone.

Support for jQuery 2.0

Ember 1.0 RC2 supports jQuery 2.0.

This allows you to use a smaller, optimized build for newer browsers that is fully compatible with Ember.

If you're targeting both older IE and modern browsers, you can use the following snippet to get the best of both worlds:

<!--[if lt IE 9]>
    <script src="jquery-1.9.1.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
    <script src="jquery-2.0.0.js"></script>
<!--<![endif]-->

Because jQuery 1.9 and 2.0 are API-compatible, this strategy will allow you to target the widest range of browsers, but ship a smaller build for modern browsers.

The future is here!

Changelog

The full CHANGELOG is available on Github, as always.

Performance

Since RC2, a series of performance improvements have landed.

• When adjacent child views are scheduled for insertion they are are now batched together, and inserted together rather then one at a time.

• Object deletion is now async, this prevents un-needed churn when destroying large interconnected object graphs.

• The number of objects allocated during view rendering has been cut down.

The ongoing performance effort is being championed by Erik Bryn and Kris Selden.

Testing

There have been many fixes and improvements to App#reset, which should now correctly clear application state when invoked. Typically this is only used for integration tests.

// before each integration test
App.reset();

Please Note: App.reset() now brings its own run loop, and no longer needs to be wrapped in one.

Initial work on a new ember-testing package has begun. The goal of this project is to make testing Ember applications easier, especially when it comes to testing asynchrony. As this effort matures, expect full documentation, examples and guides.

Props to Erik Bryn for researching integration testing approaches by many community members, including Jo Liss and Katie Gengler, and spearheading initial work on what will be our official library.

Ember Builds

Each successful CI run now publishes its build results to http://emberjs.com/builds. This should make it much simpler to reference and use the the latest ember build.

Thanks to Stanley Stuart, Luke Melia, Erik Bryn and others for getting this set up.

New Input and TextArea helpers

TextField, TextArea and Checkbox views now have corresponding handlebars helpers.

  {{view Ember.TextField valueBinding="name"}}
  {{view Ember.Checkbox  checkedBinding="isActive"}}
  {{view Ember.TextArea  valueBinding="name"}}

can now be expressed as:

  {{input value=name}}
  {{input type=checkbox checked=isActive}}
  {{textarea value=name}}

We recommend using the "dynamic tag" forms rather than the {{view}} forms because they are equivalent to the static tags that we all know and love.

Note that when using dynamic tags, you do not need to use a Binding suffix and must leave out the quotation marks around the values. Ember will interpret quoted strings as static strings in this context.

Documentation

The API docs have been refined and filled in by more community members than we can mention here. Thank you everyone for helping out!

Changelog

The full CHANGELOG is available on Github, as always.

We have noticed a performance regression, a debug flag was left on by mistake. So if you really want the goodness of RC4 without this regression use this build, we'll have an official release out soon.

Today, we are pleased to announce Ember.js 1.0 RC4:

This RC4 release of Ember puts us very close to the final 1.0 release.

Ember.js 1.0 RC4

As we approach 1.0 final, our focus continues to be on bugfixes, performance, and reliability.

BREAKING CHANGE: Controller/Model Setup

One of the roles of Route objects in an Ember application is to tell controllers which model they should represent.

By default, the object that you return from a route's model hook is set as the model property on the corresponding controller. So, for example, if you have this route:

App.PhotosRoute = Ember.Route.extend({
  model: function() {
    return App.Photo.find();
  }
});

The array returned from model would be set as the model property of the App.PhotosController. This tells the controller that it should present that model to its template.

What if you need to set up additional controllers, beyond the primary controller associated with that route? In that case, you can implement the setupController hook:

App.PhotosRoute = Ember.Route.extend({
  model: function() {
    return App.Photo.find();
  },

  setupController: function(controller, model) {
    this.controllerFor('application').set('showingPhotos', true);
  }
});

This is all well and good, but what if you wanted to prevent a model from being set on the PhotosController at all?

In RC3, preventing this default behavior was impossible. In RC4, implementing the setupController hook prevents the default behavior from happening. This is a potentially breaking change.

If your route implements the setupController hook and you want to preserve default behavior, make sure you call _super() from within the hook:

App.PhotosRoute = Ember.Route.extend({
  model: function() {
    return App.Photo.find();
  },

  setupController: function(controller, model) {
    // Call _super for default behavior
    this._super(controller, model);
    this.controllerFor('application').set('showingPhotos', true);
  }
});

Thanks to Kris Selden and Luke Melia for pulling together PRs from Paul Chavard, Rob Harper and input from others into a cohesive change. We don't take breaking changes lightly at this stage of the release process, but this one is worthwhile.

RSVP 2.0

Ember now embeds version 2.0 of RSVP.js, a microlibrary for Promises/A+ compatible promises.

All of the Ember.js APIs that return promises use this library to ensure compatible behavior.

A big, big thanks to Stefan Penner for all of his work on improving the promises story across both Ember and Ember Data.

Run Loop Extracted to Backburner.js

Erik Bryn has extracted the run loop into the Backburner.js microlibrary, which Ember now uses.

This will allow other frameworks and libraries that use Backburner to benefit from using a deferred event queue, and hopefully we can share our work to make the web platform faster for everyone.

Handlebars RC4 Compatibility

Ember.js RC4 requires the latest release of Handlebars, which is also at RC4.

Improved Route Redirection

Routes provide a redirect hook that allow them to conditionally redirect to a different route. For example, you may redirect the user to a login route if you detect that they do not have an authentication token saved.

Many improvements to the redirect hook have been made to make it more reliable. Additionally, you can now implement this hook in the ApplicationRoute, which previously would not work.

Props to Tom Dale for this work.

ember-testing Improvements

The ember-testing package, included in Ember.js, is the officially-supported library for writing unit and integration tests for Ember apps. Introduced in RC3, this has continued to be improved, with many bug fixes and performance improvements landing in RC4.

A huge thanks to Teddy Zeeny for driving many of these improvements.

disabledWhen {{linkTo}} Option

The {{#linkTo}} Handlebars helper now has a disabledWhen option that can be bound to conditionally disable a link:

{{#linkTo 'upgradeAccount' disabledWhen=isPremiumUser}}
  Upgrade Account
{{/linkTo}}

Thanks to Trek Glowacki for this improvement.

RC5 fixes several regressions and bugs found in RC4. Notably:

• A performance regression caused by a change to run loop scheduling has been fixed. Thanks to Erik Bryn for working on this.
• Promises returned from a route's model hook could cause the app to hang on page refresh. This has been fixed thanks to Alex Matchneer.
• The ember-testing package, which contains additional helpers for testing Ember.js apps, is no longer included in the production build. This means less JavaScript for end users to load over the network.

Thank you to everyone who filed issues and pull requests. Please try out RC5 in your applications and report any issues or regressions you find by filing an issue on GitHub.

Lastly, thanks to Stefan Penner, who has been busting his tail to get Ember.js to the 1.0 finish line, including doing the release engineering for these release candidates. Thanks Stef!

In fact, we're one of the few JavaScript projects that has a clearly outlined security policy and a low-traffic mailing list exclusively for security announcements.

We want developers to know that they can trust Ember enough to build their businesses on top of it.

In that spirit, today we are announcing the release of Ember.js 1.0 RC6.1, RC5.1, RC4.1, RC3.1, RC2.1 and RC1.1. These are all security releases that address a potential XSS security issue you can learn more about by following this link:

• CVE-2013-4170

It is recommended that you update immediately. In order to ease upgrading, the only major change in each release is the security fix.

We would like to thank Mario Heiderich of Cure53 for responsibly disclosing this issue, working with us on the patch and the advisory, and having patience while we went through our security procedure for the first time.

Like a smoke detector or fire extinguisher, having a security procedure is something that you hope that you don't need; but when you need it, you're glad you have it.

We hope that we can set an example for other projects in the JavaScript world when it comes to taking security seriously. Initiatives like the Node Security Project are a step in the right direction.

We are very fortunate that this security issue is low severity. Due to the sandboxed nature of the web browser, there are far fewer possible exploit vectors for a JavaScript MVC framework to worry about than a traditional server-side framework.

That being said, we will remain vigilant in ensuring that even small security issues are taken care of properly. If you discover what you believe may be a security issue in Ember.js, we ask that you follow our responsible disclosure policy.

Lastly, thanks to Yehuda Katz, Stefan Penner and Kris Selden, who donated their valuable time to reviewing the patch, auditing other code for similar vulnerabilities, and preparing the new releases.

Router Update

The biggest change is router update (aka "router facelift"), which addresses two major issues. The first was inconsistent semantics between URL-based transitions and transitionTo. The second was spotty async support which made it difficult to prevent or delay route entry in cases such as authentication and async code-loading.

We have now harmonized URL changes and transitionTo semantics and more fully embraced asynchrony using promises.

Additionally, router transitions have become first-class citizens and there are new hooks to prevent or decorate transitions:

willTransition: fires on current routes whenever a transition is about to take place beforeModel/model/afterModel: hooks fired during the async validation phase

Finally there is an error event which fires whenever there is a rejected promise or error thrown in any of the beforeModel/model/afterModel hooks.

For more on new router features, see:

• New router overview given by Alex Matchneer's at the June Ember NYC Meetup
• Usage Examples
• Client-side Authentication Part 2 Embercast

Special thanks to Alex Matchneer for his work on this!

Ember Components

The other major change is the introduction of Ember Components, which shares Web Components' goal of facilitating creation of reusable higher-level page elements.

Ember Components will generally consist of a template and a view which encapsulate the template's property access and actions. Any reference to outside constructs is handled through context info passed into the view. Components can be customized through subclassing.

Ember Components naming conventions are: 1) the template's name begins with 'components/', and 2) the Component's name must include a '-' (this latter convention is consistent with Web Components standards, and prevents name collisions with built-in controls that wrap HTML elements). As an example, a component might be named 'radio-button'. Its template would be 'components/radio-button' and you would call it as {{radio-button}} in other templates.

Stay tuned for more docs and examples of this exciting new feature.

Important Changes

Route#controllerFor no longer auto generates controllers

In some cases, people have been relying on controllerFor to access controllers for routes that have not yet been entered, relying on its auto-generation ability. Unfortunately, this can actually lead to subtle bugs. When entering a route, Ember looks for a controller with a matching name. If that controller isn’t found, Ember generates one according to the type of the route’s model. If the model is an array, we generate an ArrayController; if it’s an object, an ObjectController; if neither, a standard Controller. In most cases, people using controllerFor outside of the route are not providing a model and Ember will create the basic Controller. If the route is later entered, the controller will not be re-created and the type of the controller may not match the provided model.

Due to this, we removed the auto-generation abilities of controllerFor. In most applications, this will not be an issue, but if you were relying on this behaviors, you will need to update your application. If you do have a controller that’s not associated with a route, you should explicitly define the controller's class instead of relying on auto generation.

Removed old-router

Ember’s old router was deprecated prior to the first RC and while it’s never been included in standard RC builds, some users have still been relying on it. Despite this, it’s become time to cut the ties. Increasingly, new features we are adding, especially containers, are incompatible with the old router. Because of this, we’ve removed the old router code from Ember’s repo and you are no longer able to make custom Ember builds with it. We strongly encourage everyone still using the old router to upgrade. However, if anyone is interested in maintaining an old router library independent of the main Ember repo, please let us know.

Other changes

• Update Handlebars version to 1.0.0 — Handlebars 1.0.0 was released almost simultaneously with RC6. Unfortunately, we hadn’t upgraded Ember to support it.

• mergedProperties — Similar to concatenatedProperties but for objects. It merges the properties of the two basic objects into a single object.

• Deprecate template in favor of partial — There was a lot of overlap between these two methods. We’ve solidified around partial and no longer require an underscore-prefixed name.

• Update Backburner.js (Ember’s RunLoop) - fixes debounce adds throttle — Previously, Ember.run.debounce actually performed throttling. debounce now actually performs a debounce and the thottling behavior has been moved to Ember.run.throttle.

• Routes can now specify their controller class name with controllerName

• Add Ember.Route#disconnectOutlet, to allow for clearing a previously rendered outlet.

• Added functionality to Router.map to allow it to be called multiple times without the map being overwritten. Allows routes to be added at runtime.

UPDATE: The post previously recommended the use of Route#generateController for cases where the controller was not associated with a route. We are now directing users to explicitly declare the controller's class instead of relying on generation.

This final release candidate comes with a couple of small breaking changes that we are making before 1.0 because they should have a small impact on application code but a large impact on performance.

We normally would not make changes of this nature this close to the 1.0 final release date. However, the performance improvements were so dramatic we did not want to wait until Ember.js 2.0 to introduce the change, and we are serious in our commitment to not breaking the API post-1.0. This was our last chance to get these changes in before putting the final stamp on the 1.0.

Both of the changes are related to observers. If you find yourself writing code with lots of observers, you may be writing non-idiomatic code. In general, you should only need to use observers when you are bridging Ember code to other libraries that do not support bindings or computed properties.

For example, if you were writing a component that wrapped a jQuery UI widget, you might use an observer to watch for changes on the component and reflect them on to the widget.

In your application code, however, you should be relying almost entirely on computed properties.

If you are having trouble upgrading your application, please join us in the IRC channel or post on StackOverflow for help.

Declarative Event Listeners

There is now a way to declaratively add event listeners to Ember classes. This is easier than manually setting up the listeners in init.

Instead of:

App.Person = DS.Model.extend({
  init: function() {
    this.on('didLoad', this, function() {
      this.finishedLoading();
    });
  },

  finishedLoading: function() {
    // do stuff
  }
});

You can just do this:

App.Person = DS.Model.extend({
  finishedLoading: function() {
    // do stuff
  }.on('didLoad')
});

Array Computed

Thanks to the tremendous work of David Hamilton, there is now a convenient and robust way to build a computed property based on an array that will only perform calculations on the updated portion.

For example, say that you have an array of people, and you want to create a computed property that returns an Array of their ages.

Currently, the easiest way to do that is:

App.Person = Ember.Object.extend({
  childAges: function() {
    return this.get('children').mapBy('age');
  }.property('children.@each.age')
});

This is pretty terse, but it must recalculate the entire array any time a single element is added or removed. This works OK for small arrays, but for larger arrays, or when these kinds of computed properties are chained or doing expensive work, it can add up.

Enter Array Computed properties:

App.Person = Ember.Object.extend({
  childAges: Ember.computed.mapBy('children', 'age')
});

You can also chain these Array computed properties together:

App.Person = Ember.Object.extend({
  childAges: Ember.computed.mapBy('children', 'age'),
  maxChildAge: Ember.computed.max('childAges')
});

When an element is added or removed, the computation is only done once. In this example, if a child is added, their age is appended to childAges, and if that age is larger than the maxChildAge, that property is updated.

These computed properties are always up to date, efficient, and completely managed by Ember.

Ember Extension

After months of testing, and tons of work by Teddy Zeenny, we're finally ready to put the Ember Inspector in the Chrome Web Store.

Most recently, Teddy added support for loaded data. It already has support for Ember Data, and Ember Model is actively working on adding support.

Teddy has also significantly improved the object inspector, adding support for objects to group properties as they wish (e.g. attributes, has many, belongs to in Ember Data) and editing records in the inspector itself.

You can also see a list of all routes in your app, along with the naming you should use for associated objects. This should make remembering the naming conventions a lot easier.

And finally, a view tree that shows an overlay in your app with the associated controller and model for your application's templates.

It should be in the web store in the next day or so, so keep an eye out. Follow @emberjs on Twitter to get the latest!

Release Cycle

We know that the Ember 1.0 RC cycle was a bit long. In truth, we released RC1 too early. We're sorry if the release names caused confusion.

Going forward, we plan to seriously tighten up our release process. We will have a blog post outlining the new process together with the final Ember 1.0 release.

Other Improvements

• Several improvements to yield to make sure it always yields back to the calling context [@kselden]
• Performance improvement to range updates by not using the W3C range API even if it's available [@eviltrout]
• Completion of the 1.0 documentation audit [@trek]
• Better error message if you try to use the same template name multiple times by using <script> tags [@locks]
• Add currentRouteName to ApplicationController, which you can use in link-to, transitionTo, etc. [@machty]
• Alias linkTo to link-to and bindAttr to bind-attr for consistency with HTML naming. Old names remain but are soft-deprecated [@ebryn]

Changes TL;DR

Observers Don't Fire During Construction

Previously, observers would not fire for properties passed into create or specified on the prototype, but they would fire if you set a property in init.

Now, observers never fire until after init.

If you need an observer to fire as part of the initialization process, you can no longer rely on the side effect of set. Instead, specify that the observer should also run after init by using .on('init').

App.Person = Ember.Object.extend({
  init: function() {
    this.set('salutation', "Mr/Ms");
  },

  salutationDidChange: function() {
    // some side effect of salutation changing
  }.observes('salutation').on('init')
});

Unconsumed Computed Properties Do Not Trigger Observers

If you never get a computed property, its observers will not fire even if its dependent keys change. You can think of the value changing from one unknown value to another.

This doesn't usually affect application code because computed properties are almost always observed at the same time as they are fetched. For example, you get the value of a computed property, put it in DOM (or draw it with D3), and then observe it so you can update the DOM once the property changes.

If you need to observe a computed property but aren't currently retrieving it, just get it in your init method.

New Actions Hash for Routes, Controllers, and Views

Previously, you could define actions for your routes in their events hash. In controllers and views however, actions were defined directly as methods on the instance. Not only was this inconsistent, it also lead to awkward naming conflicts. For instance, attempting to name your action destroy would conflict with the built-in destroy method and very bad things would happen.

To make things consistent and give more flexibility in action naming, we've standardized around using a hash called actions. When extending a class with actions defined, we'll merge the actions defined on the subclass or instance with those on the parent. We also support _super so you won't lose any flexibility with this approach.

The old behavior will continue to work for the time being but is now deprecated. In the event that you had a controller that was proxying to a model with an existing actions property, we internally rename the property to _actions to avoid any conflicts.

Enforce Quoted Strings in Handlebars Helpers

In the past, we were loose with our requirements for quoting strings in Handlebars helpers. Unfortunately, this meant we were unable to distinguish between string values and property paths. We are now strictly enforcing quoting if you want the value to be treated as a string. This means that for link-to the route names must be quotes. In the reverse direction, if you had custom bound helpers and were passing a property path as a quoted string, this will no longer work. Again, quotes for strings, no quotes for paths.

Setting Properties in init

Currently, there is an inconsistency between properties set when passing a hash to create and setting those same properties in init.

App.Person = Ember.Object.extend({
  firstNameDidChange: function() {
    // this observer does not fire
  }.observes('firstName')
});

App.Person.create({ firstName: "Tom", lastName: "Dale" });

In this case, because the properties were set by passing a hash to create, the observers are not fired.

But let's look at what happens in RC7 when the same initialization is done via the init method:

// WARNING: OLD BEHAVIOR

App.Person = Ember.Object.extend({
  init: function() {
    if (!this.get('firstName')) {
      this.set('firstName', "Tom");
    }
  },
  firstNameDidChange: function() {
    // this observer fires
  }.observes('firstName')
});

App.Person.create({ lastName: "Dale" });

In this case, the old behavior would trigger the observers if firstName was not provided.

We intended the design of the object model to trigger observers only after construction, which is why create behaves the way it does.

Also, because the only way to define initial properties that have arrays or objects as values is in init, there is a further inconsistency:

// WARNING: OLD BEHAVIOR

App.Person = Ember.Object.extend({
  // initial property value, does not trigger an initialization observer
  salutation: "Mr.",

  init: function() {
    // also initial property value, triggers an observer on
    // initialization
    this.set('children', []);
  }
});

In short, properties that get set during initialization, whether they were already set on the prototype, passed as a hash to create, or set in init, do not trigger observers.

If you have some code that you want to run both on initialization and when a property changes, just mark it as a method that should also run when initialization is done by using .on('init'). This will also be more resiliant to refactoring, and not rely on a side effect of an init-time set.

App.Person = Ember.Object.extend({
  firstNameDidChange: function() {
    // some side effect that happens when first name changes
  }.observes('firstName').on('init')
});

Computed Property Performance Improvements

The latest release of Ember.js contains a change to the way observers and computed properties interact. This may be a breaking change in apps that relied on the previous behavior.

To understand the change, let's first look at an example of a computed property. Imagine we are trying to model Schrödinger's famous cat using an Ember.js object.

App.Cat = Ember.Object.extend({
  isDead: function() {
    return Math.rand() > 0.5;
  }.property()
});

var cat = App.Cat.create();

Given this cat object, is it alive or is it dead? Well, that's determined at random. Before observing the cat, we might say that it's both alive and dead, or perhaps neither.

In reality, whether or not our cat has shuffled off this mortal coil is only determined the first time we ask for it:

cat.get('isDead');
// true
// …or false, half the time

After we have asked the cat object for its isDead property, we can categorically say which it is. But before we ask, the value of the computed property doesn't really exist.

Now, let's introduce observers into the mix. If the value of a computed property doesn't exist yet, should observers fire if one of its dependent keys changes?

In previous versions of Ember.js, the answer was "yes." For example, given this class:

App.Person = Ember.Object.extend({
  observerCount: 0,

  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),

  fullNameDidChange: function() {
    this.incrementProperty('observerCount');
  }.observes('fullName')
});

Changing any of the dependent keys would trigger the observer:

// WARNING: OLD BEHAVIOR DO NOT RELY ON THIS

var person = App.Person.create({
  firstName: "Yehuda",
  lastName: "Katz"
});

person.get('observerCount'); // => 0

person.set('firstName', "Tomhuda");
person.get('observerCount'); // => 1

person.set('lastName', "Katzdale");
person.get('observerCount'); // => 2

However, because the fullName property doesn't really "exist" until it's requested, it is unclear if firing an observer is the correct behavior.

A related problem affects computed properties if their dependent keys contain a path. (Remember that dependent keys are just the property names you pass to .property() when defining a CP.)

For example, imagine we are building a model to represent a blog post that lazily loads the post's comments if they are used (in a template, for instance).

App.BlogPost = Ember.Object.extend({
  comments: function() {
    var comments = [];
    var url = '/post/' + this.get('id') + '/comments.json');

    $.getJSON(url).then(function(data) {
      data.forEach(function(comment) {
        comments.pushObject(comment);
      });
    });

    return comments;
  }.property()
});

Awesome! This will work as expected—a post's comments will only be loaded over the network the first time we do post.get('comments') or use it in a template:

<ul>
{{#each comments}}
  <li>{{title}}</li>
{{/each}}
</ul>

However, now we want to add a computed property that selects the first comment from the array of loaded comments:

App.BlogPost = Ember.Object.extend({
  comments: function() {
    var comments = [];
    var url = '/post/' + this.get('id') + '/comments.json';

    $.getJSON(url).then(function(data) {
      data.forEach(function(comment) {
        comments.pushObject(comment);
      });
    });

    return comments;
  }.property(),

  firstComment: function() {
    return this.get('comments.firstObject');
  }.property('comments.firstObject')
});

Now we have a problem! Because the firstComment computed property has a dependency on comments.firstObject, it will get() the comments property in order to set up an observer on firstObject.

As you can see, just adding this computed property now means that the comments are loaded for all blog posts in the app—whether their comments are ever used or not!

To determine what to do, we spent some time looking at real-world Ember.js apps. What we discovered is that this behavior carried with it signficant performance penalties.

1. Firing observers on unmaterialized computed properties means we have to set up listeners on all computed properties ahead of time, instead of lazily the first time they are computed.
2. Many computed properties that never get used are nonetheless computed because of path dependent keys.

To fix these issues, RC8 makes the following changes:

1. Observers that observe a computed property only fire after that property has been used at least once.
2. Observing a path ("foo.bar.baz"), or using a path as a dependent key, will not cause any parts of the path that are uncomputed to become computed.

The majority of Ember.js applications should not be affected by this change, since:

1. Most apps that observe computed properties also get() those properties at object initialization time, thus triggering the correct behavior.
2. In the case of computed property dependent keys, the new behavior is what developers were expecting to happen all along.

If your applications are affected by this change, the fix is straightforward: just get() the computed property in your class's init method.

For example, to update the observer example above, we can retain the pre-RC8 behavior by "precomputing" the fullName property:

App.Person = Ember.Object.extend({
  init: function() {
    this.get('fullName');
    this._super();
  },

  observerCount: 0,

  fullName: function() {
    return this.get('firstName') + ' ' + this.get('lastName');
  }.property('firstName', 'lastName'),

  fullNameDidChange: function() {
    this.incrementProperty('observerCount');
  }.observes('fullName')
});

link-to Bound Parameters

The link-to helper (formerly linkTo, see above) now treats all unquoted parameters (and non-numeric parameters) as bound property paths, which means that when a property passed to link-to changes, the href of the link will change. This includes the first parameter (the destination route name) and any of the context parameters that follow.

The following example template will look up the destinationRoute on the current context (usually a controller) and use it to determine the href of the link and the route that will be transitioned to when the link is clicked.

{{#link-to destinationRoute}}Link Text{{/link-to}}

The following example template will always point to the articles.show route (since the route name parameter is in quotes), but when the value of article changes, the link's href will update to the URL that corresponds to the new value of article.

{{#link-to 'articles.show' article}}Read More...{{/link-to}}

This might cause a few surprises in your app if you haven't been distinguishing between quoted strings and property paths, so make sure that any static string link-to parameters (such as route names) are properly quoted in your templates when you upgrade to RC8.

Bound Helpers: Quoted Strings, Numbers, and Paths

Invoking a custom bound helper (e.g. one defined via Ember.Handlebars.helper) with quoted strings or raw numbers will pass that raw value directly into the helper function you've defined, rather than treating everything like a bound property path that will re-render the helper when changed.

Pass the string 'hello' to myHelper:
{{myHelper 'hello'}}

Pass the property pointed-to by the path 'hello' to myHelper:
{{myHelper hello}}

This might cause a few surprises in your app if you've been invoking bound helpers with quoted strings and expecting them to be treated as bound property paths, so make sure that the only time you're passing quoted strings to custom helpers is when you really intend to pass raw strings (rather than the values of properties) to the helper.

The first commit to the repository that would become Ember.js happened on April 30th, 2011, almost two and a half years ago.

At the time, Backbone.js was rocketing to popularity. In response to large JavaScript frameworks like SproutCore, Cappuccino, and Dojo, which tried to abstract away HTML, most web developers began rejecting any solution whose source code they couldn't read over in an afternoon. The "microlibrary" frenzy had hit full tilt.

However, we knew that as web browsers became more and more powerful, these simplistic abstractions wouldn't scale up to the kind of apps that users would begin to demand.

We realized that helping developers grapple with the complexity of building 100% JavaScript web applications could only happen if we embraced the tools that they were most comfortable with: HTML and CSS.

Based on the current popularity of frameworks like Ember, Angular and Knockout, it's clear that this strategy turned out to be the right one.

As we began work on Ember.js, however, we soon realized that there was a fundamental problem. Just having templates that were bound to models was not enough. We also needed to help developers decide which templates and models to display at any given time.

While struggling to figure out the best solution, we couldn't help but notice that many JavaScript applications on the web felt broken. Basic things that we had taken for granted for two decades all of a sudden stopped working. Just clicking the browser's back button was enough to break many of these apps.

We realized that the solution to our problem had been sitting under our noses all along: the URL is what web applications use to decide what to display!

We knew that we had to go back to the drawing board. We rebooted the entire project mid-course to refocus on how to build JavaScript apps that not only helped you architect large, multi-page applications, but helped you to do so without breaking the basic building blocks of the web.

Over time, we've added even more features, like components, that help bring solid UI architecture to the web. We are incredibly proud of the job that the community has done to lay a solid foundation that we can build upon for the years to come.

This 1.0 release is a promise from us: the pain that many experienced while we were figuring out how to build a JavaScript framework for the future of the web is now over. In keeping with the Semantic Versioning spec, there will be no more intentional breaking changes until we release Ember 2.0, which we don't anticipate happening for some time.

Recent Developments

Router Facelift

Over the past few months, Alex Matchneer has taken the Ember router to the next level. Alex's changes focus on making the router an excellent tool for managing complex asynchronous flows (like authentication), and you can learn all about it in his recently completed guides:

• Asynchronous Routing
• Preventing and Retrying Transitions

Preparation for Modules

In the years since we started Ember, the JavaScript module ecosystem has become increasingly mature.

Today, tools like require.js and module systems like AMD, Node, and ES6 Modules continue to gain traction. Increasingly, people are using named modules and module loaders rather than storing their code in globals.

To prepare for this future, all of the code lookup and naming conventions in Ember.js now go through a single Resolver. The default Resolver still looks for code under global namespaces, but Ember App Kit already provides an alternative resolver that looks for code in AMD modules.

In the near future, we plan to roll in first-class support for modules into the framework, based on the experiences of users of the increasingly popular Ember App Kit.

Ember Testing

The Ember community has always been passionate about testing. Even at the earliest meetups, testing was one of the most frequently asked-about topics, and testing featured prominently in our thinking as we built out the new router.

As we got closer to Ember 1.0, we realized that we needed to provide an official set of testing-framework agnostic testing helpers. The Ember Testing package is the start of a longer-term focus on testing facilities that we plan to improve even more in the 1.x timeframe.

You can see some of our thoughts for future improvements on the Ember Discussion Forum.

Ember Inspector for Chrome

Teddy Zeenny's relentless work on the Ember Inspector has been some of the most awe-inspiring work we've seen in open source.

The Ember Inspector that ships with Ember 1.0 makes it easy to see how an Ember application is laid out, and presents all of the naming conventions in an easy-to-read table. If you're using Ember Data, it also lets you see all of the records that your application has loaded at a glance.

Coming up next is asynchronous debugging to help make sense of some of the more quirky behavior of Promises.

Performance, Performance, Performance

A number of community members, especially Kris Selden, Erik Bryn and Robin Ward have done heroic work lately on performance.

Over the years, Ember's internals have been significantly sped up time and time again, and we will continue to hone the performance of Ember going forward.

In the 1.x timeframe, we have a number of ideas that should significantly improve rendering performance and decrease the amount of GC during rendering, so keep an eye out!

Docs, Docs, Docs

The early lack of good documentation for Ember seriously pained us, as we're all big believers in the idea that user confusion should be considered a bug in the framework.

Over the past year, we've significantly improved both the API documentation and the Guides. Trek Glowacki has led up the effort, which has resulted in comprehensive coverage of how to use Ember, an excellent, up-to-date Getting Started Guide, and most recently, a Cookbook section for common scenarios.

For Ember 1.0, Trek led a documentation audit of all of the API documentation in the entire codebase, which led to 1,700 new lines of documentation, and an across-the-board freshening for new idioms and best practices.

Ember Data 1.0 Beta 1

With the release of Ember 1.0, we're glad to also release the first beta of Ember Data 1.0.

Ember Data 1.0 is a reboot of our data layer. The focus of the effort (codenamed jj-abrams, famous for franchise reboots) was:

• A more flexible codebase, able to handle streaming, custom JSON, and edits while saving with ease. If you've found Ember Data too inflexible for your backend in the past, try it again!
• Asynchronous operations are now all backed by promises. This will integrate better with Ember's own asynchronous handling, and make it easier to combine and pipeline asynchronous operations like find and save.
• Better support for modules. Ember.js itself now has good support for modules, through Ember App Kit's drop-in resolver, but Ember Data's reliance on global lookups (through App.Post.find, etc.) made Ember Data hard to use with modules. The Ember Data 1.0 API is much more friendly to modules, and therefore the future of Ember.js and the web platform.
• Much better documentation of Ember Data's APIs, including the adapter and serializer APIs. Flexible APIs are no good if it's impossible to learn about them.

If you're a current user of Ember Data, you may want to check out the Transition Guide. If you have issues upgrading that aren't covered in the guide, please let us know right away so we can improve it.

Note: If you aren't ready to upgrade just yet, we've released Ember Data 0.14, which includes a number of useful performance optimization for Ember Data 0.13 but no breaking changes.

Community

The Ember community is amazing.

I love the Ember community

— Yehuda Katz (@wycats) August 28, 2013

In addition to the insane amount of work that members of the Ember community have been doing to prepare the Ember 1.0 release, the community has also been churning out a number of awesome Ember-related projects.

• Ember App Kit: An effort by a number of members of the Ember community to work on tooling for Ember that will eventually become the core of official Ember tools.
• Ember Tools: Similar work by Ryan Florence, which will be merged into Ember App Kit as we begin to bring tooling into core.
• Bootstrap for Ember: Twitter Bootstrap wrapped in Ember components!
• Ember Animated Outlet: Support for animated {{outlet}}s and {{link-to}} on top of the current Ember by Sebastian Seilund of Billy's Billings.
• Admin.js: An awesome, flexible and configurable admin for your site written in Ember by Gordon Hempton. You can use it with an Ember app or just to provide an admin interface for your Rails, Django, PHP, or whatever app!
• The Ember Hot Seat: A regular podcast brought to you by DeVaris Brown. It regularly features members of the Ember Core Team and prominent members of the Ember community.
• EmberWatch: Philip Poot's EmberWatch Twitter account and website will keep you up-to-date on the latest projects and news.
• Ember Weekly: Ember Weekly, curated by the inimitable Owain Williams, packs all the Ember news that's fit to print into your inbox every week.
• And way more projects. Keep an eye out on this blog, or follow us on the official @emberjs Twitter account. We plan to feature more projects like these in the future.

We've also been grateful to be the beneficiary of large amounts of support from a number of companies over the years.

• LivingSocial, which funded much of the original work on Ember Data.
• Yapp, whose employees have been working on Ember (and SproutCore before Ember) for years, and which has dedicated countless hours to making Ember better.
• Zendesk, an early user and contributor to Ember. Thank you for betting on Ember as early as you did.
• McGraw-Hill Education Labs, which has been funding Ember work for over a year, with great patience, resolve and vision.
• Tilde, which employs Tom, Yehuda, Peter and Leah, and which handles much of the (unseen) administrative work of the project.
• Billy's Billings, which has given Sebastian Selund time to work on Ember, and hosted the work on ember-animated-outlet, which will make its way into a future version of Ember.

Finally, a number of large open source projects have bet on Ember. These projects contribute significantly to Ember's development, and also give Ember users a place to look at large, real-world projects.

• Travis CI: A very early Ember adopter. The Ember project makes heavy use of Travis, so thank you!
• Discourse: The increasingly popular forum engine that now powers TalkingPointsMemo and BoingBoing. These folks have contributed heavily to Ember and its community.
• Balanced: Balanced is an open-source, open company. They use Ember for their dashboard.

Undefined Semantics

There are two areas of Ember.js that have semantics that may accidentally work in some cases today, but are the source of a number of bugs, and which we don't plan to support in the future.

Observer Timing

At present, Ember observers sometimes fire synchronously, but sometimes fire asynchronously. The only thing your code should rely on is that the observer will fire after the property it observes has changed.

We plan to bring all observers into alignment with Object.observe, a future JavaScript feature. In the future, observers will never fire synchronously. If you rely on specific timing, your code may break.

Observing Properties of Framework Objects

In general, you should not observe properties of framework objects defined by the framework that are not explicitly documented as observable. Some of these observations may happen to work today, but may not work in the future.

For example, you should not observe the element property on an Ember view or component. Instead, you should use the didInsertElement hook.

If you find yourself observing a framework-defined property that is not documented as observable to work around an issue, please file an issue with us so we can give you a publicly defined API.

The Future

Despite our commitment to stability, we are not resting on our laurels. We have an aggressive pipeline of new features planned, which we'll be announcing soon.

We're also switching our releases to follow a more Chrome-like model. This means that you can expect a new release every six weeks. We'll have more details about this soon.

Thanks

Special thanks to a number of community members who have done heroic work leading up to Ember 1.0:

• Eric Berry, for the new Cookbook section in the guides and examples
• Paul Chavard, for help reviewing Ember Data 1.0 Beta 1
• Domenic Denicola, for putting us on the right path with promises
• Dan Gebhardt, for website infrastructure
• David Hamilton, for the Array Computed feature
• Robert Jackson, for the new emberjs.com/builds
• Julien Knebel, for design work
• Alex Matchneer, for the async router guide
• Luke Melia, for actions namespacing, last minute bugfix work, and the Ember NYC community
• Alex Navasardyan, for inline examples on the homepage and design work
• Stanley Stuart, for testing infrastructure
• Igor Terzic, for help reviewing Ember Data 1.0 Beta 1
• Teddy Zeenny, for the Ember Inspector
• The 300 people who submitted code and documentation to Ember 1.0
• The 131 people who submitted code and documentation to Ember Data 1.0 Beta 1
• The 269 people who helped with emberjs.com

Go forth and build great things!

First up is Ember.js 1.1.1, the inaugural stable release after our switch to a Chrome-like six week release cycle.

Because this is the kickoff release of the new process, there are very few new features and the delta between 1.0 and 1.1.1 is very small. This release is composed primarily of bug fixes and performance improvements, so we recommend you upgrade right away.

For a list of exactly what's new, see the CHANGELOG.

(If you're wondering why 1.1.1 and not 1.1, there was a regression introduced in Ember.Object.create() that could break 1.0-compatible apps that we didn't notice until after we'd tagged the 1.1 release.)

To coincide with the stable release, we've also got a new beta release of Ember 1.2. Beta releases are intended to get more eyeballs on new features that look ready to go, but may have bugs or edge cases that we haven't yet sussed out.

The only changes between a beta release and the stable version should be bug fixes and removing features that originally looked ready but didn't end up making the cut.

For a full list of the new features in Ember 1.2 beta, see the CHANGELOG.

As always, Ember 1.1 and 1.2 beta are available at emberjs.com/builds. If you're feeling particularly adventurous, you can also grab a Canary build to see what we're in the middle of working on, though do note that all new APIs in Canary are subject to change. To see what features are available to be enabled, see FEATURES.md.

We're excited about kicking off the new release process because we think that it will allow us to deliver a higher-quality product more frequently. We also believe that using feature flags in our Canary builds will allow us to more easily experiment with new APIs, which translates to more features faster.

As always, if you find bugs or need help, please file an issue on GitHub.

Lastly, my sincere thanks to everyone who has contributed features, bug reports and bug fixes to this release.

In particular, I'd like to call out Robert Jackson (@rwjblue) and Thomas Boyt (@thomasABoyt) for their superheroic efforts on the infrastructure required to make this type of release process work smoothly.

Early on, Yehuda and I made a bet that investing in making Ember.js a community project would pay dividends. We've sometimes questioned that decision when going up against better-funded competitors, but this release, I think, vindicates our decision.

This is a truly community-driven release, and both Yehuda and I were hands-off through most of it. I am deeply grateful to everyone who sacrificed hours of their nights and weekends to help us build something that matters.

If you'd like to be a part of it, we have a welcoming and helpful community, and we'd love to have you join. Come see us in #emberjs on Freenode to ask questions and get involved.

Enjoy the new releases, and go forth and build great things!

We recommend that everyone using 1.1.0 and 1.1.1 upgrade at their nearest convenience. Head on over to emberjs.com/builds to download. Our apologies for the inconvenience.

Ember 1.2 Beta 2

While we were at it, we also released the second 1.2 beta which includes a couple of bug fixes. 1.2.0-beta.2 is also available at emberjs.com/builds.

The 1.10 release represents the effort of at least 50 contributors across over 553 commits.

The HTMLBars Templating Engine

Throughout 2014 the Ember.js community has poured its shared effort into a new templating solution. This new library, dubbed HTMLBars, makes available features and performance improvements impossible to support with Handlebars (the previous library). We are delighted to announce the inclusion of the HTMLBars templating engine in Ember.js 1.10.

HTMLBars will enable the implementation of several APIs described in The Road to Ember 2.0, and contributes to our continued improvement of rendering performance. Additionally, it will allow us to continue supporting all Ember 1.x template syntax.

This long-term effort would not have succeeded without the continued contributions of the Ember community and core team. In no particular order and with apologies to anyone we've missed we would like to thank @krisselden, @wycats, @_mmun, @nerd20, @mixonic, @ebryn, @salzhrani, @rwjblue, @tomdale, oneeman, @kpdecker and the many alpha and beta testers who provided feedback and bug reports. You are the stuff "stability without stagnation" is made of.

New Features in Ember.js 1.10

HTMLBars 0.8.5

Ember.js 1.10 is dependent on HTMLBars 0.8.5. To ease this and later template library version changes, Ember's template compiler will be packaged as a part of the release files. For example, a JSBin in Ember 1.9 would need to be updated from:

<script src="http://builds.handlebarsjs.com.s3.amazonaws.com/handlebars-v2.0.0.js"></script>
<script src="http://builds.emberjs.com/tags/v1.9.1/ember.js"></script>

to

<script src="http://builds.emberjs.com/tags/v1.10.0/ember-template-compiler.js"></script>
<script src="http://builds.emberjs.com/tags/v1.10.0/ember.debug.js"></script>

The ember-template-compiler.js is only required for template compilation. The runtime dependencies for HTMLBars are built into the framework file.

To smoothly upgrade to 1.10 and HTMLBars, Ember-CLI users should update to a version at or after 0.1.12, remove their application's Handlebars dependency, and modify the Brocfile to not load Handlebars. This diff shows the changes needed to upgrade an Ember-CLI app to 1.10.

Ember App-Kit users should upgrade to Ember-CLI.

Ember-Rails users should upgrade to version 0.16.1, then remove their Handlebars dependency.

Developers of applications that follow a non-standard build pipeline should review the instructions published by Robert Jackson this week and join the conversation at discuss.emberjs.com or on IRC.

Performance Improvements

Ember.js 1.8 introduced a performance regression that we expected to re-coup in the 1.10 release. In December the team at Discourse created the ember-performance repo. This project aids Ember developers in profiling and measuring performance in the framework.

Using these benchmarks, we're pleased to report a twelve percent improvement in common rendering scenarios between 1.7 and 1.10, and as much as a fifty percent improvement between 1.9 and 1.10.

Better rendering and general framework performance continue to be a priority for the core team and community. Specific goals include reactive rendering for HTMLBars, more optimized metal views, limiting observation, and refinements to the Ember object model.

Chained Else Blocks

HTMLBars is built using the Handlebars parser, and will continue to gain features related to template syntax. Ember 1.10 features support for chained else helpers, the most common use being else if. An example:

{{#if isAtWork}}
  Ship that code!
{{else if isReading}}
  You can finish War and Peace eventually...
{{/if}}

Chained else helpers work with any else, including those of with and each helpers.

You can read more about the implemetation in the Handlebars repo. Thanks to @kpdecker for this improvement.

Block Params

Ember 1.10 introduces block parameters. Block params provide consistent scope to templates, and allow components to pass internal values to a downstream scope.

For example:

{{currentUser.name}} {{! available on the controller }}
{{#each cars as |car|}}
  {{#with car.manufacturer as |make|}}
    {{make.name}}
    {{currentUser.name}} {{! still the controller scope }}
  {{/with}}
{{/each}}

Preserving template context results in easier to read templates, and passing variables into child scopes allows for new patterns of component composition.

Block params are passed from a template via the yield helper. For example, this component yields the fullName and age values:

// app/components/x-customer.js
export default Ember.Component.extend({
  fullName: function(){
    var customer = this.get('customer');
    return [customer.get('firstName'), customer.get('lastName')].join(' ');
  }.property('customer.firstName', 'customer.lastName'),

  age: function(){
    return (new Date() - this.get('birthday')) / (86400000 * 365);
  }.property('birthday')
});

{{!-- app/components/x-customer.hbs --}}
<div class="customer">
  {{yield fullName age}}
</div>

{{!-- app/templates/index.hbs --}}
<div class="layout">
  {{#x-customer customer=model birthday=model.birthday as |fullName age|}}
    Hello, {{fullName}}. You are {{age}} years old.
  {{/x-customer}}
</div>

Many thanks to @_mmun for the implementation of this new feature.

Injected Properties

Ember 1.x has exposed two APIs for managing dependency injection. The first is the application initializer API, using register and inject methods on an application instance. The second allows configuration of an injection on controllers via needs. You can read more about these patterns in the dependency injection guide.

The new injected properties offer a more declarative API for dependency injection.

Use Ember.inject.service() to inject a service with the same name as the property it is injected as. In this example, the storage service is injected onto the storage property:

export default Ember.Component.extend({
  storage: Ember.inject.service()
});

Passing a name to the service() method allows a different service to be injected. For example:

export default Ember.Component.extend({
  storage: Ember.inject.service('local-storage')
});

In addition to injecting services, controllers can be injected with Ember.inject.controller.

Importantly, these injections are lazy. When used within a unit test, a stubbed service can be passed during create. For example:

test("a value is saved on storage", function(){
  expect(1);
  var component = this.subject({
    storage: {
      write: function(){
        ok(true, 'value was written');
      }
    }
  });

  var element = this.append();
  element.click();
});

Refer to the API documentation to read about this new feature in detail.

Thanks to slindberg for his implementation of this feature.

Notable Deprecations

As Ember.js moves forward, various APIs are deprecated to allow for their removal in a later major release (such as 2.0). The deprecations page summarizes deprecations and demonstrates how to update to a new API.

• The explicit {{bind}} helper has been deprecated. This helper has long been marked private, and was a legacy Sproutcore feature. This helper will be removed in Ember 1.11.
• Quote-less outlet names are deprecated in 1.10. An example of this is {{outlet modal}}, which should be re-written as {{outlet "modal"}}. This ensures the outlet helper is consistent with others, where unquoted words are values and not string literals.
• The beforeObserver feature is deprecated in Ember 1.10. Before observers are rarely used, but introduce significant overhead to the observer system in general. For observer use that requires the previous value of a property be known, implementing a cache is easier and more efficient. Read more about how to do this on the deprecations page.
• Observing the childViews array of a ContainerView is deprecated.
• Setting the childViews property on a view definition is deprecated in 1.10. For example:

var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  childViews: [ 'childA', ChildB ],
  childA: Ember.View.extend()
});

This use of childViews is inconsistent with other uses throughout Ember, and as a result is difficult to implement with good performance. Explicitly creating views upon initialization is preferred:

var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  init: function(){
    this._super();
    this.pushObject(this.createChildView(this.childA));
    this.pushObject(this.createChildView(ChildB));
  },
  childA: Ember.View.extend()
});

New Features in Ember.js 1.11 beta

Ember.js 1.11 beta continues a series of releases iterating the framework toward our 2.0 goals. In six weeks, these and a few other features will be declared stable.

Inline if

In 1.11 Ember's if helper can be used in the inline form:

{{if isEnabled 'active' 'disabled'}}

Thanks to @marciojunior_me for implementing this feature.

Each with Index

The each helper will support an index block param in Ember 1.11:

{{#each people as |person index|}}
  {{! The first index value will be 0 }}
  <div>{{index}}: {{person.name}}</div>
{{/each}}

Thanks to @_mmun for implementing this feature.

Bound Attribute Syntax

Current Ember developers are familiar with the bind-attr syntax, used to declare an attribute binding on an HTML element. An original motivation for HTMLBars was to improve on this syntax.

Ember 1.11 introduces a more intuitive API for attribute binding. For example, here the color variable is bound to the class of a div:

<div class="{{color}}"></div>

The inline if helper can also be used in these contexts:

<div class="{{color}} {{if isEnabled 'active' 'disabled'}}"></div>

For some attributes, like the disabled boolean, passing a literal value is desirable. An example:

<input disabled={{isDisabled}}>

To allow the data-binding of non-string values to boolean properties and custom element properties, bound attributes are implemented with a property-first setter.

When binding to an attribute, Ember first checks to see if that attribute is a property of the element's DOM node (with normalization of capitalization). If it is, the value is set with a property. For example:

<input disabled={{isDisabled}}>

// disabled is a property of input elements, so...
input.disabled = true;

If the attribute is not present as a property, then its value is set as an attribute:

<div class={{color}}>

// class is not a property of div elements, do...
div.setAttribute('class', 'red');

For SVG attributes and the style attribute, we've made a exceptions to this pattern. Despite these exceptions, the property-first rule is a good way to describe what is happening behind the scenes. In practice, the binding syntax feels natural.

Many thanks to @mixonic, @_mmun, and @wycats for their effort on the design and implementation of this feature.

Named Substates

Two routing substates exist for Ember routes. The loading substate will be entered if the async hooks of a route are still processing, and the error substate will be entered when an async hook promise is rejected.

Substates are sibling routes. When the new route of cars.new is loading, the cars.loading substate is entered. The application route has no parent namespace to nest its siblings. This makes using the loading and error substates impossible for an application route.

Named substates add a new lookup method for substates. The name of the route is pre-pended onto the substate. So a valid loading substate for application can be defined as application_loading.

Thanks to @machty for landing this feature.

Component Helper

Ember components can be bound via the component helper. For example this logic in a template:

{{#if isRed}}
  {{x-red}}
{{/if}}
{{if isBlue}}
  {{x-blue}}
{{/if}}
{{if isGreen}}
  {{x-green}}
{{/if}}

Can now be replaced by a computed property and the component helper.

{{component colorComponentName}}

The property colorComponentName should have a value of x-red, x-blue etc. As the value of the property changes, the rendered component will also change.

A big thank you to @lukemelia for shipping this new feature.

Notable Deprecations in 1.11

The following deprecations are scheduled for release with Ember.js 1.11:

• The ObjectController will be removed in Ember 2.0. In Ember 1.11, both explicitly using an ObjectController and using the proxying behavior of a generated ObjectController will raise deprecation warnings.

As the features included in Ember 1.12 are developed, additional deprecations may be added to the 1.11 release.

Changelogs

• Ember.js 1.10.0 CHANGELOG
• Ember.js 1.11.0-beta.1 CHANGELOG

Using Ember? Please take ten minutes to share your feedback by participating in the 2015 Ember Community Survey. Open until February 20th.

The 1.11 release represents the effort of at least 87 contributors across over 646 commits.

New Features in Ember.js 1.11

Bound Attribute Syntax

Current Ember developers are familiar with the bind-attr syntax, used to declare an attribute binding on an HTML element. An original motivation for HTMLBars was to improve on this syntax.

Ember 1.11 introduces a more intuitive API for attribute binding. For example, here the color variable is bound to the class of a div:

<div class="{{color}}"></div>

The inline if helper can also be used in these contexts:

<div class="{{color}} {{if isEnabled 'active' 'disabled'}}"></div>

For some attributes, like the disabled boolean, passing a literal value is desirable. An example:

<input disabled={{isDisabled}}>

To allow the data-binding of non-string values to boolean properties and custom element properties, bound attributes are implemented with a property-first setter.

When binding to an attribute, Ember first checks to see if that attribute is a property of the element's DOM node (with normalization of capitalization). If it is, the value is set with a property. For example:

<input disabled={{isDisabled}}>

// disabled is a property of input elements, so...
input.disabled = true;

If the attribute is not present as a property, then its value is set as an attribute:

<div class={{color}}>

// class is not a property of div elements, do...
div.setAttribute('class', 'red');

For SVG attributes and the style attribute, we've made an exception to this pattern and use setAttribute at all times. Despite these exceptions, the property-first rule is a good way to describe what is happening behind the scenes. In practice, the binding syntax feels natural.

Many thanks to @mixonic, @_mmun, and @wycats for their effort on the design and implementation of this feature.

Escaping Content in HTMLBars

Bound attribute syntax introduces several new uses of mustaches (the {{ syntax used in Ember templates). These new uses come with new security considerations.

Two notable new considerations are mustache use inside style contexts, and inside JavaScript contexts. For example, without escaping this binding would be vulnerable to an XSS attack (via ActiveX controls) in IE8:

<div style="width: {{userProvidedWidth}}px;"></div>

Implementing CSS and JavaScript context-sensitive escaping will require further research and development. In Ember 1.11, bound style attributes will warn when the value is not marked safe.

{{! No escaping strategy, log a warning }}
<a style="width: {{someProperty}}px"></a>

The examples that follow are intended to demonstrate how this works in practice.

{{! Works as expected }}
<a class="{{someProperty}}"></a>

{{! Works as expected, and escapes unsafe urls }}
<a href="{{someProperty}}"></a>

{{! Works as expected, and escapes unsafe urls }}
<img src="{{someProperty}}"></a>

Warnings about unsafe bindings other than style will be introduced before Ember 2.0.

{{! No escaping strategy in 1.11 }}
<a onmouseover="alert('{{someProperty}}');"></a>

{{! No escaping strategy in 1.11 }}
<style>width: {{someProperty}}px</style>

Strings that are known to be adequately escaped can be passed through the htmlSafe function to mark them safe.

import Ember from "ember";

export default Ember.Component.extend({
  layout: Ember.HTMLBars.compile("<a style='width: {{someProperty}}px'>"),
  someProperty: function(){
    return Ember.String.htmlSafe(this.get('someKnownSafeProperty'));
  }.property('someKnownSafeProperty')
});

A less savory alternative is to use the {{{ "escaped mustache" style. There are plans to improve escaped content as we approach 2.0.

Inline if

In 1.11 Ember's if helper can be used in the inline form:

{{if isEnabled 'active' 'disabled'}}

Thanks to @eaf4 and @marciojunior_me for implementing this feature.

Each with Index

The each helper will support an index block param in Ember 1.11:

{{#each people as |person index|}}
  {{! The first index value will be 0 }}
  <div>{{index}}: {{person.name}}</div>
{{/each}}

Thanks to @timmyce and @_mmun for implementing this feature.

Named Substates

Two routing substates exist for Ember routes. The loading substate will be entered if the async hooks of a route are still processing, and the error substate will be entered when an async hook promise is rejected.

Substates are sibling routes. When the new route of cars.new is loading, the cars.loading substate is entered. The application route has no parent namespace to nest its siblings. This makes using the loading and error substates impossible for an application route.

Named substates add a new lookup method for substates. The name of the route is pre-pended onto the substate. So a valid loading substate for application can be defined as application_loading.

Thanks to @machty for landing this feature.

Component Helper

Ember components can be bound via the component helper. For example this logic in a template:

{{#if isRed}}
  {{x-red}}
{{else if isBlue}}
  {{x-blue}}
{{else if isGreen}}
  {{x-green}}
{{/if}}

Can now be replaced by a computed property and the component helper.

{{component colorComponentName}}

The property colorComponentName should either have a value of x-red, or x-blue etc. As the value of the property changes, the rendered component will also change.

A big thank you to @lukemelia for shipping this new feature.

Performance Improvements

Ember.js 1.10 has favorable rendering performance compared to previous releases. We're pleased that Ember 1.11 builds upon that progress. Compared to 1.10, common list rendering scenarios have improved by about twenty percent and view instance creation is over twice as fast. These measurements were made using the ember-performance repo.

Progress continues on the Glimmer rendering engine announced at EmberConf 2015. This dramatic performance improvement is expected to land in Ember.js 1.13.

Notable Deprecations in 1.11

The following deprecations are scheduled for release with Ember.js 1.11:

• The ObjectController will be removed in Ember 2.0. In Ember 1.11, both explicitly using an ObjectController and using the proxying behavior of a generated ObjectController will raise deprecation warnings. See the deprecation guide for more details.
• Initializing instances (via container.lookup) in initializers is deprecated. For initialization that requires instances Ember has introduced "instance initializers". See the deprecation guide for more information, as well as this documentation PR and the implementation PR.
• Not a deprecation, but related: The {{bind}} template helper was a private helper, and has been deprecated since Ember 1.10. It has been removed in Ember.js 1.11.

Changelogs

• Ember.js 1.11.0 CHANGELOG
• Ember.js 1.12.0-beta.1 CHANGELOG

CollectionView with attributeBindings

During the 1.11.0 cycle much effort was put into making sure that attributeBindings used the same logic that template bound attributes use. Namely, that attributeBindings use HTMLBars' attribute helpers instead of jQuery's.

Unfortunately, this work lead to an error when CollectionView instances were used with attributeBindings specified. This regression is fixed in 1.11.1.

Invalid URLs

Refactoring in the router initialization process lead to a bug that caused the browsers URL to become out of sync with the correct URL when the back button was pressed while using HistoryLocation.

This regression is fixed in 1.11.1.

Handlebars Helper Issues

A couple regressions were fixed for Handlebars helpers with 1.11.1:

• The inverse template (aka {{else}} block) of Handlebars helpers was not properly accounted for during the HTMLBars transition. Using an {{else}} block with a Handlebars helper has not been function since 1.9.0.
• The main block could not be rendered even if options.fn() was called within the helper. This regression was first introduced in 1.11.0-beta.4.

Incorrect Assertion for {{each foos itemControler='bar'}}

During the 1.11.0 cycle, an issue was reported regarding {{each}} when prototype extensions were turned off. The solution to that issue was to add a much more helpful assertion when an ArrayController's model did not have Ember.Array mixed into it. Unfortunately, this assertion also was triggered when the model was undefined. The assertion has been updated to ignore falsey model's in 1.11.1.

{{render}} helper with View

In 1.11.0 using the {{render}} helper (i.e. {{render 'post'}}) when a PostView is present would not provide the view with a template (it was assumed to be manually specified in the view via templateName property). As of 1.11.1 you can specify the templateName in the {{render}} helpers view (similarly to in 1.11.0), but if you do not the views template will be defaulted to a template with the same name as the view itself.

Changelogs

• Ember.js 1.11.0 to 1.11.1 commit log
• Ember.js 1.11.1 CHANGELOG

1.13 beta is the first Ember.js release that includes Glimmer, the new Ember rendering engine, as well as the final batch of Ember 2.0 features. We will discuss those details more below.

New Features in Ember 1.12

Ember 1.12 is a relatively light release, and includes features that move Ember closer to ES6 class syntax and the first parts of the internal implementation needed for a stable release of the FastBoot addon.

New Computed Syntax

Per RFC #11, Ember is introducing a new syntax for computed properties. This change better aligns computed property syntax with JavaScript getters and setters and makes writing settable computed properties developer friendly.

It also has the nice side effect of improving performance, as the old syntax, with its two-in-one function signatures, was harder for JavaScript engines to optimize.

The simplest syntax for a computed property is to define the getter as a function:

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', function(){
    return this.get('height') * 1.618;
  })

});

This is still the way to write simple getters, the most common use-case for computed properties, in Ember 1.12.

To create a settable computed property in Ember 1.11 an if statement was used to differentiate the get from the set logic. For example:

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', function(key, value){
    if (arguments.length > 1) {
      this.set('height', value / 1.618);
    } else {
      return this.get('height') * 1.618;
    }
  })

});

This syntax was functional but error-prone, verbose, and hard to understand (for both humans and JavaScript engines).

In Ember 1.12, you can nicely separate the getter and setter into two different functions.

export default Ember.Object.extend({

  height: 100,
  goldenRatioWidth: Ember.computed('height', {
    get(key) {
      return this.get('height') * 1.618;
    },
    set(key, value) {
      this.set('height', value / 1.618);
      return value;
    }
  })

});

This also aligns Ember's API with JavaScript getters and setters, and simplifies the path towards using JavaScript getters in Ember 2.0, after IE8 support is dropped.

For more information see the initial implementation in #9527

Many thanks to @stefanpenner and @MiguelCamba for championing and shipping this feature.

One last thing: thanks to the experimental support for JavaScript decorators in Babel, we are also planning a further improvement in the near future:

export default Ember.Object.extend({

  height: 100,

  @computed('height')
  get goldenRatioWidth(key) {
    return this.get('height') * 1.1618;
  }

  set goldenRatioWidth(key, value) {
    this.set('height', value / 1.618);
  }

});

Instance Initializers

The next feature, instance initializers, makes it possible for FastBoot applications to run many requests concurrently.

Before FastBoot, you would only ever run applications one at a time. Even in automated tests, tests were run one at a time, in serial, so one application was destroyed before the next one was created.

In FastBoot, it is important for a single node server to be able to serve a second request while the first one is fetching its data.

Thankfully, Ember already ensures that all state is stored in the container, so in theory, all you need to do is give each request its own container instance and you get concurrent requests in FastBoot.

In practice, there was a minor API change we needed to make in order to make it work involving initializers. In Ember 1.11, initializers would run on app boot (or once per test). Some initializers were setting up code (and injection rules), which are the same across all FastBoot requests, while other initializers were creating instances, which are different across requests.

In Ember.js 1.12 application boot is separated into two phases:

• Application initializers run. At this phase of boot, the goal of initializers should be to register dependencies and injections. These initializers are doing work that is shared across all FastBoot requests, and therefore should not create instances. This phase runs once. Because these initializers may load code, they are allowed to defer application readiness and advance it.
• Instance initializers run next. This is the right time to do work that is specific to each FastBoot request. You can create instances and modify their state here. This phase runs when the browser application runs, for each integration test, and for each FastBoot request. These initializers run after code has loaded and are not allowed to defer readiness.

The two-phase initialization process is safer when multiple addons may be registering factories and injections.

Ember-CLI 0.2.3 supports instance initializers. For example:

// app/instance-initializers/sleep.js

export function initialize(application) {
  application.container.lookup('service:websocket').connect();
}

export default {
  name: 'sleep',
  initialize: initialize
};

To define an instance initializer in globals mode use the Ember.Application.instanceInitializer method. For more information about instance intializers see the implementation in #10256.

Thanks to @tomdale, @wycats and @dgeb for this feature and other refactoring work around application initialization.

Initializer Context

Previously, the this scope of an initializer was the global scope. #10179 changed initializer scopes to be the initializer object itself.

Thanks to @gf3 for suggesting and adding this feature.

Ember 1.13 Beta

And now, the big enchilada!

Together with the release of Ember 1.12, we are releasing the first beta of Ember 1.13.

Ember 1.13 is:

• the last minor release in the 1.x series
• the first release that includes the new Glimmer rendering engine

To recap; what is Glimmer?

• A new faster rendering engine that is especially fast at updates.
• An implementation of the React-inspired "just re-render it" programming model for components, with one-way data flow by default and better enforcement for data-down, actions-up.
• Supports angle-bracket components (<my-component />), ergonomic attributes (<my-link href="{{url}}.html">go home</my-link>), that hews closely to HTML syntax with a few small enhancements.

We'll be writing a blog post that expands on the programming model of Ember 2.0 and talks about the most important new features in the next few days, and full docs are coming as well.

We'd like to give a big thank you to the entire community for all the nights and weekends over the past few months getting Glimmer (almost) over the finish line. It's inspiring.

The 1.13.x Series

In most cases, you should expect Glimmer to be faster at both initial rendering and updates. If you find performance regressions in idiomatic usage in your app, we definitely want to hear about it. Please file bugs.

The Glimmer rendering engine changes parts of Ember that have been largely untouched since the days of SproutCore 2.0. In practice, this means that you may be relying on implementation details of the pre-Glimmer implementation that were not captured by tests, and that were not discovered during the Canary period.

Because of the magnitude of the internal change, we expect the first few Ember 1.13 betas to be less stable than other betas in the 1.x series. We need your help to find and fix compatibility regressions.

Please report any incompatibilities that you discover. We will investigate and consider shimming any regression that affects a significant number of apps, even if the root cause is a change in internal implementation details.

We know that there will likely be some compatibility regressions, especially in implementation details, that we do not catch during the 1.13 beta period. We plan to continue to release point releases to the 1.13 series to fix those details after 2.0 beta is released, and perhaps even for a while after 2.0 final is released.

Our goal is to ensure that most applications can upgrade to Ember 1.13.x, remove deprecations, and then upgrade to Ember 2.0 with minimal fuss. If a significant number of apps that are earnestly trying to upgrade this way cannot, we will continue to fix problems that are blocking upgrades.

For an in-depth look into our transition plan for users with existing Ember 1.x apps, please see the recent Transition to Ember 2.0 in Detail blog post.

CHANGELOGS

• Ember 1.12.0 CHANGELOG
• Ember 1.13.0-beta.1 CHANGELOG

The 1.13 release represents the effort of at least 43 contributors across over 680 commits.

Ember 1.13 is the last release in the 1.x series and the first release that includes the Glimmer rendering engine. It includes a number of deprecations that will ease the upgrade to Ember 2.0, which is due to land in six weeks.

Ember 2.0 beta is the first release in the 2.x series. This means that many features deprecated during the 1.x series will be removed in Ember 2.0. If you encounter any unexpected changes in features not marked as deprecated in 1.13 while testing Ember 2.0 beta, please report them immediately. We would like to fix these unintentional regressions before the final release of 2.0 in six weeks.

The release of Ember 2.0 beta also means that the first features in Ember 2.1 (most notably angle bracket components), are in their final canary stretch. Now is a good time to comment on RFCs and pull requests related to those features.

New Features in Ember.js 1.13

The Glimmer rendering engine, announced at EmberConf and introduced to Ember.js Canary on May 5th, is released today in Ember.js 1.13. Glimmer is the third overhaul of Ember's 1.x rendering layer (wow, right?), and dramatically improves re-render performance in many common scenarios. Additionally it lays important groundwork for the Ember 2.x development model.

We are tremendously excited to bring Glimmer to existing applications as a 1.x compatible minor release. The herculean efforts of the Ember core team, addon authors, and community to achieve this release has been inspiring. Thank you! You are too many to possibly name.

1.13 also marks the final minor release of the Ember 1.x cycle. As such, it contains a number of deprecations ahead of Ember 2.0. Resolving these deprecations in application code aligns that application with Ember's public API in 2.0. In general, Ember apps running 1.13 without causing any deprecation notices to fire should upgrade to 2.0 without changes.

The easiest way to work through deprecations is the Ember Inspector. Thanks to the work of Teddy Zeenny, deprecations will be routed to the "Deprecations" inspector pane, where you can get a grouped list of them as well as the line of code in your app that triggered the deprecation. You can also ask for a full stack trace of any deprecation.

Improved Rerender Performance

Previous iterations of Ember's rendering engine relied on granular observation for efficiency. When a piece of dynamic content was rendered, Ember registered observers, updating the content when the value changed.

While this was reasonably efficient in cases where the developer could use set (and the array equivalents) to mutate values, it had two related issues:

• This forced developers to represent all changes in terms of granular observers. In many cases this could be extremely awkward. This was especially problematic when working with Arrays, since (for example) representing a sort as a series of mutations is conceptually complex and can be cost-prohibitive.
• Ember itself was extremely inefficient when an entire object or array was replaced, despite the fact that this was often the most natural way to represent the change. This meant that while it was usually possible in theory to "just re-render" a component, it was, in practice, cost prohibitive (to say the least).

To address these issues, Glimmer adopts a value-diffing strategy, using a virtual tree of the dynamic areas of the DOM. This means that even if the original data structure (for example, an array) is completely replaced, the DOM is not updated unless the resulting rendered content has changed.

When updating an array with a new array (because you got a new array from the server, or because you produced a new array through .sort()), you will see a large improvement in performance, making this kind of replacement plausible in Ember.

Notably, the Ember strategy continues to support efficient updates via value observation, which we expect to be useful when communicating with services and models.

Glimmer's hybrid model can opportunistically take advantage of explicit mutation (via set) when it is used, while also supporting efficient re-renders of entire data structures, updating only the DOM nodes that need to be changed.

The result is a stunning improvement in many rerender cases.

We would like to thank React for showing that full re-renders can be made efficient. While we did not use their precise Virtual DOM approach, their work with Virtual DOM was extremely influential to our approach in Glimmer.

Thanks to @wycats and @tomdale for their continued focus on improving Glimmer's performance, and to LinkedIn and Bustle for their generous sponsorship of this work.

Component Lifecycle Hooks

A number of new component lifecycle hooks have been introduced to Ember 1.13. Using these hooks allows you to write data down, action up (DDAU) style components today, despite the two-way data binding of curly components.

On first render (in order):

• didInitAttrs runs after a component was created and passed attrs are guaranteed to be present. In Ember 1.13, the attributes will be available as this.get('attrName').
• didReceiveAttrs runs after didInitAttrs, and it also runs on subsequent re-renders, which is useful for logic that is the same on all renders. It does not run when the component has been re-rendered from the inside.
• willRender runs before the template is rendered. It runs when the template is updated for any reason (both initial and re-render, and regardless of whether the change was caused by an attrs change or re-render).
• didInsertElement runs after the template has rendered and the element is in the DOM.
• didRender runs after didInsertElement (it also runs on subsequent re-renders).

On re-render (in order):

• didUpdateAttrs runs when the attributes of a component have changed (but not when the component is re-rendered, via component.rerender, component.set, or changes in models or services used by the template).
• didReceiveAttrs, same as above.
• willUpdate runs when the component is re-rendering for any reason, including component.rerender(), component.set() or changes in models or services used by the template.
• willRender, same as above
• didUpdate runs after the template has re-rendered and the DOM is now up to date.
• didRender, same as above.

Note that a component is re-rendered whenever:

1. any of its attributes change
2. component.set() is called
3. component.rerender() is called
4. a property on a model or service used by the template has changed (including through computed properties).

Because of the Glimmer engine, these re-renders are fast, and avoid unnecessary work.

Closure Actions

In Ember 1.x, the actions system used bubbling as a solution for passing user behavior to a parent scope. For example, when clicking a button an action might bubble through several controllers then be handled on a route.

Action bubbling was difficult to debug, and plagued by an inability to have a return value (since the return value of an action handler controlled further bubbling).

Ember 2.x is component-driven, and replaces action bubbling with a function-passing solution. This greatly simplifies working with actions (they are functions, after all), enables return values, and introduces some powerful new currying capabilities.

For example, action submit is passed to my-component where it is called upon click:

// app/controllers/index.js
import Ember from "ember";

export default Ember.Controller.extend({
  actions: {
    setName(name) {
      model.set('name', name);
    }
  }
});

{{!-- app/templates/index.hbs --}}
{{my-component submit=(action 'setName')}}

// app/components/my-component.js
import Ember from "ember";

export default Ember.Component.extend({
  click() {
    this.attrs.submit(this.get('name'));
  }
});

Actions:

• Can be passed multiple arguments
• Return a value. For example var result = this.attrs.submit();
• Can curry. For example submit=(action 'setName' 'Sal') would pass "Sal" as the first argument to setName when submit is called. Actions can curry multiple times, adding arguments at each scope. For example submit=(action attrs.actionPassedIn someProp) adds an argument to any already curried onto actionPassedIn.

Additionally the action helper has two options:

• (action 'save' target=session) would look at the actions hash on the session object instead of the current context.
• (action 'save' value="currentTarget.value") would read the path currentTarget.value off whatever the first argument to the called action is. This is handy for destructuring objects passed as the first argument (like DOM events).

Note: Angle Bracket Components

Ember 2.1 will (likely) ship with angle-bracket components, which will introduce one-way data flow by default, and provide an opt-in for two-way data flow. Existing components maintain the existing behavior (for compatibility). While the internals of Ember 2.0 support a distinction between one-way and two-way bindings, that distinction will remain largely internal until Ember 2.1.

New Ember.js Helper API

Ember's helper story prior to 1.13 has been inconsistent and neglected. In 1.13, we're introducing a new API for writing helpers along with a set of constraints and features informed by real-world experience.

Ember helpers:

• Represent a single value
• Do not manage DOM or control flow
• Can recompute themselves, similar to how a component can rerender
• Can optionally access services
• Do not require a dash

Helpers come in two flavors. The first is a function-based API we call a shorthand helper. For example, this shorthand helper joins a first and last name:

// app/helpers/full-name.js
import Ember from "ember";

export default Ember.Helper.helper(function(params, hash) {
  return params.join(' ');
});

This helper can be used in a variety of contexts:

{{full-name "Daniel" model.lastName}}
{{my-component name=(full-name model.firstName "Smith")}}
{{! The following usage would set the model.name to the new full name
    when my-component calls the submit action. }}
{{my-component submit=(action (mut model.name) (full-name model.firstName "Smith"))}}

Helpers receive two arguments: params are the ordered params passed to a helper, and hash contains the key-value options, for example title="Mr.".

This function version satisfies a wide array of use-cases and is quite powerful. In general, you should use this helper form unless you have a strong reason to do otherwise.

Some helpers, especially in addons, may require access to other parts of Ember (services), and some control over their own invalidation and recomputation. In these cases, a helper class can be used.

For example, this helper computes a name based on a name-builder service. It also recomputes whenever the isAnonymized state on that service changes:

// app/helpers/full-name.js
import Ember from "ember";

export default Ember.Helper.extend({
  // This service name is only an example
  nameBuilder: Ember.inject.service(),
  compute(params, hash) {
    return this.get('nameBuilder').build(params, hash.title);
  },
  rebuildName: Ember.observer('nameBuilder.isAnonymized', function() {
    this.recompute();
  })
});

For more information on the new helper API please see RFC #53 on helpers and RFC #58 on dashless helpers. Thanks to the addon community (especially @jamesarosen) for bringing the requirements for this API to our attention and testing changes with little notice. Thanks to @mixonic and @rwjblue for the implementation.

Component Block Info

Ember.js 1.13 introduces two new template keywords that provide reflection on how a component is called.

hasBlock will be true when a component is invoked in block form. For example given this component:

{{!-- app/components/show-full-name.hbs --}}
{{#if hasBlock}}
  {{yield fullName}}
{{else}}
  {{fullName}}
{{/if}}

Then these two usages would be valid:

{{! app/index/template.hbs }}

Full name: {{show-full-name firstName=firstName lastName=lastName}}

{{#show-full-name firstName=firstName lastName=lastName as |fullName|}}
  Full name: {{fullName}}
{{/show-full-name}}

Additionally, hasBlockParams will be true if the component is invoked with block params (invoke in block form with as |someParam|).

Thanks to @mmun and @rwjblue for implementing this feature.

Notable Deprecations in 1.13

In preparation for Ember 2.0, 1.13 introduces many deprecations. These include:

• All view APIs in Ember. See deprecation guide
  • Ember.CoreView, Ember.View, Ember.CollectionView, Ember.ContainerView
  • {{view 'some-helper'}}
  • The {{view}} keyword for accessing properties on a view
  • Ember.Select and {{view "select"}}. See deprecation guide
  • Ember.LinkView in favor of Ember.LinkComponent. See deprecation guide
• Options to the {{#each helper that trigger a legacy and poorly performing legacy layer. These options are: itemView, itemViewClass, tagName, emptyView and emptyViewClass.
• The itemController argument for {{#each.
• The bind-attr helper. Using helpers and HTMLBars-style attribute binding is preferred.
• Reading this.get('template') to check for a yielded block on components. Instead, use the hasBlock API.
• Non-block param {{with
• The view and viewClass params for {{outlet}}
• Ember.reduceComputed and Ember.arrayComputed in favor of plain normal array manipulations. See deprecation guide

Ember 2.0 beta

Last November, @wycats and @tomdale published The Road to Ember 2.0, an RFC summarizing Ember's goals for a 2.0 release. At EmberConf, when some of these changes were already complete and others not begun, they announced our intent to ship 2.0 beta on June 12th.

Together, the features summarized in the 2.0 RFC describe a new way to author Ember applications. Model-View-Controller is replaced by Model-Route-Component-Service. Two-way bindings are replaced by data down, actions up (DDAU).

Ember 2.0 will not introduce the entirety of our improved development model. However it will take significant steps in that direction, and allow the removal of public APIs that have been difficult to maintain while we iterate forward.

Because of the focus on landing migration paths for 1.x codebases in 1.13, 2.0 will have few new features. Among them are:

each-in helper

The each-in helper allows the iteration of object properties. For example, given this value for items:

let items = {
  "Item 1": 1234,
  "Item 2": 3456
};

The following template will iterate the keys:

{{#each-in items as |key value|}}
  <p>{{key}}: {{value}}</p>
{{/each-in}}

Note that this helper is unbound. Adding a new property to items will not cause a rerender, but .set('items', val) will.

Thanks to @tomdale and implementing this feature, and to several others for helping push it to completion.

get helper

The get helper provides a bound way to fetch a single property from an object. For example given these items:

let items = {
  "Item 1": 1234,
  "Item 2": 3456
};

The following template display 1234:

{{get items 'Item 1'}}

This becomes more powerful when the second argument is a bound path:

{{get items somePathWithAKey}}

Thanks to @jmurphyau for implementing this feature.

Notable Breaking Changes in Ember 2.0

Ember 2.0 will remove a number of public APIs, all of which should have been deprecated in the 1.13 release and have a viable migration path. The Ember Deprecation Guide should provide a clear migration path for commonly used APIs.

During the 2.0 beta cycle we will be removing and disabling already deprecated APIs. Much of this work has not yet started, but the following represents what we believe the breaking changes will be.

Many controller APIs are removed in Ember 2.0. Routeable controllers still exist, but all other uses have been deprecated. This includes:

• {{render "some-controller"}}
• {{each item itemController="some-controller"}} - This usage can be replaced by nesting a component inside the item, and by using helpers.
• Ember.ObjectController
• Ember.ArrayController
• The {{controller}} keyword
• needs: on controllers

All view APIs are removed in Ember 2.0. This includes:

• Ember.CoreView, Ember.View, Ember.ContainerView and Ember.CollectionView
• Ember._Metamorph, Ember._MetamorphView
• The {{view "some-view"}} helper
• The {{view}} keyword
• {{each itemView=, {{each itemViewClass=, {{each tagName=, {{each emptyView=, {{each emptyViewClass
• Ember.Select and {{view "select"}}
• Ember.Checkbox is not removed, but will become a component instead of a view

The most commonly used parts of the view API will be supported into the forseeable future via a core-supported addon.

All Handlebars APIs are removed in Ember 2.0. This includes:

• Ember.Handlebars.helper, Ember.Handlebars.makeBoundHelper and Ember.Handlebars.helper
• Ember.Handlebars.compile

Several template helpers are removed in Ember 2.0. These include:

• {{bindAttr}}
• {{bind-attr}} (use HTMLBars-style attribute bindings instead)
• {{bind}}
• {{template}} (use {{partial}} instead)
• {{linkTo}} (use {{link-to}} instead)
• {{collection items}}
• Non-block params versions of {{#each}} and {{#with}}
• Legacy arguments to {{#each}}, {{outlet}}

The following routing APIs are removed:

• #hash paths with no forward leading slash

Other APIs:

• Ember.tryFinally
• Ember.tryCatchFinally
• Ember.required
• Ember.Map#remove
• Ember.Set
• Ember.computed.defaultTo
• Ember.DeferredMixin
• Ember.Deferred (use Ember.RSVP.Promise instead)
• Ember.reduceComputed and Ember.arrayComputed (use plain array manipulation)
• Ember.Freezable (use Object.freeze instead)

Additionally, IE8 is no longer supported in Ember 2.x. IE9+ is supported.

Many of these deprecated APIs will be moved into core-supported addons, or have already been moved.

Changelogs

• Ember.js 1.13.0 CHANGELOG
• Ember.js 2.0.0-beta.1 CHANGELOG

Hot off the presses, we've got 1.2.0 and 1.3.0 beta on deck for you. Since we started following a Chrome-like release cycle, we'll have two new releases for you every six weeks. 1.2.0 is the newest stable release; 1.3.0 beta is the latest beta channel release.

Beta releases are intended to get more eyeballs on new features that look ready to go, but may have bugs or edge cases that we haven't yet sussed out.

New in 1.2

Loading and Error Substates

While we'd all like to write apps that are fast and bullet-proof, sometimes your backend may be slow to respond, or generate an error, when your Ember app requests a model.

Dealing with those cases is much easier in Ember.js 1.2, thanks to conventional loading and error routes.

To learn how to set these up, see Loading and Error Substates section of the guides.

Non-block form {{link-to}} helper

Previously, the {{link-to}} helper required that you use it in block form:

{{#link-to "about"}}About Us{{/link-to}}

Ember 1.2 introduces a non-block form that is less verbose:

{{link-to "About Us" "about"}}

In the non-block form, the first argument is the text to wrap in an <a> tag, and the second argument is the route to link to.

sortBy

All objects that implement the Ember.Enumerable protocol now have a sortBy method that sorts the enumerable based on a property of each of the members.

For an example, see this JSBin.

Other Improvements

As usual, there are a ton of bug fixes and small improvements in this release. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.2.0 CHANGELOG
• Ember.js 1.3.0 beta 1 CHANGELOG

A very big thank you to everyone who contributed, and a special thank you to our release team that have collectively poured hours of their free time into automating the infrastructure around the release process.

As usual, you can always find the latest stable, beta, and canary releases at emberjs.com/builds.

While you're there, check out the new illustrations, courtesy of Leah Silber and Design Carnivore.

New in 1.3

Non-array Dependencies for ReduceComputed

Generally, using reduceComputed is all about efficiently computing the resulting value, but occasionally you might need to recompute every time. It is now possible to instruct reduceComputed to completely recompute when an item is added/removed (instead of calling the addedItem and removedItem callbacks).

This is done by using either non-array dependent keys or adding .[] to an array dependency.

Take a look at the following example:

Ember.Object.extend({
  // When `string` is changed, `computed` is completely recomputed.
  string: 'a string',

  // When an item is added to `array`, `addedItem` is called.
  array: [],

  // When an item is added to `anotherArray`, `computed` is completely
  // recomputed.
  anotherArray: [],

  computed: Ember.reduceComputed('string', 'array', 'anotherArray.[]', {
    addedItem: addedItemCallback,
    removedItem: removedItemCallback
  })
});

Testing

Testability of Ember applications is an ongoing priority, and the 1.3 release contains a number of updates that result in a dramatic improvement.

Custom wait() Hooks

You can now specify custom hooks to notify the asynchronous test helpers when all async actions have completed. Under Ember 1.2 if you need to wait for an IndexDB action, the default wait implementation would not wait until that action finished. Now you can register your own hook that will instruct wait that it is truly time to continue.

For example:

Ember.Test.registerWaiter(function() {
  return hasPendingTransactions() == 0;
});

This instructs the wait helper that the async actions are not finished until hasPendingTransactions is zero.

You can find more details here.

Lazy Routing

Under Ember.js 1.2 routing is started as soon as you boot your application and before you call visit. This results in duplicate routing which slows down your tests and also potentially causes your tests to be less isolated.

Under Ember.js 1.3 routing isn't started until you call visit for the first time. This provides a couple of improvements to the way you test:

• You do not need to call App.advanceReadiness() in your test setup since the application is automatically in a deferred state until calling visit.
• App.reset() now leaves the application in the same state as App.setupForTesting() (a deferred state).

You can find more details here.

Stubbable controllers Property

Prior to Ember 1.3 you could not easily stub out any dependencies specified with needs. Now you can unit test controllers and stub their dependencies all within TheControllerClass.create() instead of having to use a container, register stubbed dependencies, and instantiate the controller via container.lookup().

Simplified example:

var BrotherController = Ember.Controller.extend({
  needs: 'sister',
  foo: Ember.computed.alias('controllers.sister.foo')
});

var broController = BrotherController.create({
  controllers: {
    sister: { foo: 5 }
  }
});

equal(broController.get('foo'), 5, "`needs` dependencies can be stubbed");

Previously, specifying controllers to BrotherController would have resulted in an error, and now under Ember.js 1.3 this works as expected.

Promise Improvements

Ember.js 1.3 has updated to RSVP 3.0.3 which brings considerable performance improvements, a number of new features, and significantly improved documentation coverage.

RSVP has added a number of features that allow external tooling to be able to inspect and track the labels, states, and values of promises. These improvements will be extremely useful when used with the next major version of the Ember Inspector. Which will allow you to see a tree of promises and inspect their names, state, and fulfilled/rejected values.

RSVP added a number of additional methods to Promise:

• Promise.cast - Coerces the given argument into a promise, or returns the argument if it is already a promise.
• Promise.catch - catch is essentially syntactic sugar for then(undefined, onRejection) which makes it the same as the catch block of a try/catch statement.
• Promise.finally - The callback provided to Promise.finally will be invoked regardless of the promises fate (both fulfilled and rejected promises). This is essentially similar to native try/catch/finally statements.
• Promise.race - Will return a new promise which will be settled with the value of the first promise that settles. In other words: given an array of promises Promise.race will return the value from the first argument that settles (like the winner in a "race").

Please review the documentation for more information.

Other Improvements

As usual, there are a ton of bug fixes and small improvements in this release. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.3.0 CHANGELOG
• Ember.js 1.4.0 beta 1 CHANGELOG

New features in 1.4

Property Brace Expansion

In prior versions of Ember if you wanted to observe both foo and bar on baz you would need to setup both baz.foo and baz.bar as dependent keys.

var obj = Ember.Object.extend({
  baz: {foo: 'BLAMMO', bar: 'BLAZORZ'},

  something: function(){
    return this.get('baz.foo') + ' ' + this.get('baz.bar');
  }.property('baz.foo', 'baz.bar')
});

With the new property brace expansion, you could setup the computed properties dependencies instead like:

  something: function(){
    return this.get('baz.foo') + ' ' + this.get('baz.bar');
  }.property('baz.{foo,bar}')

This allows much less duplication/redundancy when your dependent keys are mostly similar.

See the original PR #3538 for more details.

Ember.run.bind

Ember.run.bind provides a useful utility when integrating with non-Ember libraries that provide asynchronous callbacks.

Ember utilizes a run-loop to batch and coalesce changes. This works by marking the start and end of Ember-related JavaScript execution.

When using events such as a View's click handler, Ember wraps the event handler in a run-loop, but when integrating with non-Ember libraries this can be tedious.

For example, the following is rather verbose but is the correct way to combine third-party events and Ember code.

var that = this;
jQuery(window).on('resize', function(){
  Ember.run(function(){
    that.handleResize();
  });
});

To reduce the boilerplate, the following can be used to construct a run-loop-wrapped callback handler.

jQuery(window).on('resize', Ember.run.bind(this, this.handleResize));

For more details please reference the recently added run-loop guide (much thanks to Brendan Briggs).

With Controller

The {{with}} helper can now accept a controller option. Adding controller='something' instructs the {{with}} helper to create and use an instance of the specified controller with the new context as its content.

This is very similar to using the itemController option with the {{each}} helper.

{{#with users.posts controller='userBlogPosts'}}
  {{!- The current context is wrapped in our controller instance }}
{{/with}}

In the above example, the template provided to the {{with}} block is now wrapped in the userBlogPost controller, which provides a very elegant way to decorate the context with custom functions/properties.

Lazily Bound Attributes

Previously, every attribute that was bound added some degree of cost (mostly associated with maintaining the bindings/observers themselves). This lead us to limit the list of attributes that were automatically bound for Ember.TextField, Ember.TextArea, and friends. This is a common source of frustration as more and more people want to bind to HTML5 attributes, but find that to do so they must reopen the Ember.TextField class and add the attributes they need.

This might look like:

Ember.TextField.reopen({
  attributeBindings: ['autofocus']
});

Then from the template:

{{input autofocus=omgAutofocusMe}}

This certainly is not ideal, and causes many issues for people that expect it to "just work".

Thankfully, this has gotten MUCH better with the 1.4 release. In 1.4 any attribute bindings that do not exist at the time the view is first rendered will not have observers setup (therefore removing the original performance concern), but if/when the attribute is set on the view later (after the first render) an observer is setup at that time.

This means that we are only creating observers for actual properties that are present, but we can list every valid HTML attribute in the attributeBindings property so that you can use them without having to reopen internal classes.

As of Ember 1.4 you should be able to use any HTML5 attribute with {{input type="text"}}, {{textarea}}, and {{checkbox}}.

Other Improvements

As usual, there are a ton of bug fixes and small improvements in this release. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.4.0 CHANGELOG
• Ember.js 1.5.0-beta.1 CHANGELOG

New features in 1.5

Handlebars Logging of Primitive Values

This feature allows you to log primitive values (strings, numbers, etc) from within your templates. Previously, the {{log}} helper only allowed usage of bound property lookup.

{{log "**LOOKEY HERE**"}}

New Testing Helpers

Routing Helpers

A few new testing helpers have been added to make it easier to make assertions on the state of routing in your application (for example to confirm clicking a given link results in a redirect to a specific route).

New routing test helpers: currentRouteName, currentPath, and currentURL.

Trigger Event Helper

A new triggerEvent helper has been created to allow triggering of arbitrary events on an element.

triggerEvent('#some-element-id', 'dblclick');

Ember.computed.readOnly

Generally, when you use Ember.computed.oneWay you would also need to call readOnly to ensure no data propagates back up.

// prior to Ember.computed.readOnly you would have to do the following:
Ember.computed.oneWay('foo').readOnly()

// in 1.5 you can use the following for the same result:
Ember.computed.readOnly('foo')

Ember.isBlank

A new shortcut for checking if a particular object is empty or an empty string:

Ember.isBlank();                // true
Ember.isBlank(null);            // true
Ember.isBlank(undefined);       // true
Ember.isBlank('');              // true
Ember.isBlank([]);              // true
Ember.isBlank('\n\t');          // true
Ember.isBlank('  ');            // true
Ember.isBlank({});              // false
Ember.isBlank('\n\t Hello');    // false
Ember.isBlank('Hello world');   // false
Ember.isBlank([1,2,3]);         // false

Eager Updating URL

Previously, the URL in the address bar would only update at the very end of the transition. This change causes the URL update to happen immediately unless the transition was aborted/redirected within the same run loop, which provides for a better UX 99% of the time.

Auto Location

Adds auto as a location option for the app's Router.

App.Router.reopen({
  location: 'auto'
});

When used, Ember will select the best location option based off browser support with the priority order: history, hash, none.

Clean pushState paths accessed by hashchange-only browsers will be redirected to the hash-equivalent and vice versa so future transitions look consistent.

Bound Action Lookup

The {{action}} helper will now use a non-quoted parameter and perform a bound property lookup against the action's target at the time the event is triggered. This allows usage of a dynamic action name (determined by looking up the property).

Routes Inherit Model

Ember routes and leaf resources (without nested routes) will inherit the parent route's model.

Take the following example:

App.Router.map(function(){
  this.resource('post', function(){
    this.route('edit');
  });
});

App.PostRoute = Ember.Route.extend({
  model: function(){
    return {title: 'ZOMG', text: 'AWESOME'};
  }
});

App.PostEditRoute = Ember.Route.extend({
  model: function(){
    return this.modelFor('post');
  }
});

Now in 1.5, you do not have to define the model hook for PostEditRoute as the default implementation is to use the parent routes model.

Other Notable Changes

Ever-present _super (Breaking Bugfix)

Prior versions of Ember.js used a super mechanism that was un-safe for mixins. If more than one _super was called for a given function name and there was no terminating function, an infinite loop would occur. See #3523 for further discussion.

The solution released in 1.5 fixes this behavior (see #3683), but also breaks the edge-case of using _super out of line. For instance:

  doIt: function(){
    Ember.run.once(this, this._super);
  }

Is no longer a supported use of _super. See this jsbin for a live example. If this change impacts you, please comment on #4632.

Handlebars {{each}} Helper Checks Markup

In some cases, the browser may add or fix tags, which change the parentage of metamorph tags. This problem happens frequently when the developer doesn't include the TBODY tag inside a table for example. This prevents the framework from updating or cleaning the underlying DOM elements.

An assertion has been added in non-production builds that indicates that the metamorph start and end tags have different parents. This is most commonly caused by using an {{each}} inside of a <table> tag without specifying a <tbody>.

Example demonstrating the assertion (JSBin here):

<table>
  {{#each}}
    <tr></tr>
  {{/each}}
</table>

And the resolution is to include a <tbody> (JSBin here):

<table>
  <tbody>
    {{#each}}
      <tr></tr>
    {{/each}}
  </tbody>
</table>

Other Improvements

As usual, there are a ton of bug fixes and small improvements in this release. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.5.0 CHANGELOG
• Ember.js 1.6.0-beta.1 CHANGELOG

Delays Detailed

As many of you know, the 1.6 release is the first to be published after converting the codebase to ES6 modules. The 1.6+ builds are now transpiled by the es6-module-transpiler into AMD and use a small AMD loader to handle loading the transpiled modules. Unfortunately, adding the additional loader overhead on boot has a fairly significant performance impact on boot speed of older mobile clients (approximately 5-10% boot time penalty).

This regression was brought to our attention before 1.6.0 was intended to ship (late May), and we decided to hold the release until a fix could be applied. In retrospect this was absolutely the wrong decision. The fix has taken much longer than originally anticipated and in the meantime folks are stuck with 1.5.1. Many of our users either are not affected or do not care about this regression, and they are forced to use beta/canary channels for certain bug fixes that have already been made.

As a group the core team has decided that this type of delay is absolutely unacceptable and apologize for the lack of clarity into what is going on.

New features in 1.6

Ember.computed.empty

Ember.computed.empty has been updated to automatically respect arrays without forcing users to use array.[] as the dependent key.

Test Friendly Promises

With 1.5.1 you were forced to wrap any Promise resolve and/or reject calls in an Ember.run loop while in testing, but the same code did not need to be wrapped in a run loop for normal operation.

In 1.6.0 you do not need to do this promise run loop wrapping for the purposes of testing.

Ember.Route.prototype.render Now has a model Option

Previously, you would need to set the model explicitly on the other controller using controllerFor (while trying to render a different template with renderTemplate#render).

Now render has an option to set the model that set the controller's content after the controller has been looked-up.

Before:

App.HomeRoute = Ember.Route.extend({
  renderTemplate: function(controller, model){
    this.controllerFor('bio').set('content', model);
    this.render('bio');
  }
});

After:

App.HomeRoute = Ember.Route.extend({
  renderTemplate: function(controller, model){
    this.render('bio', {
      model: model
    });
  }
});

Other Notable Changes

• Add better debugging for Resolver Lookup

A LOG_RESOLVER flag can now be added to your application instance to get nice logging output showing each lookup the resolver is doing, including which were "hits" and which were "misses" (checked items are "hits"):

[ ] route:application ..........................................  App.ApplicationRoute
[✓] route:index ................................................  App.IndexRoute
[ ] controller:application .....................................  App.ApplicationController

• Ensure context is unchanged when using keywords with itemController for {{each}} or controller for {{with}}.

Previously the following code would bind this in the template block to the itemController's content (even though the keyword form of {{each}} or {{with}} is used). In 1.6.0 the context of the block will correctly be unchanged, and the post property will be wrapped in the post controller.

{{#each post in posts itemController='post'}}
  {{this}} - Should be the surrounding context, NOT changed to that of the itemController.
{{/each}}

{{#with post as somethingElse controller='post'}}
  {{this}} - Should be the surrounding context, NOT changed to that of the controller specified.
{{/with}}

• Fix swallowed rejections in asynchronous route hooks (this may mean that errors that were previously completely swallowed are now surfaced in your application).
• Ember.copy and Ember.isEqual now support Date objects.
• Backburner and RSVP now use the Ember.onerror handler if present to log errors.
• An error is now thrown when injecting a factory into all factories of the same type.

Query Params in 1.7 Beta

Thanks to the tireless work of @machty and team, query params support has finally landed and is enabled by default in the 1.7 beta series! Please test and report any issues you come across.

Other Improvements

As usual, there are a ton of bug fixes and small improvements in this release. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.6.0 CHANGELOG
• Ember.js 1.7.0-beta.1 CHANGELOG

For more details review the following links:

• Failing JSBin from the original bug report.
• Fixing PR
• Ember.js 1.6.1 CHANGELOG

This release brings bug fixes, potentially breaking changes and new features.

New Features

Nestable this.route

This change removes the restriction that only this.resource can have nested child routes.

Prior to this change, using this.resource would reset the namespace and in order to preserve it you had to do the following:

this.resource('foo', function() {
  this.resource('foo.bar', function() {
    this.resource('foo.bar.baz', function() {
      // All this repetition to get an
      // intuitively-named FooBarBazRoute
    });
  });
});

this.route can be nested like this.resource, but unlike this.resource, the namespace of child routes is appended rather than reset to a top-level namespace, allowing the above to be written as:

this.route('foo', function() {
  this.route('bar', function() {
    this.route('baz', function() {
       // uses FooBarBazRoute
       // generates foo.bar.baz.index
       // generates FooBarBazIndexRoute
     });
   });
});

Unnested this.route works the same way as before.

Query Params

Thanks to the tireless work of @machty and team, query params support has finally landed and is a part of the 1.7.0 release!

Ember now has first class support for URL query parameters (e.g. /?page=1&sort=last_name). With this API, each query param is bound to a property on a controller, such that changes made to query params in the URL (e.g. user presses the back button) will update the controller property, and vice versa.

The API handles many of tricky aspects of maintaining a binding to a URL, such as:

• coalescing multiple controller property changes into a single URL update
• correctly casting new URL query param values to the datatype expected by the controller property (e.g. "true" for a boolean property casts to true, "123" for a numeric property casts to 123)
• omitting default query param values from the URL so as to not unnecessarily clutter the URL with default values

Please read the Query Params Guide for more information.

Breaking Changes and Deprecations

The following are a few deprecation warnings and breaking changes that have been included in 1.7. Please review the new Deprecations Page for more details.

Controller's model property

On Controllers, the content property is now derived from model. This reduces many caveats with model/content, and also sets a simple ground rule: Never set a controller's content, rather always set its model.

bind-attr and empty arrays

An empty array is treated as falsy value in bind-attr to be in consistent with if helper. Breaking for apps that relies on the previous behaviour which treats an empty array as truthy value in bind-attr.

Other Improvements

Ember is now using RSVP 3.0.13 and brings fixes for RSVP.hash in IE8.

Ember 1.8.0-beta.1

Support for IE 6 and 7

Usage of Ember is deprecated for Internet Explorer 6 and 7, support will be removed in the next major version.

Refactored view layer

Internal implementation of the view layer has been refactored. Many of you remember script tags in the DOM:

<script id="metamorph-1-start" type="text/x-placeholder"></script>
<script id="metamorph-1-end" type="text/x-placeholder"></script>

That's how Ember knows how to update the values in the DOM. This refactor removes the need for script tags.

Actions lookup on controller

Some of you might remember that you could define action handlers in the root of the controller, like so:

App.HomeController = Ember.ObjectController.extend({
  someAction: function() {
    // handle the action
  }
});

A deprecation warning was added in late 2013 that would print a nice deprecation notice if you happen to use an action name that was also found in the root of the controller. Unfortunately, even with the deprecation, we still have the possibility to conflict with controller level methods and properties.

To define action handler, you should place it under actions hash, like so:

App.HomeController = Ember.ObjectController.extend({
  actions: {
    someAction: function() {
      // handle the action
    }
  }
});

This change will remove support for older action lookup in the root of the controller completely, and finally allow usage of nearly any action name without the need to check if that name was also used by the controller.

Also, this release introduces numerous bug fixes and small improvements. You can see a list of all the changes in the CHANGELOG:

• Ember.js 1.7.0 CHANGELOG
• Ember.js 1.8.0-beta.1 CHANGELOG

This release represents the effort of at least 40 contributors across over 600 commits.

Major rendering-layer refactor ("metal-views")

In previous versions of Ember.js, the HTML of a page was created (via Handlebars) and assembled (via the render tree) using string concatenation. In Ember.js 1.8, fragments of a page are still created (via Handlebars) as strings, but are then parsed into DOM and assembled as a DOM tree.

Metal-views is the first part of the HTMLBars effort to land in Ember. It is an important step towards the complete removal of strings from the Ember.js rendering pipeline.

Introducing HTMLBars into Ember incrementally demonstrates the community's commitment to semantic versioning, and to improving the framework without abandoning existing codebases.

Some of the immediate benefits of this refactor are:

• The removal of recursion from the rendering layer. This decreases garbage collection pressure during rendering and allows the re-use of objects during render (for example, the render buffer).
• Improved HTML namespace and contextual element tracking. This introduces support for components, data-binding, and logic within inline SVG documents. Example JSBin
• Prior versions of Ember.js relied upon script tags to mark regions of data bound content. For example, a template that has {{name}} might be rendered into the page as:

<script id="metamorph-1-start" type="text/x-placeholder"></script>
Bob
<script id="metamorph-1-end" type="text/x-placeholder"></script>

These script tags could interfere with :first-child and other CSS selectors, and were a general nuisance. In Ember.js 1.8 the library powering these bindings (metamorph.js) has been replaced with a completely re-written engine that uses blank text nodes (morph.js). One of the major touted benefits of HTMLBars, the Ember team is happy to make this a reality in 1.8.

Many thanks to @krisselden, @ebryn, @mmun, @mixonic, and all developers who took time to test their applications on 1.8 beta. Delivering this update without breaking 1.x API compatibility took a significant community effort.

Performance Improvements

Ember.js 1.8 comes with several performance improvements in other parts of the codebase.

• Ember.js APIs often require the use of a string to lookup a class or route. Often these strings must be passed through a normalization step before they are used, such as pluralizing, singularizing, or changing snake_case to camelCase. 1.8 introduces several caches for these operations, resulting in common operations being performed far fewer times.
• The refactoring of commonly de-optimized functions in v8 and other browsers.
• The conversion of MANDATORY_SETTER from a runtime flag into a build-time feature flag. This allows relevant code paths in get and set to be slimmer in production builds.

Thanks to @stefanpenner and @twokul for their continued efforts on performance tuning.

Notable Deprecations

As Ember.js moves forward, various APIs are deprecated to allow for their removal in a later major release (such as 2.0). With this release a deprecations page has been added to the Ember.js website. This guide will help developers refactor their code away from old APIs.

Four notable deprecations are added with the release of 1.8.

• Ember.Set is a class for managing an unordered collection of objects (api docs). It is a private API and thus subject to change, however several libraries have chosen to use it despite this. Since the addition of this API to Ember, the ES6 draft has matured in its description of a native JavaScript Set class. Ember.Set is not compatible with the upcoming API, and is now deprecated.
• In an effort to more closely align Ember.Map with ES6, the remove method has been deprecated in favor of delete.
• The currentWhen property on links is deprecated in favor of current-when. This property name more closely tracks how component properties will be used in the future.
• Old versions of Ember.js, the guides, and the API documentation suggested looking up views as globals. For example {{view App.SomeView}}. In Ember.js 1.8 this style of view lookup is deprecated in favor of using a string, similar to how other class lookups behave in Ember. See this page for details about transitioning away from global view lookups.
• URLs containing a hash and no /, such as /foo#bar are handled by the router's hash location handler. When using the auto location handler, the presence of # will cause the hash handler to be chosen over the history handlers, despite the lack of a leading / in the path (for example /foo#/bar. This makes using anchors with the history handler impossible. Ember.js 1.9 will correct this bug, and in 1.8 a deprecation is raised.

Breaking Changes

Ember.js strives to maintain strict API compatibility across minor releases. In cases of API inconsistency or where behavior is unspecified, breaking changes may be introduced to resolve the issue. Additionally, deprecated APIs may be removed if they were from a previous major release (such as pre-1.0 deprecations).

In this release there are several small breaking changes that may impact your application.

• didInsertElement is now always called on a child view before it is called on a rendering parent view. In previous releases of Ember.js didInsertElement would often be called first on a parent view, however this behavior was inconsistent. In general, developers are encouraged to consider scheduling work into the afterRender queue if it includes accessing DOM not immediately under that view's control.
• Actions defined directly on the controller object and not in the actions: hash have been deprecated since Ember.js 1.0. In Ember.js 1.8 support for those actions has been removed.
• Ember.Map has been tweaked to more closely match the ES6 spec for Map. The forEach callback now takes value,key,map as arguments. Previously it was passed key,value. This API is private, but several libraries have chosen to use it despite this. Ember-Data now includes a polyfill. Ember.OrderedSet, a super class of Ember.Map, has also had minor ES6 cleanups applied. to allow consistent usage across the pre-1.8 and 1.8 API.
• Ember.js has long had an run-time flag called MANDATORY_SETTER. With this flag enabled, attempts to set an observed object property without the use of Ember.set() would throw an error (a desirable behavior for development builds). This runtime flag has been changed to a standard build-time feature flag named mandatory-setter, allowing it to be removed from production builds entirely.

Ember.js 1.9 beta

As with any minor release of Ember.js, the current canary branch is forked to become the next beta. This ensures a constant graduation of features and improvements for release. Builds of beta are made available every week for six weeks, then promoted to release.

In Ember.js 1.9 several new features and changes will be introduced.

• "Streams" are a new Ember.js internal that replace bindings at the lowest level of the Ember rendering pipeline. They greatly simplify the implementation of template helpers and are yet another important step toward the landing of HTMLBars.
• Handlebars 2.0 will be required for Ember.js 1.9. See this summary of the transition for more details.
• Further performance improvements and bugfixes.

Changelogs

• Ember.js 1.8.0 CHANGELOG
• Ember.js 1.9.0-beta.1 CHANGELOG

Throw exception when attributeBindings includes class

Prior to 1.8, it was possible to make class part of attributeBindings and have those values merged with classNameBindings. For example, with the following template and code "from-template" and "from-class" would be merged into the DOM node's class list.

{{foo-bar class="from-template"}}

App.FooBarComponent = Ember.Component.extend({
  classNameBindings: [':from-class'],
  attributeBindings: ['class']
});

The intent of this code is unclear and the pre-1.8 behavior was unintentional. In Ember 1.8.1 an exception is thrown for including class in attributeBindings.

View instances

Passing view instances to the {{view}} helper was broken in Ember.js 1.8. This behavior has been restored.

Work-around provided for more iOS8 ARMv7 JIT Bugs

iOS8 has introduced a severe bug in optimized ARMv7 code. In 1.8.0 we worked around the issue in a number of modules, and we have expanded our work around for more modules in 1.8.1

Further Reading:

• https://bugs.webkit.org/show_bug.cgi?id=138038
• https://github.com/emberjs/ember.js/issues/5606

Support rendering of null-prototype objects

meta-data objects in Ember-Data are null-prototype, a special kind of object created with Object.create(null). In 1.8 these objects could not be rendered. 1.8.1 repairs this.

Support non-string unescaped content

In Ember 1.8 rendering an unescaped value that was not a string {{{someNumberLiteral}}} would raise an exception. This has been fixed.

Support multiple option-rendering template blocks

In Ember 1.8, template strings are parsed into DOM via innerHTML. Creating a stand-alone option tag this way results in that tag being considered "selected" even if it is not explicitly so. Consequently the last option of a select would often be selected upon render instead of the first.

We've restored support for templates like this:

<select>
  <option>First option is selected at render in 1.8.1</option>
  {{#each item in items}}
    <option>{{item.name}}</option>
  {{/each}}
</select>

Known whitespace issues in Chrome

Some templates may result in missing whitespace in Chrome. For example, if the following template renders initially with no names, then updates via data-binding later, the space between names may not be visible.

{{firstName}} {{lastName}}

In Ember.js 1.9 we expect to land a refactor to the morph library that updates dynamic DOM content, and this should alleviate this issue. Merging the refactor into a point release is too risky, so we have labelled this issues a wont-fix.

The Chrome team has been notified of this bug and you can track progress here.

Changelogs

• Ember.js 1.8.0 to 1.8.1 commit log
• Ember.js 1.8.1 CHANGELOG

The 1.9 release represents the effort of at least 52 contributors across over 436 commits.

The Road to Ember 2.0

In early November Tom, Yehuda, and the Ember.js Core Team shared The Road to Ember 2.0. This RFC document acts as a map for the next several releases of Ember.js.

Ember.js 1.9 introduces several important deprecations that signal upcoming changes. Additionally, many view-layer internals are refactored to take advantage of the "streams" observation pattern.

Ember.js 1.10 (beta) begins a series of releases that will introduce new APIs while deprecating ones to be removed in 2.0.

To that end, and with much excitement, we are extremely pleased to announce the introduction of the HTMLBars templating engine into Ember.js 1.10. This new rendering pipeline marks a significant milestone for the framework, and by maintaining complete API compatibility it demonstrates our commitment to stability without stagnation.

New Features and Deprecations in Ember.js 1.9

Handlebars 2.0

As announced in October, Ember.js 1.9 adds support for Handlebars 2.0 templates and removes support for Handlebars 1.x templates. This change does not affect the template syntax or public API of Ember applications.

Projects using an Ember-CLI version less than 0.1.5 will require a bump of the Handlebars dependency version:

bower install --save handlebars#2.0.0

Additionally the template pre-compiler (installed via npm) will require an update:

npm uninstall --save-dev broccoli-ember-hbs-template-compiler
npm install --save-dev ember-cli-htmlbars@0.6.0

Non-CLI applications will likewise require a bump of their Handlebars dependency version.

Streams

Data-binding in Ember.js has traditionally been based on the concept of a key-value observer. In Ember 1.x, KVO observers fire immediately upon the change of a value, giving them performance characteristics that cannot be changed until Ember 2.0. In comparison, streams distinguish change notification from value calculation. The value of a stream can be described as "lazy", as it is not computed until needed.

The addition of streams to Ember and their use throughout the view layer improves the performance of rendering, simplifies many helpers, and prepares Ember's codebase for HTMLBars.

Thanks to @_mmun, @ebryn, and @krisselden who wrote an Ember.js stream implementation then updated every Handlebars helper to the new API.

Activate and Deactivate Events

Ember.js routes have long supported an activate and deactivate hook. For example:

// app/routes/index.js
export default Ember.Route.extend({
  activate: function(){
    collectAnalytics();
  }
});

Ember.js 1.9 introduces corresponding events for these hooks.

// app/routes/index.js
export default Ember.Route.extend({
  collectAnalytics: function(){
    collectAnalytics();
  }.on('activate')
});

Thanks to @pangratz for the addition of this feature.

pauseTest

When debugging an Ember acceptance test, it can be helpful to pause and inspect the DOM or application state. Ember.js 1.9 adds a new test helper for indefinitely pausing test execution.

test('clicking login authenticates', function(){
  visit('/');
  return pauseTest();
  // The test will never proceed to execute this click
  click('a:contains(Login)');
});

Thanks to @katiegengler for the addition of this feature.

key-up and key-down actions

The {{input}} and {{textarea}} helpers in Ember emit several actions, including enter, insert-newline, escape-press, focus-in, focus-out, and key-press.

This release introduces key-up and key-down actions. For example:

{{! call the `validateName` action on the current controller
    or component scope: }}
{{input value=name key-up="validateName"}}

Performance Improvements

Ember.js 1.9 comes with several performance improvements.

• The implementation of _super in Ember is fairly complex, and can perform badly. Ember 1.9 uses a check against the string version of a function to determine if all parts of the implementation are needed, or if some work can be skipped.
• Additional improvements to the performance of Ember.Map have been made.

Thanks to @stefanpenner for his continued efforts on performance tuning.

Notable Deprecations

As Ember.js moves forward, various APIs are deprecated to allow for their removal in a later major release (such as 2.0). The deprecations page summarizes deprecations and demonstrates how to update to a new API.

Ember 1.9 deprecates context switching in templates. Templates with context switching are difficult to read, and the concept is challenging for new developers. The removal of context switching from templates in Ember 2.0 aims to make scoping consistent and predictable. This deprecation is a step toward that goal.

Two Ember helpers support context switching. The first is {{each}}:

{{!-- app/templates/people.hbs --}}
{{! this context is the controller }}
{{#each model}}
  {{name}} {{! this context is each person }}
{{/each}}

The non-context switching version of this helper is now preferred:

{{!-- app/templates/people.hbs --}}
{{! this context is the controller }}
{{#each person in model}}
  {{person.name}} {{! this context is still the controller }}
{{/each}}

The second helper is {{with}}:

{{!-- app/templates/people.hbs --}}
{{! this context is the controller }}
{{#with model}}
  {{name}} {{! this context is the person }}
{{/with}}

The non-context switching version of this helper is now preferred:

{{!-- app/templates/people.hbs --}}
{{! this context is the controller }}
{{#with model as person}}
  {{person.name}} {{! this context is still the controller }}
{{/with}}

New Features and Deprecations in Ember.js 1.10

Ember.js 1.10 marks the migration of Ember's rendering pipeline from a string-based process to a DOM-based one. Existing application templates require no modification to run HTMLBars. New syntaxes enabled by Ember's DOM-based rendering pipeline and HTMLBars will land over the next several releases.

Before branching into 1.10 beta, HTMLBars was available for nearly two weeks behind a canary feature flag. We thank the community members who took time from work or weekends to test the change and provide feedback.

Teasing apart the HTMLBars project to ship it incrementally has ensured that existing codebases can make the jump without modification. This release lays the infrastructural groundwork for features and even greater performance improvements to come.

Input and feedback on the 1.10 beta from real-world use will help us ensure a smooth transition to release.

To test your Ember-CLI codebase on Ember.js 1.10 and HTMLBars, follow these steps to upgrade Ember:

rm -rf bower_components
bower install --save ember#beta
bower install

Then update your template compiler to HTMLBars:

npm uninstall --save-dev broccoli-ember-hbs-template-compiler
npm install --save-dev ember-cli-htmlbars

Over the beta cycle, we expect to see 3rd party libraries and build pipelines update to support HTMLBars. If you manage a project and have any difficulty, reach out to the community and core team on the forum or #ember-dev IRC chatroom.

Block Params

Block parameters are a new feature introduced with 1.10. They address two problems in Ember:

• The non-context switching version of {{#each}} and {{#with}} are inconsistent. {{#each car in cars}} and {{#with model as car}} have similar meaning but different syntaxes.
• Ember's components are strictly encapsulated. Values are explicitly passed in, and only actions are emitted from components. The inability to pass values makes composition of components difficult.

Block params add a template syntax that allows values to be yielded from one helper or component to a child scope. The new syntax makes the named value version of {{#each}} and {{#with}} consistent. For example:

{{currentUser.name}} {{! available on the controller }}
{{#each cars as |car|}}
  {{#with car.manufacturer as |make|}}
    {{make.name}}
    {{currentUser.name}} {{! still the controller scope }}
  {{/with}}
{{/each}}

Preserving template scope context results in easier to read templates.

Any component in Ember 1.10 can use this feature. For example:

{{!-- app/templates/components/my-unordered-list.hbs --}}
<ul>
  {{#each items as |item|}}
    <li>{{yield item}}</li>
  {{/each}}
</ul>

{{!-- app/templates/index.hbs --}}
{{#my-unordered-list items=cars as |car|}}
  Auto: {{car.name}}
{{/my-unordered-list}}

The my-unordered-list component is called, passing cars as items. The component template iterates through each item in items, yielding to the calling template with a block param. The calling template accepts the block param as car and displays the car's name.

Many thanks to @_mmun for the implementation of this important new feature.

Renaming Release Files

A release of Ember.js consists of three files:

• ember.prod.js - an un-minified production build (no asserts)
• ember.min.js - a minified production build
• ember.js - a development build (with asserts)

The non-production build of Ember will not perform as well as the production build. To ensure there is no confusion about using the ember.js build in production, Ember.js 1.10 and later will use a new filename:

• ember.prod.js - an un-minified production build (no asserts)
• ember.min.js - a minified production build
• ember.debug.js - a development build (with asserts)

An ember.js file will continue to be provided with a deprecation warning.

Notable Deprecations in 1.10

The following deprecations are scheduled for release with Ember.js 1.10:

• Setting the childViews property on a view definition will be deprecated in 1.10. For example:

var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  childViews: [ 'childA', ChildB ],
  childA: Ember.View.extend()
});

This use of childViews is inconsistent with other uses throughout Ember, and as a result is difficult to implement with good performance. Explicitly creating views upon initialization is preferred:

var ChildB = Ember.View.extend();

export default Ember.ContainerView.extend({
  init: function(){
    this._super();
    this.pushObject(this.createChildView(this.childA));
    this.pushObject(this.createChildView(ChildB));
  },
  childA: Ember.View.extend()
});

• The beforeObserver feature is deprecated in Ember 1.10. Before observers are rarely used, but introduce significant overhead to the observer system in general. For observer use that requires the previous value of a property be known, implementing a cache is easier and more efficient. Read more about how to do this in the deprecations page.
• Quote-less outlet names are deprecated in 1.10. An example of this is {{outlet modal}}, which would be re-written as {{outlet "modal"}}. This ensures the outlet helper is consistent with others, where unquoted words are values and not string literals.

As the features included in Ember 1.11 are developed, additional deprecations may be added to the 1.10 release.

Changelogs

• Ember.js 1.9.0 CHANGELOG
• Ember.js 1.10.0-beta.1 CHANGELOG

{{view}} Helper & Instances

The 1.9.0 release introduced a regression where the Handlebars {{view}} helper would only work with Ember.View subclasses, not instances. In 1.9.1, passing a view instance to the helper has been fully restored.

We intended to deprecate this functionality, not remove it entirely. If your app was relying on this behavior, first, please accept our apologies for the accidental regression. Second, please consider refactoring your code to use components instead of views, as support for this API will be removed in Ember 2.0.

XSS Improvements for Bound Attributes

XSS vulnerabilities happen when you unintentionally put unescaped user-supplied content into the DOM, creating a vector for attackers to trick the browser into evaluating JavaScript that has the same access to data as your legitimate JavaScript.

Since its inception, Ember.js has automatically guarded against these attacks by HTML-escaping any bound data that goes into the DOM. For example, given this model data:

{
  "firstName": "<script type=javascript>alert('pwned!');</script>"
}

The following template would not be vulnerable to XSS:

Hello, {{firstName}}!

That's because Ember automatically replaces the < and > characters with < and >.

However, there is still another potential exploit vector: bound attributes.

Let's say you display a profile for your users and allow them to supply an arbitrary homepage that your app links to:

{{!-- app/templates/user.hbs --}}
First Name: {{firstName}}
Homepage: <a {{bind-attr href=homepageUrl}}>{{homepageUrl}}</a>

While this template may look harmless at first glance, imagine a malicious user provides the following data:

{
  "firstName": "Guardians of Peace",
  "homepageUrl": "javascript:alert('Kim Jong Un is not to be
disrespected!')"
}

If the attacker can induce another user to click the profile link, you will have inadvertently allowed their JavaScript to be evaluated in the same origin as your trusted code.

As of Ember 1.9.1, we will automatically escape any bound href, src or background attributes that contain a javascript: or vbscript: protocol handler by prefixing their value with unsafe:.

We are also releasing a new beta version of Ember 1.10 that contains even more targeted fixes. Thanks to the additional power the HTMLbars parser gives us, these attributes will only be escaped on elements where they trigger a top-level navigation and thus a potential exploit: a, body, link, iframe, and img.

We'd like to thank Mano and Manoharan from Zoho for responsibly disclosing this potential XSS vector and working with us to find a solution that helps developers write secure apps.

Changelogs

• Ember.js 1.9.1 CHANGELOG
• Ember.js 1.10.0-beta.2 CHANGELOG

Ember 2.0 only removes features that were deprecated as of Ember 1.13, so apps that run on Ember 1.13 without any deprecation warnings should run without issues on Ember 2.0.

New applications should begin using Ember 2.0 today. Apps requiring Ember-Data should use Ember-Data 2.0.0-beta.1 (2.0 release coming shortly!).

New Features in Ember.js 2.0

• <This space intentionally left blank!>

Major releases of most libraries try to do two things. They introduce new APIs, and remove deprecated ones. Our release focuses on doing one thing well: Instead of introducing new features, the goal of Ember 2.0 is to remove accumulated cruft.

Since Ember 1.0, adherence to semantic versioning has helped us grow an amazing community. Ember powers extremely ambitious applications, and most of those applications have been able to move forward over 13+ releases as new features arrived.

We are committed to giving every Ember codebase a path into 2.x. To ensure this, we've flagged everything removed in 2.0 with a deprecation in the 1.x series. If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0. There are no new features to adapt to or adopt.

In the first few releases in Ember 2.x, we plan to land a variety of exciting features. We are all the more excited that thousands of existing apps will be ready to use them immediately. More about this below.

Removed APIs

Internally, we've taken to calling Ember 2.0 a "garbage collection" release. Two years is a lot of framework development, and there are many things dropped in today's release.

Developers migrating forward will find these resources helpful:

• The 1.x Deprecation Guide contains a summary and migration path for many deprecations since Ember 1.7. Additionally, this guide is linked to from deprecation messages in your browser's console.
• The Ember Inspector is an essential tool for debugging Ember apps, and provides some tooling for managing deprecations.
• Core team members Robert Jackson and Matthew Beale published the ember-cli-deprecation-workflow addon in July. This tool helps to manage upgrades to your codebase through deprecation messages. Watch Robert present on upgrade workflows in this NYC meetup video.
• The ember-debug-handlers-polyfill addon provides a future-safe API for writing your own upgrade tooling.

Some of the major API removals follow.

Views have been removed in Ember 2.0. Components, which provide better isolation and scoping semantics, fulfill the use-cases views were introduced for.

We recognize that existing apps will not complete their migration away from views for several months, so we have published the ember-legacy-views compatibility addon, that will allow you to spread out the transition over more releases. We are committed to maintain support for this addon until at least Ember 2.6.

If you are building a new application, the use-case for views have completely been subsumed by Components. Existing apps should refactor away from the {{view}} helper and Ember.Views in favor of Components.

However, existing applications that make use of top-level Views do not need to immediately refactor those views to components. The future Routable Components will provide a softer transition path for this use-case and we commit to support the compatibility addon until the community has had a chance to transition to Routable Components.

Similarly, the use-cases for Controllers have largely been eliminated.

As with views, we have published the ember-legacy-controllers compatibility addon that you can use to spread out the transition. This addon will also be maintained until at least Ember 2.6.

If you are building a new application, you should almost never need controllers except to manage query parameters and communicate with the route (ala transitionTo). For these cases, Ember 2.0 retains support for top-level controllers with no addon required. While we plan to completely replace these use-cases during the 2.x series, everything that works without the compatibility addon will continue to work until 3.0.

Existing applications should refactor away from using the {{controller}} property, use of proxying controllers (ArrayController and ObjectController), itemController, etc.

However, existing applications that make use of top-level Controllers do not need to immediately eliminate those controllers. As with top-level views, the future Routable Components will provide a softer transition for this use-case and we commit to support the compatibility addon until the community has had a chance to transition to Routable Components.

ReduceComputed and ArrayComputed have been made obsolete by the Glimmer rendering engine introduced in Ember 1.13. These APIs allowed array operations to be performed without creating new arrays. Glimmer's value diffing makes this unnecessary. Computed property macros that operate on arrays are still present, but they are not backed by ReduceComputed.

Context shifting in templates ({{#each}} and {{#with}} without block params) is removed in Ember 2.0. For any template, there is now only one this and it cannot be changed for part of that template by any helper. This makes templates easier to reason about, and unlocks opportunities for performance improvements.

IE8 support has been dropped for Ember 2.0. For the 2.x series, IE9+ will be supported.

Legacy Handlebars helpers are removed in favor of the Ember.Helper API. This API does not provide a mechanism for helpers to take a block, but does introduce support for nested helpers which can be used in concert with built-in helpers (like {{#if}} and {{#each}}) to achieve the same ends.

Please see the CHANGELOG.md for an authoritative list of cleanups.

The Road Ahead

Over the last few releases of Ember 1.x, we added a large number of new features. These additions, including a whole new rendering engine, were introduced while maintaining backwards compatibility. Unsurprisingly, maintaining support for the semantics of two rendering engines (among other things) introduced a large amount of cruft. Continuing to provide backwards compatible legacy APIs has a non-trivial impact on the performance of Ember applications, and on the project’s momentum.

Ember 2.0 allowed us to purge much of that built-up cruft. That was no small task; removing code, documenting deprecations, and building new workflows for managing these changes would not have happened without lots of hands. It was an incredible effort, and we'd like to thank the community for making it happen.

With the garbage collection sweep out of our way, we can continue to expand on the foundation solidified in Ember’s 1.x series.

Improved Release Cadence

Since Ember 1.0, we have followed Semantic Versioning, working very hard to maintain public API compatibility while adding new features. In the lead-up to breaking changes in Ember 2.0, we made a number of mistakes that caused our users to experience a great deal of churn.

While we successfully followed our existing policies regarding deprecation before removal, and ensured that each deprecated feature had a viable replacement, we did not do a good job of distinguishing between different kinds of deprecations. Additionally, many deprecations landed very late and all at once. These factors combined made the entire process feel overwhelming.

The feeling of "churn" is contrary to all our release process goals. In addition to the continued maintenance of a six-week release cycle, we have a number of tweaks to the process planned for 2.x. These are intended to help us avoid a similar problem late in the 2.x cycle.

Some examples of improvements are:

• LTS (Long-Term Support) Releases (RFC #56), which can give users who want to upgrade less often than every six week a sanctioned way to do so.
• Mandatory docs. No new features will be added to the Ember 2.0 release channel without accompanying documentation.
• More informative deprecations. All deprecations will include which release their behavior will be removed in, as well as a link to transition instructions.
• Improved deprecation tooling. More informative deprecations allow us to make the Ember inspector's deprecation pane smarter, and more useful for incrementally working through deprecations. In particular, we can avoid nagging you (by default) about removals that will not happen until far in the future. For more information see RFC #65 and the included comments.
• Svelte Builds, which allow you to ask Ember CLI not to include deprecated features you are no longer using. This will reduce pressure on future major releases.

Ember 2.x Themes

In addition to a better release process, you can look forward to several high-level areas of improvement throughout the 2.x series.

Alignment with JavaScript. Throughout 2.x, we will continue our efforts to align Ember with ES6 and future versions of JavaScript. As the JavaScript decorator proposal stabilizes, and as transpilers improve their implementations, we plan to adapt computed properties and other APIs to that syntax.

JavaScript Modules. We will also continue to evolve further towards a modules development style and away from a globals style. Among other things, this will allow us to more aggressively automate the removal of dead code paths.

Stabilization and Integration. The Ember ecosystem will continue to stabilize and integrate tightly. Ember-Data and Ember CLI will be versioned in lockstep with Ember itself. Putting these projects on the "release train" with Ember will mean they adhere to the same backwards compatible and incremental change policies as Ember did through 1.x.

Ember Data. With the release of Ember 2.0, Ember Data is now a stable part of Ember's releases. It will adhere to Semantic Versioning policies like Ember itself, and every release of Ember will include a compatible release of Ember Data. Along those lines, Ember Data will not make any breaking changes until 3.0.

New Features in the Pipeline

Many of our other plans have already been proposed via the RFC process and discussions on GitHub, but here's a recap.

We are actively working on the implementation of these features, and expect them to land gradually over several releases.

Angle-Bracket Components and One-Way Data Flow. Ember 2.x will transition to angle-bracket components. For example <my-button> instead of {{my-button}}. These will operate with one-way binding as part of a larger transition to a "data down, actions up", or "DDAU", style of programming that you will read about as features land. We expect these components to land in 2.2 and be refined over the next few releases. See RFC #60 and PR #12011 for more details about our progress.

Pods. We are also actively working on finalizing the pods directory layout for applications, which makes it easier to group related parts of your application together. This change will be completely opt-in, and existing layouts will continue to work.

Routable Components. After angle-bracket components and the pods layout land, we will be able to transition the last few use-cases for controllers to the much-anticipated Routable Components. RFC #38 and PR #11939 track our progress so far.

FastBoot, Ember's alpha release server-side pre-rendering library, will continue to improve and stabilize over the 2.x lifecycle. Find it on GitHub as ember-cli-fastboot.

In addition it means many of the first features for Ember 2.2, most notably angle bracket components, have landed in Canary behind a feature flag. If you're interested in help us progress with those features, now is a good time to try them out.

On to the changes coming in our late September/early October release.

New Features in Ember.js 2.1

Ember.js 2.1 will be a minor release of Ember. This means changes to the API are made in an additive, backwards compatible manner. In roughly six weeks, these features will be part of the 2.1 stable version.

A summary of the new features in today's release follows.

{{get}} Helper

The {{get}} helper allows dynamic property lookup on objects in templates. For example, these two usages are equivalent:

{{user.name}}
{{get user "name"}}

A property with a value of a string can be passed as the second argument, making both the object and the property being read dynamic. For example:

{{get user somePropertyName}}

For more information on the {{get}} helper, reference the implementation in PR #11196 and PR #11691.

Big thanks to @jmurphyau for the implementation of this feature, and for his excellent ember-get-helper addon that demonstrated how useful this helper would be. Trying his ember-truth-helpers addon is highly recommended.

{{each-in}} Helper

The {{each-in}} helper iterates keys and values of an object. It is similar conceptually to the for (key in object) { syntax of JavaScript. For example, this code would display a list of all property names and values on the user object:

<ul>
{{#each-in user as |key value|}}
  <li>{{key}}: {{value}}</li>
{{/each-in}}
</ul>

When using {{each-in}}, the iterated list of keys will be unbound. If a new property is set on user with user.newProp = 'newVal';, the new property will not appear.

For more information on the {{each-in}} helper, reference PR #11171.

Thanks to @tomdale for the implementation of this feature, and thanks to @miguelcamba for his followup PRs.

Deprecate and Warn Handlers

In the run up to Ember 2.0, it became clear that the tooling for management of deprecations was poor. One of the reasons for this was the lack of a public, documented API for deciding how a deprecations and warnings should be handled. 2.1 introduces a proper API for our tooling to build upon.

The default behavior of a deprecation or warning is to log to the console. To change this behavior, register a handler and write custom logic. For example this handler would throw an exception for any deprecation messages with the word should in them:

Ember.Debug.registerDeprecationHandler((message, options, next) => {
  if (message.indexOf('should') !== -1) {
    throw new Error('Deprecation message with should: '+message);
  } else {
    // defer to whatever handler was registered before this one
    next(message, options);
  }
});

In this example, all warnings are silenced:

// next is not called, so no warnings get the default behavior
Ember.Debug.registerWarnHandler(() => {});

Handlers are provided with the following data through arguments:

• message is the text logged by default
• next is a caller for the previously registered handler. Often, this is the default handler.
• options.id is an id in the format package-name.specific-deprecation

Deprecation handlers will also be provided:

• options.until is the version of Ember this feature and deprecation will be removed in

As of Ember 2.0, deprecate and warn calls must provide an id option, and deprecate calls must additionally provide an until option. Addons not providing this data during 2.x will trigger a deprecation warning.

For more information see RFC #65 and the implementation in PR #11833. This API can be used with older versions of Ember via the ember-debug-handlers-polyfill, though id and until data is not provided until Ember 2.0.

Thanks to @rwjblue for shipping this API and the polyfill addon, and to @mixonic for the RFC.

Registry and Container Reform

The Ember.js registry and container are some of the most extensively used private APIs in the framework. They provided one of the only ways to lookup arbitrary objects from Ember's dependency container.

In 2.x, we are committed to stabilizing this part of the framework and offering public APIs. This first step creates a normalized way to interact with register and lookup that we expect to last through the 2.x cycle and beyond.

Ember.Application instances are passed as the first argument to initializer hooks in 2.1. initializer hooks are where dependencies between object types can be configured, and factories can be registered. Several public APIs will exist on Ember.Application instances, some of them new:

• register - register a factory
• inject - inject a factory into another factory, or all factories of a type
• unregister - remove a factory from registration
• resolveRegistration - fetch a registed factory
• hasRegistration - check for a registered factory
• registerOption, registeredOption, registerOptions, registeredOptions, registerOptionsForType, registeredOptionsForType which manage options for a factory (is it a singleton, can it be instantiated).

Ember.ApplicationInstance instances are passed as the first argument to instanceInitializer hooks in 2.1. instanceInitializer hooks are where objects and classes can be fetched out of the configured and booted application. Two new relevent public APIs will exist on Ember.ApplicationInstances:

• lookup - fetch an instance of a factory (with dependencies)

For more information about these changes read RFC #46 and the initial implementation in PR #11440. To better understand dependency management in Ember and how to use these APIs, see the section on dependency management in the 1.13 guides.

This feature also introduces two minor deprecations:

• Calling appInstance.container.lookup on the first argument to an instance initializer is deprecated in favor of appInstance.lookup.
• Expecting two arguments for an initializer hook is deprecated

Deprecations flag where we expect to change an API in the future. It is not recommended that you use deprecated functionality, but you can also safely silence a deprecation message and continue to use that functionality until its removal date.

Huge thanks to @dgeb for his tireless work on the RFC and implementation for this work, as well as his patience building consensus around changes to Ember's internals.

For more details on changes landing in 2.1, review the Ember.js 2.1.0-beta.1 CHANGELOG.

Ember.js 2.2 beta, the branch of Ember that will be released as stable in roughly six weeks, is also being released today.

New Features in Ember.js 2.1

Changes to the Ember's API in 2.1 are backwards compatible. A summary of the new features in today's release follows.

{{get}} Helper

The {{get}} helper allows dynamic property lookup on objects in templates. For example, these two usages are equivalent:

{{user.name}}
{{get user "name"}}

A property with a value of a string can be passed as the second argument, making both the object and the property being read dynamic. For example:

{{get user somePropertyName}}

For documentation on get, reference the API documentation.

Big thanks to @jmurphyau for the implementation of this feature, and for his excellent ember-get-helper addon that demonstrated how useful this helper would be. Using his ember-truth-helpers addon in 1.13 codebases is highly recommended.

{{each-in}} Helper

The {{each-in}} helper iterates keys and values of an object. It is similar conceptually to the for (key in object) { syntax of JavaScript. For example, this code would display a list of all property names and values on the user object:

<ul>
{{#each-in user as |key value|}}
  <li>{{key}}: {{value}}</li>
{{/each-in}}
</ul>

When using {{each-in}}, the iterated list of keys will be unbound. If a new property is set on user with user.newProp = 'newVal';, the new property will not appear.

For documentation on the {{each-in}} helper, see the API documentation.

Thanks to @tomdale for the implementation of this feature, and thanks to @miguelcamba for his followup PRs.

Registry and Container Reform

The Ember.js registry and container are some of the most extensively used private APIs in the framework. They provided one of the only ways to lookup arbitrary objects from Ember's dependency container.

We are committed to stabilizing this part of the framework and offering public APIs. This first step creates a normalized way to interact with register and lookup that we expect to last through the 2.x cycle and beyond.

In 2.1, Ember.Application instances are passed as the first argument to initializer hooks. initializer hooks are where dependencies between object types can be configured, and factories can be registered. Several public APIs will exist on Ember.Application instances, some of them new:

• register - register a factory
• inject - inject a factory into another factory, or all factories of a type
• unregister - remove a factory from registration
• resolveRegistration - fetch a registered factory
• hasRegistration - check for a registered factory
• registerOption, registeredOption, registerOptions, registeredOptions, registerOptionsForType, registeredOptionsForType which manage options for a factory (is it a singleton, can it be instantiated).

Ember.ApplicationInstance instances are passed as the first argument to instanceInitializer hooks in 2.1. instanceInitializer hooks are where factories can be fetched out of the configured and booted application. One relevant public APIs exists on Ember.ApplicationInstances:

• lookup - fetch an instance of a factory (with dependencies)

You can find updates to the guides regarding initializers in the revamped Application Concerns section. The API documentation is similarly updated at the ember-application namespace, Ember.Application class, and Ember.ApplicationInstance class.

This feature also introduces two minor deprecations:

• Expecting two arguments for an initializer hook is deprecated
• Calling appInstance.container.lookup on the first argument to an instance initializer is deprecated in favor of appInstance.lookup.

Deprecations flag where we expect to change an API in the future. It is not recommended that you use deprecated functionality, but you can also safely silence a deprecation message and continue to use that functionality until its removal date.

A huge thanks to the tireless @dgeb for his work on the RFC, implementation, and documentation for these changes. They represent a significant improvement in Ember's dependency injection system.

Deprecate and Warn Handlers

In the run up to Ember 2.0, it became clear that the tooling for management of deprecations was poor. One of the reasons for this was the lack of a public, documented API for deciding how a deprecations and warnings should be handled. 2.1 introduces a proper API for our tooling to build upon.

The default behavior of a deprecation or warning is to log to the console. To change this behavior, register a handler and write custom logic. For example this handler would throw an exception for any deprecation messages with the word should in them:

Ember.Debug.registerDeprecationHandler((message, options, next) => {
  if (message.indexOf('should') !== -1) {
    throw new Error('Deprecation message with should: '+message);
  } else {
    // defer to whatever handler was registered before this one
    next(message, options);
  }
});

In this example, all warnings are silenced:

// next is not called, so no warnings get the default behavior
Ember.Debug.registerWarnHandler(() => {});

Handlers are provided with the following data through arguments:

• message is the text logged by default
• options is an object containing at minimum the property id in the format package-name.specific-deprecation
• next is a caller for the previously registered handler. Often, this is the default handler.

Deprecation handlers will also be provided:

• options.until is the version of Ember this feature and deprecation will be removed in

As of Ember 2.0, deprecate and warn calls must provide an id option, and deprecate calls must additionally provide an until option. Addons not providing this data during 2.x will trigger a deprecation warning.

For more information see the Ember.Debug API documentsion. This API can be used with previous versions of Ember via the ember-debug-handlers-polyfill, though id and until data is not provided until Ember 2.0.

Thanks to @rwjblue for shipping this API and the polyfill addon, and to @mixonic for the RFC.

For more details on changes landing in 2.1, review the Ember.js 2.1.0 CHANGELOG.

Ember.js 2.2 beta

No new features are slated for Ember 2.2. During the canary cycle leading to this beta, the core team and community have been primarily focused on performance improvements or feature work still behind a feature flag.

For more details on changes landing in 2.2, review the Ember.js 2.2.0-beta.1 CHANGELOG.

This also kicks off the 2.11 beta cycle for all sub-projects. We encourage our community (especially addon authors) to help test these beta builds and report any bugs before they are published as a final release in six weeks' time. The ember-try addon is a great way to continuously test your projects against the latest Ember releases.

Starting with this release, we will be publishing a single, unified release blog post summarizing all the changes for all three sub-projects in one place. You can read more about our general release process here:

• Release Dashboard
• The Ember Release Cycle
• The Ember Project
• Ember LTS Releases

Ember.js

Ember.js is the core framework for building ambitious web applications.

Changes in Ember.js 2.10

Ember.js 2.10 is the first release to include Glimmer 2, a ground-up rewrite of Ember's rendering engine.

Despite all the changes that took place under-the-hood, we are committed to making this a drop-in, completely backwards compatible upgrade for virtually all Ember.js users. Over the past few months, we have been hard at work to make this a reality.

Thanks to everyone in the community who took the time to test their apps and addons against the Glimmer 2 alpha and beta builds, this has been one of the most rigorously tested releases in the history of the Ember project. We are quite confident that upgrade will go smoothly for most apps. However, if you encounter any issues, please do report them to the issue tracker.

While this release is focused on compatibility and does not expose any new capabilities, the new rendering engine has unlocked a lot of new frontiers for us, creating a much better foundation for adding new features as well as room for future performance impovements. With the initial integration now out of the way, we are quite excited to return our efforts to those areas in upcoming releases.

Other notable changes

In addition to the Glimmer 2 integration, a few other notable changes are also included in this release.

First, Trent Willis, Nathan Hammond and Alex Speller have contributed a series of patches to address some long-standing issues and edge cases in the routing layer, particularly in the area of query params.

Second, thanks to Robert Jackson, we now use WeakMap to store object metadata on browsers that supports them. A pleasant side-effect of this internal change is that Ember no longer adds an __ember_meta__ property to every object.

Finally, it has come to our attention that it is quite common for developers to accidentally mutate the arguments passed into a helper. This is problematic as these objects are often shared or reused, causing subtle issues that are very difficult to debug.

To help track down these kind of issues, these objects are now frozen in the debug build before they are passed into helpers. As a result, you will get an error if you attempt to modify these objects directly. It is recommended that you clone these objects (e.g. using Object.assign and Array#slice) before making any modifications to them.

(It has been brought to our attention that the last change might have an unintended consequence. A fix is being worked on by Matthew Beale. Please refer to the linked issue for a detailed description and suggested workaround.)

For more details on the changes in Ember.js 2.10, please review the Ember.js 2.10.0 release page.

Upcoming changes in Ember.js 2.11

Currently, no new features are planned for 2.11. However, there are a few notable changes:

• Similar to the change to helper arguments, concatenated properties (such as classNames and classNameBindings) are now frozen in debug builds to help track down unintended mutations.

• The legacy render helper (i.e. {{render 'foo'}}) has been deprecated.

• The private Component#renderToElement API has also been deprecated.

For more details on the upcoming changes in Ember.js 2.11, please review the Ember.js 2.11.0-beta.1 release page.

Ember Data

Ember Data is the offical data persistence library for Ember.js applications.

Changes in Ember Data 2.10

Ember Data 2.10 represents the work of more than 10 direct contributors with over 20 commits.

There have been no user facing changes in Ember Data 2.10. Under the hood, Chris Thoburn has instrumented Ember Data with internal tools making it easier to track the performance of Ember Data. This instrumentation is stripped from production builds and should have no impact on existing applications.

Chris also improved the messaging around assertions and warnings when an adapter responds with no id for a record.

For more details on the changes in Ember Data 2.10, please review the Ember Data 2.10.0 release page.

Upcoming changes in Ember Data 2.11

Ember Data 2.11 is already shaping up to be a big release with many performance and documentation improvements.

HasMany Computed Property Keys

One of the performance improvements included in Ember Data 2.11 fixes an issue where changes to the records of a DS.hasMany() caused unnecessary work. As a result, Ember Data would over-eagerly invalidate computed properties that depended on these hasMany relationships. Due to the nature of the fix application code depending on a relationship array without watching the contents of that array may need to be updated. For example you may need to update computed property keys that depended on record.someHasManyRelationshipName to record.someHasManyRelationshipName.[].

Deprecations in Ember Data 2.11

Ember Data now issues deprecation warnings for store#serialize(). Instead, it is recommended that you use record.serialize() in place of store.serialize(record).

store#lookupAdapter() and store#lookupSerializer() have also been deprecated starting in Ember 2.11. These methods were never publicly documented. In their place we recommend you use store#adapterFor() and store#serializerFor() respectively.

store#recordIsLoaded() is deprecated in favor of store#hasRecordForId(), as the logic in these two methods has been identical since March 2015.

All of the deprecated methods mentioned above will be supported until Ember Data 3.0. Until then they will log a deprecation warning to encourage use of the recommended replacement APIs.

Move ds-improved-ajax out of beta channel

The ds-improved-ajax implemented in PR #3099 aims to provide public hooks on the rest adapter for customizing requests. For example to specify the HTTP method or provide custom HTTP headers per request. This feature has been available in beta builds since the 2.8 beta cycle.