I'd like to see a move toward mini-kits instead of frameworks. The problem with frameworks is you are dealing with a dark-grey box. If the components work, eve

I'd like to see a move toward mini-kits instead of frameworks. The problem with frameworks is you are dealing with a dark-grey box. If the components work, everything is great. If they don't, you have to either fiddle a lot to find a work-around, or read and debug thousands of lines of framework code. For example, a "routing engine" to translate URL's into specific function/method calls doesn't have to be rocket science for smaller applications, yet they are rocket science (thousands of lines of code) in many frameworks. Come up with a standard interface for routing engines and let me choose which implementation best matches our org rather than have to use the thousand+ lines of code version. You have a choice: bicycle science, car science, and rocket science versions. A large org or special domain may need the rocket science routing engine, that's fine, but don't force all framework users to use the rocket science one. If I use the bicycle-science router, I can read it and fix or customize it quickly. ORM's, HTML templating engines, field managers (models), can all also be interface-itized this way, and ship with or offer 3 levels: bicycle, car, and rocket. Frameworks should then only be interface managers, not implemented conglomerates of fat "helpers".