The Ember project has opened a Call for Blog Posts to help inform the first ever EmberJS project roadmap! Read my thoughts below, then share your own with the hashtag #EmberJS2018.
This is my wish-list for the things I’d like to see happen in the Ember ecosystem in 2018! The overall theme of how I imagine things could be? “Developer ergonomics.”
Accessibility
My #1 goal for this year is to see us figure out how to tell assistive tech that the view has changed (even if the URL hasn’t). No framework solves this problem out of the box yet. It might be bigger than a framework- it might take coordination with browsers and folks to work on assistive tech. BUT, I’d like us to figure this out- and I definitely believe this is possible. I believe we can be magnanimous and inclusive and get this done for EVERYONE.
I also really like Jamie White’s RFC that addresses the need for Semantic Test Selectors! The idea of Ember providing the well-lit developer path for more inclusive development is something that I am completely on board with. Developers don’t want to have to think about this sort of thing- so making it there by default is super helpful!
Ember Engines
The ember-engines model for “how to giant apps” is absolutely incredible, especially for companies with globally distributed teams. It allows teams to build individually but then it all comes together without name-spacing issues. It’s so.fucking.cool. Right now, dependency management is very difficult though. It’s hard to explain to globally distributed teams that “yes you can build in isolation but if you want it all to work when it comes together you really need to plan your dependency versions better” because I then get the response of “then what’s the point of using engines at all?” (which ugh but okay)
Things that would explicitly make my day job easier:
- teams could not have to care about what versions of dependencies were in peer engines (say, as long as the major release was the same, maybe?)
- there would be some sort of exploration phase of the build, so that dependency tree-shaking could happen a bit more intelligently.
- the documentation would be more clear about the problems you would see if you chose to do things weirdly- this might seem like a weird ask but when you think about the types of issues that an enterprise team would face, and that the use case for ember-engines is well-suited for the enterprise environment, it will start to make sense why this is an explicit wish-list item.
- there would be an increased number of use cases around ember-engines so more experimentation can be done
- the testing story being clearly defined (and maybe finished!)
Better Evangelism
Developers that love Ember really love Ember….but after the 100th time you hear “wait Ember is still a thing?” it gets pretty old. It’s especially frustrating to see newer frameworks trying solutions we already know won’t work, or shouting that they’ve invented something new when it already exists in Ember. It’s discouraging to see devs not understand how Ember frees you from needing to care about the inconsequential decisions that are maybe fun to work on, but will get in your way when you’re trying to ship business value. It’s irritating to be rejected in a conference CFP because you used Ember in your examples, and not (anything else).
I want everyone who loves Ember.js to speak up and be counted, with a strong bias toward action. Be present, loudly but not obnoxiously. I want our internal community to feel so supported that they don’t have any complaints to begin with, and if they do, they’ll come talk to someone about it first.
This June, it will be 22 years since my Uncle Paul gave me my first computer and told me, “learn how to write code for websites- and not just how to use a GUI tool. Write the actual code. That’s the future.” I started writing code then and I’m still writing it now and I can say beyond a shadow of a doubt, that Ember.js is the thing I’ve been looking for all my life- and I’m here to help it be everything we have ever imagined.
