Developers Rail Against JavaScript 'Merchants of Complexity' | Hacker News Reader

Developers Rail Against JavaScript 'Merchants of Complexity'

thenewstack.io

I work in the Python ecosystem, and I see the same problems here as in JavaScript. The problem, as I see it, is moving fast and breaking things. I appreciate that it's very fashionable, and that the people making these libraries and frameworks are much cleverer than me and are building these things out of very elegant ideas that I don't understand, but building things on moving foundations is more trouble than it's worth.

More like not invented here syndrome and lack of experience. Puts it pressure off on your resume to create yet another project which gets stars

There’s a simpler solution that allows you to leverage the simplicty of good modern tools without suffocating in dependency hell:

Ban ‘npm install’

It’s nothing more than a party drug.

Just copy/paste any helper code you need into your ‘libs’ folder and be done with it. Your app will still run in 2044.

As I’ve gained more experience I feel like this advice is just “edgy” and no real engineer would willingly pick a solution that might not scale if things pick up. HTML and JQuery starts nice but add enough complexity and tell me you didn’t just hand roll your own framework. Now you’ll need documentation in order to onboard anyone if you are lucky enough to be in a position to expand.

The shiny new framework can create a static site and a true web app and is likely well documented with examples. The tradeoff is a subset of users have longer load times.

Some people are really selling complex solutions around React though, for instance. The lib itself isn't that complicated, but there are JEE levels of frameworks built on top of React now and the people selling that can't even fathom the irony in all this...

It's almost easier to learn JEE and Glassfish than stuff such as Next.js...

While not a wrong response in itself, the onboarding cost argument tend to be a bit exaggerated most of the time, because unless you plan on hiring people for a week at most, you're usually better served by avoiding sources of complexity.

The argument is to avoid going all-in on Redux by default if you're doing a React project, not telling you to hand-roll your own Redux.

If you're doing a mostly-static site with a few bells and whistles, then HTML and plain old JS will probably do.

>but add enough complexity...

I don't know that we spend enough time questioning whether that complexity is necessary.

Because, yes, if we want to transmogrify Web standards largely intended for a static document model into a full-blown application platform then there will definitely be complexity involved. Especially true if we do so while keeping those Web idioms fully surfaced.

But, how often do we really need SPAs versus traditonal Web apps that feature judicious use of dynamic behavior? I doubt that the complexity chasm is frequently worth it.

But, if it is, then we need to commit to standards/frameworks that push down the complexity by abstracting away the underlying Web idioms that create it.

> “The merchants of complexity will try to convince you that you can’t do anything yourself these days,” wrote David Heinemeier Hansson (DHH), the creator of Ruby on Rails. “You can’t do auth, you can’t do scale, you can’t run a database, you can’t connect a computer to the internet. You’re a helpless peon who should just buy their wares. No. Reject.”

Such a beautiful quote, and really describe well my experience. For the past few months I've been in a team that keeps trying to pull dependencies and library of components for the simplest of things, and trying to argue my point kinda in vain, to the point that I'm starting to get cranky and rant-y about the subject[1].

Need a header on top of our application? Let's use a Angular Material component, why would you code it yourself? Need to display stuff in a grid, oh we better should center our project around Ionic so we can use ion-grid.

More than 'merchant of complexity', I thing that a huge culprit is the need for content marketing, and so any new thing in a framework become the theme of multiple conference, and the obligatory Medium posts explaining the new stuff (in itself, not necessarily a bad thing), but which often tend to snowball into "Method X is obsolete, why you should all port your code using newfangled method Y".

And now, I have a colleague working in an Angular app that keeps on rewriting stuff and wrap everything with signals. Signals can be good sometime, I'm not against angular signals in itself, but he's just taking dead-simple code and making it more complicated because apparently now everything Angular should be about signal. At least I'm away from the part of the React ecosystem that keeps trying to re-invent the cascading part of CSS but with Typescript in the mix. shudders.

[1] https://news.ycombinator.com/item?id=40476275

Reply on news.ycombinator.com