3 ms·

Here is a new MVC framework looking to displace backbone and knockout: http://derbyjs.com/ http://derbyjs.com/ "Many developers now include a client MVC frame

Here is a new MVC framework looking to displace backbone and knockout: http://derbyjs.com/ http://derbyjs.com/ "Many developers now include a client MVC framework like Backbone to better structure client code. A few have started to use declarative model-view binding libraries, such as Knockout and Angular, to reduce boilerplate DOM manipulation and event bindings. These are great concepts, and adding some structure certainly improves client code. However, they still lead to duplicating rendering code and manually synchronizing changes in increasingly complex server and client code bases. Not only that, each of these components must be manually wired together and packaged for the client."

nateps 15y ago
Hey, I am one of the authors of Derby. Knockout and Backbone are pretty different, and they both have good aspects. Knockout's strength is its powerful view-model bindings, and Backbone is targeted at providing an MVC structure. However, neither of these libraries claim to be a complete solution. If you want a more full-featured client framework similar to these, SproutCore is one of the better ones right now. The reason we started working on Derby, is that none of these frameworks offer a full-stack solution. Backbone and SproutCore will provide better structure and some automation of client-server data syncing. However, they still require manually creating appropriate server routes that handle AJAX requests and communicate with a database. They may provide client-side routing, but these routes are totally different from the server routes, so if you want to use the same URLs, you have to duplicate routing code. SproutCore uses Handlebars, so you might be able to render the same templates on the server for faster page rendering, and non-JavaScript browser or search engine crawler accessibility. However, this will require writing a bunch of custom server code to pull out the right data and render the templates. In addition, none of these frameworks provide tools to deal with data conflicts. Conflicts are inevitable in a multiple users realtime application, especially when supporting offline. Derby's focus is to unify as much code between server and client and to provide automatic realtime syncing among all models and views. This approach requires less code, delivers faster load times, provides instant client-side rendering from full pages to individual data bindings, and supports offline by default. It's a work in progress, but let us know what you think about it so far.
- edmellum 15y ago
  I've taken a look at Derby, but I still can't piece together how you're supposed to do queries and the like. Like if I need a list of 25 items of a type or check if the current user has the right permission to edit something.
  - nateps 15y ago
    We plan to support reactive functions, more complex queries, and authorization, but such features are not implemented yet.

nateps 15y ago

Hey, I am one of the authors of Derby. Knockout and Backbone are pretty different, and they both have good aspects. Knockout's strength is its powerful view-model bindings, and Backbone is targeted at providing an MVC structure. However, neither of these libraries claim to be a complete solution. If you want a more full-featured client framework similar to these, SproutCore is one of the better ones right now. The reason we started working on Derby, is that none of these frameworks offer a full-stack solution. Backbone and SproutCore will provide better structure and some automation of client-server data syncing. However, they still require manually creating appropriate server routes that handle AJAX requests and communicate with a database. They may provide client-side routing, but these routes are totally different from the server routes, so if you want to use the same URLs, you have to duplicate routing code. SproutCore uses Handlebars, so you might be able to render the same templates on the server for faster page rendering, and non-JavaScript browser or search engine crawler accessibility. However, this will require writing a bunch of custom server code to pull out the right data and render the templates. In addition, none of these frameworks provide tools to deal with data conflicts. Conflicts are inevitable in a multiple users realtime application, especially when supporting offline. Derby's focus is to unify as much code between server and client and to provide automatic realtime syncing among all models and views. This approach requires less code, delivers faster load times, provides instant client-side rendering from full pages to individual data bindings, and supports offline by default. It's a work in progress, but let us know what you think about it so far.

edmellum 15y ago
I've taken a look at Derby, but I still can't piece together how you're supposed to do queries and the like. Like if I need a list of 25 items of a type or check if the current user has the right permission to edit something.
- nateps 15y ago
  We plan to support reactive functions, more complex queries, and authorization, but such features are not implemented yet.