Comment by Cthulhu_ | Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Parent Full thread

When I first worked with Backbone.js almost a year and a half ago, honestly, me and my team hardly had any clue what we were doing; the documentation was probably just as good as it is today, but it just didn't click with us, it seems. We did finish our application at the time (a six-screen monitoring application, think a lot of tables and some graphs), but it didn't feel "nice".

A year ago we started our second project, and it made a lot more sense. It's a pretty big project, we've got ~10.000 LOC of Javascript, most of which is Backbone views/models/routers, some Handlebars helpers. The project has, based on our filenaming conventions, 18 routers, 68 views, and probably around 75+ models. Using Require.js we keep the codebase clean and organized, and using some custom functions (a close function, most importantly) we stop it from being a memory hog.

I like Backbone. The major competitor is Angular, but it's more high-level; Backbone itself is just a thin layer on top of vanilla JS, jquery and underscore, really, but that's what gives it its power.

Looking forward to upgrading to 1.0. The change in reset behavior will cost us some work, but it sounds like it's doable.

Not to rain on Backbone's parade, but I am easily twice as productive in angular.js. The learning curve is a bit steeper but once you mastered you end up with (IMO) a cleaner more maintainable app.

The coupling between views and controllers - at least based on the examples on the front page - looks horrible to me, and makes it a non-starter right out of the gate. To me that feels like a return to the bad old days when we embedded PHP right in the HTML....

If Angular doesn't float your boat, that's fine. For those wondering if this is true, it's not. Views in Angular can interrogate their controller for model data, and they can fire events into the controller. The controller doesn't know about the view (or even if it is hooked up to a DOM instead of a test runner). You can reuse a view with a different controller (provided, of course, the controller supports the same operations). I don't believe that this level of coupling is harmful. In fact I think it separates these concerns nicely.

The view is written in HTML, you declare the bindings with moustache-style templates or with attributes. Some people get really hung up on this, but the declarative UI is not Turing complete, so it's not really like embedding PHP at all.

By the way, I like Backbone too, and I use Underscore everywhere. Congratulations to all involved on reaching an important milestone and creating tons of value for everybody.

> You can reuse a view with a different controller

Then the examples on the site are really misleading, given that they hardcode the controller name in the example views.

EDIT:

To give an example of what I object to, this is cut and pasted from the Angular homepage:

    <div ng-controller="TodoCtrl">
      <span>{{remaining()}} of {{todos.length}} remaining</span>
      [ <a href="" ng-click="archive()">archive</a> ]
      <ul class="unstyled">
        <li ng-repeat="todo in todos">
          <input type="checkbox" ng-model="todo.done">
          <span class="done-{{todo.done}}">{{todo.text}}</span>
        </li>
      </ul>
      <form ng-submit="addTodo()">
        <input type="text" ng-model="todoText"  size="30"
               placeholder="add new todo here">
        <input class="btn-primary" type="submit" value="add">
      </form>
    </div>

First, it hardcodes the controller name. This, to me is configuration information - part of setting up routes - that the view should not know. Then there's the ng-click and ng-submit bits. More configuration that I really don't want in my views. It also seems to declare the model to update in the view?

This is what I meant about tight coupling to the views.

Good questions. I fully support DOM Spaghetti Aversion, but Angular's approach is quite different from PHP. I'd hate for people to dismiss it because they heard its the new PHP or because it cosmetically resembles an anti-pattern.

To answer your specific concerns, you can in fact imperatively bind Angular controllers to route views in the app's configuration block. However, this approach doesn't always make sense—you can have multiple apps in a page, each app having multiple controllers, so they can't all use the URL as the engine of application state. In cases like this you can your view as a directive, and then you can inject the appropriate controller (in fact this is exactly how ng-view works with the router).

Or, you can take the approach quoted above, and use an XML-like declarative configuration language to describe the view and its relationship to whatever happens to be its controller, and let the compiler generate the appropriate HTML for you. (I'm kidding, it's HTML all the way. But in Angular, the view describes its own structure, appearance and behavior, the controller is concerned with mutating state and not DOM manipulation.)

I'm not trying to evangelize, just put some good information out there. Backbone's templates, as I recall, use ERB-style syntax to push values and imperative code into templates, which then set up their models (http://backbonejs.org/#FAQ-bootstrap). I think you agree it would be unfair to put down Backbone as the new PHP based on that fact that its templates let you write in that style.

Enjoy!

You know, it's really nice to work with. I like the structure Angular provides, but I tend to agree. It doesn't feel entirely "right". Maybe I just need to get over it.

How big is your Angular project? I mean I like the idea behind Angular, but my concern how Angular holds up in a huge app, let's say if Angular was written as the client of WordPress (or some blog) admin. I don't have enough experience with it to be able to judge how well it is to handle that.

Or would it be a hybrid of Backbone + Angular?

Would love to hear the opinion of someone more experienced.

The common anecdote is that Google used Angular to make the the Doubleclick advertiser interface, which is just as big if not bigger than the Wordpress admin interface. It turned out to be great, with much less lines of code than what they had before (GWT).

Regarding Backbone + Angular in a large project, I wouldn't touch that code base with a 10 foot stick.

Great thanks. My perception up until this comment was that Angular was more of a mini-tool for MVVM for use in little widgets, and not really able to be huge.

I wish it was advertised more what large projects using Angular and that they are actually architected completely with Angular.

I'm not sure what you mean by _really able to be huge_ -- a large single page app? a site with a huge number of pages? # lines of code? I don't think there are any hidden limitations in Angular proper -- in fact it will allow you to organize source for a "large" project very well, and will perform very well -- but you have to be careful with scope digests (i.e. don't try to "compile" a bazillion objects -- but that is mainly common sense)

A lot of articles I originally read/skimmed with Angular didn't really tout it's ability to organize large codebases... I got the impression is targeted toward smaller projects, whereas Backbone they market themselves in your face "we will clean up your large codebase".

Angular and Backbone are very different. Angular is a full framework; it's brilliant but also gets in my way on a regular basis. It may take me longer to write the same app in Backbone but it's a library and happily co-exists with other libraries. With Backbone I feel like I'm using JavaScript, with Angular I'm learning Angular.

I also write a LOT less code, a LOT less boilerplate code -- after writing a number of Angular apps, I won't go back.

I think angular offers some amazing features, but it's very opinionated in how you use it. My experience with angular has left me feeling less like a javascript wrangler and more like an angular wrangler. I mean no disrespect to the framework, because it is amazing, but, it's just different.

Even though the Backbone API has been solid for a very long time, here's hoping the psychological effect of reaching "1.0" continues to spur opinionated abstractions that sit on top of Backbone.

Reply on news.ycombinator.com