First off, you can't just take the label "framework" and slap it on any arbitrary piece of code which works together for one or more tasks. By that logic, every

First off, you can't just take the label "framework" and slap it on any arbitrary piece of code which works together for one or more tasks. By that logic, every site and app ever written is its own framework. But... > You know what I did? I wrote a framework for that site, and I called it “the site”. The key differences between my "framework" and these popular frameworks: 1. I'm not holding out my "framework" for that specific site as some general reusable "best practice" for every other site on the planet. 2. It's highly customized, and customizable, to the specific site. When I don't like how events interact with views, I don't need to worry about forking some general framework project (and creating upstream update nightmares) and hacking into the guts of it to change the assumptions it makes. My "framework" is much thinner of abstraction, and far less convoluted. Not because my "framework" is better. Just because my "framework" is specific to the task.