Last week I argued that backward compatibility in Web applications might be roadkill thanks to innovation that increasingly moves at Internet speed. This week the EmberJS team pushed back, insisting that this kind of tradeoff—exemplified by its chief rival, move-fast-and-break-things JavaScript framework AngularJS—are neither prudent nor necessary.
See also: Why Web Tools Like AngularJS Need To Keep Breaking Themselves
Historically, successful vendors were forced to take on the burden of supporting customers for 10 years or longer. In the Internet age, however, any developer that puts customers on such long-term life-support plans may be doing them a disservice.
I talked with Yehuda Katz (@wycats) and Tom Dale (@tomdale), two members of the core team behind EmberJS, a popular JavaScript “framework” for developing Web application, to see if it’s possible to marry Internet-speed innovation with enterprise stability.
Slowing Down By Speeding Up
ReadWrite: You don’t buy into the premise that the Web must be broken to ensure forward progress?
Yehuda Katz: No. We believe it’s possible to achieve stability without stagnation.
In fact, this is a nut that browser vendors cracked years ago. The Web as a platform has advanced significantly in the last 10 years, but it still has very serious compatibility requirements, many of which are non-negotiable.
See also: Why Even Simple Technology Can Be Hard For Developers
At first, the browser vendors accepted this false dichotomy, releasing new versions of their browsers ploddingly. In the bad old days of the early 2000s, the platform stagnated. People fled to Flash and wondered if the experiment of the Web was over.
With Chrome, Google realized that this pace of progress wouldn’t do. They adopted a rapid-release strategy carefully tuned to balance the stability requirements of the Web with a desire for rapid progress. Firefox soon followed.
The effects have been profound: the pace of progress on the Web has sped up.
But the solution is not to abandon stability! It’s to adopt the same strategy that the browsers have used to speed things up. And that’s what Ember did when we announced the post-1.0 release cycle, and what we plan to continue doing moving forward.
Keeping thing moving incrementally and in a compatible way is a driver of this kind of speed. Forcing everyone to rewrite everything every few years is the best way to slow things down.
The Benefits Of Being Small
RW: Fair enough, but it’s Google behind AngularJS. Surely they know something about both innovation and the need for stability?
Tom Dale: At the end of the day, the Web is about experimentation, and it’s exciting to see Angular, Ember and React all vying to provide developers with the best possible experience.
An important difference is that Ember is not developed at a huge company like Google or Facebook. Everyone on the core team (and the vast majority of its contributors) work on products built using Ember, and make their contributions on nights and weekends.
That might sound like a weakness, but in fact, we think it’s one of our biggest strengths. Building your livelihood on the open-source project you maintain places a huge amount of pressure to make sure that new features are implemented in a backwards-compatible way.
ReadWrite: Yes, but meanwhile AngularJS or another project can speed ahead, no?
TD: That’s the second part. Of course no one wants their competitor to be able to build a better product with a newer, flashier framework. Avoiding stagnation is extremely important, it just has to happen in a realistic and methodical way.
This seems counterintuitive, but history bears it out: Open-source projects such as Apache, Postgres, Linux, maintained by a coalition of companies, offer long-term stability and longevity. How many companies have built on APIs from Apple, Google or Facebook and then suffered when they were shut down suddenly?
We think simply choosing “stability” or “progress” is the easy way out. Carefully balancing the two requires seriously hard work, but the best open source projects have figured out a process for making it possible.
Lead image courtesy of the Library of Congress
