Hacker News Reader

Comment by hasenj | Hacker News Reader

I didn't really like backbone at all. It was a pain. It didn't offer anything to help you build complex UI.

I had to use backbone to build a mildly complicated UI - not so complex, mind you, just something that's supposed to be somewhat interactive.

Backbone was no help at all. Its "views" don't really offer anything.

Just about 2 weeks ago I discovered knockout.js, and I felt stupid for spending days building something that would probably take an afternoon to do with knockout.js.

Then, a week later I discovered angular.js and felt even more stupid.

Now I really dislike backbone.js

View on HN

I've built moderately sized applications in both angular.js and backbone, backbone is much more pleasant to work with if only for the fact that everything is obvious, even if that requires you to do more development legwork and thinking about your application structure. (this is a feature, not a bug)

Angular.js data bindings are great and things like ng-repeat are neat until you start to step outside of the bounds of the angular garden.

Want to fetch data yourself and not use the angular resource plugin? (The resource plugin restricts the shape of data you can return from your server, i.e. every resource.get() request must only return a single object, if you want to receive an array you need to use .query() ). If you want to use jQuery for ajax, for instance, you lose all data bindings because vanilla javascript doesn't have the angular secret sauce! edit: angular provides utilities to alleviate this issue, addressed in comment below.

Well that's fine maybe there's an event somewhere you can hook into and trigger off of, right? Try to find this in the docs, I dare you! If this doesn't demonstrate the incidental complexity caused by using a tool like angular, consider the documentation for backbone and angular, or either projects source for that matter. You can read backbone's source in an afternoon, I couldn't say the same for angular (or ember, or knockout). Because of this I can be confident backbone is largely bug free, I absolutely can't say the same about larger projects like angular.

Angular.js is meant to have a low barrier of entry, but because of this the developer interface is a thin facade on top of astonishingly complex internals. Contrast this to backbone which provides a simple and solid base for your application, providing freedom and foundation rather than a cookie cutter solution.

When I consider the trade-offs between client-side tools for structuring applications backbone consistently comes out on top.

"If you want to use jQuery for ajax, for instance, you lose all data bindings because vanilla javascript doesn't have the angular secret sauce!"

Data bindings should work as normal...if you're running into issues, try using $scope.$apply().

Angular uses jQuery, internally, so there are events you can hook into -- jQuery events.

And comparing the complexity of Angular and Backbone's internals is a bit misguided. They aren't meant to solve the same problems. Angular is complete Javascript application framework, and Backbone isn't. To use a non-foolproof analogy, if Angular were Rails, Backbone is Sinatra.

I wasn't aware of $scope.$apply, should help simplify some of my angular stuff. Thank you :)

You're welcome. :)

You raise valid points about Angular's complexity and lack of documentation.

This is why I also mentioned knockout.js

Knockout is more explicit than Angular, it's well documented, and the tutorials are just amazing.

I used to be in the "dynamic" crowd, but now I'm starting to lean towards the "explicit is better than implicit" philosophy, so I'm somewhat torn between Angular and Knockout. I'm choosing angular - like you said - for the low barrier of entry but if it turns out to be complicated I will probably switch to Knockout.js

However, I don't see any reason why I should use Backbone. What exactly does it provide? I don't see it providing anything useful to me.

I recommend checking out http://blog.stevensanderson.com/2012/08/01/rich-javascript-a... for a more in depth exploration of the trade-offs between the popular client-side architecture tools.

I can only speak of my personal experience with these tools, and I've only tinkered with knockout (though we do use it for one of our tools internally, and the developer of that project gave it glowing reviews). I would recommend using the tool that is the closest to your development style.

If you like opinionated frameworks that make it as easy as possible to do the most common tasks (like rails), maybe you'd enjoy something like ember.js (or knockout). For me the style closest to home is the ability to plug in My Favorite Solution to each particular problem as it arises.

A primary offering from backbone then is a simple structure for plugging all these previously disparate tools together, the serverside corollary to this is something like python's Flask or ruby's Sinatra where it comes with only a simple routing base and ways to plug your own components in.

Want to use your own templating library? Easy. Want to use your custom persistence style? No problem. Backbone isn't going to make these choices for you, you will need to make them yourself.

This may or may not be the right choice for you, just investigate and make the choice that makes the most sense for you !

There is a good reason for this http://stackoverflow.com/questions/3503102/what-are-top-leve...

Besides the official JSON spec doesn't support JS top-level arrays.

This is my concern after looking at and playing with Angular a little bit.

I would say it's because you guys are doing it wrong. Backbone is just a very bare-bones backbone for your app. As you say, views don't provide anything. In fact backbone barely helps you with organizing your code at all. It's great for making a todos app but terrible for anything stretching across multiple pages, and with more than 10 views on a page.

Let's be serious here.

DON'T USE BACKBONE TO START A NEW APP!!!

Use one of the higher level frameworks built around backbone.

The most flexible / clean, decoupled framework (my preference) is: https://github.com/derickbailey/backbone.marionette

If you like coffeescript: https://github.com/chaplinjs/chaplin

If you want *only good views/layout: https://github.com/tbranyen/backbone.layoutmanager

If you want modelbinding: https://github.com/mikeric/rivets

Backbone is very much bring your own module, starting with just backbone is not the way to go for an app of any reasonable size!

I'm afraid that advice is about 180 degrees away from the truth.

If you look at the kinds of large scale projects that people are building with Backbone:

http://backbonejs.org/#examples

... or the new Hulu.com, from earlier this week -- I'm not aware of any of the sites on that list using any of the libraries you're recommending.

@jashkenas Those sites use their own custom libraries that do about the equivalent of what the libraries I suggested use. I say this not out of any disrespect, I love backbone, but backbone doesn't provide enough to build a complex app. Does it have memory management? No. Does it provide a pub/sub pattern? No. Does it handle views/nesting subviews and layout management? No.

You can roll your own library, of course, it's not that hard. But you can also not reinvent the wheel and use an existing open source solution.

If you read the complaints in this thread it's mostly *backbone doesn't do enough. Backbone is great as 1 layer of abstraction, but you need more layers in order to code effectively.

    > Does it have memory management?

JavaScript has memory management; JavaScript has a garbage collector. If you structure an app (with any library) not to leak references, then no manual memory management or bookkeeping is needed. Not having additional memory management is a feature, not a bug.

    > Does it provide a pub/sub pattern?

Yes. That's Backbone.Events, which is the core how models work with changes, and can be mixed in to any object.

    > Does it handle views/nesting subviews and layout management?

Right -- your UI and your HTML is your business. Not having an explicit view hierarchy or layout paradigm is part of the reason why Backbone Views can be used in the kinds of diverse environments you see in that list of examples ... from "enhanced" static pages like Pitchfork.com, to interactive SVG-based graphics like SeakGeek's stadium maps, to multiplatform hybrid web/native views like LinkedIn Mobile.

That said, if you think you've got an idea for a "layout" feature that would help with UI across the spectrum, it would make for a great pull request.

> > Does it have memory management?

> JavaScript has memory management; JavaScript has a garbage collector.

The problem with javascript apps is not leaking memory, it's forgetting to unbind events and/or binding events multiple times.

Angular.js and Knockout.js relieve you of this problem because they handle all the event binding so you don't have to worry about it.

  If you structure an app (with any library) not to leak references

But that's boilerplate.

  That's Backbone.Events, which is the core how models work with changes, and can be mixed in to any object.

But it's messy out of the box for other parts of your app without boilerplate. You need to structure your events somehow. It doesn't take much code and the libraries that I recommend are very small.

I don't think Backbone necessarily needs more features. It's great for certain sites that uses Backbone in limited ways. I'm talking about making an entire website end to end in Backbone, something that most of your examples do not try to do. But if you're making a whole app in backbone, not just a feature or a widget, something with many many routes and regions that swap nested views constantly, you'll need a bigger library.

So, backbone alone is fine for apps that's mostly traditional / server based, with some client side features. If the entire app is built in backbone then you'll want to build on top of it. There are many many frameworks popping up around Backbone and they should be supported by Backbone. Developers clearly need them or else there wouldn't be so many of them.

I'm not sure if this is something that could be helped with some doc changes, but it took me awhile to figure out that pubsub is exactly what Backbone.Events gives you. And even then, I only figured that out from reading tbranyen's code.

This might be something that you're thinking people should work towards... Aura (http://addyosmani.github.com/aura/ ) "an event driven architecture built on top of backbone"

Also check out http://thoraxjs.org/beta

Yes! Not to hijack this thread but I hated building web interfaces with javascript, struggling with cross-browser support for anything remotely non-standard. We've been using Angular.js for the last month to build a very beautiful, complex interface and I'm loving every minute of it. As long as the framework doesn't change too drastically over time I know we'll be able to keep what we've built for its 2-3 year lifetime and fingers crossed that IE14 and Safari 7 don't break too much of it.

Angular.js doesn't really solve the hard parts of writing web applications either. The hard part is structure. Not data binding. I don't need a framework to automatically update an <input> for me, input.value = val isn't costing me sleep at night.

What we need to make web applications easier are equivalents to things like UIPageViewController in iOS or Activities in Android. Real views that do real things. It seems that JS frameworks only give you the very top level base View class that does almost nothing.

I disagree. The hard part is nesting views/widgets, and these are very annoying to maintain manually.

Knockout.js provides a "foreach" binding, and Angular provides ng-repeat. These are good solutions that automatically handle nested-views in an efficient way.

Nesting views, along with data binding as MatthewPhillips pointed out, is not the hard part of developing frontend apps. Custom UI/UX is the hard part. Can angular fadeIn/slideDown your nested repeated/collection element? No. In angular, along with any other MV* framework, to handle this trivial UX, you have to write a special js routine (directive). Most apps will have much more custom UI/UX and you are going to have to write javascript, and you may have to fight your framework if it is too opinionated.

I think that these views are going to happen, especially as the Angular-UI project moves forward. The documentation of Angular needs a lot of work, but the fundamentals are sound and I think we might have a framework that genuinely gets us building apps instead of struggling with jquery.

Do you use CoffeeScript with Angular? I am curious if that combo works well.

Not at this stage but there are a lot of people using it successfully according to the comments on the (very active and informative) mailing list.

thanks. good to know

I do.

I'm with you. knockout.js is a sharp tool that does one specific job very well. It lets me stop writing boring JavaScript, and focus on business logic.

Backbone just feels complicated by comparison.

Could you be more specific? What was Backbone not doing that Angular does?

Nested views and automatic view updates.

How would you display a list of items in backbone? What do you do when an element is removed/added?

How do you update a view when an element changes?

It's a lot of grunt manual repetitive work.

In Knockout and Angular, it's all automatic.

Related: forms.

>How would you display a list of items in backbone? What do you do when an element is removed/added?

Collections

>How do you update a view when an element changes?

Model/View binding.

I didn't think it was bad and the only issue I had was when your views broke the hierarchical nesting. I see no solutions to that problem in Angular. Was curious if your problem was something similar.

Reply on news.ycombinator.com