It is not accurate to claim that frameworks automatically make programmers bad. In fact, frameworks are powerful tools that can accelerate development, promote best practices, and facilitate code maintenance. However, it can be argued that overly relying on frameworks without understanding the underlying principles of programming may have some negative effects. Here are some reasons why this might happen:

  • TootSweet@lemmy.world
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    5
    ·
    10 months ago

    I work for the man with a team of other developers. But for my side projects, I avoid dependencies like the plague. Dependencies always come with costs.

      • TootSweet@lemmy.world
        link
        fedilink
        English
        arrow-up
        15
        arrow-down
        6
        ·
        edit-2
        10 months ago

        Depends on the wheel.

        I mostly work in Go when I have a choice, and it’s got a lot in the standard library. (The Go standard library doesn’t count as a dependency… or at least not an optional one.) When I write web (as in JS-in-the-browser) stuff, I don’t use any JS dependencies aside from browser built-ins.

        Also, I don’t mean to imply I don’t use dependencies at all. But having dependencies that aren’t pretty much absolutely necessary is the kind of thing that ought to make one hate oneself a little more. Just a little self-flagellation for each dependency can’t hurt either. (Just to be clear, I don’t mean this literally.)

        As an example, not long ago, I wrote a web-based virtual tabletop application (the kind of software you’d use to play Dungeons and Dragons remotely) in Go. Aside from the Go standard library, it’s got exactly three Go dependencies: a Sqlite3 driver, a library for minifying HTML/CSS/JS, and a transitive dependency of the minifier for parsing HTML/CSS/JS. The JS has zero dependencies other than browser built-ins.

        The “wheels” I could arguably be said to have “reinvented” just off the top of my head:

        • Go:
          • Facilities for building static assets into the compiled binary.
            • And serving those static assets, but that’s kindof one thing with the building into the compiled binary thing.
          • Authentication.
          • HTTP session management.
          • Server-side in-application message bus.
        • JS/Web:
          • JS dependency management. (Something like RequireJS.)
          • Client-side templating. (Something like Handlebars.)
          • Running code on document ready/loaded.
        • Somewhere In Between:
          • CSRF protection.
          • Server push (using SSE).

        Now, I could pull in Handlebar and RequireJS and React and jQuery and Underscore and Gorilla and have a build system that depends on NPM and Bower and maybe has a Makefile to coordinate it all. But I really don’t see the benefit. Especially compared to the drawbacks.

        And by not pulling in libraries for these features I’m saving:

        • Performance.
          • Client-side JS is smaller.
          • The browser isn’t bogged down.
          • Quicker compile times.
          • The back end is more responsive.
        • Less cognitive load and fewer moving parts.
        • I know much better how these features work.
          • With FOSS dependencies, I could also know how things work, but honestly it’s probably faster to write it myself than look through the source code of a framework.
        • Less hard-to-track-down bugs.

        More reading relevant to avoiding dependencies and frameworks:

        • MrMcGasion@lemmy.world
          link
          fedilink
          arrow-up
          15
          arrow-down
          1
          ·
          10 months ago

          I’d even go further and say that if you are using a “high level” language that requires you to re-invent the wheel for simple things (for example JS not having built in functions to shuffle an array or, clamp an number to a range) are indications of poor language design that have lead to the prevalence of all the bloated JS frameworks like jQuery. Obviously I don’t think every language should have a Python-tier standard library, but I’d really like to not have to download half a language from every site I visit because every site uses jQuery for a lot of things that come standard in better languages.

        • anti-idpol action@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          edit-2
          10 months ago

          Second what you’ve written regarding Go framework providing what you need for a lot of things. Recently I’ve managed to reduce a binary size of my app by over 6 MB (16%) and make the thumbnailer it uses over 50% faster by removing dependency on a library that utilized ffmpeg bindings, because it was bloated with AWS SDK dependency and just using the standard library.

      • Jackinopolis@sh.itjust.works
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        10 months ago

        Depends on the project. If it’s for fun, sure make all the square wheels you want and learn how to make them round. But if you just want your project to work you’d find something to use. Really depends on the developers goals.

      • MrScottyTay@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        3
        ·
        10 months ago

        I would say it’s less reinventing and more recreating. Also if you want a red wheel but all of the ones available to you come in shades of blue, then if you make your own you can make sure it’s red.

      • Kool_Newt@lemm.ee
        link
        fedilink
        English
        arrow-up
        3
        ·
        10 months ago

        Sometimes that’s better than having to learn other people’s interpretations of the same wheel over and over again.

    • Carighan Maconar@lemmy.world
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      10 months ago

      Yeah, costs such as having to write the actual business logic during office hours instead of building a framework but not even making it available.