Posted on

Today's Ember is not what you think either

Prelude

In considering the call for #EmberJS2018 blog posts, I wondered whether I should add my voice. The past two years I have been blessed to work alongside a deep bench of core-team members and regular contributors to the community. During this time, most of my open-source contributions have been towards one of the core projects (#emberData) and helping to set its direction.

I mention this because in a lot of ways I have felt that I am too invested and too close to the project to write one of these posts. In addition to giving the community a greater voice, a driving principle behind this request for blog posts was to surface where the primary contributors have not seen the community's needs.

However, as more posts were published and common themes emerged, I realized that I have much to say from a perspective the community seems to be missing. I present that perspective organized into two parts: Ember in 2018, and Ember in 2019. This post is for 2018.

Ember in 2018

Today's Ember is not what you think.

Many of the posts thus far have focused on doubling-down and delivering promises and work already in the pipeline. And I agree! What's more, if you watched the keynote from EmberConf this year, you probably already know that core agrees as well, and that many of these commitments have already landed or are near landing.

Other posts have focused on the need for additional learning resources and a stronger focus on documentation. I agree! Especially when it comes to Ember Data. By not documenting friendly patterns for solving common problems, we have left countless users frustrated. The key insight here (I think) is that not every developer thinks like an architect, and we shouldn't expect them to. Some folks, especially beginners, are primarily implementors, looking for productivity by using the set of known-solved problems.

More importantly though, as pertains the learning story for Ember Data (and probably other parts of the Ember ecosystem as well), we have not made ourselves available as contributors and maintainers to help users to understand and use the project we are building. When I look at the success of Webpack and Redux , I don't see ideas or projects that were so powerful that they built overwhelming momentum automatically. I see contributors like Dan Abramov and Sean Larkin that spent countless hours on twitter, in Github issues, and in other public forums helping their users understand and best utilize their projects.

In the Ember ecosystem, we have a learning team. I think this is amazing, there is undoubtably more work to do on learning and documentation than individual project contributors can handle on their own. But offloading the entirety of the learning and documentation story to the learning team is not something that we should have done. It should not ever have been their responsibility to understand our intent. Going forward, we need to collaborate better, and to do so consistently.

A parting note on the absence of contributors in the learning story: many folks have complained about our use of Slack as a learning medium. On one hand, I agree, more things need to exist in more permanent mediums. Lot's of other folks agree too, which ultimately has led to that discuss post being buried almost 500 posts back. I still believe in the benefits of "ephemeral" explanations, because best practices and best answers evolve with time and often blog posts are a wee bit too permanent. But I didn't bring this up to defend Slack, but rather to sound a warning about Discord.

One of the benefits of Slack was that conversations about work being done on the framework were had in public channels. Anyone could see them, anyone could engage, it was easy to spot the progress and momentum (as long as you were active in Slack). While some of these conversations would (again) have been better suited to a more permanent medium, we have instead moved most conversations into a public-but-not-publicized discord forum. Tons of amazing ideas are discussed there, in tantalizing technical depth. Locked away. I don't think the intent was to hide the conversations, but rather a desire to avoid the message-loss of Slack and the annoying performance of Slack's mobile and desktop clients. Regardless, I don't think this has been good for the community. We have a lot of contributors, a lot of strong ideas, a lot to say; but we are saying it into our own box instead of out in the broader community. I think this hurts us.

And finally, a few posts have tried to lay out vision. I am particularly a fan of @pzuraq's blog post describing Ember as a Component/Service architecture. This is a viewpoint I subscribe to heavily. In fact this viewpoint is why I say that Ember in 2018 is not what you think.

For the past 2-3 years, the Ember apps I've worked on (mostly outside of work..) have centered around this viewpoint. Yes, what I am saying is that I've been writing Ember apps using ES2015 classes since 2015, and doing so from a component/service architecture perspective. It confused me, tbqh, why more folks didn't discover the extent to which "just use Javascript" has worked in Ember for a long time, and I think Ember should have done more sooner to make "just use Javascript" the default experience. Better late than never though.

It is, of course, worth noting that in those past few years Ember has invested in ideas like broccoli and glimmer that seem capable of carrying Ember to undiscovered heights. Even while we've fallen behind in areas around what folks see, we've leaped ahead in terms of what we are building upon. It's time to bring those foundations out into the clear, strip the cruft, and see Ember for the beautiful gem that it is.

So what is Ember today?

The Framework

Do you want to use Typescript? Awesome! Use Typescript. Not only is there support for it, but that support gets better all the time. Especial shoutout to Dan Freeman for his work to bring Typescript support to handlebars templates.

You likely know that Glimmer is written in typescript. Ember and Ember Data have embarked on a journey to be typed as well. A big need right now is for community addons to expose typings (even if not converted to typescript), and that's somewhere you could be involved.

That said, Typescript support would be even better if we supported native ES Class syntax and @decorators , right? So use them!. For the most part, classes and decorators "just work"™ with a few caveats:

Mixins have second class support, although honestly you should just start refactoring them away. Services, Singleton Modules, shared utils, helpers, higher-order components, and component composition are all better sharing primitives than Mixins.

Events and Observers don't quite work with decorators and classes yet.

Using JS module imports would also help editor integration and Typescript, yeah? So use it! In fact, if you don't use it, you'll get a nice eslint warning these days :D

And isn't Ember.get and this.get annoying a.f.? So don't use that either :)

Don't use jQuery ? It's no longer required, and you can drop it today to see a very nice file-size saving in your bundle. You might want to help some of your favorite addons migrate off of it though :)

Want to use async/await ? Just do it! Ember Concurrency is an amazing project, but it's by no means the only way of utilizing this nifty language feature. We've done work in Ember, Ember Data, and most core addons to ensure they play well with test waiters and async/await. When working to ensure good async/await compatibility we even took the opportunity to add automatic test leakage detection to ember-qunit .

In the Pipeline

A few things are also still in-the-pipeline for the core framework, but Very Close™ . And if you want one of these things, help land it! There's tons of work being done, but more hands makes lighter work :)

The build system

I see a lot complaints about build performance and features. Folks struggle to find learning materials for broccoli . Many folks ask why we don't just use webpack . Some of these complaints are because of feature requests such as tree shaking and code splitting .

I firmly believe that building over broccoli is one of our greatest strengths. Do you like immutability? Functional programming? Virtual Dom? Awesome! There's a reason that Stefan Penner sometimes describes broccoli as "react for the file system".

Broccoli is a file system renderer, that takes a set of file paths as inputs, and produces files as outputs. Broccoli plugins are components, they receive immutable args, and their output can be passed into child components. Plugins instead of components, files instead of data and html. This is broccoli. Broccoli doesn't itself do anything to your files, the components ... er "plugins" you write do that. Babel, uglify, source-map, asset-rewrite, webpack..., rollup... these are plugins.

Performance concerns are typically misplaced angst at the performance of particular plugins, such as uglify , source-maps , browserify , image processing, sass , or babel . These performance concerns affect every eco-system alike, and improving those core libraries helps everyone. Often core Ember contributors have invested time to do just this to ensure that builds are fast for others.

Want to know what components in your build or rebuild are slow? Here's a tool for that.

But that's not to say we still couldn't improve! On the performance side, ideas we are trying to bring to ember-cli include

Prebuilt Addons

Faster source-maps

less dependence on browserify

A virtualized file-system (basically smarter diffing and smarter data flows between your components... err plugins ;) )

Upgrading to Broccoli 1.0 (to use system tmp , which will help both Typescript users CPU and windows users)

You may have noticed that I described Webpack as a plugin. Soon, it'll play a role as part of the default packager strategy. And herein lies a truth we've been trying (poorly) to explain for a while: Webpack and broccoli are NOT competing, but complementary. There's likely a lot of work to be done to make Webpack (or Rollup, or something else) realize their full potential as a bundling solution, but one thing is clear: broccoli is not a bundler.

Broccoli being clear about what it is and how plugins and addons etc. work means that ideas like build-targets and prebuilt addons are first-class.

More importantly, it means that when we give files to the bundler, the bundler doesn't need to figure out things like which files need transpiled, and how to transpile them. The bundler gets to focus on it's core purpose: bundling.

If you love the concept of higher-order-components, or the single-responsibility principle, you will love broccoli. Now it's time to learn it.

What's coming for the build system?

A lot of great things are coming very soon to builds near you (as in, this work is either in releases already or in PRs approaching release). This includes:

even more build svelting (we're getting good at eliminating things in ember-data and ember that you aren't using or don't need) even more production code stripping of debug code

code-splitting

tree-shaking

module unification

So please, help us bring home all the greatness, and make these defaults that everyone gets out of the box! :D

Exiting 2018

As a parting note on 2018, I absolutely 100% agree that we need to deliver on the work that is in the pipeline. But this is either a future that is already here ™, or closer than you think ™. With that in mind, I think it's time to look towards the future. What can we do as an ecosystem, as a community, as a team to build an technology stack that is happy, productive, easy, and performant?

I'll tackle these questions in my next post, Ember in 2019.