However he completely misunderstood my point to suggest that worst-is-better is a conscious design quality. In no way did I mean that, and I don't believe Richard Gabriel meant that either. Worse-is-better is about the reason certain solutions win in the market; it's about an evolutionary trait, not a design philosophy.
Look at it this way. If there are 100 possible technical solutions to a given computing problem, the ones that solve the problem more comprehensively are naturally going to tend to be more complex, this complexity comes with an adoption cost, and that cost works against the likelihood of adoption. 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, it will need to go through many iterations to solve all the things that CSS solves (which no single human being is comprehensively aware of btw). In order to see that kind of investment a system needs buy-in from downstream users over long a period of time.
So the strawman that the author sets up is the idea that someone is out there selling a worse solution on purpose because of this meme which is simply an observation of how technical adoption markets play out. Of course such foolish people may be out there, but no intelligent developer sets out to create something that is deliberately worse. Rather, each tradeoff is considered in its specific contemporary context of the imperfect information available. Whether a solution gains traction and wins in the marketplace is has nothing to do with the subjective qualities of "worse" or "better", but rather is a confluence of the state of the market at various points in time: how well it solves immediate problems, how well it works with existing tech, how easy to adopt, and of course some amount of hype loosely related to the aforementioned.
What doesn't play a huge role is how ugly the evolution of this tech is going to look 20 years down the line when the entire landscape has evolved.
It's a little tiresome when a young idealist comes into a 25-year-old field (I'm guessing the author is not much older than that himself), pisses on the hard work of thousands of people pushing web tech forward bit by bit over decades, and says it should be replaced wholesale because it's just rubbish, and then when someone tells them that you're welcome to try but you'll never get any traction in that Sisyphean task, he responds that people aren't engaging in a rational discussion.
> ...but rather is a confluence of the state of the market at various points in time...
> That is, we do not merely calculate in earnest to what extent tradeoffs are necessary or desirable, keeping in mind our goals and values, there is a culture around making such compromises that actively discourages people from even considering more radical, principled approaches.
If you can suspend your frustration for a moment, it seems that you and the author are both arguing for explicit consideration of the tradeoffs faced in the real world. Both sides of the field have a tendency to reduce this consideration to easily evaluated heuristics (eg "useless ivory tower wankery").
I think the authors earlier posts on generous reading apply here. There is plenty here to disagree with but noone gains much from taking sides and fighting to the death. Rather than getting wound up we could be having a much more valuable discussion of how market forces shape technology and how we might find ways to support and apply long shot research.
EDIT From the discussion you mention:
> What might otherwise be an interesting, nuanced discussion of the economics of technology adoption, network effects, switching costs, etc, is instead replaced with sloganeering like 'Worse is Better'.
> There may well be times where fighting for revolutionary change or finding some adoption story for completely new tech is a better path forward than incremental improvements. Questions like this can not be settled at the level of ideology or sloganeering...
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:
His articles addresses your comments about the market: that they're being irrational by viewing their purchasing decisions without considering the impact it has on the portfolio - going full government bonds.
You're as much strawmanning his article as you're accusing him of strawmanning other points.
It's possible lots of people did put a lot of work in to styling on the web, and that it's still bad and we could do better if we started over. Of course it's going to take a lot of effort to get back to where a current project is, but that's the point: people who are using current projects should also be looking at their future costs (total cost of ownership over company/product lifetime), and take on a couple high risk investments if their projected long term cost is lowered by it. They're not doing that, because people like you show up and say "Hey, it'll never get done because it's a lot of work, so let's just keep hacking on a complexity explosion."
Of course a CSS replacement isn't going to immediately replace it. That's nonsense. Rather, the author is saying that if we started now, in 5-10 years, our choice to reduce complexity would have paid off, and we'll now pull ahead of where the hackpile that is CSS would have us at that time.
But if we never start, we're never going to get that growth, and have to keep hacking away at a mess forever.
> If there are 100 possible technical solutions to a given computing problem, the ones that solve the problem more comprehensively are naturally going to tend to be more complex, this complexity comes with an adoption cost, and that cost works against the likelihood of adoption.
The opposite is true. The best solutions are simple, not complex. Piling features one on top of other features to solve every problem as you encounter it gets you started faster than first thinking carefully about the problem space and then designing a solution. That's worse is better, or better: worse is quicker.
Stating that as an absolute truth is extremely naive. The cases for which that is true are the easy ones, you are very lucky if you have the choice to limit your work to things which have simple and elegant solutions. Most things that touch the real world have an irreducible complexity that you can't simplify with destroying the core value proposition: witness Unicode.
Sure, but that's not what we are talking about here. Given two solutions that solve the same problem, the simpler one is almost always the better one. A worse is better methodology produces a complex and worse solution, whereas you were saying that it produces a simple and worse solution.
And by the way, CSS is definitely not complex because of irreducible complexity.
But coming up with a simple solution takes much longer than coming up with a complicated one; and by the time you've come up with your simple elegant solution, your competitor has already beaten you to market with something worse but was actually "good enough" and no one cares about your solution. Worse is better is not a methodology, but an observation.
I have made this longer than usual because I have not had time to make it shorter. Blaise Pascal
Plus, I had to be done in ten days or something worse than JS would have happened. Brendan Eich
However he completely misunderstood my point to suggest that worst-is-better is a conscious design quality. In no way did I mean that, and I don't believe Richard Gabriel meant that either. Worse-is-better is about the reason certain solutions win in the market; it's about an evolutionary trait, not a design philosophy.
Look at it this way. If there are 100 possible technical solutions to a given computing problem, the ones that solve the problem more comprehensively are naturally going to tend to be more complex, this complexity comes with an adoption cost, and that cost works against the likelihood of adoption. 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, it will need to go through many iterations to solve all the things that CSS solves (which no single human being is comprehensively aware of btw). In order to see that kind of investment a system needs buy-in from downstream users over long a period of time.
So the strawman that the author sets up is the idea that someone is out there selling a worse solution on purpose because of this meme which is simply an observation of how technical adoption markets play out. Of course such foolish people may be out there, but no intelligent developer sets out to create something that is deliberately worse. Rather, each tradeoff is considered in its specific contemporary context of the imperfect information available. Whether a solution gains traction and wins in the marketplace is has nothing to do with the subjective qualities of "worse" or "better", but rather is a confluence of the state of the market at various points in time: how well it solves immediate problems, how well it works with existing tech, how easy to adopt, and of course some amount of hype loosely related to the aforementioned.
What doesn't play a huge role is how ugly the evolution of this tech is going to look 20 years down the line when the entire landscape has evolved.
It's a little tiresome when a young idealist comes into a 25-year-old field (I'm guessing the author is not much older than that himself), pisses on the hard work of thousands of people pushing web tech forward bit by bit over decades, and says it should be replaced wholesale because it's just rubbish, and then when someone tells them that you're welcome to try but you'll never get any traction in that Sisyphean task, he responds that people aren't engaging in a rational discussion.