Reduce, Reuse, Recycle
When you’re building an application, it makes sense to take advantage of as many open source libraries as you can. These libraries can often save a lot of time… or not.
Fit or Misfit
When you’re building an application, it’s easy to fall into the trap of assuming your Google results for some function you want will actually do what you want. While these libraries can be pretty good at what they do, they tend to come with three common pitfalls.
First — Some libraries are trying to be everything to everyone. The programmer(s) have done a fantastic job of building a complete piece of functionality and have trapped all sorts of edge cases. This isn’t a problem if you’re OK with the library’s out-of-the-box functionality, but if you’re trying to do something very specific, you may quickly find yourself trying to ram a square peg into a round hole.
Second — In a lot of cases, these libraries are black boxes. Documentation can be hit or miss with these libraries. The examples work great, but when you try to write an example tailored to your needs, things get dicey. You don’t know how well the libraries scale with large amounts of data without doing your own testing. In some cases, you also don’t know how secure the code bases are. Sure, you can dig into the code, but the reason why you even considered the library was to save time, effort, and headaches.
Third — Since most libraries are borne from a programmer’s own need, they are developed with themselves in mind. That is to say, there’s an opinionated design. The API or data structures are a certain way, and they may not match the way your application is built. They may also be a mismatch for the other libraries you’re dependent on. Just figuring out the learning curve for remapping your data structures could take longer than if you wrote your own library from scratch.
Not Invented Here
Someone wise once said “If you think something is easy, you probably don’t know what you’re talking about”.
Thinking you can easily build an application by just grabbing a pile of pre-written libraries is a trap. Are you going to add D3.js to your application just so you can put a single pie chart on a single page in your application? That’s a lot of code to be adding just for a small feature.
Unless all of those libraries you wanted were written by similar thinking people (pro tip: they’re not), you’re going to be dealing with a bunch of different programming styles and API invocation approaches. Integrating a pile of code written by a bunch of randos may not be technically difficult, but if you’re trying to do something non-trivial, integrating that code is going to be time-consuming. First you have to learn how each library works, and then you need to make the libraries talk to each other. And then you need to make sure that upgrades to one library doesn’t break anything relying on the other libraries.
In some cases, you’re better off writing your own new code. And you know what, it’s not the end of the world.
Let’s be clear, it makes no sense to re-invent the wheel if you can at all avoid it.
So what should you do? In building Assign It To Me, we’ve gone through a litany of different libraries. When we discuss adding a feature, we always see if any wheels have been already invented and whether they fit on our car, so to speak. If they don’t we have to make our own wheel.
In general, I find that large libraries that do more than I need tend to be a bad fit. The best libraries are the smaller, “do one thing really well” libraries. They’re easier to decode and integrate. Because we try and ensure that mobile users can use the same set of code, payload and dependencies matter. Or more clearly put, I don’t want to deal with sizable pieces of new code or dependencies on libraries I don’t already use. For example, we don’t use jQuery in any of our client side code. I’m not going to add an extra 100KB or so of code to our client app just so we can do something trivial. Heck, I’m going to need convincing even to do something non-trivial. The cost is that I lose access to hundreds of canned user interface libraries, but it hasn’t been nearly as big as a hindrance as it would seem.
From my perspective, it pays to be hypercritical about including any new libraries in your code. All of your externally sourced libraries move at their own pace. As mentioned earlier, an upgrade to one library can lead to a litany of negative side-effects in your other libraries.
There’s a delicate balance between being able to show forward progress quickly by using some canned code and making sure that the rest of your code base is clean and performant. Do evaluate and consider open source libraries for your applications, but don’t be afraid to write your own code either. Remember — a lot of open web frameworks were written because existing frameworks didn’t do the job that the programmer needed. It doesn’t mean that you need to eventually rewrite all the third party libraries you’re using. But if you outgrow them, it’s better than being dependent on someone else’s work and update schedule.
Other articles by this author:
- Boring, But It Works
- How to Save Data Locally in Electron
- Quick Hit: Create Visualizations Using YAML/JSON files
- Quick Hit: Flutter to Support Desktop Applications