Home Innovating Fast And Slow: EmberJS Insists, “We Don’t Need To Break The Web”

Innovating Fast And Slow: EmberJS Insists, “We Don’t Need To Break The Web”

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

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.