...again, the FUD that if you go framework-less, you're automatically re-inventing the wheel. Total B.S.

You're not reinventing the wheel but you are essential inventing your own framework.

So there are only 3 possible choices:

1. reinvent the wheel 2. use a framework 3. write your own framework.

This 'light glue code to bind together my libraries' thing someone mentioned. That. That IS a frikkin' framework! And it sounds clunky as hell.

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.