This week, the Ember.js Times awaits you with news about Glimmer Components landing in Ember, an overview of this year’s roadmap for Ember CLI, and a Readers’ Question - this time focussing on the future of Glimmer ✨❤️🐹
Also, it's the final countdown to EmberConf 2018, the largest Ember gathering worldwide! There are still tickets available for the conference, trainings, and activities. Join the #conf-emberconf channel on Slack to connect with other attendees.
In an effort to get a better picture of the Ember community and its needs, the Ember Community Survey 2018 is underway, and your input is needed! Similar to previous years, @mixonic,@AkankshaKana and @iezer are investigating how the community is using Ember for everyday work - and the results will ultimately influence decisions on the content of the current roadmap of Ember itself.
The survey is still open for a few more days until March 7th and takes less than 10 minutes - so if you’re just reading this during your coffee break ☕️- this is actually the perfect time to do it! The full results of the survey will be presented at this year’s EmberConf on March 13th.
There you are in a template. It’s dark outside, the weather is rough, and you encounter the double curlies. Not familiar with the app, since it was just given to you by your boss a few hours ago, you start to pull your hair. Is it a helper? A property on the component? Is it an attribute passed in? After digging around frantically (probably using ctrl F, or command F for the mac people) you discover it’s a property of the component. Why the ambiguous nature of the curlies? For ages, every Ember developer has been putting this uncertainty into the hands of the default property fallback. Whatever shall we do?!? The new RFC for deprecating the property fallback behaviour in Ember aims disambiguate the curlies and remove the confusion when reading a template. To provide clarity, the PR proposes ((this.foo)), being foo a property. By doing this, it is certain that the property belongs to the component class. While not the main focus of the proposal, the PR could have positive effects on the rendering system by reducing compiler overhead when discovering the true intent of the curlies in question. Even though this is still in discussion, it certainly provides a path forward that to enrich the developer experience. Make sure to read the discussion – which includes a post by @wycats on how various recent RFCs tie in together into a coherent future for the framework future – and make your opinion heard in the comments section.
@tomdale recently posted the “Glimmer Components in Ember” quest issue to lay out the work necessary to bring Glimmer components to Ember. This gives developers an option to use all the nice things Glimmer components have to offer while living alongside the current Ember.Component class.
The quest is split up into a number of Phases:
Phase 0 builds off the custom component RFC adding a custom component manager API, allowing addons to implement any custom component API, not just Glimmer one.
Phase 1 offers a transition and migration path so that developers can opt into Glimmer components at their own speed.
Phase 2, angle brackets.
Finally, enough said. Phase 3 is most of Glimmer goodies, especially the @tracked decorator, resulting in the wonderfully simplified component code of a Glimmer component.
Over the weekend, a new landing page was launched for the API docs! Hard refresh if you still only see the "application" module docs. The power of the cache is strong.
We'd like to give a special shout out to @rimian who has been steadily fixing a ton of links in the Guides! The Learning Team also continues to diligently chip away at the migration of emberjs.com to Ember repos in github.com/ember-learn. 👏
In the final sprint to this year’s EmberConf, the Ember CLI team is getting ready to create an plan for which major features should land for the tool in 2018.
Tree Shaking, out-of-the-box support for npm packages on install, Yarn Workspace Support and a workflow for Service & Web Workers are only a few among the plethora of topics under discussion - and your suggestions and comments are needed!
The first changes for code splitting in Ember apps are already underway with several new pipelines for creating directory trees for dependencies landing in the CLI (1, 2); finally, a few more internal improvements landed this week (3, 4, 5).
This week we have another Readers’ Question ready for you: This time it’s all about the implications that splitting Ember into separate, independent packages will have on the stand alone library Glimmer.js.