How Google is redefining web development (and Backbone.js is getting obsolete)

Very lately, Google made announcements that have rightfully excited the web developers’ community; but after talking around, I feel that not everyone realizes how those moves may entirely redefine how web development is done. So, I decided to summarize what’s going on in this post in a concise, straight-to-the-point way.

Note that this scenario depends on the popular adoption of what Google just announced, and of course, strictly represents my opinion only.

Recent events

  • On May 20th, Google Chrome 35 got released with a fully working implementation of Object.observe (here is more information).
  • On May 23rd, Google Search revealed that they’ve been interpreting JS during their crawling (here is the announcement).

Explaining the Object.observe stuff

In a nutshell, there are two approaches for how the model tier of front-end MVC frameworks work:

  • Backbone and Ember require that you create a model by extending a model class they provide (var Product = Backbone.Model.extend(); var product = new Product(); …), and that you use get() and set() methods when you want to access and change stuff in your model. This allows for the get() and set() methods to not only change stuff, but also to let the view know about what changed when it does.
  • Angular allows to use plain old JavaScript objects (var product = { name : “Chair”, price : 50 };). When you change one of those model objects, your views “magically” update.

Now, obviously most people would agree that Angular models are more efficient to develop, and more pleasant to work with, but this “magic” comes with a huge trade-off, which is called ” dirty checking”, and is indeed very dirty.
Some people explain it at length better than I would, but the idea is that plain old objects don’t have logic, and therefore can’t alert your views by themselves when they’re changing. So Angular needs to continuously check if something in there just changed, and compare the current state of all model objects to their previous states to find out what actually changed, one by one. Dirty checking is indeed dirty, and quite slow.

Detractors of Angular have been saying that Angular couldn’t be the way of the future, as dirty checking is indeed very dirty, and their opinion has been making sense. It turns out they were probably wrong after all, as Chrome now fully implements Object.observe, which means you don’t need dirty checking anymore to be alerted when something changes in a plain old JS object, and therefore you can use plain old objects as model objects with no trade-off.

Now, this is Chrome-only today, but if this gets implemented by other browsers and become fully usable in production, then Backbone.js and Ember.js model tiers as we know them today will simply be suddenly obsolete.

Explaining JS interpretation during Google’s crawling

The “front-end MVC” architecture has been coming with a major downside : Google didn’t interpret JS, and therefore those sites were very hard (if not impossible) to get indexed without having to create another, more “static” site. The issue in a nutshell is that a single-page app is most likely to be a blank page that gets modified by JS; so without the JS, Google sees the blank page only.

I’m aware of the other downsides, such as accessibility or performance, but I don’t consider them as major since I believe stuff can be done to make them better; also, there’s fault-tolerance, but I don’t believe it will be as hard a problem in the future (I’ll get back to that). All in all: with a single-page app website that was well-conceived, the only unavoidable dealbreaker was SEO, which made them suitable only for cases that don’t need SEO (authenticated apps, …).

Google’s announcement means that this is simply not a problem anymore for a website’s Google indexation, as their crawler knows how to execute JS, and to see pages just like you do, even front-end MVC architectures. And it won’t do it “tomorrow maybe”, it’s doing it today, actually has been doing it for a bit of time already. Dealbreaker gone.

First, what this won’t change

You will still need back-end stuff. As long as you need to persist data and perform data transactions that impact multiple users or devices, full-front-end is not an option.
Performance is another downside of front-end apps today, and as much as we can still make this way better (more on this later), average front-end performance won’t be able to match average back-end performance. It certainly can get very, very close, but the JS code will always have to be sent and interpreted, no matter what (there are heuristics to make it a lot better in some cases, though).

What this would change

Front-end would have to handle more complexity, and I believe this is probably a good thing in the long run. I believe we’ve only been scratching the surface of what can be done with front-end MVC frameworks, and there’s still much to get done to make them better, and make them cover more use cases (more on this later).

Also, back-end would therefore get more simple, covering less of the business logic and general role of the application. My guess is that most back-end stuff would probably be made of 2 kinds of approaches:

  • RESTful resource-based databases, and we already have many options among existing frameworks. Only last week, the awesome people at StrongLoop released LoopBack, a framework dedicated to doing just that in a very simple way, based on MongoDB and Node.js (which is always a good choice for stateless small transactions with not much business logic).
  • API cloud services that serve various simple purposes and can be integrated jointly for a given project, for instance: Firebase for real-time communication, Parse for an advanced cloud database, Moltin for e-commerce, or (full disclosure: that’s the product I work for) for content management. This is a really, really exciting time to be working in API-based products.

What would have to get better

There are some weaknesses in current front-end MVC frameworks to build complex apps, but I think that now that SEO is gone, all of them can be made way better. Remember that front-end MVC has been reserved for certain kinds of apps so far, but now that they are a thousand times more relevant, it will just make sense to better address the issues for complex apps. I’m pretty sure I don’t have all of them in mind, but here are at least my two personal favorites.

Performance is king of issues today; for instance, to load one webpage, you will have to load the code for every controller in your website (this is true for Angular, and as far as I know, this is true for Backbone and Ember too); the bigger your application, the more this becomes a problem. Angular’s modular approach is pretty solid, but still requires the code for all modules to be available and loaded at all times. However, I don’t see what the problem would be if this approach was changed so that we can lazy-load the JS code of modules that may not be used right now. This way or another way, it’s safe to say that this can be made way better.

Fault-tolerance is annoying with JavaScript, as, in real life, a single issue can make your whole JavaScript execution go to hell. Back when I was working with my friend Jérémie Patonnier, he would always say that you give too much trust to JS when you make it do something you could do in the back-end, because you never know where it’s gonna break. This is even more true when the application becomes more complex, and more bugs might happen. But the language already contains stuff that can be used to safeguard your JS execution; they’re just not very well used today, and today’s MVC frameworks don’t seem to be very focused on solving this. But it could definitely be made better, and JS can definitely be made more resilient with the right tools.

Should we throw away Backbone and Ember right now? Is Angular the king and only winner?

No, and no.

If Object.observe does become a thing, and other browsers implement it seriously, then Backbone and Ember’s approach to model won’t make sense anymore, alright. If this happens, then they both will obviously implement models with plain old objects at some point, and even though I don’t know the amount of work this represents to make it happen, I don’t see why they wouldn’t.

EDIT: Paul Chavard, who contributes on Ember.js, got in touch with me on Twitter, to let me know that POJO are indeed on the table, but that something else is in the way: handling “unknownProperty” and easy inheritance / mixins. It looks like it will be solved by ES6 Proxies. (Tweets are here and here.)

Also, Angular comes with that approach for models already today, which does make them earlier than anyone to the game; but they also come with other concepts and values that one may see fit or not for their need (in the data binding, the modular approach, the dependency injection, etc.). To address the huge spectrum of needs, web developers will need choice, and I’m pretty sure in time we will have a lot of choices, whether from revised versions of existing frameworks, or from new ones that will happen over the next few months/years built from other concepts and values, or with specific use cases in mind.

So, what now?

My advice to be prepared: if you don’t know an MVC framework, learn AngularJS, or another MVC framework you see fit. With Angular in particular, I found that the learning curve seemed steep at first, but it becomes fun very quickly, and is really, utterly powerful.

Then, if you need to store data, look into LoopBack, or Parse, or how to make it happen with the back-end framework you know. If you need to have real-time communication (chat, whiteboard, …), look into Firebase. If you need e-commerce, look into Moltin. And of course, if you need content, create a account today!

16 thoughts on “How Google is redefining web development (and Backbone.js is getting obsolete)”

  1. var o = {};

    Object.observe(o, function(changes) {
    changes.forEach(function(change) {
    console.log(change.type,, change.oldValue);
    }); = 1; // add, ‘foo’, undefined = 2; // update, ‘foo’, 1
    delete; // delete, ‘foo’, 2

    Without Object.observe we currently rely on:

    wrapper objects (Backbone.Model, Ember.Object)
    dirty checking (Angular)
    getters and setters

    With wrapper objects we lose native connection with the plenty of Javascript libraries built to operate on plain objects.
    On the other hand dirty checking can be expensive to perform.
    Getters and setters will only notify us of changes on the property level and not of the deletion and addition of properties on the parent object.

    Once Object.observe lands on all browsers, I think most people will be more than happy to go back to using plain old JS objects.

  2. Thanks a lot for the article.

    Google is not the only one to move the lines in this domain.

    If client-side MVC/whatever is your thing, check theses solutions, too :
    – Facebook’s ReactJS :
    – Mithril :

    Please note that React is more a view engine than Angular or Mithril.

    Mithril and React use virtual DOM diffing (which is very performant) instead of “dirty checking”.

    I started testing react on a side project (made with Angular), and so far, I find the workflow much more fluid, enjoyable and consistant (disclaimer : I’m absolutly not an Angular specialist).

  3. I like your article. There’re some points however with which I disagree:

    “that you use get() and set() methods when you want to access and change stuff in your model” and
    “Backbone.js and Ember.js model tiers as we know them today will simply be suddenly obsolete”

    Why? After all it is still OOP. AngularJS uses syntactic sugar, that’s all and maybe subject to change in the future if you have a closer look at ECMA6 classes.

    ECMA5 introduced getters and setters aswell, so a POJSO might be accessed in AngularJS “the Backbone way”.

    1. Simply because it’s easier to use and to learn, and the added complexity would then be useless (although it would be technically the same, we agree). I added an “edit” in the post with information from Paul Chavard, who is part of the Ember.js team, and confirms that they are looking towards POJOs; however, they have another obstacle to solve to get there, that I didn’t know about.

  4. I’m not sure I’d point people at AngularJS. I think I would first say, go look at and dip your toe in the water. I see a path forward with patterns from backbone combine with vue.js or react.js side stepping model and collection classes.

    1. You’re right, I’m not 100% sure Angular is the best to learn from (although the quality of their tutorials / documentation is just off the charts!). I just changed the phrasing of that sentence to open to other frameworks, because what matters indeed is that people get interested in front-end MVC frameworks in general.

  5. I just can’t get into Angular. It reminds me of a J2EE framework. Still fond of Backbone but am starting to really like Vue.js, which has all the good parts of Angular without the overengineering.

  6. Great post. Nice to see a really objective look at Angular vs. other technologies. The one thing that bothered me about Angular was the “just do it our way” when it comes to integrating jQuery or other existing code features into Angular applications. Yes, rewriting them as Angular only code is the best way to run them in an Angular app, but it does force total acceptance of Angular as the “solution”.

    Like the author, I like what I see in Angular. It is just nice to see that this area of web development will continue to expand and include ever more flexible solutions which build on the excellent concepts that AngularJS has brought to the forefront.

    1. Yes, I agree with this, although I used to think it was a bad thing, and now I think it is kinda a good thing to have that option.

      I’d say that Backbone, for instance, comes with tools, but not a strong philosophy in how things should be done. To some extent, it is meant to be used more like a “library” to your JS code, than an actual framework that organizes your JS code. Therefore, it is very friendly with other libraries, but there are many ways to use it, and all of them are right.

      With Angular, however, even though you can technically integrate other libraries, it does come with a strong philosophy, so it kinda defeats the purpose to want to integrate third-party stuff that doesn’t abide by the same philosophy.
      But to some extent, all previous JS frameworks were very shy over how things should be, and it was kind of a shame not to have one that would be more opinionated; I believe it did keep the industrialization of front-end code behind not to have that option. This reminds me of why Rails was needed when it came out, with the whole “The Rails Way” philosophy that provided guidance about how things should be done, even though Rails was entirely incompatible with the PHP/Java/.Net code that existed everywhere before. And all of those existing frameworks were more focused on “what” could be done, rather than “how it should” be done.

      Anyway, I’m really hopeful for what AngularJS brings to the industrialization of complex front-end apps, and I sure do hope that it will survive the test of time, like Rails did!

  7. Wonderful web site. Plenty of beneficial facts in this article. I am transmitting the idea to a few pals ans likewise expressing around scrumptious. Not to mention, cheers with your effort!

  8. I must appreciate your effort in explaining the new techniques used to redefine web development field. Being a website designer it is always good to learn something which I am not aware of. Thank you for making me and various other web developers who are not aware of this “angular” technique.

  9. Honestly, I don’t think Object.observe is all that is hyped up to be. Vue.js uses it already (whereas production Angular does not) and in most browsers, Vue’s performance is just a bit slower than Mithril’s, which uses nothing but old DOM APIs (but to be fair, Vue and Mithril are the most performant frameworks in the market right now).

    The problem with POJO-based architectures is that computed properties don’t fit the paradigm. Vue ties its computed property mechanism to view models, and Angular has $scope.$watch which ties them to views, but neither of the two is ideal, imho. Ember’s non-POJO approach is designed to solve the problem in a more correct way (i.e. in the model layer). Mithril is somewhat unique in that it lets you decide how POJO-based you want to be, so you get the best of both worlds (and that actually works today, in all browsers, and without handwavy polyfills)

    Other things in this article are kind of solved problems: stop-the-world syntax errors can be caught with JsHint and Grunt/Gulp (or you could use something like Typescript for extra type sanity), and lazy loading has been solved by a variety of libraries (with RequireJS being perhaps the most famous)

    I think that in order to “make Backbone obsolete”, a mere new HTML5 API is not enough to provide a leap forward: there needs to be a more fundamental shift in how we reason about applications. Templating engines like Angular’s are one step in that direction, but I think the next step requires stripping the complexity of frameworks rather than building on top of it.

    Case in point: why is lazy loading even considered a problem? One should just be able to pick a library that solves it, plug it in and be done with it. With Mithril, this is pretty easy ( see ). If I was to pick a low hanging fruit in terms of exponential increase in potential, it seems like a no-brainer to be able to easily integrate to the larger javascript ecosystem (rather than the “Angular ecosystem” or the “Ember ecosystem”).

  10. Ampersand.js was the solution for me and anybody who felt Backbone lacked something but didn’t wanna mess around with its plugins, frameworks (marionette etc) or move to scary opinionated stuff like angular and ember.

    Ampersand uses es5 getters and setters so you get pojo-like syntax on top of the Backbone flexibility, and a bunch of clever additions like session and derived properties.
    Every single piece is modular so I object.observe will be implemented in no time when it will be usable in production.

Comments are closed.