this post was submitted on 28 Aug 2024
36 points (100.0% liked)

Technik

299 readers
27 users here now

die Community für alles, was man als Technik beschreiben kann

Beiträge auf Deutsch oder Englisch

founded 4 months ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Waldowal@lemmy.world 23 points 2 months ago* (last edited 2 months ago) (2 children)

I don't like developers getting blamed for what is often due to being rushed to arbitrary deadlines from management. But, I will say I agree with the article in that a large portion of the development toolbox is completely fucked. The last 15 years of most business development has basically been this:

  • Let's implement cool JS frameworks that don't really work with the browser natively!
  • Let's execute browser code on the server and server code on the browser!
  • Let's transpile code to artificially improve upon native languages and make our JS frameworks easier to code. We need a transpilation tool!
  • Let's take "DRY" way too far! Everything we need should already be in existing code packages we can combine together. We need a package manager tool!
  • Uh oh, it's too hard to start projects. We need a scaffolding tool!
  • Uh oh, we now have too many packages. We need a bundling tool!
  • Uh oh, our development environments are now too complicated to setup. We need a virtualization container tool!
  • Uh oh, we have too many virtual machines. We need a container management tool!
  • Uh oh, deployments are super complicated now. We need deployment automation tools!
  • Ok, NOW we're setup to code 20% faster, but we need 3 new DevOps employees to support all this.
  • Oh yea, we're "agile" now too. I think that means we fire our QA testers. I'm not sure. We can't agree on what being "agile" even means.

Not saying it's all bad. Mostly good ideas that have gone off the rails.

[–] Jesus_666@lemmy.world 14 points 2 months ago

Let's also not forget "half of what we're using frameworks for has been directly supported by every browser since 2011 but we still have a dependency on a framework that extends another framework that hard-requires jQuery as a selector engine so we're not going to remove any of them".

It's kind of depressing to ship two megabytes of dependencies for something a hundred lines of vanilla JS would do just fine these days. But of course it's far easier to maintain external code than int– oh wait, one of our dependencies switched a dependency and now security needs to re-evaluate the stack before we can install the latest security-relevant update.

[–] TunaCowboy@lemmy.world 6 points 2 months ago (1 children)
[–] gandalf_der_12te 2 points 2 months ago

reminds me of this:

simple and genius