3 ms·
> I would tend to think if you built your own framework the right way you would end up looking a lot like... an existing framework. Nope, existing frameworks a
by BigJono 6y ago
> I would tend to think if you built your own framework the right way you would end up looking a lot like... an existing framework.
Nope, existing frameworks are designed to solve the problems in 100,000 different applications across every domain known to man. Your "framework" (which if you're doing it right is probably more like a set of patterns and a carefully selected set of libraries that do one thing well) solves your own problems, and only your own problems.
If something tailor made to solve your use case specifically looks exactly the same as something like Django, then you're either Google or you've overengineered it.
- methodin 6y agoI don't necessarily agree with the sentiment as a whole as there's pretty consistent design patterns for things like routing, http requests and responses and user roles and permissions across many languages and frameworks both large and small. Your point holds when you start digging into more niche things (like form handling) but even if using frameworks you don't have to do any of that stuff if you choose not to - it's there if and when you need it. Things normalize because access patterns dictate that. Bucking that trend because your app doesn't need that _yet_ is a slippery slope that leads to exponential increase in time as your app gets more complicated since your framework lacks core features that you have to go back and build and risk breaking other things you've already built. If you abstracted that away to avoid that then you are already thinking like a framework, so what's the point?