Thinking about how well your web architecture will hold up for 100 years (or even 10 years) is bikeshedding and a pointless exercise.
Perfect is the enemy of good and all that. If something is useful, it’s possible to fix the architecture later. The only counter-example I know of has been GitHub, which was built on RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
> RoR and so poorly planned that it’s still biting Microsoft on a regular basis.
Disagree. The RoR front end was way more stable and usable than the mess they have made now.
The issues are with the Ruby backend.
RoR is the only framework I’ve ever heard of being so bad that it killed startups. I personally know of two that were doing well, but RoR was so brittle and slow that they couldn’t hire enough to keep it going. This is compounded by Ruby devs being pretty rare.
> RoR was so brittle and slow that they couldn’t hire enough to keep it going.
This is such a "poor carpenter blaming his tools" take.
RoR isn't holding you back from writing performant, high-quality code. However, letting inexperienced developers run wild without supervision does end up with a codebase committing most of the deadly sins of software: (1) proliferation of competing patterns (2) proliferation of competing third-party libraries, leading to more #1, (3) inadequate test suite, and (4) an app that serves up so many 500 errors that you can't tell which are new and/or which indicate a problem. #4 is definitely more common in untyped languages, since that whole class of bugs can't be caught at compile time.
By the time a lot of these "startups" get to the mature state they have like a 7-year-old codebase that is beyond help. But you can use Ruby and Rails responsibly. I've seen it done. Usually all that's needed is to apply yourself to understanding how to cache, and then, identifying the key expensive high-traffic endpoints and converting them from ActiveRecord N+1 messes into single-query eager-loaded beasts, sometimes skipping ActiveRecord's object instantiation. Sounds scary, but it's inevitable for a popular application on any language/framework that you'll need to go beyond the tutorial-grade code for key transactions. This kind of thing is what Staff Engineers are for.
Thinking about whether a web architecture will hold up for 100 years is bikeshedding, is bikeshedding as well
calling thinking about bikeshedding, bikeshedding, is peak bikeshedding.
bikeshed
pronounced "by-kesht"
Only if you don’t know what bikeshedding is and want to broaden the definition so much that it’s meaningless.
This is Hacker News. This is exactly the place to tell people they’re overanalyzing and should just build something.
Sir, this is a Wendy's
100 years, sure, but 10 years? Definitely not bike shedding, I'd hope your website can stay up for 10 years at least.
You don’t need to agonize over a library choice to know that your site will be up for 10 years. If it outputs web standards, the browser engines will make sure it is.
Yes, unless you choose wrong, which is what we're talking about, as sometimes choosing right is worth the bike shedding.
Sure but it's a spectrum. Surely some choices will age much more poorly than others.