Why I am excited about micro-packages

Wednesday’s “internet breakdown” kicked off a whole wave of tweets, posts and even one-liners as a service that are all about the current state of the JavaScript community and its cult-like pursuit of micro-packages.

It especially sparked a discussion around packaging up one line functions as packages and how many packages end up depending on them. “Have we forgotten how to program?” Is it a best practice to create micro-packages like isarray that can be rewritten in 5 minutes? Do we really need 28000 files for a blank JSPM project template?

Let’s try to address these questions, starting by reversing the first one: Do we actually know how to program?

The community as a platform

Modern software development is a young discipline. Over the last 20–30 years, patterns and best practices started to develop and evolve and I am sure that we are just scratching the surface when it comes to productivity.

One of the biggest issues is the fear of reinventing the wheel when it comes to writing our programs. I am a working student JavaScript developer who is payed by the hour to fix specific problems within my team. The reason why we are even able to develop cost effective solutions for our clients is that we can rely on the open source community for existing solutions that fit our needs.

This means that I can fully focus my development time and efforts on the problems that I am paid to solve and not tinker around solving the problems that thousands of other developers have solved already. I can reuse shared solutions to incorporate and mix them into my solution for my problem.

The platform that I’m relying on here is neither JavaScript, nor Node, nor React, not even npm. The platform I am relying on is the community itself and its developed ideas. I am re-purposing ideas to solve my problems and when I discover a problem that has not been solved yet, I am able to provide a solution that can then be re-purposed for the next problem that someone else might encounter.

I don’t think we have forgotten to program. I think the opposite is true. We are starting to learn how to program, or specifically, learn how to program together.

Writing code is easy, but writing has never been the problem

Sometimes we need to know whether we are looking at an array. The solution from the isarray package solves this problem similar to the following line:

Array.isArray || function (arr) { return {}.toString.call(arr) == ‘[object Array]’;}

It’s silly taking up another dependency for this simple line of code right? We can simply create our own function and paste it into our code which takes less than 2 minutes, including googling.

But the moment we paste it into our code, we created a lot of work for us, which might haunt us later:

1. Is this piece of code working for us right now?
2. Will it continue to work in the future?
3. Who is responsible to make sure it works in the future?
4. Who writes tests for this code?
5. Where do we put this code in our solution?
6. What if someone comes up with a better way to solve the problem?

I want to focus on the last question, because I think it raises the biggest issue. The moment we paste the code into our solution, we create an isolated fork of it. Whenever someone comes up with a better idea, or JavaScript evolves and our solution gets deprecated, we have broken code at our hands and someone needs to fix it.

The solution? The package itself. By outsourcing the code into the isarray package, we have outsourced the solution to the problem into a package that can be maintained in isolation. If I would come up with a better solution, I wouldn’t mock the existing one, but instead make a pull request and the next time I build my code I will have that solution as part of my application. And the biggest benefit: So will everyone else.

28000 files for a blank template — An indicator of possible improvements to our workflow

This great post also raised the issues of having way too many files required as a starting point for a blank project. I definitely agree with this premise, but I think we have to take a step back and look at the underlying issue and come up with a solution to solve it.

You see, the reason why we are doing an npm install in the first place is only to build and test our code. But do we actually need that step? Code is text, it will not change whether I have its dependencies installed or not. The reason why we have to install all these dependencies locally is simply because at this point in time, we have to build our code locally.

But what if we were to change this workflow? Videos, Audio, Images and even text are being happily streamed over the internet, enabling more and more users to get their content on demand instead of requiring a hard copy on their local disk. Why shouldn’t the same be true for our dependencies?

Why do I have to write my code locally and have every dependency installed on my system? I’m anyways using an code editor that is built on web technologies, I don’t think it is science fiction that someday I will just navigate to a URL and start coding. And when that day comes, I will no longer think about the number of files that my dependencies come with, I will not even think about the number of dependencies that I am relying on. When that day comes, I will build on current ideas right where they are stored. Directly in the network, in the open source community.

Conclusion

This week’s breakdown highlighted challenges that the JavaScript community has to face. We were tackled by serious issues around copyright laws and the infrastructure of our package systems.

But I feel that this can be seen as a good thing. It can be seen as a starting point for better code, better workflows and better teamwork in the community in general. It can be seen as a guiding point on how to improve our infrastructure to make sure that this doesn’t happen again.

It is fun and easy to mock and make jokes about these things. But we could also use the energy and time that we use to create joke libraries and services and use them to improve our community one small step at a time.

Our development experience is what we make of it, micro-packages might seem silly and are sometimes taken to the extreme. But the main idea behind it presents a future that puts collaboration and the community in the center, and even though we might not have the perfect representation of that in today’s infrastructure, I think that we are definitely onto something great which should not be dismissed the moment the first challenges arise. Instead, we should focus on the benefits and see what we can do to take our community to the next level.