[88913527]

How far can this argument be extended? We can go back to vanilla JS/HTML/jQuery; these are all "easy to understand" things. But then too much spaghetti code builds up and then progress grinds down (much like in the Ramda team situation). You need some abstraction and order to maintain consistent productivity levels over the long-term.

[axblount]

I don't think they're arguing against abstractions. Just this one in particular.

[solardev]

I might also argue that sometimes writing the same dumb basic declarative code 20 different times is still faster and easier to read, debug, and maintain than trying to write one master class to handle every possible edge case.

IMO it's one thing if you're writing an engine or library where you have to ensure extremely high quality and good coverage. Or maybe you just work for an incredibly well run outfit where newcomers are deeply trained in the ins and outs of your codebase and style. But no place I've personally worked with has been like that.

If you're just building a bog standard business app for a small or medium business, I don't think purity of code is typically the primary bottleneck. Likely turnover and poor documentation and lack of on-boarding and sudden frequent pivots will be bigger deals, all of which are significantly complicated by over-abstracted code that can't be modularly changed by a single developer.

People worked with vanilla HTML and JS for decades, maybe using server side includes for some basic DRY. It wasn't pretty, it was hecka tedious, but it also wasn't Inception-level nightmarish like some modern abstractions are. There's an ideal level of abstraction for a given team and codebase, IMO, and it's not always "more abstraction is better" (not that you were arguing that). It's just a process of discovery and design by fire that gets you there, not usually a lone genius that produces a masterpiece in any one particular style.