Contrasting Backbone and Angular | Hacker News Reader

Contrasting Backbone and Angular

victorsavkin.com

64 pointsvsavkin23 comments

I must be in a minority, but I find AngularJS inelegant. I am back to Backbone and its simplicity. Angular tries to solve declaratively what could be better solved with JS, HTML and your favorite template engine.

The point is why do you want to write things from scratch each time you start a new project? That is a huge waste of time and also a huge waste of resources ( money ? ) for whoever is paying for the project.

Scratch? Use Yeoman.

Does anyone use Yeoman for serious projects? I've tried it, but in the end you just end up subscribing to someone else's idea of a good app structure. I found myself constantly rearranging everything.

Then again, I'm really not a big fan of "code generation" tools.

Meh, I find it to be useful. Of course it doesn't always get you to where you want to be - but you can always create your own generators as an easy way to bootstrap your own projects.

I think it's immediate value is in boostraping new projects.

I clone the generator repos that I use mostly, and have set them up the way I want, but yes, it's primary value is bootstrapping new things, obviously.

We're using it in a big app right now and have been happy with it in general.

"Angular" or "Write things from scratch" is a false dichotomy.

I see the dependency injection as the solution to a massive problem I couldn't see an obvious solution to with Backbone.

You dont need angular for dependency injection , there is a lot of JS IoC containers on npm already.

I think that might be the main reason I find angular attractive when compared to mostly DIY approaches with backbone.

Sure I can build a best of breed utilizing a wide range of libraries together with backbone... Well I would think I am intelligent enough to do that but in the end it feels like it's based a lot more on opinion rather than fact.

I rewrote an admin backend in half the time it took someone to do it in backbone with their choices of libraries. YMMV, but I am loathe to get into another discussion of which templating library to use, which UI widget things, etc., etc. Just let me build it already! And take care of 90% of the annoyances for me.

I prefer building my own stack. Refactoring is quicker down the road has I dont have to rewrite all the application.With angular you'll just be writing Angular plugins when things change ( and they will , Angular is not the ultimate JS framework ) ,you'll be stuck with Angular or waiting for an update, i'll just be swaping a layer in my application ).

What problems do dependency injection solve for you? I haven't had a chance to use it yet, and I've always been curious about its benefits in real projects.

Everytime you pass arguments to a constructor or a method,if the parameter is itself an object you will call a method on (message passing), you are doing dependency injection.

So it's a fancy word for a basic idea.

The OP is talking about an IoC container or a service locator. which is a tool that will wire up and build objects on demand according to a definition. The alternative is writing factories( ex : document.createElement("DIV") is a factory method ).

I generally use browserify to handle dependencies the same way I do in node.js. It's worked pretty well for me so far.

https://github.com/substack/node-browserify

I felt that way until I actually used it.

In practice, compartmentalizing sections of a page into declarative chunks of JS and HTML actually helps keep things really organized. When each link in a nested directive chain is completely independent of one another, it makes refactoring a problematic area much simpler. And of course all of this makes unit and functional testing much simpler.

Angular's declarative approach makes it easier to separate angular out if you choose to switch frameworks for whatever reason.

Personally, I've found backbone pretty disgusting, although perhaps better than vanilla js/jquery.

Check React or Ractive for the view layer , they are awesome.

Between 3-4 years ago my work was heavily using GWT. We first tried the MVC pattern but we've always felt that it didn't fit well. We didn't know MVP at that time until Google I/O mentioned it. We looked at it, we gave it a try, and it was the perfect fit for the client-side of single-page app.

Maybe MVC with tweak would work too, just rename the Presenter to Controller. But maybe that is no longer called MVC but MVP-with-name-change.

I'm not big on MVVM (knockout.js) but YMMV.

I've only done a little bit of Angular, but as is widely reported, the docs were a huge turnoff. The learning curve to build anything is pretty steep, which is where really solid docs would be crucial.

I've been living in Backbone land for a few months now, on projects without Marionette, and having looked closely into the Marionette way of doing things, I think it's pretty much essential to writing maintainable code. I'm in the process of trying to convert chunks of the app to Marionette, little by little, and also running a simple home-cooked dependency injection scheme, which I may blog about once the kinks are all worked out.

For those who've been burnt by Backbone in the past, I really suggest giving Marionette a shot. It's not perfect, but it standardizes a very clean, very understandable methodology for building Backbone apps.

Might worth checking out this:

https://github.com/devmatters/backbone.rocks

Reply on news.ycombinator.com