Yesterday morning at EmberCamp London I gave a talk on Glimmer, Ember.js and the relationship between the projects.

As part of that talk I covered the latest news on Ember’s new application filesystem layout, a project we refer to as “module unification”.

As of a few days ago, all the code needed to run a module unification app has landed in the various requisite repositories. In this post I’ll give you a little background on the work we’re doing and tell you how to start a new app or migrate an existing one.

Google’s Progressive Web Apps, or “PWA”, initiative specifies a set of requirements for modern web apps. In this post, we will take a new Ember app and transform it into a deployed PWA using service workers, server-side rendering via Fastboot, a web app manifest.

The checklist for being PWA compliant is pretty extensive. The general idea, however, is to build apps that are:

• Reasonably secure and private (HTTPS).
• Responsive to screen sizes and device capability.
• Provide a basic offline experience.
• Have acceptable performance, even on low-end networks and devices.

When a developer follows these guidelines they are rewarded with an application that performs well regardless of network availability or device quality, is a candidate for web app install banners, and generally has a quality user experience.

www.shop-201.com is a progressive web app built using Ember by the team at 201 Created. It can be installed on your Android home screen, works offline, and when you are online supports credit card and Apple Pay checkouts.

To support developers building progressive web apps, Google has provided Lighthouse. Lighthouse is a Chrome extension that analyzes a website for PWA compliance. Lighthouse can’t validate all parts of PWA compliance, but it’s the best check we’ve got.

When you run Lighthouse, it provides a score between 0 and 100 for several buckets: Progressive Web App, Performance, Accessibility, and Best Practices.

Let’s see how to land a perfect 100 score in the Progressive Web App category while starting from scratch with Ember. We did this in the process of building www.shop-201.com, and the result is pretty great.

In the first half of 2017 I spent a lot of time preparing training materials for introductory and intermediate Ember.js courses. Now that 201 Created has given those training courses a few times I’d like to share how we approach teaching software in general and Ember.js in particular.

Our team at 201 Created is composed of Ember contributors and community leaders. I’m also happy to say it’s composed of individuals with varied background and experiences teaching and learning in different environments. Members of our team have taught programming to middle school kids, college students, and adult professionals.

Together we had run several small workshops, but working together to assemble the materials for a multi-day training has been a new experience for us. We created two courses: A course for beginners with some JavaScript but no Ember experience and an intermediate course for developers already familiar with Ember.

Interested in contributing to this effort? Give this post a read and join us in #st-module-unification on the Ember.js Community Slack.

Last fall the Ember.js Module Unification RFC was merged after a final comment period. This RFC describes a change to how Ember applications are laid out on disk. The change is a big one, and has several motivations.

• Simplify the rules for file naming. Ember maps a factory name to a filename using a part of the system called the resolver. For example route:cars is mapped to app/routes/cars.js in your application because of the Ember-CLI resolver. There are a few resolvers in the Ember ecosystem, however none of them have an internally consistent design. Instead, each is a fairly ad-hoc set of hard-coded solutions for whatever use cases came up when it was written. This make the filesystem of an Ember application more difficult to teach and learn than it needs to be.
• Allow for new features. Existing resolvers were designed without considering two important use-cases:
  • They did not take into account the idea of a component providing context for routed templates (aka “routable components”).
  • Components and helpers in Ember currently share a single application-wide namespace. The rules of existing resolvers limited how we could change that rule and permit components and helpers scoped to only part of an application (aka “local lookup”).
• Improve how addons are exposed to applications.
  • Ember addons currently expose themselves to a consuming application by merging their app/ folder onto the application’s app/ folder. This approach doesn’t allow for very robust namespacing of addon API away from app and other addon API.
  • Addons today cannot easily add their own “types” to the Ember filesystem. For example, ember-cli-mirage stores files in mirage/ and adds that directory to the build output. A goal of the new design is that addons may define new types that Ember and other addons can know about.
• Cleaner and better performing code. In existing resolvers the large amount of scenario-solving design makes it difficult to create an implementation that minimizes string allocation and branching logic. Additionally, the rules are so complex and ill-defined doing some of this work during a compilation step is not possible. A simpler, unified design friendly to a compilation step would be preferred.

In this year’s EmberConf keynote Tom and Yehuda made passing mention of module unification, but most of the focus was rightly on the Glimmer application project. Glimmer has been a great opportunity to iterate on parts of the module unification story, and where we take module unification next is coupled to how we can share solutions between Ember and Glimmer.

Let’s break down where the project is today and where you can help.

Say hello to Tom Zellman (@tzellman). Tom is CTO of the startup Digital Roots and runs his local Ember meetup in Ann Arbor, MI. Our survey team at 201 Created is happy to have him kick things off for 2017!

We are back at it again this year, asking...