Thing is, most if not all of those “large enterprise level applications” either need to be split into smaller separate applications (the “big tent” failing), or are just ridiculously and poorly written because of half-tweet trash like frameworks. In most cases they shouldn’t be “large” in the first place and the notion they “need” to be large products is as much a part of the problem as shoddy code. “Big tasks” become surprisingly easy to write and maintain when you break them into smaller pieces.
Again, to use what I see on websites and applications all the blasted time; 200k of HTML, 500k of CSS, and megabytes of JavaScript to do things that only need 16k of HTML, 48k or less CSS, and little if any scripting if you give a flying purple fish about usability and accessibility… maybe 48k of JS if you insist on layering atop bells and whistles.
More so with people throwing this “application” stuff at things that should be normal websites, NOT applications… in the process telling large swaths of potential users to go F*** themselves all because some script kiddy couldn’t keep their bling bling in their pants.
I mean, there are legitimate cases for when things should be an app, but generally those don’t need to be these multi-megabyte monstrous train wrecks. It’s REALLY bad though when people make applications out of things that shouldn’t.
And most places I’ve gone into as a accessibility and efficiency consultant, that’s EXACTLY what I see time and time again screwing over my clients. And at fault in mindset and intent is most always dipshit nonsense like bootcrap or tailwind, or just plain time wasting rubbish like React, Vue, etc, blowing megabytes of code on doing double digit kilobyte’s job!
At least in terms of what’s being vomited up client-side.
See a insurance company I just did some work for. They were choking to death a room full of Xeons (24+) to do the exact same task with nearly the same number of users that I was doing faster, easier, simpler, and in a fraction the code on a 486 DX-50 (real 50, not the /2) with 16 megs of RAM 27 years ago.
Why? Laravel, Bootstrap, jQuery, LESS, non-semantic markup… almost all their bottlenecks were caused by the front-end, not the database.
After going through it and systematically all the junk, throwing the SPA style construction in the trash in favor of conventional pageloads, they’ve got 23 multi-core Xeons sitting there with their thumb up their backside.
Something I discovered I had a talent for in the ‘00’s — taking systems that were killing 3ghz+ multi-core Xeon dedicated hosting, and paring them down to run on leftover P3 or Atom rigs with processing power to spare.