My first six months with Ember.js
After reading this Ember.js six months in article, I realized it was time to publish my own 6-months-in report. I started with Ally Financial as a Senior Front-end Engineer in November 2017, so as of this writing it’s been about 6 months. Since March, though, I’ve been a tech lead for a scrum product team, so I haven’t been quite as hands-on in day-to-day development. I still do a good bit of new feature work, bug fixing, code review, and so on, though, so I haven’t left development behind completely.
Before I go on, I must emphasize the following: the work of all the Ember.js core team and the community of developers is amazing and I am in no way trying to disparage the work of those involved or belittle their effort. When it comes to technology, as with everything, there are trade-offs; they’ve chosen certain design decisions that, say, the React team has not. I fully respect these decisions, even if I don’t always agree with them.
Convention over configuration
The build tool that Ember uses under the hood, Broccoli, has a pretty straightforward concept—it works with trees, as opposed to files. This seems very simple, but can lead to very strange issues when it comes to merging trees. Naming collisions cause very-hard-to-debug errors. For example, we realized one of our app files had the same name as a 3rd party dependency, so it was overriding the dependency. No compile or runtime errors.
One category of conventions that is still somewhat confusing to me is add-ons vs. apps. The whole index.js vs. ember-cli-build.js file seems like an arbitrary distinction—each type of project has each of the files, but apps use one file (ember-cli-build.js) and add-ons use the other. Huh?
Also, add-ons require re-exporting files for use in the consuming app. That really threw me off in my work starting out with apps that had add-ons because the duplication seemed so unnatural. This isn’t such a problem if you let ember-cli handle all the file manipulation for you, but that in and of itself takes somet time to master; to remind yourself “oh yeah, I can’t delete anything on my own or else things get out of sync” or “I shouldn’t create this file by hand because then it won’t have a re-exported file created for it, unless I remember to do it manually”.
Ember still relies on jQuery under the hood for DOM manipulation, but that is going away soon. The problem with it at the moment is developers tend to rely too heavily on it, because it’s there. At least in a fresh React app, it’s not available, so you have to do things more “the React way”. I think having jQuery around allows you to break out of Ember’s component model too easily, so I’m glad it’s going away in the future.
Always pros and cons
There are always pros and cons to every piece of technology and you ultimately have to pick the right tool for the job without being overly dogmatic about your decision. I think Ember is a great addition to the tools available to web developers these days. It’s worth knowing about these pros and cons before diving into a new framework, so hopefully this helped give some insight into what a newbie Ember developer coming from a React world might expect.