I'm a little bit further on that point and I think you should slow down a bit. (All that follows is my humble opinion, apply grain of salt and critique as need

I'm a little bit further on that point and I think you should slow down a bit. (All that follows is my humble opinion, apply grain of salt and critique as needed) Writing a framework for the first time is hard. You said you don't really know what happens server-side and this may get in your way. A framework is often designed to address specific problems/needs in a specific context. These problems/needs don't have to be shared by anyone else, it could just be you thinking "It's hard to build RESTful urls, I should build something to do it for me" and have a CLI util or a script handler that would register them for you in your app server. And some can be everyday problems: "F*ckin' databases, how do they work?"[1]. However, you need to know these problems to address them. Which is a part of my long-term feud with frameworks: "If you always use a framework, you will never have (too much) problems and will never learn how to solve them" (writing my own active-record-like ORM for node.js is a lot of fun actually). Which is why my advice to you is: Don't write a framework. Instead, write an app, get stuck a lot of times and find a way. Identify your problems. Then write a different app. This time, look at what you are doing the same way, what problems you are solving another way and what you'd like your framework to automate. There, for this second app, you can start writing your framework because you'll have a better idea of what you need to address. You don't really need to make a framework that caters to everyone's needs, but one that caters to your needs and expand from there. Next (optional) step is rewriting the first app with the second app's framework and iterate new functionalities. 1: http://www.youtube.com/watch?v=_-agl0pOQfs http://www.youtube.com/watch?v=_-agl0pOQfs