May 30th, 2018
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.
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.
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
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 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 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!