2y ago

Here are 20 reasons why frameworks make us lousy programmers

Chat Rooms and Programming Content | Chat-to.dev

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:

27 comments

I much prefer to have all my framework tools half-implemented with no searchable documentation by a guy who quit 6 months ago .
- So say we all.
Article title: Here are 20 reasons why frameworks make us lousy programmers
Article body: Frameworks don't make us lousy programmers
- It's very annoying that if an article title seems interesting, that it's a bait-and-switch/clickbait.
  I honestly don't click the ones that seem too amazing.
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.
- So you prefer to re-invent many wheels?
  
  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:
  https://tonsky.me/blog/disenchantment/
  https://idlewords.com/talks/website_obesity.htm
  
  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.
  
  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.
  
  Yeah sure, better than pulling 1000Gb of node_modules..
- 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.
developing frameworks, on the other hand...
- Because that's the alternative, anyways. People love to pretend that's not going to happen, but of course we all do that. Nothing as cool as building your own little meat framework.
  Of course, by the time you leave, it's an undocumented nightmare that has 15+ calls for every single functionality, is so abstracted it'd make my Math professor blush and has more security holes (that no one even has a reporting mechanism for) than all the frameworks you could end up using together.
  (Still love writing my own stuff! 😅)
  
  I use it as a learning tool. When I was making my own framework it forced me to learn all the intricacies of the thing I was making the framework off. TBH it never saw any use in a project but the process of making it is a huge learning experience for me.
- As someone who wanted to use an engine, I tinkered with a framework for a bit and immediately found myself in the beginnings of creating a framework for said framework.
  And they almost got away with this obvious scam, but unluckily for them I didn't want to do stuff like that. They might've pulled it off if the particular thing I wanted was more straightforward.
frameworks are powerful tools that can accelerate development, promote best practices, and facilitate code maintenance.
Citation needed.
IMO most "flashy" frameworks betray the principle of high cohesion. Importing a time library to handle timezones is a great idea. Importing a math library to calculate derivatives is common sense for good reason. But huge frameworks that change the entire way a language is written are ridiculous. I'm looking at you, Vue and Tailwind. I usually see these sorts of frameworks used by people who aren't qualified programmers and who don't know software architectures or best practices. In other words, the kinds of people who get promoted to management positions and tell us what frameworks to use.
(Typescript is awesome though)
This feels like something that was written by an AI, except for the last sentence.
lousy and lazy
Haven’t read the article, but it feels to me the obvious dimension here for the future is the effect of AI assistance, which may come to, if it hasn’t already, encroach on providing the same broad utility that frameworks do and so in turn emphasise the value of knowing more about internals or fundamentals.

27 comments