Ember: Our Secret Weapon

At Prototypal, we’ve been using Ember since the very early days of the project, when it was still called SproutCore 2.0. We’ve never been more excited for the future of Ember. As part of the #EmberJS2018 call for posts, we wanted to share some of our thoughts with the community as one of the earliest Ember.js consulting/training companies and the team behind Ember Weekly and Embercasts.

We consider Ember a secret weapon that enables teams big and small to be massively more productive and ship industry-leading web experiences in a fraction of the time. The productivity you get from Ember isn’t just about the framework’s code. It comes from our community, which values building shared solutions, and from the process used to run the Ember projects. A big part of this is because of Ember’s commitment to SemVer and it’s train release model. These give Ember users the confidence that new features and improvements will be regularly released, while also knowing that they can stay up to date without needing to make significant changes to their codebases. For Enterprise projects that need longer term support or security guarantees, Ember’s twice annual LTS releases ensure support and security without having to stay up to date with the cutting edge. No other JavaScript framework offers LTS releases. The fact that Ember defines patterns for most of the common architectural needs of a web app means that once you learn Ember, you’re able to jump across projects and teams with ease. It’s common for Ember developers to be shipping code to production days after starting a new job.

Onboarding the next generation of Ember users

Ember has traditionally had the stigma that it has a huge learning curve. Those days have long passed, thanks to the amazing work of Ember’s Learning Team. We believe web development without Ember has a huge learning curve. At Embercasts, we’ve been focused on helping onboard new developers to the ecosystem by trying to bridge the knowledge gap for developers building traditional web applications. We’ve currently released courses for Rails and Phoenix, with Node.js, PHP & .NET courses coming soon.

One particular area that we think needs attention is how we teach data access with Ember. For years, Ember Data has provided a first class ORM experience with caching, relationship mapping, and background loading all baked in. We use Ember Data every day in our projects and think it’s a great choice for many applications, but it’s not the only tool we use. With the Fetch API and Promises now included in every major browser, along with the rise in popularity of tools like Redux, GraphQL and Apollo, it’s hard to prescribe Ember Data (at least as it is today) as the right solution for every app. We think it’d be a great improvement to our guides to start teaching Ember without Ember Data, instead just using fetch. That would allow new users to better understand how Ember works and be able to choose (or build!) the right data library for their app’s needs. We also believe more effort needs to be expended marketing the benefits of JSONAPI.

While Ember has never required the use of Ember Data, it’s been the only officially documented solution in the guides. That has made it seem like the only way Ember apps should be built, instead of how they could be built. Thankfully, these ideas aren’t controversial. It’s clear the Ember Data team is committed to break Ember Data down into smaller libraries that can be used more incrementally. The future of Ember Data looks extremely bright.

Zero Configuration by Design

One of the trends in JavaScript in 2017 was the rise of tools like Create React App and Parcel.js starting to market themselves as Zero Configuration. Ember and Ember CLI have led the way with Zero Configuration tooling in the JS ecosystem, except have historically been marketed as Convention over Configuration. While this phrase is proudly embraced by the Ember and Rails communities, it doesn’t resonate with many developers. Even though they mean pretty much the same thing, this messaging is something we should improve on in the Ember ecosystem.

We should also promote that Ember is much more flexible than most people realize. Tools like Redux & GraphQL are usable with Ember. Ember’s testing harness has been refactored to better support different testing tools and patterns. Ember is also easy to integrate with projects like Tailwind CSS as shown by Ed Faulkner’s recent video.

This flexibility is key, but like most software, can still be further improved. For many popular libraries, there are corresponding Ember Addons that provide a Zero Configuration bridge and great developer experience. Some of these addons, like ember-moment, provide nice Ember-specific functionality alongside the Moment.js library itself. These types of addons are super helpful, and we believe there will always be a place for them, but Ember CLI needs to support using regular NPM packages out of the box, where import moment from 'moment' works by only running npm install moment instead of needing ember-moment-shim.

There’s great work being done right now by Kelly Selden and the Ember CLI team to bring this and other features, like tree-shaking, to Ember. Massive enhancements to the internals of Ember CLI are underway, all while staying true to SemVer.

Ember Can Get Smaller

One of the key dynamics that has changed recently in the JavaScript ecosystem is that the language itself has evolved at a rapid pace. The hard work of folks like Yehuda Katz and Dave Herman on TC39 have helped modernize JavaScript. For most of its history Ember has had to fill in the gaps of the JavaScript language. Now that the platform has caught up, Ember can shed a significant amount of its codebase and provide automated migration paths towards things like ES Classes and Decorators.

Ember has also begun implementing a “Pay As You Go” strategy in the framework. That means that you should only have to ship the framework code you actually use. This is critical for Ember to stay a competitive choice for building web experiences in 2018 and beyond. The Ember Community, and in particular LinkedIn, have invested significant resources into making sure there won’t be any reason to not build with Ember. At Prototypal, we no longer see the need to distinguish between “websites” and “web apps.” Ember will be the best choice for both, thanks to the great work being done on Glimmer, FastBoot & Prember.

We’re already on the right path, let’s just keep shipping

We genuinely believe Ember is already on the right path, it’s just a matter of execution at this point. Tom & Yehuda’s keynote at this year’s EmberConf shared the vision. We’re very close to having a “shiny new Ember.” One that we can iteratively adopt within our projects, while keeping all the things we love about Ember today. The value of being able to iteratively adopt new framework features and patterns cannot be understated. At Prototypal, we help our clients build multi-million dollar products for the web. Rewriting on a yearly basis to keep up with latest features or current trends is not a option. By design, Ember allows teams to adopt features as they go and upgrade over time instead of needing a rewrite. Tools like codemods and ember-cli-update make this process even easier (and almost automatic!) for many Ember projects today and we’re excited to see this trend continue as more tools are released. As new features arrive, you’ll be able to use them right away to deliver value.

If you’re interested in learning more about the modernization effort in Ember.js and what new and exciting features are available today, we recommend you check out our teammate Ryan Tablada’s recent talk at the Silicon Valley Ember.js meetup.

Thanks for reading!