4 ms·
Take any engineering analogy you like. At some point you need to restrict changes in foundational components in order to create a robust product. It’s not pract
by bottled_poe 6y ago
Take any engineering analogy you like. At some point you need to restrict changes in foundational components in order to create a robust product. It’s not practical to continually change the foundational components, especially when the builder is left with the responsibility for continuously integrating and testing the compatibility between those components.
- skybrian 6y agoEvery website has the ground changing under it whenever browsers update to a new version. This usually doesn’t break much because browser vendors are pretty conservative about changing features that are in wide use. I guess that’s one way of restricting changes to foundational components, but maybe not what you meant?
- PurpleFoxy 6y agoAnd as a result, the browser may never break existing APIs so JS is left with multiple ways to do the same things where certain ways are strictly worse than others. Also the web browser apis go under orders of magnitude more scrutiny than your average library.
- konjin 6y ago> Every website has the ground changing under it whenever browsers update to a new version. Every app has the ground changing under it whenever the kernel updates to a new version. Yet somehow we can still run binaries from the 90s. The browsers are broken and need to be frozen. Not something that will happen because google, like microsoft before it, benefits from constantly breaking, changing and extending everything to not let anyone catch up to them.
- majkinetor 6y agoIts not only about practicality or work involved either. You are replacing something that works and is battle tested, with something that is unknown (even if its just minor upgrade). That can lead to bugs that affect end users. Even if you have automatic tests, it still applies, as you can never test everything.