Why DockYard Builds with Ember.js
DockYard builds modern web applications for all platforms. This article is intended to provide an explanation as to why DockYard uses Ember.js as our frontend framework to do this.
Modern Web Apps
Ember.js’s Origin Begins with Apple
As early as 2008, Apple was trying to solve the problem of building a robust, JS framework with a project known as SproutCore. A workshop at their Worldwide Developer Conference (WWDC) that year read:
To unpack that a bit: Cocoa is the API for the Macintosh operating system (now called “macOS”); Cocoa applications are now built using Apple’s Swift programming language.
Essentially, before Apple was raking in $28B per year via the App Store, they were trying to build Progressive Web Apps. Steve Jobs’s original vision for the iPhone supports this with:
The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps. And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today. Jobs’s original vision for the iPhone: No third-party native apps
Fast-forwarding a bit – SproutCore 2.0 became Ember.js under the guidance of former Apple developer Tom Dale and Ruby on Rails core team member Yehuda Katz. The project combined Apple’s best practice application architecture with the developer-friendly ergonomics of Ruby on Rails.
DockYard Adopts Ember.js
DockYard got on the Ember.js train early, before it reached
v1.0.0. We knew that it was the right tool for the jobs we wanted to be working on (ambitious web apps), so we never hedged our bets on Ember.js by picking up competing frameworks. We’ve organized the Boston Ember.js Group since 2013 and hosted Wicked Good Ember in 2014, 2015, and 2016.
This specialist vs. generalist approach to frontend development has left a lot of React.js, Angular 1, and Angular 2 work on the table over the years, but it has also meant:
- We’ve been building the applications we want to build for the clients we want to work with.
- We’ve been able to develop our Ember.js expertise beyond that of other, generalist consultancies.
- It has attracted the best talent to DockYard.
In short, we’ve interpreted “the right tool for the right job” to mean: find the right job.
Thankfully, Ember.js is the right tool for a lot of projects.
The Right Clients for Ember.js
The clients we work with generally have three driving concerns:
- Is the technology choice going to be an asset or a liability to our feature roadmap?
- Can I hire for the technology?
- How difficult will it be to maintain and extend the application after it’s delivered?
1. Ember.js Enables Product Roadmaps
Ember.js’s all-in-one architecture enables teams to focus on app-specific code and defer configuration details to the framework. This is better known as “convention over configuration.”
Focus on App-specific Code
Because it was inspired by Apple’s approach to native application development, Ember.js takes a holistic approach to solving the challenges that come along with modern web app development. It is comprised of libraries and APIs that standardize how developers write, test, and deploy an Ember.js application; it provides a first-class command line tool in ember-cli (which others have “borrowed”) and takes care of the build tooling, compression, asset fingerprinting, minification, and a host of other trivialities.
Again, Ember.js adopts the “convention over configuration” approach that Ruby on Rails pioneered. This means that developers spend less time thinking about configuration decisions, and more time thinking about the product roadmap. It also means that teams adopting Ember.js are inline with best practice web app architecture right out of the gate. The same can’t be said for frameworks that rely on Bring Your Own layering.
Customize as Needed
Ember.js has also worked hard to ensure that the architecture is modular. So if there are a few defaults that present challenges to specific teams, they can swap out the 10% of libraries that don’t suit them and benefit from the 90% of the framework that has been carefully curated for them. For teams that look at Ember.js’s architecture and think – we’ll probably need to rip out 50% of the defaults – Ember.js is probably the wrong framework for them.
2. Ember.js Hiring: Great Developers at Critical Mass
“There are more [insert hot, new JS library here] developers in the world than there are Ember.js developers.”
Going up against a Google-backed framework (Angular 2) and a Facebook-backed project (React.js) has not helped Ember.js win adoption. “Nobody ever got fired for buying IBM” logic applies here, and in part, it explains why Ember.js has faced an uphill battle in the JS framework marketing war.
But fixating on this fact is the wrong approach for building a great development team. The better question is: how many more good [hot, new JS].js developers are there than good Ember.js developers?
Leverage the Learning Curve
Compare this to Ember.js’s homepage, which reads: “A framework for creating ambitious web applications.”
Ember.js provides a solution that goes beyond the narrow concerns of other libraries, and this naturally comes with more to learn. But part of what makes Ember.js difficult to adopt is what makes its developers so great: it’s more imposing to junior-level developers and provides some natural selection in the hiring process.
For hiring purposes, it can be useful to ask:
- Does the technology have critical mass?
- Does the technology make it more or less likely we build a great team?
There is already a critical mass of Ember.js developers, and the framework is growing each year alongside the Ember Learning team. For hiring managers who need to quickly deliver great web apps, it makes sense to adopt a framework that focuses less on short-term adoption and more on long-term potential.
Companies Using Ember.js
If you’re nervous about finding and hiring Ember.js developers, consider the companies who have made the investment in Ember.js: Amazon, Apple, Condé Nast, Heroku (Salesforce), Kickstarter, LinkedIn, MassMutual, McGraw-Hill Education, Microsoft, Netflix, Sony, Square, TED, Yahoo, and many more.
3. Ember.js for the Long-Term
We chose Ember.js because it would be easier for our clients to maintain, extend, and upgrade.
Onboarding New Developers
Ember.js’s embrace of “convention over configuration” and its pursuit of an all-in-one solution pays dividends when it comes to onboarding new developers.
Ember.js has tried-and-true best practices, which create a shared knowledge base for the development team. There are fewer conversations around “what’s going on in this part of the codebase” because there is an “Ember Way” to implement much of the code. Compare that to a custom-crafted, frontend tech stack which may require Senior-level developer talent to understand, maintain, and extend responsibly.
Invested in Web Standards
Ease of Upgrading
Keeping a production application on the latest, most secure version is never easy. But it’s easier with Ember.js.
Ember.js’s all-in-one architecture means that the core libraries, while modular, are designed to fit together. The core libraries align their roadmaps and follow Semantic Versioning on a 6-week release cycle or about twice a year on the Long-Term Support (LTS) release channel. The release team also does a great job of flagging deprecated features and wrapping new ones in feature flags, to ensure that developers can test out new APIs and sunset old ones.
Embracing Great Ideas
Ember.js is also unapologetic when it comes to borrowing great ideas. When another framework does something better, Ember.js is open to adopting it. And while this requires swallowing one’s pride, the impulse to borrow from other frameworks is great for the longevity of Ember.js. For example, much of Ember.js’s advancements in the rendering and view layers are inspired by React.js’s approach to delivering fast and lightweight UI components.
Borrowing great ideas (with due attribution) will allow Ember.js to evolve with a technology space that is always fickle and ever-changing. For the last 6 years, the Ember.js community has done a great job of responsibly incorporating new ideas into the framework; their ability to continue to do so makes Ember.js a great long-term bet moving forward.