4 ms·

> between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstra

> between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstractions, you'd have a hard time trying to justify wasting time rolling your own when others already did all that work. That's only true when all the abstractions you need have already been implemented by others. Most of the time though, in addition to off-the-shelf abstractions, you need to build new abstractions which are specific to the business problem at hand; and shoehorning those abstractions on top of an existing framework which was not created with them in mind may be more work and may provide a less robust, way more complex solution.

woojoo666 4y ago
It's really just a cost-benefit analysis of whether it's worth it to build your own solution or build on top of somebody else's. I think a few years of experience gives everybody an idea of the general tradeoffs of each approach, some people will just tend to lean one way while others lean the other way
arinlen 4y ago
> That's only true when all the abstractions you need have already been implemented by others. Not really. More often than not, any framework already ships with far more features than the ones you'll be using, with the added benefit of already being production-ready and extensively tested not only by the maintainers but also by everyone else already using it. When you roll your own... Well, good luck. > Most of the time though, in addition to off-the-shelf abstractions, you need to build new abstractions which are specific to the business problem at hand (...) You're confusing implementing higher-level abstractions which allow the low-level details to be ignored with actually implementing your own business logic.
- ratww 4y ago
  > You're confusing implementing higher-level abstractions which allow the low-level details to be ignored with actually implementing your own business logic. The grandparent definitely isn't, and that's a bit of an uncharitable interpretation. I'm sure there must be a tiny minority of developers out there that doesn't ever have to write higher-level abstractions, but in the real world, writing both "business logic" and higher-level abstractions is the norm for most jobs. Only toy projects and the most menial development jobs escape that. Even frontend, which someone erroneously claimed above that is "99% isn't custom" really is. The two major libraries, React and Vue, and the rising one, Svelte, really aren't frameworks at all, and require in practice not only a lot of custom stuff but also higher-level abstractions. Again, the exception is toy projects and menial dev jobs.
ryanbrunner 4y ago
Frameworks can be limiting, but I've never seen a framework that doesn't allow you to implement business logic on top of it. At the end of the day frameworks execute code that you write, and you can break out of the concepts your frameworks introduce and do whatever you want. Just because 10% of your codebase is uniquely unsuitable to the 'standard' introduced by the framework doesn't mean that you can't use it for the remaining 90%. And even for that 10%, it's probably not so alien that some of the functionality provided by the framework is still relevant.

woojoo666 4y ago

It's really just a cost-benefit analysis of whether it's worth it to build your own solution or build on top of somebody else's. I think a few years of experience gives everybody an idea of the general tradeoffs of each approach, some people will just tend to lean one way while others lean the other way

arinlen 4y ago

> That's only true when all the abstractions you need have already been implemented by others. Not really. More often than not, any framework already ships with far more features than the ones you'll be using, with the added benefit of already being production-ready and extensively tested not only by the maintainers but also by everyone else already using it. When you roll your own... Well, good luck. > Most of the time though, in addition to off-the-shelf abstractions, you need to build new abstractions which are specific to the business problem at hand (...) You're confusing implementing higher-level abstractions which allow the low-level details to be ignored with actually implementing your own business logic.

ratww 4y ago
> You're confusing implementing higher-level abstractions which allow the low-level details to be ignored with actually implementing your own business logic. The grandparent definitely isn't, and that's a bit of an uncharitable interpretation. I'm sure there must be a tiny minority of developers out there that doesn't ever have to write higher-level abstractions, but in the real world, writing both "business logic" and higher-level abstractions is the norm for most jobs. Only toy projects and the most menial development jobs escape that. Even frontend, which someone erroneously claimed above that is "99% isn't custom" really is. The two major libraries, React and Vue, and the rising one, Svelte, really aren't frameworks at all, and require in practice not only a lot of custom stuff but also higher-level abstractions. Again, the exception is toy projects and menial dev jobs.

ryanbrunner 4y ago

Frameworks can be limiting, but I've never seen a framework that doesn't allow you to implement business logic on top of it. At the end of the day frameworks execute code that you write, and you can break out of the concepts your frameworks introduce and do whatever you want. Just because 10% of your codebase is uniquely unsuitable to the 'standard' introduced by the framework doesn't mean that you can't use it for the remaining 90%. And even for that 10%, it's probably not so alien that some of the functionality provided by the framework is still relevant.