Furthermore, when you are talking about something that solves the scope of problems which CSS solves, there is no way you can just sit down and design a better system
CSS has proved an awful system for layout, design and practically every domain it attempts to address over the last couple of decades. Having worked with both for a long time, here's the fundamental difference between HTML and CSS, as I think it's a useful comparison and highlights when worse is truly better, and when it is just worse:
HTML was limited and simple by design, and has gradually improved (the original worse is better ethos)
CSS was broken by design, and hasn't much improved (maybe in a few years with flexbox and grids, maybe).
I don't find it at all surprising that someone thinks CSS could and should be replaced, and I'm skeptical that if the best minds of our generation took another look at it, they couldn't find some far better ways to lay out content than an inconsistent and confusing box model with concepts like floats tacked on to it and lots of module proposals to try to glom on additional layout modes. I can't think of many problems CSS solves well, apart from separation of style/layout and content, even there at present we have div soup for grids instead of table soup - hardly a huge improvement on what went before. Some of the problems it attempts to solve are not even real-world problems and are of its own devise (for example the Cascading Style priorities in its name - what a bizarre focus for a layout language).
Perhaps the answer is a turing-complete layout language (personally I doubt it), or perhaps it's another more informed declarative one, but I'm quite sure we can improve on it, and the comparison to HTML is apposite, because that has stood the test of time rather well compared to its companion technologies.
It's a little tiresome when a young idealist comes into a 25-year-old field
We don't live in the best of all possible worlds, and to make it better, we sometimes have to take a step back from a local maximum and look at the bigger picture; that involves listening to 25-year-olds coming up with something better - most of the time they won't, but sometimes they will. If you find yourself not even listening, and more concerned with sunk costs, work already done, and expertise already gained, that's not healthy and not a convincing riposte.
"that involves listening to 25-year-olds coming up with something better"
That doesn't involve listening to them, it involves them putting in the work to develop something as a proof of concept, and that proof of concept evolving through feedback and collaboration into something people want to use.
To put it more crassly, people don't stop using something because others say it's shit, they stop using something when there's a better option on the table, and that better option needs to be more than just architecturally improved, it needs to be genuinely useful, and this is what people who twist "worse is better" fail to understand... legacy code sticks around when it's genuinely useful.
And to address the original author... yes, the idea with writing software is to get the job done, but if you want to work on tooling to improve that process be my guest.
That doesn't involve listening to them, it involves them putting in the work to develop something as a proof of concept, and that proof of concept evolving through feedback and collaboration into something people want to use.
Well I think it's always useful to listen - even if you disagree or think your interlocutor mistaken. Of course as you say ideas are worth a lot less than implementation, but the one point I fully agree with the original author on is this:
CSS is not best of breed, existing for 20 years does not make it good in any sense, and it is a terrible example of worse is better in the original sense. However arguing over "worse is better" is just going to end in arguing about what that vague phrase means, so I won't enter that particular rabbit-hole - I agree the original author misunderstood or has not encountered the original meaning.
In the case of CSS, what holds back adoption of alternatives is almost entirely browser-vendor inertia and the institutional barriers to producing a better solution, not some technical superiority of CSS, so what I object to in the parent comment is the implication that CSS won because it is technically superior to other layout methods and is complex because it deals with lots of complex domain problems which a 25 year old couldn't possibly fathom. It introduces needless complexity, doesn't even properly address the domain problems (design, layout, grids etc), was badly designed from the start and has become even more complex with age, and I'd argue it has succeeded mostly by riding on the coat tails of HTML.
Only a quick glance after the previous article, I think it looks interesting, not something I would use right now, but interesting as an alternative to what we have in the web at present. I particularly liked this little page for playing with it:
CSS has proved an awful system for layout, design and practically every domain it attempts to address over the last couple of decades. Having worked with both for a long time, here's the fundamental difference between HTML and CSS, as I think it's a useful comparison and highlights when worse is truly better, and when it is just worse:
HTML was limited and simple by design, and has gradually improved (the original worse is better ethos)
CSS was broken by design, and hasn't much improved (maybe in a few years with flexbox and grids, maybe).
I don't find it at all surprising that someone thinks CSS could and should be replaced, and I'm skeptical that if the best minds of our generation took another look at it, they couldn't find some far better ways to lay out content than an inconsistent and confusing box model with concepts like floats tacked on to it and lots of module proposals to try to glom on additional layout modes. I can't think of many problems CSS solves well, apart from separation of style/layout and content, even there at present we have div soup for grids instead of table soup - hardly a huge improvement on what went before. Some of the problems it attempts to solve are not even real-world problems and are of its own devise (for example the Cascading Style priorities in its name - what a bizarre focus for a layout language).
Perhaps the answer is a turing-complete layout language (personally I doubt it), or perhaps it's another more informed declarative one, but I'm quite sure we can improve on it, and the comparison to HTML is apposite, because that has stood the test of time rather well compared to its companion technologies.
It's a little tiresome when a young idealist comes into a 25-year-old field
We don't live in the best of all possible worlds, and to make it better, we sometimes have to take a step back from a local maximum and look at the bigger picture; that involves listening to 25-year-olds coming up with something better - most of the time they won't, but sometimes they will. If you find yourself not even listening, and more concerned with sunk costs, work already done, and expertise already gained, that's not healthy and not a convincing riposte.