Can we please stop with the framework approach? Node.js has what is probably the best package management system out there. Frameworks are really only necessary when you have crappy package management or specific problems. NPM makes is so easy to use libraries liberally and that's what people should be doing.
With frameworks, the framework calls your code.
With libraries, your code calls the libraries.
If you've never taken the libraries approach and are working with a framework, then you are essentially holding a hammer and looking at all problems as nails.
What I'd prefer to hear about is a discussion of Racer, the synchronization library used in Derby.
Actually, we are big fans of modular libraries. We know that a lot of the code in Derby and Racer is too monolithic, and we intend to restructure as the projects mature. For example, we already refactored out Derby's simple HTML parser (https://github.com/codeparty/html) and our wrapper around Express for routing on the client and server (https://github.com/codeparty/tracks). These are now indendent npm modules that were originally part of the Derby codebase. Also, as you mentioned, the Racer data-syncing and model library can be used separately from Derby.
Derby is an npm module, and developers are in control of their own standard Node.js/Express server files. We use Browserify (https://github.com/substack/node-browserify) to bundle up scripts, so you can use any standard npm module on both the server and the client without modification.
We have a long way to go in terms of customizing Derby; however, it is already very flexible in some ways. For example, Derby apps can be rendered and sent to the client from Express routes or via Derby app routes. There's also a method to simply get a blob of rendered HTML or render a static page using the same templates. Derby includes model-view bindings, but it's simple to bind some things and not others or nothing at all.
Much of Derby and Racer is very different from how web apps are written today, and we are focused on iterating quickly to start. As it matures, Derby will become more of a collection of independent modules. That way, most developers could use Derby out of the box, but others could fork the project and customize or use features of the framework independently. It's a ways off, but that's the long term goal.
This is a false dichotomy. Code calls code calls code; frameworks are libraries are frameworks. The only difference is when a library gets big and complicated enough, we call it a framework.
By your silly standard, passing a function to _.each() makes Underscore.js a "framework", which is probably not the point you were trying to make.
It isn't a false dichotomy. Inside of vs on-top-of. Or, you can say that framework code is lower in the stack frames. Or, you can say that you must make your code comply with the framework's execution model. Or, you could say that the framework supplies the organization and you provide the customization.
From this perspective, underscore.js presents an Enumeration framework. However, it is usually a couple stack frames deep and still way at the leafs of your code paths. Backbone.js is clearly a framework -- it describes your data model plumbing and interactions and provides the bindings and pipelines -- this structure dominates the organization of your code and program flow. Nothing about underscore's utility functions have this "infectious" or "dominating" characteristic.
I don't have a strict definition for library and framework, but I think the distinction comes down to more than just size.
A framework is indeed "just a library," but when one is using a framework one is building on that framework, using that structure to construct some new thing. A library I see as something that is called into for some routine, it's a body of functionalities one can tap into. Your code is-a instance of your chosen framework, and it has-a series of calls out to libraries.
"No one agrees on frameworks. It's difficult to get consensus on how much or how little a framework should do. Flatiron's approach is to package simple to use yet full featured components and let developers subtract or add what they want"http://flatironjs.org/ , Philosophy
I agree that the best thing about Node.js is how small, what tiny surface most modules have. Node, hopefully, can stay on this path so far away from the rest of the development world, can be a programming environment where people understand full stack how their application functions. I think not making frameworks or making them out of small modular systems is what it takes to make that win.
The problem was that the HTML-plus-JavaScript paradigm was never meant for building applications. Sure, you don't need a framework if you're just sprucing up some web pages, but if you want to build a desktop-like app in the browser [1], it's nice to get a leg up from something that understands that sometimes we need the humble web page to be something more.
Don't get me wrong--there's plenty of ways for frameworks to get this wrong, but the overall idea is not inherently useless.
[1]: And why would you want to do that? Because desktop apps never evolved some killer features of the web app: lightweight, cross-platform, zero-install, a passable remoting API, and sandboxing.
With frameworks, the framework calls your code. With libraries, your code calls the libraries.
If you've never taken the libraries approach and are working with a framework, then you are essentially holding a hammer and looking at all problems as nails.
What I'd prefer to hear about is a discussion of Racer, the synchronization library used in Derby.