> I feel like when you don't use a framework, you actually end up creating your own framework. It's kind of a reusability fallacy: you have needs, and you impl

> I feel like when you don't use a framework, you actually end up creating your own framework. It's kind of a reusability fallacy: you have needs, and you implement (or glue together off the shelf small independent blocks) that solve those needs. Of course: you a) structure your code and b) a framework implements similar blocks. So of course a) resembles b) because it solves largely similar problems, especially in the www/HTTP world. But what doing a) solves that b) can't is that b) is a dependency, and often a big one. The bigger, the higher the chance of a systemic impedance mismatch. And sometimes (more often than we think) the impedance mismatch is too much to bear, and even changes over time as the framework updates, causing cascading costs (including people getting up to speed with the new version). It's all the more frustrating when the impedance mismatch is caused by structural decisions (which are not wrong in themselves!) on technical or functional parts of the framework you're -not- using. More generally, there's a big myth about reusability in software, which seems to work in an ideal theoretical world, but in practice isn't a fit for everything because reality is messy. There's this big placating warning and shaming over NIH and 2SS, but these should not be dogma. What I found to be consistently true though, is that simple code produces the best results, both in TTM and saving-my-future-ass-some-bloody-time-and-blood-pressure. But simple is also the hardest. Sometimes it's spinning up over a framework because it's a good fit, sometimes it's skipping or dropping the framework because it's too impacting. Both are OK, and sometimes both are even OK at the same time because overall it's a multivariate trade off.