ActiveCampaign loves Ember! The stability and productivity that it has afforded us over the past three years has been immense.
This year, we sent some people on our team to EmberConf to explore, learn, and share their experiences. I’d like to introduce you to the ActiveCampaign EmberConf 2018 delegation to share their takeaways from the conference!
Accessibility in Ember
Alexis Jennings shares her insights.
Accessibility was a strong theme of the conference. In Ambitious for All: Accessibility in Ember, Melanie Sumner gave the community five easy wins and five challenges.
The easy wins are simpler things we can all start doing now:
- Use Semantic HTML
- Link vs. Button
- Keyboard Navigation
- Consider Color Contrast
- Use ALT tags with image
The challenges were a bit harder:
- Announcing Route Transitions
- Accessible Modal Dialogs
- Better Aria-* Support in Ember
- Keyboard Functionality for all Mouse Actions
- Accessible Password User Verification
The energy from the conference around solving these problems was exciting. Since the conference, there has already been some discussion and movement on the modal dialog and password issues!
“Am I being pedantic or being nuanced?”
Streamlining Ember Mirage
David Tag shares his insights.
Sam Selikoff and Ryan Toronto ran a Mirage workshop that provided a lot of really great insights about abstracting common Mirage patterns and using those to potentially reduce code redundancy. I did a quick search of our Mirage configuration file to find potentially repeated code and found a lot of results:
I saw generalizing our Mirage endpoints as a sequence of steps. In the first step, we would generalize behaviors common among multiple Mirage endpoints (such as paginating results, as in the chance between the first and second code snippets below) and to create standalone functions that encapsulated that behavior.
The next step would be to abstract behavior even further: for every Mirage model that required this paginated behavior, we could provide one single place in the code where we would handle all pagination. That’s the change highlighted by the second arrow in the diagram below; this generic design for mocking endpoint design was something I wouldn’t have known without attending EmberConf.
Abstracting Common Properties
Broccoli Builds in Ember
Isaac Askew shares his insights.
Oli Griffiths ran a Broccoli workshop that dove into the details of how it works by building stand-alone broccoli transforms. They explored how it works in detail, how to visualize and debug your build pipelines, and how to reduce build times.
Running the visualization on our current ember app produced a very complex graph, which is probably why our current build times are so large. This will be useful in refactoring that down. Here’s just a snippet of our build visualization:
The broccoli caching system seems especially useful in a CI environment. We’re going to explore using broccoli-persistent-filter for that. Faster builds, here we come!
Progressive Web Apps in Ember
Kosal Vann shares his insights.
Marten Schilstra and Estelle DeBlois ran a “Deploying Progressive Web Apps with Ember” workshop. Marten explained what a Progressive Web App (PWA) really is, benefits of a PWA app shell model, and addons we can use to build and deploy PWAs.
Nick Schot gave the talk Creating Fluid App-Like Experiences With Ember, which explored his Ember-based PWA project. He focused on how gestures and routing interact at both the desktop and mobile scale.
The emphasis on offline performance wasn’t just about temporary service interruptions and page speed. It was very clear that writing applications with these issues in mind is still beneficial to the always-connected user as well!
TypeScripting your Ember Apps
Marion Huebner shares her insights.
TypeScript was another theme across several sessions. There seems to be growing interest in adding those optional types to our Ember apps!
Chris Krycho ran a “TypeScript Up Your Ember.js App!” workshop, where he explained how to gradually and sustainably move a legacy Ember app into TypeScript.
The great thing about migrating to TypeScript is that you can do this iteratively, by fine-tuning the strictness level of your type rules config. It is even possible to leave plain `.js` files as they are and still get some of the benefits of using TypeScript.
A partially or completely typed app will provides a few major benefits that make it worth considering the switch to TypeScript:
- inline, up to date documentation for functions and classes (in configured editors)
- encourages build time errors instead of runtime errors
- reduces “undefined is not an object” errors
- simplifies refactoring
- renaming a class will update it all use instances throughout the app
The ember-cli-typescript addon can get you started.
Functional CSS in Ember
Sean Massa shares his insights.
Sam Selikoff and Ryan Toronto ran a “Functional CSS” workshop that taught you the basics and ran you through exercises styling markup in an Ember app. I came in very skeptical of a utility-class-based CSS framework that promised to remove the need to write almost any CSS directly. After the workshop, I’m far less skeptical!
They covered three different aspects of building an Ember app with functional CSS: the specific CSS framework they prefer, how to reuse collections of utility classes effectively in Ember, and a new CSS grouping addon they are developing to make that easier.
The CSS framework of choice (well, of their choice) is Tailwind CSS. It’s designed to be customizable to your needs (brand colors, your own scale factors, etc.). Using this can result in some gnarly class assignments, though.
To combat that, they went over strategies for grouping lists of classes into Ember components. There was also an interesting discussion about separating your levels of abstractions in templates (Ember Components, HTML + CSS Classes, and CSS Rules) such that in each area of code you only have to care about one level. Taking this to an extreme, you can imagine a higher-order component (or route) template file only invoking ember components, then in a component only invoking HTML and CSS Classes, then in CSS files only using CSS rules. It’s hard to say how hardline you should be about this, but it’s an interesting idea that deserves more exploration.
To bring back some of the higher-level functionality bundling you used to get by writing your own classes, they introduced a preview version of ember-cli-ui-components. This allows you to group mutually exclusive CSS options on a component to provide a higher-level API for customizing a component’s visual options.
We can’t wait to see the release of this addon and the potential of this approach unfold. Sam and Ryan said that in projects where these use these strategies, they don’t write any CSS directly 95% of the time without hurting the maintainability of those projects. That’s really compelling!
Documentation and Communication
Colleen Grafton shares her insights.
“Developers will often resort back to old ways if not informed of new ones.”
During the opening keynote, I was excited to hear about some really cool new tools that would be released in Ember 3.0. But not all of these cool updates are available to us right now, which was frustrating. I was sitting in the crowd thinking, this will be really cool for people who can implement it right away. I wanted something I could get my hands on now!
While the keynote mentions cool new features and standards it also mentioned several ember-cli modification tools that can be used to automatically move your Ember Application from on old standard (such as the original file structure) to a new standard (such as the previously experimental pod structure).
Documentation is critically important for teams, especially as they grow. Discoverability, consistency, and clarity of that documentation determines how effectively the team can share knowledge. We have a responsibility to not only record our standards but inform everyone that they exist. Using new Ember-Cli Modification tools we can reduce the amount of deprecations we need to document and focus on the future!
The energy at EmberConf was very positive, inclusive, and infectious. Community was a pervasive theme of the conference. We all came back excited not only about the future of Ember, but also about the current tools we have access to that will make our application better.
The closing keynote Shining a Light by Saron Yitbarek and Vaidehi Joshi was especially great at highlighting many important aspects of community, responsibility, and representation. We encourage everyone, not just Ember developers, to watch it.
We can’t wait to go back next year!