This week at Ember


This is an important month for Ember.js, and we are excited about the progress we have made. With so many things happening, it may be difficult to keep up with the latest situation of the project, so here is what you need to know.

Embers camp

Although we have an incredible network of local gathering groups, Embers camp It is the first national event of the Ember community.

We have been working hard to ensure that this event is both fun and educational, and we will announce the speaker lineup soon. Unfortunately, the tickets are already sold out, so if you don’t buy them this time, you must grab them next year!

During Ember Camp, please pay close attention to this website and Our Twitter account. There will be several announcements you won’t want to miss!

Peeping password

We had the honor of spending a day with Geoffrey Grosenbach, reviewing his ongoing PeepCode screenshots of Ember.js. He spent a lot of time getting to know Ember deeply, and we think the final product is invaluable for new developers who are starting to use the framework.

The road to 1.0

If you keep following master In the last month, you know that we have made many major improvements to Ember.js in rapid succession. Some of them involve API changes that are not backward compatible.

Thank you for your patience when we are about to release version 1.0. We take feedback on “developer ergonomics” very seriously, and if we are not satisfied with the performance of the API, we will not rush to release.

Thank you for all your excellent feedback on the early iterations of the router API.Learn how you found the API confusing or difficult to use, driving our work on the final version released pre4.

router

The first iteration of the Ember.js router (some people began to refer to it colloquially as “v1”) allowed us to begin to flesh out some conventions about application structure. In the past, the application structure was mainly completed on a temporary basis, but a general agreement appeared in the community, and we included it in “Router v1”.

However, although developers appreciate the conventions around application structure, their response to the first version of the API can be generously described as TerrifiedIn fact, routers for large applications are starting to look like a twisted merger of views in the old SproutCore application. We knew that we had to go back to the drawing board with the lessons we learned.

In contrast, our response to the router proposal “v2” was very positive. Although we have made several adjustments in the past month to ensure that the API is as intuitive as possible, the overall concept behind the API remains stable.

We believe that we have finally resolved the edge case and have no plans to make any further backwards incompatible changes to the router API before the final 1.0 version.

To understand the full content of this router API, please visit Routing guide.

API freeze

In the preparation phase of Ember 1.0, we chose to actively make API changes in response to your feedback, in an effort to make the 1.0 API as good as possible.

The reward for enduring this level of churn is that we plan to remain very stable after 1.0. As we approached that milestone, we began to freeze some APIs.

Starting today, we will no longer make changes to APIs that affect advanced tutorials, screencasts, or introductory documents, unless such changes are necessary to resolve critical errors.

When we release the first RC, we will no longer make changes that affect any part of the documented API-again-unless such changes are necessary to resolve critical errors.

meets the Semantics, Once we release the final 1.0, before Ember 2.0, we will not make disruptive, backward-incompatible changes to the publicly documented API. We may deprecate the API and print a deprecation warning in the debug version, but things will continue to work.

In order to facilitate the freezing of these APIs, we plan to take the following steps:

  1. We will convert high-profile screencasts and most of our public documents into integration tests. “Your submission broke the PeepCode screenshot” is what Travis will tell contributors.
  2. We will freeze Ember 1.0 tests and run them against all Ember builds in the 1.x series. If we make a potentially backward-incompatible change, this will notify us and we can check if it is the result of an API change or a fragile test. If we must modify the old test, we will announce it here.

Documentation

Perhaps the most extensive feedback we have received from developers is:
“Ember.js looks cool, but your document is not.” We heard your voice clearly.

We recently launched Completely redesigned guide, And because of their more focused nature, they have been able to iterate quickly. Since the deployment of the new website, the bounce rate has dropped sharply, and interaction with any particular page has almost doubled.

As we approach the 1.0 version, we have more great documentation to provide you, we think the design work Matt Grantham The work done on the new guidelines will make them more accessible to new developers.

We are also working on improving the API reference documentation. in particular, Stephen Penner Have been making heroic efforts to make them have a beautiful appearance similar to the tour guide.

Thank you

We have been working on Ember.js for more than a year, and it is no exaggeration to say that it attracts some of the best and smartest web engineers on the planet. It’s very gratifying to see our ideas take shape, and we can’t wait to see what web applications will look like in 2013.

Thank you all Our contributors, They spent hours of nights and weekends to help us make one of the best tools for writing ambitious Web applications. Without you, we really can’t do it.

I wish you all the best in the new year,
Yehuda Katz and Tom Dale



Leave a Reply

Your email address will not be published. Required fields are marked *