4 ms·
I never understood the "knockout vs backbone" mentality. Knockout binds your UI model to display elements, and backbone binds your server model to your display
by kogir 15y ago
I never understood the "knockout vs backbone" mentality. Knockout binds your UI model to display elements, and backbone binds your server model to your display model.
It can absolutely make sense to have two models for two very different interactions with the same data - UI and REST server calls. Anyone who's written a substantial Silverlight or WPF app already has done this.
Or am I totally crazy? I intend to use both in my latest project, and I'll see how it goes.
- wahnfrieden 15y agoJust a nitpick, Backbone uses RPC, not REST. URLs are essentially hardcoded in the client - Backbone constructs URLs like e.g. "/collection[/id]" which is totally RPC. Which is not a bad thing, it's just not REST.
- catch23 15y agomaybe it's not REST's ivory tower definition, but it is most definitely REST style urls the way that everyone else interprets REST. Also, you construct your own urls in backbone, so it's technically adaptable to whatever, but in Backbone.sync, it does the usual REST verbs to http actions.
- wahnfrieden 15y agoYep, that's just good HTTP usage. REST doesn't care what your URLs look like, as long as it is not the client which constructs them. It helps to use terms more precisely. I don't care if Backbone isn't REST.