3 ms·
I like posts like this, because software with these properties does deserve to be roasted. It seems like no one can figure out or remember anymore what's wrong
by dgreensp 4y ago
I like posts like this, because software with these properties does deserve to be roasted. It seems like no one can figure out or remember anymore what's wrong with it, though. It's a valid question.
But a couple clarifications.
I don't develop or distribute software that depends on Node, but I imagine deciding which versions of Node to support, or conversely require, for software like Ghost, is a bit like deciding which Java VM versions to support, or which browsers to support. That is, there is a lot of compatibility between Node versions, but do you just develop and test on the latest one, or do you make an effort to support more/older versions? In this case, Ghost seems to be tested on v12, v14, and v16. The author seems to mistakenly think that only the "Active LTS" version of Node gets security fixes, but that's not the case, v14 and v16 are in "Maintenance LTS" and receive security fixes. That said, their "ends of life" are in April and September of this year, for whatever that's worth. At the end of the day, I think it is considered easy to update and/or run multiple versions of Node. I'm don't know why an app written for Node 16 wouldn't work with a newer Node 18, though, that kind of stuff annoys me sometimes.
For the MariaDB support, I googled and found this note from the Ghost devs: "Note: MariaDB is not an officially supported database for Ghost. It just happened to work given the similarities with MySQL, but we optimize and test for MySQL 5 and 8. As of Ghost 5.0 we are clarifying that official support is purely for MySQL8 in production so that we can double down on DB optimizations." Maybe that's what we're talking about? https://github.com/TryGhost/Ghost/issues/14446 https://github.com/TryGhost/Ghost/issues/14446
Now, the deeper trend that I think is misguided is the rate of iteration and breaking changes, and apps and libraries having too many dependencies. The problems propagate through the dependency graph. Someone releases a library, and then adds a bunch of features, and then rewrites it, adds features, rewrites it again. That's fine for some hobby project that no one is using. I think anything I say won't be appreciated by someone who hasn't experienced programming and computing any other way, e.g. writing Java applications in the 1990s and 2000s. Or even just using desktop applications in the 90s. Software used to sort of "mature" and then continue to be used and supported, while staying pretty much the same, for years. It wasn't constantly rearranged to use new versions of things that are constantly rearranged to use new versions of things that are constantly rearranged etc. etc. etc.