4 ms·

> 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 wit

> 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.