I’m not going to claim that I’m the best Ember developer in the world but since you may not know who I am, I figured I’d at least give some reasons why my opinion isn’t completely without merit. I worked at a startup that wrote Ember and Elixir for a couple of years. During that time, we contracted with DockYard, who was pretty well known for Ember (in the world and especially so in Boston). When that startup didn’t last (because that’s what happens at startups, unfortunately…), I went to DockYard. My time at there was mostly spent in Ember (with some Rails sprinkled in for good measure), where I spent most of my time (about 2 years) contracted to work for the biggest content provider in the world.
During my career with Ember, I’ve contributed to the framework itself, written multiple blog posts and helped author and maintain many open source projects. I also have a YouTube Channel where I’ve done a lot of Ember tutorials with about 65,000 views. My Ember Data tutorial has over 16,000 views at the moment (which I recorded long before I considered myself “senior” by any means).
I’m not trying to brag (…ok, maybe a little) but I just wanted to say that I have been a part of the Ember.js Community for quite a while and as more than just a passive user. So, hopefully my opinion isn’t discredited immediately.
This isn’t meant to serve as a “this is why Ember is great” or “this is why Ember is bad” post (although I certainly have opinions on both). It’s just meant to be a reflection on the framework, community, the greater web community and hopes for where Ember will go in the future.
I feel like I see a ton of tweets and posts from really smart people in the community answering the question “is Ember dead?” with a resounding “heck no!” But honestly, I don’t actually see a lot of people asking that question (except for the occasional troll). Nobody thinks Ember is going to disappear — there are a lot of companies that are invested in it, a community that is passionate about maintaining it and enough smart people behind it to help drive it into the future. We need to stop being overly defensive about this.
Yes, less people use it — that’s just the truth. Every year, during the “State of the Web” survey or the NPM survey, Ember will come in behind React, Vue and Angular. But that’s always been the state of Ember and it will probably be the state of it indefinitely. We, as a community, don’t love Ember because we think it will be the framework to rule them all.
Ember has a reputation for having a steep learning curve and I think that was definitely true when I learned Ember 4(ish) years ago. There wasn’t a lot of documentation and the documentation we did have at the time was a bit contrived.
That being said, it is still harder to learn Ember than React and Vue because they are different things. I think everyone in the Ember community gets that and can make that argument, but I don’t think they quite realize the impact on adoption. Yes, “batteries included” solves so many problems out of the box that larger applications run into. The problem is that newer and more junior developers don’t understand those problems yet. They aren’t worried about state management, routing, built-in testing, etc. So they learn React because it is easy to get started and when they hit those problems, they find other people have solutions already.
Need a routing solution? There’s React Router. Need state management? Redux, Apollo, Mobx and more!
These are problems that devs run into one at a time and they find these solutions one at a time. When they finally get to the point where “batteries included” clicks, they already have their own framework and mental model they are comfortable with. I’ve talked with other devs, explaining the virtue of all the things Ember gives us and the response is typically “Oh wow, I wish I had all that when I was starting this project.” It’s a great sentiment but doesn’t change the fact that their project is already invested in React or Vue.
Obviously, I really like Ember and I would have liked a job where I could keep writing it. Unfortunately, it just isn’t that easy because most companies just aren’t using it. React has almost become a default in the web-dev community and regardless of whether you like it, the truth is that you are more employable if you know it.
So, I started volunteering some time at a pre-funding startup with a mission I believed in to get some experience in React (since I wasn’t going to get it at work). That’s when I learned how much easier it is to get started with a library that just cares about the view layer.
I formed a lot of good habits because of Ember in terms of structuring an application, writing tests, handling how data moves through my components and more.
But I also formed some bad habits without realizing it.
Foo extends Component,
super(), years of
I get that Ember helped pave the way for these things because weren’t available yet.
I also get that “stability without stagnation” means that sweeping changes can’t be implemented as the goal is to not break every app out there with each release.
But it still boils down to me not knowing something that the rest of the Web Dev world has figured out.
broccoli.js for example.
I learned a lot of about trees in broccoli, build pipelines and more!
But everyone else in the world was using webpack and I knew absolutely nothing about it.
My skills didn’t feel transferable.
The next thing I noticed when I started working outside of Ember is that I was getting some stuff for free without realizing it.
Native extensions are cool and I love using things like
firstObject on arrays.
I get that you can opt out of these things but as a junior dev, you don’t even realize they exist yet, let alone have an understanding of how to opt out of them.
If someone was starting out and they asked me what JS library they should start learning, I would 100% tell them to learn React even though I prefer and love Ember. There are simply more people and companies writing React out there. Learn what will get you a job.
I know it’s sounded like a lot of gripes so far in this post and I don’t want to be overly negative. Again, I can’t stress enough how much I enjoy working with Ember. But the point I’m trying to drive home is that it took a few years and a lot of intimate knowledge to appreciate all the amazing things Ember does for me. That’s why my biggest wish for Ember is that it becomes even more accessible to junior developers.
People in the Ember community aren’t unaware of this issue and a lot of steps have been made in this direction. However, I want to list out a few thoughts I have.
The web dev community is used to starting projects with just the view layer, then adding things in later when they feel they need it. Yes, we like that the batteries are included, but only because we have this mental model in place already and know what we’re looking for.
A new app is too bloated and Ember Data is huge. I’m not trying to discredit the library at all, but it has become too synonymous with Ember itself and the lines between Ember Data and Ember proper need to be clearly defined.
Let people hit a wall first and then go to Ember Data as the solution.
This feels like a weird suggestion, but until I started working with other libraries, I didn’t understand just how much the resolver did for me. And I think that made me a worse developer in some ways. In my React app, I have to import my components all over the place — the app isn’t aware of them just because I put them in the components folder!
And although it feels more verbose, it also feels so much more obvious to newer developers — sometimes “it just works” can make things more confusing.
A few others have said this in other posts, but I want to reiterate: get rid of controllers and just use components for controlling whats available to a template and services for singleton behavior. I hate explaining controllers to developers coming other JS libraries.
Just like opting out of native extensions, there are other parts of the framework where it feels like you have to possess an intimate knowledge in order to work around it. Breaking Ember conventions shouldn’t feel so hard (but to be fair, it’s easier now than it was 2 years ago).
This is kind of a joke… but also… it’s not.
This is the biggest one but also the most vague — make Ember familiar to people from other frameworks. I’m not saying that Ember should be identical to something like Vue or React, but it shouldn’t feel quite so foreign at first glance. Ember Octane is a great step toward this goal and I’m so excited to try it out soon on a real project. As a community, we may have to do away with “stability without stagnation” if we want the user base to grow — it’s an awesome goal but sometimes it feels like we’re getting left behind.
Until then, I’ll still find Ember projects when I can and contribute to the community when I have time.