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.
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:
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.
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.
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.
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!
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.
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:
find and save.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.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.
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.
{{outlet}}s and
{{link-to}} on top of the current Ember by Sebastian Seilund of Billy's
Billings.We've also been grateful to be the beneficiary of large amounts of support from a number of companies over the years.
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.
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.
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.
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.
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.
Special thanks to a number of community members who have done heroic work leading up to Ember 1.0:
actions namespacing, last minute bugfix work, and the Ember NYC communityGo forth and build great things!
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。