My first 6 months using Ember: A retrospective
I started working for Google in September, on the Nest Store team. We code entirely in Ember, with a tiny layer of Express for some server-side performance benefits. My prior experience was about 3 years of jQuery, Angular 2+ (from the beta to version 4) and some vanilla JS. I jumped into Ember the same way I prefer to jump into any framework — I embarked on an overly ambitious project and tried to push through the various failures. This time, I chose to create a platform on which communication was done entirely in video. It’s not hosted publicly anywhere because, frankly, I wasn’t interested in fixing multi-platform WebRTC issues or in moderating it. Here’s the code: https://github.com/robert-j-webb/ember-video
I learned a lot from this simple project. Ember makes it easy to start a project and add extensions to it using the Ember cli. I was using firebase to store recorded video; it was about 2 lines of boilerplate and a single ‘ember install’ command to set up a seamless data storage backend. Additionally, deployment was done with an Ember command. However, there was no Ember add-on that was a wrapper around WebRTC and video recording, so I had to put a lot of time into it myself. I found the default folder structure for Ember projects to be downright miserable. In my opinion, the pod structure, where the JS, CSS and HBS live in the same folder, is the only excusable directory structure. I learned some of the syntax and usage of Ember, but I didn’t experience it in a production environment.
After I started working full-time at a job where I maintained a heavily trafficked website with Google-level standards, I started understanding the reasoning behind Ember’s philosophy and why people liked it so much.
The most impressive and beneficial part of Ember is the community of people who make it exist. Unlike Angular or React, Ember is mostly free of corporate influence, which means everyone is encouraged to contribute and help each other. Ember’s design and philosophy don’t come from a tech lead at some big corporation, but rather from the collective wisdom of the core team, which makes it very robust and battle-hardened. The community is also incredibly helpful and pleasant. The Ember slack channel will help you with problems you might be having with your code, or help you write a talk for a conference. They’re also very inviting to people who want to get involved.
My favorite part of Ember’s design is that almost everything is extensible in very powerful ways. A great example of this is the fastboot add-on, which allows server-side rendering simply through ‘ember install fastboot.’ Ember has hooks to allow for the modification of the build process as well as just about everything else. This gives community members the ability to add new features to Ember to use it in any way they want, including server side rendering.
If I were to summarize my understanding of Ember’s philosophy in a few words, I would call it “restrictive but for good reasons.” “Data down; Actions up” is one of these philosophies, and its intention is to ensure that data definitions and modifications to data happen in route files so as to prevent messy state management. However, this gets tedious with large applications. Often, I wrote services to encapsulate data because I didn’t want to deal with the hassle of passing data down through many layers. Similarly, these services had the actions in them, so I could encapsulate the modifications to the state in the same file. I found this to be much more convenient and cleaner than writing actions in each route where I wanted to modify the state, because it avoided repetitive coding and the need to keep track of each separate invocation of an action.
Learning Ember can be challenging and frustrating for newcomers. Handlebars is actually really annoying to learn, mostly due to poor developer ergonomics. There’s no ide integration that shows you errors without compilation. The most frustrating thing about this is that I would write broken handlebars, and my server would refresh, but nothing would change. Eventually, I would see the error in the terminal where I was serving Ember and fix it. Handlebars also requires helpers for any kind of logic or transformation in a component. This means that if you want to do a specific action that relies on a loop index, you must write a helper for it or use existing ones. Therefore, I had to write helpers for specific actions, like, for example, setting the first character of a string to lowercase. In Angular, I could simply write JS inside the template, avoiding the need to pollute global scope with these one-off helpers.
One of Ember’s core issues is a lack of quality documentation for so many parts of the framework. Although the build tools are amazing, and I’d love to do more with them, Broccoli documentation is almost nonexistent. All Ember questions online are usually hopelessly outdated and most of the basic questions don’t get asked. The Ember API docs are pretty solid, but I feel like the tutorials fail to cover the more advanced parts of it. The Ember docs do have tutorials that get you through the basics, but they lack a “cookbook” section, which is problematic. The biggest effect of this is that I am often ignorant of what the framework is capable of doing, which causes me to hack a solution rather than use the tooling that’s already there.
Another problem with Ember is that there is no code splitting or tree shaking. Angular and React both support these, and they feel like a must-have for modern web development. When I add a library, all of it is going to be downloaded and parsed whether I use one feature or all of them. I know that this is on the roadmap but it’s something that other frameworks have supported for quite some time.
Still, Ember is moving in the right direction. While it may be doing this slowly, I don’t mind that in a web framework. Ember is for creating ambitious web apps, which always makes me think of very complex apps that require years of development time. Ember absolutely does an amazing job when it comes time for an application to scale up its complexity and continue adding features. Overall, I’m impressed by the framework and community, and I’m looking forward to the future of Ember.
