Fun bit of trivia: the first two major web libraries - cgi-lib.pl and CGI.pm - were written by bioinformaticians. Steven E. Brenner and Lincoln Stein, respectively.

Cgi.pm was great, really nice little abstraction. Create react app is also a really nice abstraction, although I wouldn’t call it little :-)

This 100%. The vast majority of websites (not webapps) don't need anything more than HTML, CSS and some JS/JQuery.

> Or name me one person who can, from memory, correctly configure the rails sprockets asset pipeline

I feel that one, it's insane that the most basic "I need to execute a few lines of very specific JS on this specific page" must devolve into a DRY absolutist abstraction madness, previously with sprockets, now with webpacker.

Your second paragraph neatly sums up the state of things. It's gotten downright cartoonish.

I remember when Rails first hit the ground. It was touted as a revolution in Web simplicity (and was relative to then, when what we expected of our apps was relatively simple).

But, someone got it in their heads that web apps should be near-indistinguishable from desktop apps. But, let's not address the impedance mismatch there. Instead, let's create a bunch of layers out of new tools and concepts to obscure the fact that these things don't fit together.

So our projects/apps now demand more and have just grown extremely complex. Turns out that making the Web act just like a native app (while battling all its Web semantics) is hard. We want it to be X, when all it wants to be is the Web.

Add to this all of the other disparate pieces that we want to work together: countless technologies, languages, libraries, 3rd party services, etc. And if you're talking full stack (and who's really not fullstack these days?), the number of universes that you must make coexist is insane. And, much of this is to layer over existing technologies (like Rails) that weren't intended to be used in this way. Enter entire concepts like transpiling, webpacking, etc.

Then to deploy, You're probably dealing with no less than 6-10 cloud provider services, each with its own set of concepts and requirements to be satisfied. Even if you're not the one deploying, you have to understand their implications on your code.

Web development is now less about writing logic and much more about wiring a bunch of existing stuff together, with discrete chunks of logic serving as the business/domain layer glue. I mean the app still has to serve some business purpose, so the code that supports that must be written. But that's barely the start these days.

Is anyone still using bower?

Also webpacker for rails is somehow both insanely complex and alright to use.

A perfect proof for GP's/TFA's point.

To this I'll only add that "follow these instructions carefully + magic happens" works only for ~6 months after a tutorial is published, longer than that and some dependency or toolchain update somewhere is bound to break the instructions in a way incomprehensible to a novice.

Not only to a novice. I was recently contracted to update a client from rails 4 to 5.2, which included updating sprockets, which ended with us downloading the source code of all the gems to because nobody could figure out why the html would contain the correct url for the asset, but rake would first produce the file during asset precompilation and then later delete it during cleanup. 2 days wasted on broken magic...

Oh I agree, my current preferred way to use Rails is as an API with no frontend at all.