Skip To Content

Ember Conf 2018

Day 1 #

Keynote #

Ember is seven years old this April. Emphasizing the framework's built in conventions and stability, for building ambitious apps quickly. Relies greatly on the community.

One presenter is dressed like they're presenting the Oscars. Another is dressed like they're managing the Oscar's IT systems.

Goals to 2019:

Plot twist - All of these currently in the stable, beta, or canary release.

Upcoming changes (in RFC):

WebAssembly - gets native-speed on all different devices and browsers. Very good progress on getting all of Ember and Glimmer integrated with WA.

Accessibility in Ember #

Accessibility - defined as making app usable by people of all abilities, disabilities, and and conditions.

Official Standard - WCAG 2.0. Has three measures: A, AA, and AAA. AA will usually cover most businesses.

There's been many advances in bringing disabled people certain senses and abilities back, and Ember should try to do something similar with accessibility solutions (aside from making #A11Y tomsters).

Web Standards here to save the day! #

Don't stop fighting. Fight about the right things, for accessibility. Don't look unaccessible apps and say "this is fine."

Some add-ons exist for this (but not quite enough: #

Don't feel bad about knowing how to do this yet. Don't pretend you do.

Ember Community #

People often make (sub)cultures around tech. Subculture: a cultural group within a larger culture, with beliefs/interest at variance with the larger culture. Similar yet also distinct.

What of the Ember subculture in JavaScript? #
Ember Subculture's Communication #

Say More - Testing and Test Helpers #

Slides here

A "What if?" talk about UI Testing #

Next Generation of Testing #

Slides here

Ember's New Filesystem Layout #

New filesystem (Module Unification) is still in development, but should be ready soon. #
Basics of new filesystem #

Today, this can be used with the CLI Canary with a feature flag

Mastering the Art of Forms #

Slides here

Two main pieces: Component Patterns and Data Management

Component Patterns #
Data Management #
Accessibility #

Training and Hiring New Devs #

Ember has great stability, but this makes it harder to get others excited for the framework as much as others. So how do you hire well for people to work with Ember?

Develop a good Ember teaching culture that lasts #
Leveraging these things to teach Ember #
How it Affects Hiring #

Final tip - have a Style Guide for constant programmatic reference. Don't just rely on Ember Docs.

Living Animation #

Slides here

Game-Engine Principles #

Ember Animated - A "Glimmerization" version of Ember Fire

Day 2 #

Future of Data in Ember #

Future of Data in Ember is whatever you need it to be. Several different data tools we can use that meet different needs.

Only need web standards for simple data task, like fetching JSON from a server-side endpoint(s). Only web standards === no Ember Data needed.

Problem: Need to fetch data while online.
Solution: Service worker add-ons (a proxy between the app and the network layer, can cache and use cache as a fetch fallback). Still just web standards as well.

Problem: Add admin pages to edit data (no offline use needed).
Solution: Need new server endpoints for CRUD. Move past pure web standards to include Ember Data.

Problem: Everything must work offline, including admin pages.
Solution: Orbit data layer, or ember-orbit. Queues up CRUD updates and executes them when back online.

Problem: Update costs are relatively high due to adding these additions.
Solution: Apps may need to just accept the complexity trade-off for these capabilities. But each addition doesn't require extra heavy configuration, sticking with the Ember philosophy. Also strong boundaries between each new, functional layer.

In 2013, JSON API gave Ember a strong, flexible connection to the different data layers provided by the API. Works well with Ember Data and Orbit.

JSON API secret - composable, well-defined interfaces can interact with it. Gave lots of freedom for these interchangeable components to interact with it. It works well with this scaling of the Ember data layer since it works with basic CRUD up to more advanced data fields. v1.1 will soon be out to expand this even further.

Applying this to Ember Data: Use the same secrets as JSON API - composability and extensibility, working with well-defined interfaces. This includes different adapters and serializers. Need to address the tight coupling between store and model, which decreases space and available data new add-ons need to work.

Orbit basics - synchronizes data between many different sources on the same level. Allows flow-control for actions dependent on others, such as with promises. Uses a cache to track changes, and handle them in a git-esque workflow.

In the future: Ember data can have Orbit's capabilities in a convention-driven package, and give lots of experimentation (similar to how Glimmer is to Ember).

Smartphone Symphony #

More of a demonstration piece where all our phones are possessed, no real notes here.

Journey from Projects of Products #

Using Ember to not build "ambitiously scalable web apps," but instead "ambitiously fast web apps."

Projects - Sold then built
Products - Built then sold

Take the Ember framework and use it as a group of evolving templates for different projects. In this case, templates for web pages for movie companies/releases.

Work with:

Requirements to use this model:


Template is broader, as a base app with defined user flow. A specific purpose, but open within this purpose.

Ember makes is easier to create a living style guide for your template as well, by displaying all the components on one page.

Ember Events #

Within the DOM there are specific DOM events, such as click and keypress. DOM Nodes let the program do something when an event is triggered. A common way to do this is the onclick attribute that holds the JS to execute, or link tags to event listeners.

Event Propogation - Process of events bubbling up through the DOM tree.

When using Ember event listeners, event propagation can be stopped with the bubbles=false attribute. Ember handles the state of all the DOM event listeners through the Ember source code.

When clicking an Ember element:

  1. Calls any native DOM event listeners
  2. Calls any propagated DOM events
  3. Calls any Ember events on the elements
  4. Calls any propagated Ember events

Note: DOM events are called before Ember ones! So how to tell them apart?

Make sure Ember ones don't accidentally become DOM ones, since it'll mess up the order and damage the app flow.

Other gotchas:

Main takeaway: pick one event listener API and stick with it. Neither one is really faster or have better performance. Just choose one you can write the best.

Best option for optional events listeners: buttons with disabled states (semantic HTML). If that's not an option, can use conditional HTML to render clickable elements or conditionals in native DOM events (careful if they clash with Ember events).

Ember Debugging #

Tips and Tricks #

Lightning Talk - Toyota's Shared Component Library #

Fluid App-like Experiences #

Slides here

Layout - setup with a fixed header and footer around the main viewport content. Best done with CSS Grid or Flexbox.
* Uses a Material side menu that pops out from the side

Transitions - good for increasing perceived responsiveness, showing the app's flow
* Keep with theme by having new pages slide in and out of each other.

Responsiveness #

Closing Keynote #

Both are ways the speakers at first felt alone, but then through this loneliness built a community. Both succeeded at least in part by their friendliness and inclusiveness.

Also good to acknowledge and validate the initial fear of learning something new. This makes it easier to begin learning and finding a community.

Despite wanting to be inclusive, there are always biases and blind spots that limit the communities we can be a part of and serve. Can fill these by listening to those with different lived experiences than our own.