3 ms·

I follow your reasoning for the most part, but there's one core problem that inevitably comes up: everything has quirks, and the quirks add up over time. Boring

I follow your reasoning for the most part, but there's one core problem that inevitably comes up: everything has quirks, and the quirks add up over time. Boring stacks are partly boring because they've been around for a long time, but they are also boring in the sense that they are predictable. The problem is that in any suitably large project, you will inevitably cover enough use cases to run into a library or language's quirks. Browser support issue in this one corner, language ambiguity in this other corner, unsupported arcane combination of theoretically orthogonal functions in yet another corner, and then a slow inner loop in some other corner. Once you've added everything together, you get a big headache. With more mature stacks, it's easier to anticipate these issues because they are well documented all over tutorial materials, knowledge bases, and just professional experience. They've also had time to iterate and address many of the design and polish issues that would slow developers down.

bartread 10y ago
Yep. Most of my experience with these kind of issues recently has been on the client side: stuff works in one browser or, worse, one version of a browser, and not in another, or it works well in the desktop browser, but not the mobile version of the same browser. These issues tend to be huge timesinks - I literally lose count of the number of times I've lost a couple of hours or more due to some weird quirk that would never have come up as an issue in plain old .NET. That being said, in any suitably large project, the quirks in your own codebase will inevitably start to drain resources in the same way whether your stack is boring or otherwise. The advantage with boring is that, 99% of the time, if there is a quirk you know it's probably your quirk and something that's under your control to fix.

bartread 10y ago

Yep. Most of my experience with these kind of issues recently has been on the client side: stuff works in one browser or, worse, one version of a browser, and not in another, or it works well in the desktop browser, but not the mobile version of the same browser. These issues tend to be huge timesinks - I literally lose count of the number of times I've lost a couple of hours or more due to some weird quirk that would never have come up as an issue in plain old .NET. That being said, in any suitably large project, the quirks in your own codebase will inevitably start to drain resources in the same way whether your stack is boring or otherwise. The advantage with boring is that, 99% of the time, if there is a quirk you know it's probably your quirk and something that's under your control to fix.