0001 The Why
As strong as Express is, the openness of the framework doesn't lend itself to a system with a shared system of application components. Take for example, layouts. While there is a good and fine system for layouts in express, layouts traditionally come bundled with static resources(css, js, images, etc.), navigation elements, and other constructs. There is no easy way to package such elements in such a way that they can be easily dropped in and switched out. As strong as it is, it is not conducive to, say, creating a calendar application that can share configurations, layouts, models etc with the larger service.
Similarly, its method of handle composition is to chain one or more functions together. That is fine in some contexts, but in general I find that this technique is a bit constraining as the functions are (from each others' POV) anonymous -- all you know is you can either render now or punt to "next" -- whatever next is. I prefer clear, named stages in my design. and nuby-express reflects this.
Also, while it has got a bad name in some circles, creating scaffold for things like REST services is a big timesaver for larger apps.
Lastly, my personal view of the traditional way MVC applications distribute their resources is that they create vast yawning canyons of files that make jumping around the resources central to a given action or controller very tedious. Almost as bad, controllers tend to become huge sprawling files, the contents of which -- in the context of a single request -- have little to do with each other. From a Repo point of view, continuing to update the same controller is note nearly as illuminating as updating an action file when that specific action is updated.
As impressed as I was by Strata, its impossible to ignore the value and testing that you get from Express, so I have to some extent emulated the CGI pattern within the context of the execute method - an "environment" or request state input, and a callback through which the useful data for a request is put.
It is designed to fulfill the role of Ruby -- that is, to rapidly deploy applications. However, given the tremendous amount of borrowed code and the areas that are simply not addressed by Nüby (yet?) its not really fair to equate the two.
One trait it does share with Ruby (over Express) is that it separates the application logic from the loading and routing logic, at least, where such separation makes sense. While I hope this does not support user ignorance when it comes to the workings of express and requests in general, it should make it somewhat easier to focus peoples' attention where it belongs during the development cycle.
The greatest departure Nüby demonstrates is that there is no convention/ActiveRecord treatment for models. There is just too much diversity in data treatment in the new Node/NoSQL world to make any assumptions as to how data is being stored for any single system of model handling to be relevant. So while I use Mongo/Mongoose for my own uses of Nüby, this is not embedded in the framework. All information that Nüby uses is contained within files or modules or passed through the request/response chain.
While there are a lot of solvers in the action class, I would point out that everything -- even the fundamental "handle" method -- can be overridden when such is necessary for a given task.
The default chain -- handle -> auth -> execute -> render || redirect -- is pretty standard and useful but there should be no lateral effects for creating another execution chain in a given call, or for directly accessing the express response object and taking more full control of the output or request process.
Similarly, the load system at present has two loaders -- default and REST. If you want a whole new loader that doesn't use the stock action as its starting point, feel free.
There are so many different repo systems in use by Node developers that I don't feel it is useful or wise to canonize any one system within Nüby. I personally like mongo/mongoose, but the decision to use it to solve issues in my own work is too individual to bind into the application. I do provide a simple_model class for data that you don't need to remember outside of the runtime -- really, it was just put up for unit testing -- and I do have a mongoose_model class that wraps the mongoose model (and honestly adds little value to it) but none of Nüby's essential working systems are bound to it at this point.
So, hopefully, what is in Nüby is useful to someone other than myself, if for no other purpose than to serve as one example of how you can use Express in a larger context.