Disclaimer: this article will be an inevitably subjective account of what I think Ember’s biggest problems are, why I think so, and how to fix them. There will be a lot of criticism, but it will come from a place of care. Please don’t take it personally. It will be way too long, so if you don’t want to read it all, there will be a TL;DR at the end. It will also be rather pessimistic at times, if you are a subscriber to relentless positivity, perhaps see e.g. this TED talk first.
Ember is still an immensely competent framework, and you can achieve anything you want in it. This article won’t be about what is great about Ember, there are lots of articles like that out there, but largely about things that are broken at this precise moment of time, and suggestions on how to fix them.
Ember, you’re awesome. But if you want to stay relevant, you really need to change some things.
Let’s start with where Ember is.
When I started with Ember 2.5 years ago, Angular1 was on a way out, Angular2 was in alpha, Vue was niche at best. I picked up Ember, because I liked its philosophy, I liked the abstractions, liked the syntax. It made me have fun programming again, and I was comfortable in my choice for a while. Ember was sitting at #2 (or #3, if you count Angular1) and had a bright future, or so I thought.
Fast forward to today though — ember-cli has 95K weekly downloads on npm, up from 75K a year ago. Sounds good? Hold your horses — @angular/cli now has 550K weekly downloads, up from 150K a year ago. Vue has 330K, up from 140K. React has 2.3M, up from 1M. Even Preact is now at 50K, up from 12K a year ago. It’s pretty clear that Ember has lost the momentum compared to the rest of the pack, big time.
So how did it happen?
If I had to pick two reasons, it would be bandwagons, and not listening to the userbase.
If you take a look at what the competition looks like in most sectors of the economy, it will look quite similar to what happened in front-end framework space — dominated by few major players, with a bunch of smaller competitors scrambling. Facebook and Google, being de facto gateways to the internet for the majority of the world’s population, have the brand recognition Ember is never going to be able to compete with. And as every CEO of a company that’s third or fourth in the market would tell you, that means you only have two things to compete on — price and quality.
And, with all frameworks being free, the only thing left to compete on is quality. After a long period of ignoring the userbase (every problem I’ll mention has been around for years), Ember just doesn’t seem to be convincing enough there either.
So what does quality in technology mean? In my opinion, it boils down to a single question:
Is Ember the BEST tool for the job?
The answer to that question will be dependent on your situation. Imho, the reasons to (not to) choose Ember look something like this:
Lot of the assumptions about Ember’s superior value hinge on the fact, that you have to create a custom framework out of React or Vue — that is no longer true, it’s entirely possible to take some open-sourced project or $30 admin panel with all the bike-shedding done, or go with batteries-included frameworks/libraries like Angular/next/nuxt. It probably won’t be as pretty, sure, but it’s largely a one-off cost, and having access to React’s 55000, Angular’s 8-22000 (hard to get a precise number) or Vue’s 12000 addons instead of Ember’s 5500 can very likely justify spending some time wiring it all up quickly.
Bite-sized libraries may be a better fit for a lot of the applications too — Ember’s learning curve is very steep. For a single developer, it can only hardly be justified if they live in an area with no/few Ember jobs or can’t/don’t want to work remotely. Even for small companies, there will be a lot of bugs and hard problems (performance, tooling) that they might not have the skills and resources to deal with for a long time.
A lot of managers, especially in mid-size and large companies, will have the risk-averse, “nobody ever got fired for buying IBM” mentality, which means for Ember to succeed it has to be consistently better and provide far more value than the rest.
It’s a tough spot to be in, but there is pretty much only one way forward — in order for Ember to start turning those boxes green and become the best tool for the job for everyone, it has to focus on alleviating the concerns for adopters of every size — hard problems, learning curve, productivity, quality and their subsequent cost.
Fix hard problems
The thing is, if the only issue with Ember’s adoption was the learning curve, the difference with other frameworks wouldn’t be that big. However, there are a lot of complicated problems even beginners have to deal with in Ember, and it sucks up a lot of time and enthusiasm to a point most people that tried Ember just gave up.
Performance
First of all, Ember needs to go on a diet.
Best Ember HackerNews PWA is 140K, naive version is 230K. React is 50K, Vue 45K, Preact is 15K, Angular5 is 95K, but with its Ivy renderer able to go as low as 2.7K for a Hello world app around the corner, that will change soon.
We were all shown the comparison between Glimmer and Preact recently, and it looked good on paper. Here’s the rub though — Ember is not Glimmer. While you might be able to compile away the 27K difference between Preact and Glimmer if your templates are large enough, you just won’t be able to compile away another 110-220K, especially since even if your templates were bigger in other frameworks, route-based code splitting works there today and you don’t have to send all templates at once. Best Ember version of HackerNews PWA was twice as slow to load as best React (4.7s/4.2s vs 2.5s/2.1s), and that’s a very minimal application. Even worse, out of the box, Ember HNPWA took well over 10 seconds, and getting it to boot at ok speed takes skill and time most beginners don’t have (and perhaps even shouldn’t have to have). Given that 52% of all website visits are now from mobile (65% in Asia and Africa), and cheap Android phones are a vast majority of it, Ember just might not work for large parts of your audience at all.
Ember’s render performance got better after 2.10, but Ember 3.0 is still on average 2x slower in most scenarios, except for update, where dbmon can perform slightly better than React 15 (React 16 might be faster again though). Big problem is create performance — the first time I needed to create over a thousand of elements on click of a button, only to have browser completely lock up for a full second, I thought my PC crashed. You can brush it off as “that’s just benchmarks”, but sooner or later, you will run into a situation where it will cause you a lot of grief. And it’s not getting better lately either — while comparing latest 3.2 beta with 2.13 at http://emberperf.eviltrout.com/, most results are somehow getting worse. If you need your app to perform on cheap Android phones, the fact that you cannot rely on your framework to be able to support your every use case without some serious efforts on your part is a major downside.
At the very least, documentation should try to mention every trick in the book to make the performance less of a concern until better solutions are available, to drive the effort and guesswork required down as much as possible.
Increase productivity
Code assistance
Even with Typescript, code assistance in Ember is very weak. Thanks to EmberObject.extend(), IDEs have trouble even recognizing the types of objects, let alone their shape. 10 years ago, I was coding in Visual Studio with CodeRush, a plugin that lets you write and navigate your code as fast as you can think of it, and refactor anything you want across your whole code base instantly, with full fidelity. Going to language and framework that only recently learned how to suggest field names onthis(some of the time), feels very unproductive.
So how can it be fixed?
First of all, EmberObject has to go. It was nice while it lasted, but it’s time, there is no way around it. Ember-data has to be able to function with plain ES6 classes as well.
However, there absolutely needs to be an officially sanctioned and documented path to migrate mixins off .extend() — even if you don’t like them, a lot of the essential addons in a typical application use them to provide their basic functionality.
Almost none of the addons have Typescript typings yet, so there should be a mechanism to nudge addon authors into writing them — either with a score on Ember Observer (raising maximum points to 11, subtracting a point from all existing addon scores, or assigning just half a point to two of the less important characteristics and a full point for typings), or some sort of lint rule.
While mentioning Ember Observer, why not make it a part of official Ember website as well? Making everything in Ember’s addon ecosystem instantly discoverable the moment a new user lands on the website could be a nice selling point.
Rebuild + Reload
I’m going to be blunt here — ember-cli’s rebuild times are horrible. On Windows, rebuild of few changed bytes on a larger, e.g. dashboard style project takes 6–10 seconds, plus 5–10 seconds of reload. Even if you use Linux or Mac (rebuild in half the time) and optimize the heck out of it, you’ll get to 8-10 seconds save -> ready cycle at best.
It’s just a few seconds though, who cares, right? Let’s piano-tuners-in-Chicago the problem.
Rebuild+reload is by far the most used ember-cli’s function, by order of several magnitudes. If you are an application developer, in an 8 hour work-day, running it just once in 8 minutes (a very conservative estimate) means reloading 60 times a day, with 600 seconds, 10 minutes wasted each day. In a 220-day work year, those 10 minutes a day add up to 36 hours — just because of rebuilds and reloads, one week of your productivity each year is wasted waiting around for cli to finish. Two weeks, if you are on Windows or don’t know how to optimize your bundle (or your app just grew big enough that you can’t). And even more than that, if you edit templates, unless you can Rain Man hbs+js+css in your head, you’ll need to save & reload at least once a minute. And you can easily double or triple all that because of the constant and inevitable loss of focus, context switches and distractions that you will need to resort to if you want to keep some semblance of sanity.
That means in every large Ember organization, there is probably a whole department whose only job is to twiddle their thumbs while staring at a blank screen.
Worst of all, it’s a 100% self-inflicted and fixable wound. The fixes even started to be implemented, but were left unfinished for almost a year now here and here (at least 2/3rds of the time are wasted rebuilding addons and by using a slow source-maps library).
How is there zero urgency in fixing this is beyond me.
Another half of the rebuild + reload cycle is spent on reload. One way to minimize it is hot reloading, common in every framework except Ember. ember-cli-hot-loader is a barely known addon that was broken for almost 9 months last year, and no one with a knowledge of changes in Ember/Glimmer internals that broke it cared enough to fix it, even though it took 3 lines of code.
Now, I get the argument that hot reloading might be unreliable in some situations, but that’s not a reason to dismiss its major productivity benefits, especially while editing templates — this should be included by default, even if turned off with a large “Here be dragons” sign next to the switch turning it on. Document the cases where it will break, or better yet, if they can be detected at run-time, log and force a full reload automatically. Even if it works reliably only in 95% of cases, it saves a huge amount of developer time, and no other approach will get you anywhere close.
Having instant rebuild+reload (and couple of other things) could also enable Ember to have one killer feature — a WYSIWYG editor, perhaps in form of a plugin to Pinegrow, a very capable editor producing the same html you would write with just drag&drop, or some open-source editor based e.g. on GrapeJS/Gramateria. Being able to edit templates without/with just some light coding would also open Ember to completely new audiences, and the productivity gains (no more Photoshop or Sketch, \o/) could be incredible.
Ensure quality
Bugs happen, it’s inevitable. Coming from a back-end and corporate background however, I have never dealt with a framework with quite as many bugs as in Ember. I tend to stumble upon a server-side bug maybe once or twice a year, in Ember’s ecosystem, there are some pretty much every other week. Before, the solution was usually just to update to a new version, or do a quick PR in an hour or two. Now the solution is usually to report an issue and watch nothing happen for 3+ months, or drop everything and take days/weeks off deep-diving into some code that’s usually way outside my domain knowledge or way above the skill level. And the smaller your company is, the bigger problem this is going to be. I get frequently sidetracked by serious bugs that were reported months ago (the record being 1.5 years, with another problem with a solution abandoned in a PR for full 4 years). This is not a sign of healthy ecosystem.
Now, front-end is complex, and compared to server-side, evolving at breakneck pace, so bugs are kind of expected. What isn’t expected though, is what happens afterwards. Which leads me to Ember’s fundamental source of all problems:
Ember just isn’t managed well
In any project with limited resources, you can do basically two things if you want to move it forward — get more resources, or focus your efforts. If you keep doing the same thing, you aren’t going to get more resources — community won’t be growing fast enough, if at all, and assuming you want to have a life too, you’re not going to work harder either. So you need to focus more.
Features
Ember doesn’t seem to have any feature priorities, everybody just kind of scratches their own itch, without much concentrated focus on delivering anything. “It will be ready when it’s ready” or “PRs welcome” being the standard answer to most questions about concrete plans. A lot of things get poked around for a bit, then the first complication appears, and a feature is abandoned for the next shiny thing on the horizon, over and over again, while problems keep piling up. Out of 18 releases in 2.x cycle, 12 releases were bugfixes only, 4 releases had minor features and as far as I can tell there were just 5 major features (engines, glimmer, fastboot, testing, typescript), in 30 months, 2.5 years between Aug 13 2015 and Feb 14 2018. A lot of code was written, but the real question should be — did it really have the most impact it could have? And judging by how quickly Vue and Angular2+ overtook Ember, both in features and community size, probably not.
If you want to build a thriving ecosystem, you need to constantly organize your backlog by the impact on productivity, yours and your community’s. Every planning meeting should start with the same question — what is the feature or two with the most impact on the community that we can absolutely deliver for the next release? Ember would get better in no time.
Basic software development lessons apply — developers should always team up, even if not everyone works on the problem, you’ll always have someone with enough insight to help you move forward if you hit the brick wall. Don’t let the important things hinge on you not feeling like doing it this week/month/year, talk about what you are working on constantly, and ask your pair for help if you feel unmotivated. Always focus on one or two features at most, multitasking is a myth, there is no way you can track more than 7 things at once without the overhead and stress of it paralyzing you completely.
Bugs
When dealing with bugs, if you want to ensure quality while keeping your sanity, you need to be able to judge their impact as well. What could help is to classify bugs better, e.g. by having your GitHub issue templates for your every package include a table like this:
(There is no acceptable level of data loss, just fix it right away. Affects: < many would lead you to downplay issues as localized to a person reporting the problem, which is almost never the case). Prioritize bugs with a major loss in functionality or productivity, or the ones that affect everyone. Even more minor bugs can wreak large havoc if they affect everyone.
Have a bot convert it to labels automatically, color code them by severity. Suddenly, you’ll know immediately what you need to fix now and what can wait, and your users know they can rely on Ember for their worst issues.
Your stress goes down, as now you don’t have to care about 200 open issues that all look as if they could implode the world. The moment I properly classified my todo list, my stress levels went down by 2/3rds instantly. Turns out, not all bugs are of equal importance.
The reality is, that if Ember wants to be a successful framework, issues and PRs cannot stay ignored for months — every serious issue, every PR is a company or a developer that is failing with Ember and getting one step closer to leaving forever for the safety of the herd elsewhere. You cannot expect all your users to fix framework and tooling bugs either, not everybody has the skills or resources to do it, it takes years to get to that level. If you do, you reduce your potential userbase growth by at least 80% — majority of the users will still be completely new to JS frameworks, the major shift is happening only in last two or three years (JS framework downloads almost tripled just in the last year, doubled the year before that, for 6x in two years). If Ember wants to become/stay mainstream, it needs to be usable for people of every skill level, and that means getting serious about resolving reported issues.
Your development process needs the same thought and benchmarking you apply to your technology — measure the number of open issues and PRs, and improve on time to resolution constantly. Make the progress public, if you take it seriously, quality can become a major selling point, for individual and corporate adopters alike.
Less effort wasted on deep dives and hard problems also means the community can add more value in addons, and the ecosystem’s value improves faster.
Reduce the learning curve
Ember needs to be easier to grasp — either by refactoring, or better documentation. Idea of teaching Ember as Components-services framework simplifies the mental model nicely. Going all in on ES6 classes everywhere, without .set(), would help. Perhaps controllers should just get deprecated already — the whole routes vs. controllers situation is pointlessly confusing, and route is a better concept to keep. Attempting routable components again might be too much effort with little benefit.
Documentation should return the cookbook format, at the very least, it should have tutorials on performance and on how to connect Ember to every major server-side framework out there, Rails, Node/Express, .NET, Java Spring Boot/Play/Dropwizard, PHP Laravel/Symfony, Django/Flask, Wordpress/Drupal, GraphQL, Firebase etc. For a brand new user, being able to have a set of concrete steps to follow in order to get the data in and out of database in hours, instead of days/weeks, clears a major hurdle in adoption.
If you don’t want to write the articles, find existing tutorials and ask authors for a permission to republish them, or ask your community to write some. I’m sure they’ll say yes.
Make it easier to share
Compared to other ecosystems, Ember is now very (2–10x) lagging in number of addons, especially UI components. Perhaps there could be a cli command that would make extracting them to addons and sharing easier, with a standard way to share component styles, without having to code anything or deal with broccoli and manual imports— something based on CSS Blocks or e-component-css/e-css-modules, with a common theme format. It’s an ideal topic for RFC, there absolutely can be a shared solution to this problem.
Ember Observer could then perhaps automatically generate and feature component screenshots, something like that would go great with a WYSIWYG editor to provide a massive click-to-install library of components. Reducing friction in sharing these tiny single purpose components could really make their number balloon quickly, catching up with the rest of the JS pack fast.
Embrace the JS ecosystem
I think everybody can agree that imports from npm, code-splitting and tree-shaking should just work. Might be just an idea for an addon, but adding Preact as a component manager could enable Ember to access a lot of the 55000 React components on npm at a pretty low cost (5K). There should be a path to consuming and building WebComponents, or if there already is one, it needs to be documented.
Improve marketing
A lot of people in the community seem to think that Ember’s low adoption rates are a problem of marketing — but there is no amount of marketing that can make people adopt a technology en masse if better alternatives exist. Plus even if it may seem unfair, unless you rename Ember to “LinkedIn, Netflix, Apple, Microsoft and Sony present: Ember, the most awesome framework ever”, Facebook and Google will always have the brand recognition on lock, and there is nothing you can do about it.
Ember will have to convince some very smart people solely on its merits, by being better than the rest. Only after it does that, people will want to start to talk about it more enthusiastically and more often.
That doesn’t mean you can’t do anything to market it in the meantime though — the only reason Vue shot past Ember, despite being smaller and arguably worse in the beginning, was that it got adopted by Laravel, the most popular modern PHP framework, and featured in its docs. Learning/marketing team should actively seek out opportunities like that, providing examples and assistance to other developer communities (.NET, Spring Boot, Node Express/Sails, Laravel/Symfony, Wordpress/Drupal, Django etc.), as much as possible. Getting just some of them to adopt Ember in this way could instantly add thousands of new developers to the ecosystem.
Ember’s website needs a makeover, the analysis that floated the community was 100% on point. My $.02 — If you want to be taken seriously, act serious. De-emphasize Tomster, while it’s cute, it doesn’t scream “It’s ok to drop a few million on this technology” or “It’s ok to get a second mortgage to fund your startup with Ember at its core”, it just says: “Do they have a rodent problem?”, sorry. Get an abstract logo. Gitlab did it, and it served them well. Relegate Tomster to a being a fun mascot and an inside joke, not a first thing everyone sees. Putting off parts of your potential audience immediately after landing on the site is never a good way to go about growth — if you want to be treated as a mature technology by serious people that need to be able to trust Ember with life and death of their companies and well-being of their employees, don’t plaster everything with cartoon characters. The perception problems are just not worth it.
Communication and community
Communication is well, not stellar. Newsletters do a great job at communicating what already happened, but future plans are largely unknown to public. Dashboard has the same few features on it since it was started, no ETAs, no details, no links. People that need to be able to plan for the future are out of luck. Compared to Angular, with strict deadlines, feature lists and public issue progress checklists, Ember feels very amateurish.
Sadly, Ember’s community feels a lot like a typical OSS bubble — the people are super smart and nice, but there is a strong tendency to avoid talking about problems. The fact that the same two questions (how do I import from npm, why are my builds so slow) pop up several times a week on Slack for years now, is quite telling about how disconnected the core team from their userbase is.
I can’t count how many times I heard an attempt at “these are not the features you are looking for”. The criticism is quickly shut down, as if the mere fact that you didn’t hear it made all the problems go away. “Happy thoughts only” is a great approach if you want to build a cult, not so great in technology — if you discourage criticism, you prevent yourself from hearing half the valuable feedback while doing nothing to fix the underlying problems, and you’ll be worse off anyway. You can get away with it inside your bubble for a while, but that will never work on the people outside. And judging by Ember’s shrinking market share, it hasn’t.
The worst thing that can happen to a community isn’t criticism, but indifference.
Future
Honestly, without some major changes, I don’t have many reasons to be an optimist — core team doesn’t seem to be even aware that the fact that other frameworks grew by 3–4x in the last year while Ember stagnated, or that some competitors have 24x userbase already, is a problem. And it is, a big one, every technology needs growth and new users to remain viable.
Over the years, I’ve seen several developer ecosystems die off, even though they were at some point clearly superior to their competitors, and it was always for the same reasons— it always starts with the lack of investment on part of companies running them or some major years-long rewrite, neglecting day to day needs and productivity of their users, with bugs piling up and bad tooling ignored. Interest starts to plateau, big name competitors come by, year or two, and poof, it’s over. And every warning sign of precisely this trajectory is here — Ember is now at 3% of framework downloads, down from 6% a year ago.
In my opinion, this is the last year Ember has a chance to show it’s a viable option, one more year of “this is a bugfix release”, and the annual EmberConf “noone is using Ember” photo joke will turn into “everyone that’s using Ember” commentary on a brutal lifecycle of JavaScript frameworks. The time to get serious about the future is now.
And that means the biggest Ember adopters first — a lot of corporations I’ve seen tend to misalign short-term interests of their project managers (spreadsheets showing immediate costs level/down sure look good at quarterly meetings) with a long-term company interest (viability and TCO of their products) badly. I might be wrong, but judging how long have the same problems been popping up, it looks like something’s off - if you are a company with $4 billions a year in revenue, would it really hurt you to hire 5 more developers to work on a technology at a core of your business full-time, instead of waiting on individuals and small shops to do it? Just fixing the sub-optimal tooling would get you any investment back in months at this scale.
TL;DR — how to fix Ember for 2018 and beyond
Bend the curve of effort to value for adopters of every size:
- fix hard problems
- finish imports from npm, tree-shaking, code-splitting
- make cli rebuilds faster/instant, include and support hot reloading
- improve boot and render performance
- improve code assistance and productivity - get rid of EmberObject, nudge addon authors into writing typings, think of the ways to enable WYSIWYG
- make it easier to share single purpose components and their styles
- embrace the JS ecosystem — add Preact component manager, add/document a way to build/consume WebComponents - learning curve & documentation — refactor away controllers, settle on official path forward for mixins, switch to components-services mental model, add detailed performance section and cookbook recipes for server integrations
- project management — commit to a feature or two with the most impact on community for each release, team up and make 100% sure you deliver. Prioritize bugs better, fix serious ones quickly, and benchmark and improve on time to resolution constantly. Reduce multitasking to a minimum. Talk about your process more, review its outcomes often.
- marketing — pursue other server-side developer communities, improve website design, make Ember Observer a major part of the official website
- communication — better communicate the plans for the future, make progress tracking more discoverable/public.
- corporations and large Ember shops should step up where small shops can’t.
So there you have it, this is what I think Ember should and could be in 2018 — a more reliable, properly managed framework with all the modern features in — from functional code assistance, instant rebuilds, npm integration, to tree-shaking and code-splitting, with WYSIWYG possible, cleaner concepts, better documentation, with higher quality, serious issues classified and taken care of in a timely manner, and happy and growing community that can focus on adding value in addons.
I’ve learned a lot and had a lot of fun with Ember over time, and would like nothing more than it to become the best version of itself. But for that, core team will have to get serious — formulate a plan, and execute on it with laser focus. Ask your community for help, but be realistic about where they can help, and where you have to lead. Skating by on good decisions made years ago won’t save Ember forever. With 3% market share, it’s time to act.
For a 2019 sequel to this article, click here.
P.S.
I understand that after this much criticism, your first instinct might be to brush it aside, yell at me for being ungrateful, or to try to bargain by showing me how awesome Ember is — but that would be missing the point completely. I get how great it is. But without enough convincing reasons for larger world to start to get it as well, it won’t matter.
The goal of this article was absolutely to burst some bubbles, try to empathize about why I felt compelled to write it this way — not much of what I wrote here is news to anyone, these problems have been around and ignored for years. By doing so, Ember managed to paint itself into a corner that will be impossible to get out off without a significant change in thinking. It’s time to acknowledge that. I tried to provide as many recommendations on how to do it as I could.
The biggest one? Take a lesson from people that already did it, focus, set your objectives and key results, and measure and deliver what matters.
