You deride the use of preprocessors and such in other places in this thread

Strictly speaking that's probably true, but I'd like to be clear that I'm not really deriding the idea of preprocessors, but rather the need to use preprocessors to make up for weaknesses in the underlying technology that shouldn't be there.

Any time you start talking about a build process, you're talking about introducing (and subsequently managing) overheads. If adding that extra step is a big win for some other reason, the overhead is worth it. But if adding that extra step just brings you up to where everyone else was in the first place, your underlying platform isn't good enough.

Put another way, I think it's crazy how often I find a potentially interesting library for building a modern web page/app, but then the getting started page starts with something like "First install package management library P and with that get dependency management tool D, then create configuration file F, featuring dependencies A, B and C, run setup script S to install those dependencies and create scaffolding S', and now you have a complete project ready to go that includes only 3 levels of directory hierarchy and 17 files to start you off so you can follow the 'Hello, world' tutorial." That is an absurd amount of hassle just to get something going in a quick experimental project and see whether it's actually any good, and it amplifies the problems already caused by having so much fragmentation and NIH syndrome in front-end development today.

Stuff built on top of current web technologies hasn't been under development for nearly as long as stuff built on top of machine code.

That's a fair point, but I suggest to you that there is a flip side: when we build new tools today we also have the wisdom of hindsight. We have several decades of general software development experience to draw on that the guys building early tools in languages like C and the guys who developed the first GUI libraries didn't. And this is really the heart of my problem with the current situation: we don't seem to be paying any attention to those lessons, or the flashing neon signs that developers who went before us installed to warn us never to tread this path again.

I will give you a challenge: come up with an idea, and I posit folks will come up with a way to implement it on top of these “broken models”.

I almost rose to that challenge, but then I realised it was missing the point. You can write a word processor in assembler, and some people have, but just because it's possible, that doesn't mean it's an efficient way to do it with the other tools and techniques we have available today.

But regardless, without presenting clear ideas on what a better path would be, I'm concerned your complaints aren't truly useful

The problem with modern web development is that instead of trying to build tools that are comparable with the best we've developed elsewhere, learning from the greater experience of other software developers and DBAs and sysadmins and UI designers and all the rest, we're taking it as axiomatic that we have to build on what's already there.

Why should we do that? The amount of resources being thrown into new web standards and languages and preprocessors and tools across the industrial as a whole is vast, and it already includes several projects on a scale not very far from building the kind of "portable Web assembly language" or "powerful, flexible, extensible layout model" concepts I'm talking about. Just think about all the new rendering engines, JS runtime environments, X-to-JavaScript compilers, X-to-CSS compilers, and so on that have been built in recent years.

I don't claim to be nearly as creative or smart as, for example, the people who developed tools like SASS. But such tools have been developed, and have been very successful, and we can learn a lot from that both in terms of what is possible and how much easier good tools can make the development process. We can also learn a lot from where even those tools haven't been as successful, because as preprocessors they are inherently limited by their target format.