Blog Post for an Ambitious Framework
The Ember project has opened a Call for Blog Posts to help inform the writing of a project roadmap. Read our thoughts below, then share your own with the hashtag #EmberJS2018.
201 Created has been working with Ember.js since Cory and I signed our first client in 2013. We’ve grown the business slowly but deliberately, choosing to take on projects that kept ourselves and our growing staff close to the framework.
Our team as it stands today has worked on several dozen apps. We’ve worked on greenfield projects for small startups and performance and maintainability for well known, high-traffic sites. We’ve run Ember.js training for developers who never saw let
before, and have made meaningful contributions to most of Ember’s codebases and community efforts (including the Ember Community Survey, itself a good look at what people think about Ember).
Five years in seems like a good time for us to share our thoughts on where Ember is today, and where we would like to see it go. To get the conversation going, I’ve prompted the 201 Created team with a few questions:
Why do we recommend Ember to our clients?
Cory (Cory Forsyth): Ember apps are easy for teams to work on. They have a consistent structure, a great addon ecosystem, and an excellent build/cli tool in ember-cli. These same features help us at 201 Created to be immediately productive when we enter into a new engagement with a client. We can jump into a codebase with a minimum of hassle because we know where the components, helpers, controller, routes, addons, etc. all live. For example, we can look at a template file and, without even looking at the rest of the project’s files, infer the backing context for that template (its component or controller) and make educated guesses about how it fits into the rest of the app. This helps developers at our clients stay productive, too. They can rotate people on and off an Ember project, as well as maintain multiple Ember projects at once, because Ember’s conventions provide a similar structure, with the same primitives and concepts, for all your apps.
In frameworks that are more minimal, or less adherent to the convention-over-configuration approach, this isn’t the case. We’ve found clients that use other frameworks typically have similar problems (routing, data loading, template rendering, js bundling, etc) but, when their frameworks don’t provide affordances for these needs, solve them in disparate ways. The result is that in companies with multiple long-running projects on the same framework, they have completely different approaches to solving those same problems and that hampers the ability for developers to drop in and out of these projects productively.
We sometimes hear developers talking about not needing a framework, or not wanting all of the overhead that an ambitious framework like Ember provides. My take on this attitude is: You do need a framework. And you will end up with one, either by selecting one deliberately, or through the accumulated small decisions you make along the way. You could choose a minimal framework and then work out solutions to the common framework problems you meet along the way, in effect building your own customized framework, or you can choose something like Ember that has best practices for many of those requirements already and lets you focus on writing code that solves the problems that are unique to your business.
Isaac (Isaac Ezer): The Ember community does a great job of introducing new techniques and ideas that emerge in the broader web development community into the framework so that they can be introduced into existing apps that were built long before these techniques were on anyone’s radar. Good examples of this include the Glimmer rendering engine, service workers, and building desktop apps using Electron.
The community also does a good job of rallying around a smaller number of shared solutions. Most Ember users who want to integrate with Google Analytics or Stripe, use D3, or test their app for accessibility, will choose the same add-on for each of these purposes. This increases the odds that an add-on you choose to use today will still be around and actively maintained several years from now.
Matt (Matthew Beale): Ember has good performance characteristics and can adapt to most use cases where a single-page application is appropriate, but I suggest Ember for other reasons.
Ember applications sustain. It isn’t rare to see an Ember app that started early in the 1.x release cycle and is upgraded and going strong today. That kind of long-term, productive platform is something I’m happy to build for our clients.
Ember is also responsive to the needs of our clients. When a project introduces a dependency, its team effectively cedes the power to make technical decisions over part of their domain. In frameworks run by a single company, there are few ways to influence what maintainers prioritize. Ember, as a community-driven framework, is more malleable. Clients can make significant contributions, they can sponsor features, they can publish addons and rally community around them, they can write RFCs, and they can become leaders with a clear voice.
Kevin (Kevin Pfefferle): As software developers, we spend our day working out solutions to problems. I enjoy working through the problems specific to the application I’m building, but I don’t enjoy spending my mental energy working through boilerplate problems. I recommend Ember for client-side development because most of the boilerplate problems are solved for me by the Ember framework and addon ecosystem. This allows me to focus primarily on the problems that are specific to the application I am building.
Jonathan (uosʞɔɐɾ uɐɥʇɐuoɾ): In short, Ember applications are built to last. In a JavaScript ecosystem that I’d charitably say churns more than others, Ember stands out as a good option for long running projects.
For years I worked on applications written in jQuery, Backbone.js, Angular 1, and Knockout. Each one needed a custom, bespoke setup. Ember does a very good job of ensuring that boilerplate decisions are taken care of. It makes sure that new developers can be on-boarded with ease. Ember allows us to focus on the interesting problems in our client’s domain instead of re-inventing a build tool, or an asset pipeline.
Furthermore since Ember has been doing this with an eye on the future, the solutions it provides are tested against many large and long-lived apps. This means that the solutions for testing, build pipelines, asset management, and much more are really well engineered and will carry our client into the future.
Why do we, as consultants, continue to invest in Ember?
Matthew: The Ember project’s focus on common solutions means we see the same addons and design decisions again and again. This helps us be incredibly productive with our clients, often opening a pull request in the first few hours of an engagement. That isn’t to say every solution is perfect, but like any complex tool after working with it for a long time we’ve learned how to best leverage it.
201 Created is able to have a partnership with the Ember community. We’ve invested into the project by running workshops, writing, speaking, sponsoring conferences and travel, and more. I feel like we have agency to influence the project and help it grow, and to be part of that growth.
Kevin: I believe wholeheartedly in the value of shared solutions. When I run into a problem that seems like a problem other developers might share now or in the future, I’m excited to share an open-source solution that not only may benefit others, but also may benefit my own projects as other contribute to iterating on that shared solution. Ember’s community, robust addon ecosystem, and prioritization of convention over configuration make sharing and collaborating on solutions a core part of the Ember experience.
Isaac: We work with great clients who have been using Ember for years and continue to get immense value out of the framework. We also have new clients contacting us all the time, often companies we’ve never heard of, who have done amazing things with a very small team on a tight timeline.
There’s also a fantastic community around Ember and it’s a joy to catch up with very smart, talented, helpful, and friendly people at conferences around the world (Portland, San Diego, Amsterdam) to see the amazing things that they’ve been building and how we can collaborate on open source projects.
Ember has a great baseline for productivity, but some functionality easily “hacked” into other frameworks requires an expert in Ember. What features suffer from this, and how can we improve Ember in this regard?
Cory: Ember is very much an “all-in” framework. This quality has benefits, but can make Ember a challenge for new developers. For example, many web devs want to treat Ember templates like “augmented HTML”. This works fine most of the time because Ember templates look a lot like HTML with occasional “curlies” in them, but you’ll run into trouble if you add a <script>
tag. In my experience, the largest source of friction for new developers is when the lessons they learned about unadorned web APIs (HTML, JS, CSS) don’t apply to Ember.
Another example of this difficulty is interacting with jQuery plugins. Nearly everyone has already “integrated” a jQuery plugin into a website in the past, and the process is very simple: Add a <script>
tag to your HTML file, then invoke the jQuery.somePlugin
API in a DOMReady
listener. Ember’s architecture doesn’t map well to this mental model. Instead of dropping a script tag into your HTML, you need to instead incorporate it into your build file. Getting this done in the optimal way, such that the plugin’s output is import
-able, isn’t always easy, and is almost always harder than the alternative (putting a script tag in an HTML file). After making the jQuery plugin available through the build process, understanding the didInsertElement
hook is another mental leap for a learning developer.
These impedance mismatches between “how I did it before” and “how Ember wants me to do it” arise most often when coming from a less complex framework, be that React or Vue or (most often) “plain HTML and JavaScript”. The complexity that Ember brings feels uncomfortable when you know there’s a simpler solution that you’ve used before, and the lack of a mental model for Ember’s architecture can make it feel like the Ember Best Practice is more involved than it needs to be.
One way that Ember can improve is by doing its best to look more like the world that other developers are coming from. There are numerous examples where Ember has, and continues, to do this. The use of this.get
is a common stumbling block, and Ember 3.1 makes ES5 getters a possibility for the first time, eliminating many of the places this.get
would be needed. Ember’s templating system has improved by leaps and bounds over the years. Not long ago, the fact that <div class="static {{dynamic}}">
didn’t work was a stumbling block, but Ember has sanded down that rough edge as well. The runloop is a frequent source of FUD for developers, and its importance is also being actively minimized in modern Ember. These changes help to reduce the mental model shift that new developers need to make.
Another way Ember can get better is by improving the documentation so the necessary conceptual building blocks of Ember are more quickly understood by new developers. The more they get to know the building blocks of Ember, the better their intuition about how to use it will be.
Matthew: Lazy loading for parts of an Ember application should be simple. Ember has declarative APIs for its rendering layer and, with module unification, a file-system layout that constrains developers into writing apps friendly to route-based lazy loading. Ember apps should provide this functionality out of the box. Having used Webpack for this, I think Ember has a fair shot at creating a more developer friendly and maintainable solution.
What are the most promising parts of the web Ember should take advantage of?
Matthew: Google’s Progressive Web App (PWA) initiative has always been popular in the Ember community, but the framework itself has remained hesitant to embrace PWA recommendations out of the box. This applies to places where picking a default is hard, like ServiceWorkers, and to recommendations that should be easier to comply (for example the web app manifest). Experienced developers can add these features to their apps in minutes, and that means we’ve dragged our feet on the slightly harder work of making them default.
I’ve long been frustrated by Ember’s weak support for web components. The path to improve Ember’s support for web components is very clear: We need to make attributed default in Ember templates and introduce explicit prop and listener modifiers (an alternative would be to introduce a generic element modifier API).
Ember makes many things about single-page app development easier (build pipeline setup, writing addons). What else should Ember make easier?
Kevin: I’d love to see more innovation in the CSS space. Ember does a wonderful job of letting application developers write cutting-edge JavaScript that gets compiled into compatible browser JS. I’d really like to see more of that innovation take place in the area of CSS styling. I’m really excited by the new CSS Blocks project that LinkedIn just open sourced this week for example, and I’d love to see the Ember community help drive forward the adoption of some projects like this that make writing maintainable CSS as easy as writing maintainable JavaScript.
When you introduce a developer unfamiliar with Ember to the project, what story do you tell them? What story would you like to tell?
Matthew: I talk to new developers about how quickly they can start to focus on their business domain. I also push them to start testing, which can be intimidating.
In the past I would tout the Ember Inspector to them as well. Unfortunately the inspector’s compatibility with Ember breaks with most bumps of glimmer-vm, making it hard to rely on. I’d like to be able to show how Ember can make your application easier to debug. Developers learning a new tool, like Ember, benefit from visual and spatial representations of their code as they learn.
Kevin: I often tout the mindset going into a new project that you’re building a standalone app for the browser, so think about it like you’re building a native mobile app for iOS or Android. This mindset really rewires your brain to think about the client and server as two separate but complimentary projects.
I’d really love the new wave of browser features (service workers, local storage, etc.) to become more of the central approach to building these standalone browser apps. I think we’re still a bit too stuck in the mindset that building a single-page app with Ember is just “another way to build your front end” because we haven’t yet realized the potential that exists to build “native apps for the browser”.
What is something Ember does well, but which most people outside the community don’t know?
Kevin: I think that ember-cli-deploy is vastly underrated and largely unknown outside of the Ember community. For many common deployment strategies, ember-cli-deploy plugins already exist to build and upload an Ember application and its assets to a variety of hosting options. I’ve worked with multiple clients who simply assumed we’d need to spend days on configuring deployment, but thanks to this sub-ecosystem we’ve had their deployment set up and fully automated in just hours.
Jonathan: The testing story in Ember is something that is very understated. Ember has created a testing harness that would be the envy of any other language/framework. After consulting for many years now I can say that there are few things as important as having a rock solid test suite. It gives your engineers peace of mind that when they leave on Friday they won’t get paged at Midnight. It let’s manager’s know that when the team rolls out this next critical feature last month’s work doesn’t go up into flames. If you want to make changes to your system, it isn’t refactoring without tests, it is just moving code around. Ember makes this whole aspect of a flourishing team/project easy and fun.
Ember CLI provides generators to create tests for a rich set of abstraction levels. Want to test something in an isolated unit test? It has you covered. Want to test user interaction? It has you covered. To that end, Ember will allow you to easily wait for asynchronous behavior to finish or, with the help of a few community driven add-ons, test interleaved behavior like loading states with ease.
If instead you would prefer a more end-to-end style test you can do so entirely in ember and stub / fake / mock your backend with Ember CLI Mirage, another community driven add-on.
Matthew: The quality of Ember application tests is nearly unmatched. The testing patterns in Ember are a great example of how conventions and using a full framework can benefit the developer. If Ember were not a framework but a collection of libraries, building a test suite that worked against real DOM and whole applications would be a unique engineering adventure for each project. New developers (and JavaScript has a lot of new developers) are always intimidated by testing. Ember can do more to share a story around testing, and to evangelize testing practices.
What initiatives in the Ember project are you excited about seeing to completion?
Jonathan: That’s a tough question for sure, Ember has a lot of cutting edge technologies ready to be pulled in from the Glimmer library (a forward-looking experimental project for Ember features). I’d say I’m most excited to see FastBoot support rehydration in Ember applications. FastBoot is the out of the box server-side rendering solution for Ember. Rehydration is a rendering feature that allows some of the work done during a server-side render to be shared on the client-side (in the browser) and allows Ember to re-use most of the initial render DOM.
I’d also love to see strides toward utilizing more advanced JS features like decorators, and classes. Ember was an early adopter of ES2015 module syntax and we are still seeing benefits from that decision, so any adoption of future ES features is very exciting to me as well.
Matthew: Ember’s runloop was a necessary evil when it was authored. Today, with microtasks in the browser and native promises becoming more common, the runloop is no longer viable as implemented. Work maybe inefficiently scheduled and the timing of scheduled executions is confusing. Ember’s runloop needs to complete the transition to an “auto-run by default” strategy that leverages the microtask queue.
What are the biggest challenges to Ember’s longevity?
Kevin: I believe it’s vitally important that large companies that benefit so greatly from Ember also contribute back to the project and ecosystem. This is a challenge as so many of them have long-standing cultures of keeping anything they are working on a secret. While this approach makes sense for major product launches or the business logic that makes the company’s core product unique, a large open source project like Ember only survives as long as those who depend on it most continue to invest into its longevity.
Cory: Adoption is a big challenge. It’s important that new developers pick up Ember. Their ideas and use cases help to continue to push Ember forward. How do we improve adoption? To me, this is a marketing question more than anything else. On the technical side, Ember has a lot going for, but its perception in the larger JavaScript ecosystem is colored by “drive-by developers” who used it once (typically a long time ago) and not again since then. To its credit, an Ember still looks, superficially, a lot like it did several years ago. Ember’s stability without stagnation principle makes it look, from the outside, as though Ember has not changed a lot. In reality, even though many of the same primitives and APIs from years ago are still around today, the internals, the related build tooling, and the addon ecosystem, are all wildly different (and better!) than they were in the past. But a developer who used Ember several years ago, didn’t like it, and peeks in again from time to time will have the impression that there’s nothing new worth exploring in today’s Ember.
What parts of the framework do you explain to developers because the documentation is missing or otherwise fails them?
Kevin: I’d really love to see more documentation around writing addons. I have worked with a number of developers who would love to share a solution to a problem that they are sure others are struggling with, but the learning curve for implementing their addons is intimidating. A good example of this would be most addons that attempt to modify Ember’s build system. The CLI API docs outline a number of hooks that are available to addon authors, but doesn’t really make clear when and how each hook should be used in a given use case. I think we’ve missed out on a lot of really great shared solutions from Ember devs who haven’t yet cleared this hurdle.
Cory: Data loading is always a struggle. Figuring out how and when to load the necessary data for a route isn’t always straightforward. Although the route hooks provide a good on-ramp to effective use of the data layer, as an app grows in complexity those same hooks may be less effective. Understanding how to use relationships, as well as when to denormalize the data and avoid relationships, is more of an art than a science. I see many developers who don’t have a good grasp on the tradeoffs of different API+Ember Data modeling decisions, and don’t feel confident that they’ve built something the right way.
Onward!
What is your own team looking for Ember to deliver on this year? What are the challenges and opportunities you see? How do you plan to participate in the conversation and process around Ember?
Our team has, for the most part, focused our contributions in the last year on helping Ember deliver on long-made promises. Examples are my own work with Isaac on Ember’s new filesystem layout and Jonathan’s push to get rehydration released as public API. These contributions are our most powerful voice, they are a practical demonstration of where we think the project’s priorities should lie.
Whatever your own goals and ambitions are for Ember, I encourage you to join us in participation with the Ember project. Open source will give you the most benefit when you give back.
At 201 Created we’ve helped dozens of clients (including YC startups and Fortune 50 companies) make the most of open source solutions like Ember. Contact us to learn more about our work and how we can surprise your users with what the web can do.