a procrastinator's ember.js roadmap 2019-06-04

Given it is already June, I'll share my thoughts in 6 points or less.

This post responds to the call for blog posts in 2019 about ember.js and its direction. I've appreciated reading the 2019 roadmap posts thus far. I subjectively respond below. Flagrant name-and-hyperlink-dropping ahead. Besides, what else is internet for?

more teaching

the voice of Ember's leadership is largely missing from the materials that are most often used. Jen Weber

I think we should treat learning as important as the technical ideas that distinguish ember.js. This echoes what Chris Krycho said last year about technical leadership. Teaching ember.js has been challenging. I also find gaps in advancing I and my team's knowledge about using the framework as best we can while building a product. My fabulous colleagues have often asked spot-on, difficult questions about the guide's admonitions to do something a particular way. I too often resort to shallow "that is just the way it is" answers. I appreciate the zest to Andrew Callahan's post; however, I do not agree with reducing the entire programming model in ember.js to components. I do agree we need to simplify what key concepts we teach and how. Ryan Tablada gave a talk on this last year and I found it helpful to share when onboarding new developers. Rich Hickey's Simple Made Easy talk has shaped how I think about the trade offs between designing for ease versus simplicity. I complect far too often.

clarify role of ember-data

The current state of ember-data documentation fails the new user twice. Identify the goal and mission of ember-data. Write it down, refer to it often. Melanie Sumner

I think we need to clarify the use cases that justify ember-data and then tailor the guides and other learning materials to suit. Chris Thoburn's announcement to blog about ember data complements this goal and how to improve learning nicely. What are other "happy paths" for working with data in ember.js applications? The guides and official learning experiences have the potential to help guide users of varying experience. What are "happy paths" anyways?


Addressing accessibility issues in your application makes your application more usable. Yehuda Katz

I too often neglect caring for people with limited abilities to experience the benefits web technology can bring. Neither government or market demands force me to implement accessibility in the primary application I work on. We could expound on and debate the ethics here extensively. I'll side step and offer two reasons:

  1. Web technologists build with an abundance of resources. We should give those freely, especially regarding those who have less resources.
  2. Why not? Engineering challenges abound and offer satisfaction to the solvers. This is an engineering challenge that community can solve and then share as a helpful nudge.

close the loops

The Ember project as a whole needs to get much better about closing the loop on these dead ends, and communicate more clearly with the community so that they can avoid known future pitfalls when developing their ambitious applications. Robert Jackson

I think core teams have improved their communication since last year. I still think we can improve communication and distribute news and key decisions redundantly throughout the ember.js community. The ember-cli 2018 roadmap thread was a great first step, but I do not think follow up happened.

terse postscript

Yes to improve query params. Yes to embroider. Yes to "interactive code, data-driven graphs, or user stories" to better explain the whys of ember.js. I think that relates to the discussions the learning team has had about a why page. Thank you for reading. I look forward to further discussing and making ember.js better this year and beyond.