Boss to developer at 5pm Friday: “That proof-of-concept you knocked up last week for the sales team web dashboard ? We’ve promised the full-blown version to the users by next week – you’re good with that, right?”
Anonumous Dev
Outside of todo lists and pizza ordering demo’s, there’s a lot to learn to write a useful application. You have to handle all the back end data storage stuff, then produce a decent looking user interface. Writing a UI with a consistent look and feel is long and hard work. Churning one out quickly is difficult. So I can appreciate the pressure to get the acceleration of libraries of code from other people. They put the hours in so you don’t have to. And it’s all free to use.
You see, somewhere along the line libs moved away from being an individual dev sharing the fruits of their learnings and became code that others would take and blindly rely on. There is no malice in this, the devs relying on the libs were enjoying pumping out amazing results, and just so productive that their bosses continued to expect / demand that kind of productivity.
So, what could possibly go wrong?
Quality
What I mean here is this – is the code in this library as good as it should be? Can we rely on it to be stable and reliable. What security implications does it introduce. If the code in the lib is not better than you would produce yourself then consider whether you want to take it on.
Bloat
In relation to client-side libs: So you downloaded a lib that gives you a smart feature that you otherwise would have had no idea how to code. And anyway, it’s only 3.2Kb minified. What’s wrong with this is that you loaded another dependency into your code base to cover a knowledge gap. The feature you needed from that library might be the entire 3.2Kb, or it might be only 1% of it with the remaining 3Kb being bloat. Sure, 3Kb ain’t bloat on a desktop with a speedy broadband connection, but on a flaky line from somewhere rural? You should know exactly what the unused parts of the lib do and be able to justify their inclusion as dead-weight in your project.
Breaking changes
What happens if the author carries out a heavy re-factor, or changes their mind on a main component of the call structure the day before you go to production, or a security weakness is discovered in the lib and the author won’t fix it, or the author of an npm dependency removes it from the web – which is exactly the scenario when the 11-line npm package left-pad, by Azer Koçulu was taken offline in a registered trademark dispute. You should mitigate these issues before you accept that you have to ship with reliance on any third party code.
CDN goes offline
So you’re using a CDN to pull some lib that your app relies on into the users browser. And the support site lights up with ‘won’t run’ issues. The CDN went offline, or the author of the lib got swatted in a copyright wrangle with a big tech co, or the author shipped a broken change. Now what do you do ?
How to mitigate and avoid these issues
Mainly, aim to learn as much as possible from libs, but deploy as few as possible.
Rule 1: Try not to use third party libs in production.
Rule 2: Do a code review of the lib. Find out how much of it covers the feature you need – can you trim it down or DIY it ? Is the remaining code of good quality ? Does the developers work show an understanding of how to produce efficient, well documented, secure and performant code? You will almost always learn something from a code review of this kind.
Rule 3: If you absolutely must use a lib then take a copy of the lib to your own server and serve it from there. If you have the lib code on your own server then you are at least in control of your own destiny.
Rule 4: Try not to use third party libs in production.
Whatever the outcome, if you follow these rules you will have a better understanding of the balance between risk and gain that the lib represents.
Selecting a lib
A lib should have low dependencies – if it needs 1 more lib to run then that’s doubling the risks of using it.
It should be stable and mature.
- Look at the git or equivalent, is there recent activity?
- What’s the authors voice like in responses to issues or help requests – are they pragmatic and helpful or is there tumbleweed?
- Are the issues being fixed? Are there plans slated for a big refactor (meaning breaking changes) in some future release?
What about documentation, tutorials, and samples? What’s the history in StackOverflow? Is there an active Discord channel? Overall, is there a good, multi-dimensional community?
Can you hire and retain devs with knowledge of the lib?
Finally, can you selectively deploy the components you need and leave the rest out of your deployment package?
Summary
Take care when diving in to a lib and showing off what you did to your boss – it’ll become the expected norm. If you have to use a lib, and there are times when it IS relevant, then choose carefully and don’t be afraid to decide to learn from the lib then make your own minimal viable feature set and escape the dependency trap.
Thanks for reading
VW July 2021
Resources:
- Cloudflare stutters and the internet stumbles
- How one programmer broke the internet by deleting a tiny piece of code
Other peoples thoughts on the same topic
- Remy Sharp – The web didn’t change; you did
- Chris Ferdinandi – Framework fatigue and the changing web
Coding for the long view 