Web dev - How do you know when you overabstract and over encapsulate?

  • 🇵🇦 Nuestro primer dominio localizado está en español en kiwifarms.pa. Our first localized domain is on Spanish on kiwifarms.pa.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Destacado
U

Unknowing

Banned
kiwifarms.net
Registrado
11 de Mar, 2025
i would write about this on Reddit, but I hate it, and other sites I'm uncomfortable with.

Currently doing some code, and I come to find that the temptation of making niggerlicious code to be of the devil.

He be speaking to me when I try to decide whether I should just write the array straight inside or put it in a container.
 
any abstraction that doesn't make your system easier to work with is a bad abstraction
it's really shrimple
 
why are you doing "web dev" as opposed to writing normal hypertext like tim berners-lee intended
and if you're writing an application why are you calling it "web dev"

rule 1 of javascript (and programming in general really): if you can find a decent excuse to not add complexity, you should use it
 
web dev is the fucking worst. every couple of years you have to relearn a whole new paradigm of putting buttons on a webpage. web devs are also incredibly insecure because they know they're frauds deep down so every web dev project somehow takes minutes to build and has all sorts of unit test harnesses and typescript and declarative frameworks and shit like react. like i started with php doing forum shit, then i had a coldfusion phase, then i was doing C# mvc with razor pages, then I went through horrible jquery phase, then a typescript phase, then ruby on rails, then did nodejs with angular/react as the front end, then back to .net core, and then just for the hell of it the last project I did using axom in Rust. (I'm not counting anything I didn't get paid money to do.)

using web software to make a desktop application is inherently disgusting - it's like dressing a man as a woman, it fucks the user the experience. javascript was developed in 2 weeks as a language to let you punch the money and win 20 bucks and for some godforsaken reason everyone keeps using it, it will never be a real programming language. if you're asking yourself questions about "abstraction" you're just pretending to be a real developer (and you are not.)
 
If you compenswoggle without discombobulating first, you're setting yourself up for major overdwanning during every pineswomple that follows. Many rookies make this mistake, trying to cut corners which results in subterfanglantion of every asset and, as a result, complete sqardelifence of the project. Ever hear of The Great Quimpasfarco of 1999? Yeah. That's what cheap mortwarurge does to you.
 
I agree with all the ripping on webdev, but I'll give a serious answer instead.

The maximum levels of abstraction is the same for the maximum levels of inheritance: one, at most. Anything over that and you are over-engineering your design. In fact, you likely don't need the 1 level either. Every serious coder and code shop I know tries to refactor away abstraction, because it always has a cost, and rarely has a concrete benefit.

Encapsulation has the same "guaranteed cost with theoretical benefits" problem. The one useful place for it is edge-of-system integration points, where your system and another one completely outside your control will be talking for years after you've left the project. Basically, if you (or your organization) have control over every place the data travels, encapsulation is unnecessary. Only encapsulate if you have to integrate a 3rd party into your data flow (like an external microservice), when you aren't sure if your system or the external one will change the API.

Unknowing dijo:
whether I should just write the array straight inside or put it in a container
Presiona para expandir...
If that array isn't leaving your webdev setup until you close out the transaction, write it straight.

If your long term data storage guys are the ones making such demands, then call them autistic nerds, pass them the array, and mock their SQL skills. They'll handle it out of spite and save both of you unnecessary work.
 
Harvey Danger dijo:
I agree with all the ripping on webdev, but I'll give a serious answer instead.

The maximum levels of abstraction is the same for the maximum levels of inheritance: one, at most. Anything over that and you are over-engineering your design. In fact, you likely don't need the 1 level either. Every serious coder and code shop I know tries to refactor away abstraction, because it always has a cost, and rarely has a concrete benefit.

Encapsulation has the same "guaranteed cost with theoretical benefits" problem. The one useful place for it is edge-of-system integration points, where your system and another one completely outside your control will be talking for years after you've left the project. Basically, if you (or your organization) have control over every place the data travels, encapsulation is unnecessary. Only encapsulate if you have to integrate a 3rd party into your data flow (like an external microservice), when you aren't sure if your system or the external one will change the API.


If that array isn't leaving your webdev setup until you close out the transaction, write it straight.

If your long term data storage guys are the ones making such demands, then call them autistic nerds, pass them the array, and mock their SQL skills. They'll handle it out of spite and save both of you unnecessary work.
Presiona para expandir...
thank you
 
Destacado
Debes iniciar sesión o registrarte para responder aquí.
Atrás
Top Abajo