For the longest time as developers, we were taught not to reinvent the wheel. “There is a library for that,” we were told, so instead of implementing our own solutions for common, recurring tasks, we just imported and linked the library in question.
And sure, it made a lot of sense. Countless hours of development time were saved. Projects were completed on time, within budget. And once the system worked, it, well, worked. So long as there was a need to maintain the software, we just kept the old development tools around for the occasional bug fix and recompile. I remember keeping a Visual Studio 6.0 configuration alive well into the 2010s, to make sure that I could offer support to a long-time customer.
But then… then came the Internet. Which implied several monumental paradigm shifts. One of the most fundamental among them is that a lot of software development no longer targeted cooperating users in a closed environment. Rather, the software was exposed to the public and, well, let’s face it, not all members of the public have the best intentions in mind when they interact with our systems.
Which means that third-party code turned from an asset into a substantial liability. Why? Because of potential security issues. Using old versions of third-party libraries in public-facing systems is an invitation for disaster. Those third-party components must be kept up-to-date. Except…
- Updating a component may break other things. There is a need for extensive regression testing, especially in complex systems, to ensure that an upgrade does not result in unintended consequences.
- Updates are not always available. The third-party code may no longer be supported. Source code availability can mitigate this to some extent, but it can still result in a disproportionate level of effort to keep the code secure and functional.
- Long-term reliance on third-party code implies long-term reliance on the integrity and reliability of the vendor. Code ownership can change, and the new owners may have different objectives. In extreme cases, once reliable third-party code can end up being used as Trojan code in planned cyberattacks.
For a while, there was a great need for third-party code in Web development. HTML4 had limitations, and browser implementations varied wildly. Widely used third-party libraries like jQuery made it possible to prepare code that ran well on all major platforms. But this really is not the case anymore. “Out of the box” HTML5, CSS3 and modern JavaScript are tremendously capable tools and the implementation across major browsers is quite consistent these days, with only minor idiosyncrasies that can be easily dealt with after a modest amount of testing.
So really, my advice these days to anyone developing a new Web application is to avoid third-party libraries when possible. Especially if the application is intended to have a long life-cycle. Third-party code may cut down development time slightly, but the long-term costs may far exceed those savings. And there will still be more than enough to do just to keep up with other changes: witness the changes over time that occurred in browser security models, breaking once functioning Web applications, or the changes between, say, PHP5 and PHP7.
And of course there are still valid, legitimate use cases for specialized third-party libraries. For instance, in a recent project I used both MathJax (for rendering mathematical formulas) and markdown (for rendering displayed code). Developing something like that from scratch is just not an option.
Why am I harping on all this? I am currently facing a minor crisis of sorts (OK, that may be too strong a word) as I am trying to upgrade my Web sites from Joomla 3 to Joomla 4. Serves me right, using a third-party content management system instead of writing my own HTML! Worse yet, I used some once popular extensions with Joomla, extensions that are no longer supported, and which are wholly incompatible with Joomla 4. Dealing with this is difficult and time-consuming.
It would be a lot more time-consuming were it not for the help I get from our LLM AI friends. Thankfully, these tools, GPT-4 in particular, are immensely helpful. E.g., one third-party Joomla extension I used offered a nice way to present images as clickable thumbnails. This extension is now badly broken. However, GPT-4 already helped me write a clean, functional alterative that I’ll be able to use, and thus avoid having to redesign some important pages on my site.