Stop limiting your open source library’s potential
Tags: opensource, javascript, career
Published: 2019-04-04 13:45:24

---
title: Stop limiting your open source library’s potential
canonical_url: https://changelog.com/posts/stop-limiting-your-open-source-librarys-potential
cover_image: https://thepracticaldev.s3.amazonaws.com/i/rgoez8j9ssv0aigohm4s.png
published: true
description: When you hard-attach your library to a specific technology or framework, you limit its potential impact. By thinking ahead and putting in _a little_ more effort, your library could benefit orders of magnitudes more people.
tags: opensource, javascript, career
---

This morning I stumbled across [Griffith](https://github.com/zhihu/griffith) – a _React-based_ web video player. That's cool and all, but you know what'd be even cooler? A web video player that we all can use.

---

There's a recurring theme in open source where `TECHNOLOGY_X` gets popular and then a bunch of libraries and tools get created specifically for (or ported to) `TECHNOLOGY_X`, but they can't be used with `TECHNOLOGY_Y` or `TECHNOLOGY_Z`.

This is especially common in front-end-javascript-land where there are so many frameworks that come and go over the years. Examples!

1. You want a search box but you find an [Angular search box](https://github.com/dnauck/angular-advanced-searchbox)
2. You want a geocoding library but you find a [jQuery geocoding library](https://ubilabs.github.io/geocomplete/)
3. You want a datepicker but you find an [Ember datepicker](https://github.com/wesm87/ember-datepicker)

It doesn't have to be that way!

<mark>With a little forethought you can build a generically-useful library and then provide small wrapper libraries that _adapt_ the generic library to specific framework use cases</mark>. This is called [the adapter pattern](https://en.wikipedia.org/wiki/Adapter_pattern) and I swear it's not as bad as we make it out to be in this tweet.

{% twitter 1110224694093987842 %}

[Nicolás Bevacqua](https://twitter.com/nzgb) has been applying this principle to much success for years. He's a great example to follow if you need some help figuring out the details!

Case in point: he created [Dragula](https://github.com/bevacqua/dragula) – a generic drag-n-drop library you can use directly with vanilla JS. He then followed it up with adapters (which he calls _bridges_ – same difference):

1. The official [Angular bridge](https://github.com/bevacqua/angularjs-dragula)
2. The official [Angular 2 bridge](https://github.com/valor-software/ng2-dragula)
3. The official [React bridge](https://github.com/bevacqua/react-dragula)

What's even cooler about this approach is that Nicolás has paved the way for others to come along and build [an Ember adapter](https://github.com/bevacqua/react-dragula) for Dragula, an [Aurelia adapter](https://github.com/michaelmalonenz/aurelia-dragula) for Dragula, etc.

And when `TECHNOLOGY_X++` comes along next year? You can guess what it'd take to build it an adapter for Dragula....

---

When you hard-attach your library to a specific technology or framework, you limit its potential impact. By thinking ahead and putting in _a little_ more effort, <mark>your library could benefit orders of magnitudes more people</mark>. Maybe even _future-you_, once you've moved on to `TECHNOLOGY_X++`...

> Note: _read the original article [on changelog.com](https://changelog.com/posts/stop-limiting-your-open-source-librarys-potential)_