6 ms·
> but I’m really fond of the less restrictive nature of Backbone, so I’ll probably end up sticking with Backbone. Backbone is terribly devious in that it trick
by dustingetz 13y ago
> but I’m really fond of the less restrictive nature of Backbone, so I’ll probably end up sticking with Backbone.
Backbone is terribly devious in that it tricks you into thinking that it is unrestrictive and unopinionated. Backbone manages state with mutable models and model change callbacks, so Backbone's opinion naturally is that models and change callbacks are a good way to organize your application. "I want to write hundreds of callbacks to keep everything in sync" said no UI developer ever.
- 204NoContent 13y agoI'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.
- akoumjian 13y agoBackbone 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.
- kevincennis 13y agoThat'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.
- rybosome 13y agoIf 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.
- nateabele 13y ago> "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).
- kevincennis 13y agoMy fault. I guess I misunderstood the point being made.
- coderzach 13y agoOr 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.
- colemorrison 13y agoHuh? 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.
- gumballhead 13y agoYes. 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.
- andybak 13y ago> 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)
- dragonwriter 13y ago> 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.
- solomone 13y agoPerhaps they meant an ORM instead of crud.
- peterhunt 13y agoI think REST is more accurate, and REST does a shitty job of efficiently expressing relational data.
- modarts 13y agoI know React is backend agnostic, but out of curiosity, what does your ideal server API architecture look like if not RESTful?
- dclowd9901 13y agoThe 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.
- PhrosTT 13y agoOr just don't use callbacks and observe the model attributes for changes...