6 ms·

> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That is only "technically

> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That is only "technically" true, in the way that if you develop any kind of sufficiently complex program then you will have, by necessity, built something which could be called a framework. Realistically, though, your point is invalid and misses the mark. To say that programmers shouldn't write pure code without an existing framework is akin to saying that a house builder shouldn't use bricks and lumber to build a house; they should buy a pre-fab kit instead. Which is, of course, nonsense unless you want the shittiest quality most generic house possible.

arinlen 4y ago
> To say that programmers shouldn't write pure code without an existing framework (...) That's not what's been argued. The overall thesis is that developers end up using higher-level abstractions, and 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.
- TuringTest 4y ago
  > 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.
jseban 4y ago
> then you will have, by necessity, built something which could be called a framework. What they call "building your own framework" is simply what I think of as programming. You design a program, it will have a structure. Why is that "forbidden" and something that programmers are thought of as unable to do?
- codedokode 4y ago
  Because if you move from one project to another you want to see a familiar implementation of Request class or ORM from a framework rather than reverse engineer custom-built undocumented untested replacement for this. It may make sense if custom framework is a magintude order better, but if it is the same as a standard framework or worse then it is not worth to spend time on it.
- codedokode 4y ago
  > What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is going to make all bricks and nails himself. You don't usually write your own standard library, why would you write your own framework?
  - jseban 4y ago
    Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.
    - delusional 4y ago
      The analogy is now officially making the argument less clear
      - deleted 4y ago
        [deleted]
xmprt 4y ago
The house building analogy is pretty good and I think that frameworks are pretty close to how house building works right now. Pre-fab is like using cookie cutter components and throwing them together into a website using something like Wordpress or Squarespace. On the other hand, frameworks are like using common tools, foundations, scaffolding, and (literally) frameworks to build a custom architectured house. Of course, building your own home is possible but that could be a shack made up of sticks and mud or a stack of bricks and mortar with no base/foundation which can fall apart at any moment.
- jseban 4y ago
  > On the other hand, frameworks are like using common tools, foundations, scaffolding, and (literally) frameworks to build a custom architectured house. This is exactly the problem, you are trying to use a standardised blurprint, to build a custom architectured house. Where you should probably make a choice here, either go standard or custom. > Of course, building your own home is possible but that could be a shack made up of sticks and mud or a stack of bricks and mortar with no base/foundation which can fall apart at any moment. Why would a highly skilled builder build a shack of sticks and mud, or a house without foundation? Why do we assume that every software developer is an incompetent clown?
rightbyte 4y ago
I agree with your point but the analogy fails in that prefab house elements does not add complexity in the way software frameworks do which is the main problem in my opinion.

arinlen 4y ago

> To say that programmers shouldn't write pure code without an existing framework (...) That's not what's been argued. The overall thesis is that developers end up using higher-level abstractions, and 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.

TuringTest 4y ago
> 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.

jseban 4y ago

> then you will have, by necessity, built something which could be called a framework. What they call "building your own framework" is simply what I think of as programming. You design a program, it will have a structure. Why is that "forbidden" and something that programmers are thought of as unable to do?

codedokode 4y ago
Because if you move from one project to another you want to see a familiar implementation of Request class or ORM from a framework rather than reverse engineer custom-built undocumented untested replacement for this. It may make sense if custom framework is a magintude order better, but if it is the same as a standard framework or worse then it is not worth to spend time on it.
codedokode 4y ago
> What they call "building your own framework" is simply what I think of as programming. If you want an analogy, this is like a builder claiming that he is going to make all bricks and nails himself. You don't usually write your own standard library, why would you write your own framework?
- jseban 4y ago
  Except it's not like that, software is not standardised, it's custom made. And software engineers already have their toolset. The real analogy would be telling all the builders that they now have to use those shitty multi tools that are 10 screwdrivers and a hammer all in one.
  - delusional 4y ago
    The analogy is now officially making the argument less clear
    - deleted 4y ago
      [deleted]

xmprt 4y ago

The house building analogy is pretty good and I think that frameworks are pretty close to how house building works right now. Pre-fab is like using cookie cutter components and throwing them together into a website using something like Wordpress or Squarespace. On the other hand, frameworks are like using common tools, foundations, scaffolding, and (literally) frameworks to build a custom architectured house. Of course, building your own home is possible but that could be a shack made up of sticks and mud or a stack of bricks and mortar with no base/foundation which can fall apart at any moment.

jseban 4y ago
> On the other hand, frameworks are like using common tools, foundations, scaffolding, and (literally) frameworks to build a custom architectured house. This is exactly the problem, you are trying to use a standardised blurprint, to build a custom architectured house. Where you should probably make a choice here, either go standard or custom. > Of course, building your own home is possible but that could be a shack made up of sticks and mud or a stack of bricks and mortar with no base/foundation which can fall apart at any moment. Why would a highly skilled builder build a shack of sticks and mud, or a house without foundation? Why do we assume that every software developer is an incompetent clown?

rightbyte 4y ago

I agree with your point but the analogy fails in that prefab house elements does not add complexity in the way software frameworks do which is the main problem in my opinion.