That's sort of a weird way to frame it. I could make the same argument against Angular:

"I want to write a bunch of gross code to perform dirty checking of objects to keep everything in sync" said no UI developer ever.

That's the point of libraries and frameworks. They do the repetitive or "ugly" or "hard" things that we don't want to do over and over.

> "I want to write a bunch of gross code to perform dirty checking of objects to keep everything in sync" said no UI developer ever.

Except that this is in no way an equivalent comparison. With Backbone, you actually have to write the hundreds of callbacks in your application code.

Whereas with Angular, you attach a value to a scope, and declare it in a template. In that case, the framework actually does take care of the 'ugly' for you.

Backbone keeps the ugly in front of your face, it just gives you a slightly neater way to organize it (i.e. as compared to jQuery soup).

My fault. I guess I misunderstood the point being made.

Or you use a templating engine/language and write a simple reusable adaptor. An adaptor you have to write once, assuming one doesn't already exist.

If I'm reading the above comment correctly, the author is stating that Backbone surfaces this to the user. To manage state in a Backbone app requires lots of callback binding.

Huh? I've written quite a few large scale angular apps...and I haven't written a bunch of code to do any of that. If you have something that needs to be checked outside of angular, it belongs in a directive.

The way I see it is you craft those state changes for the objects that need them. You could create a base object that handles basic state changing, too, and just extend from that. On the opposite end of the spectrum, we can make as many assumptions as we like, and override as needed, or we can create an unassumptive mesh of mixins that coordinate and comprise complex objects.

I can do that with a framework that doesn't presume the best path from 0-F. The reason I like Backbone is because it treats me like a developer who knows how to architect an application.

Yes. Backbone basically supplies CRUD mapping and an event bus. So it is opinionated about models.

But CRUD is a solved problem that's easy to implement, and view / controller code ends up being the bulk of your application. I'd rather my framework give me a little help there.

CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database.

> CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database.

Please explain how doing CRUD operations -- which is, after all, what SQL INSERT, SELECT, UPDATE, and DELETE statements are -- prevents you from doing relations in your relational database. Because that's a seriously wierd claim.

I think REST is more accurate, and REST does a shitty job of efficiently expressing relational data.

I know React is backend agnostic, but out of curiosity, what does your ideal server API architecture look like if not RESTful?

I mean REST has its place. For example, it has very predictable performance and well-known cache characteristics. The problem is when you want to fetch data in repeated rounds, or when you want to fetch data that isn't expressed well as a hierarchy (think a graph with cycles -- not uncommon). That's where it breaks down.

I think you can get pretty far with batched REST, but I'd like to see some way to query graphs in an easier way.

I think REST is orthogonal to relational data. (Actual REST, that adheres to HATEOAS and a real REST standard. If one rolls his own JSON services, it's not REST.) HATEOAS puts no constraint on how your data is shaped. A specific implementation of REST may or may not have a nice way to navigate graphs.

[0] http://restcookbook.com/Basics/hateoas/

RESTful Web APIs (2013)[1] is a very, very good book about this stuff. The book has a mailing list with some good discussion about this stuff [2].

[1] http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp... [2] https://groups.google.com/forum/?fromgroups=#!searchin/colle...

I'm still exploring this stuff myself so maybe I am wrong or misunderstanding you.

How is REST problematic for cyclic graphs? I mean the Web is a graph with many cycles and the Web is the defining instance of a REST application. HATEOAS, a pillar of REST, seems, among other things, to be particularly apt for dealing with arbitrary graphs.

Perhaps they meant an ORM instead of crud.

> CRUD is even kind of an anti-pattern, because it prevents you from doing relations in your relational database.

I'm not sure I get this. How are the two things connected? i.e. why can't CRUD honour relations? (Django's admin does auto-CRUD and handles relationships moderately well - at least to one level of nesting)

Backbone requests return jQuery promises, so you aren't required to use traditional callbacks, but that may be a pedantic distinction. It is also incredibly easy to run all model change events to a global event publisher if that's how you want to bind your logic.

I'm in favor of using whatever framework fits your application the best. I would probably choose Angular if I envisioned hundreds of callbacks in Backbone.

Or just don't use callbacks and observe the model attributes for changes...