4 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. If you build it the wrong way

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. If you build it the wrong way then it would look like an interwoven mashup of code that you would have no remembrance of if you came back to it after a period of inactivity. If you are not confident you can do the former _in a production environment that isn't just a side project_ then I would argue that you shouldn't until you can.

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 ago
  I 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?
helldritch 6y ago
This has been my experience: In creating a Framework which follows the general principles of a Symfony application (since we're all familiar with Symfony) we've ended up with interfaces that closely mirror what we're used to in Symfony. The end result has its own pros and cons: * We don't get the brute-force security you get when millions of websites are running the same framework * Our implementation is much faster (and there are many fewer memory leaks, as that was a core concern), as it only has the features we actually need. * Without middleware layers for cross compatibility there are fewer abstractions, this allows the entire framework and application to be reasoned about with a lot less magic obfuscating the code which is actually running. * If something is slow, it isn't an opaque problem of "symfony being slow", it's "@helldritch can you take a look at \App\Framework\DB\Query\JoinHydrationStrategy on line 112? If you unset the fields you no longer need, the hydration runs in linear time - much quicker when joining collections of Users against the Groups they're in)" <-- an actual message from our Discord. * Each feature takes a little bit longer to develop (as the Framework needs the implementation before the application can use it)
unclebucknasty 6y ago
>if you built your own framework the right way you would end up looking a lot like... an existing framework That's true only if you're looking at it through the lens of the current paradigm; for instance, assuming that you need "typical" routing, HTML templates, reactivity, etc. But, these each represent just one way to solve the problems they address. So, "the right way" here is kind of self-referential and assumes there's no better paradigm to be found. The current crop of frameworks are conceptually all very similar and represent just one more iteration. We'll move on to a completely new paradigm at some point.

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 ago
I 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?

helldritch 6y ago

This has been my experience: In creating a Framework which follows the general principles of a Symfony application (since we're all familiar with Symfony) we've ended up with interfaces that closely mirror what we're used to in Symfony. The end result has its own pros and cons: * We don't get the brute-force security you get when millions of websites are running the same framework * Our implementation is much faster (and there are many fewer memory leaks, as that was a core concern), as it only has the features we actually need. * Without middleware layers for cross compatibility there are fewer abstractions, this allows the entire framework and application to be reasoned about with a lot less magic obfuscating the code which is actually running. * If something is slow, it isn't an opaque problem of "symfony being slow", it's "@helldritch can you take a look at \App\Framework\DB\Query\JoinHydrationStrategy on line 112? If you unset the fields you no longer need, the hydration runs in linear time - much quicker when joining collections of Users against the Groups they're in)" <-- an actual message from our Discord. * Each feature takes a little bit longer to develop (as the Framework needs the implementation before the application can use it)

unclebucknasty 6y ago

>if you built your own framework the right way you would end up looking a lot like... an existing framework That's true only if you're looking at it through the lens of the current paradigm; for instance, assuming that you need "typical" routing, HTML templates, reactivity, etc. But, these each represent just one way to solve the problems they address. So, "the right way" here is kind of self-referential and assumes there's no better paradigm to be found. The current crop of frameworks are conceptually all very similar and represent just one more iteration. We'll move on to a completely new paradigm at some point.