Today, we're excited to announce the final release of Ember.js 1.0.
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!