This is the age of code components. Web, React, Angular, Vue, and even Node components are the building blocks of pretty much everything these days.

This makes sense. Software should be built by composing smaller, isolated functionalities together. Modularity and reusability are key for composability. When designing software, we should be designing a composition of smaller functionalities. When I say small, I don't really mean X or Y lines of code. What I do mean is small in the sense that it handles a single focus or responsibility.

On Reusability And Modularity

More and more, particularly when it comes to web components, it seems like designing isolated and reusable components is not only simpler than it used to be, it's sometimes the only right way to design them.

So, how come achieving true reusability for code components remains such a challenge? the answer lays not in design, but rather in the question how do we create, find and use these components.

Micro Packages Are Not The Answer

Obviously, we don't want to be copy-pasting components everywhere. Duplications are very bad, and there is no need to elaborate. The problem is, up until not the only alternative to duplicating code was publishing these components as packages, or "micro-packages".

I don't think small components should become packages. Packages are not fit for making them practically reusable, and they add too much complexity. Here is why:

• Initial overhead: to create a new repository and package for every small component you would have to create a repository, the package boilerplate (build, testing, etc.) and somehow make this process practical for a large set of components.

• Maintenance: modifying a repository and a package takes time and forces you to go through multiple steps such as cloning, linking, debugging, committing, republishing and so on. Build and install times quickly increase and dependency hell always feels near.

• Discoverability: it’s hard if not impossible to organize and search multiple repositories and packages to quickly find the components you need. People often used different terms to describe the same functionality, and there is no single source of truth to search and trust.

Making reusability practical

I'll start at the end- we built an open source project to solve this problem. It's called Bit and it enables us to quickly create reusable components during your workflow, export them to a distributed repository designed for code components called a Scope (which stores, organizes, manages, tests and builds your components) and then use them anywhere across repositories and applications. Components can be used as a virtual API pulling nothing but the code actually used in your application.

Bit was created to solve the three problems described above. To do so, it had to give components everything packages couldn't. It had to make them quick to create, simple to maintain and easy to find. Designed for code components, Bit introduces some new capabilities to make this not only possible but also practical:

Bit comes with a reusable and isolated component environment. This environment is also configurable, saving the overhead for creating new boilerplates for new components (which can be done directly withing any project you're working on). This environment also takes care of testing and building your components, using any framework you choose.

To organize, store and manage your components Bit uses "Scopes". A Bit Scope is a distributed and virtual layer of components on top of a source-code repository (and outside of it). You can export components to a Scope, where they will be stored, organized and made reusable. Scopes are distributed and can be used for organizing components by context, collaborators or other abstract methods. Scopes makes it simpler to maintain a large collection of reusable components, keeping them all in one place while modifying and using them individually.

Bit also solves the discoverability problem using the Scoping organizational system, and features such as a built-in semantic search engine.

Distribution and centralization

Distribution has many advantages, both practical as well as keeping things separated from commercial interests. However, centralization has its own advantages particularly in the areas of collaboration and the comfort of work. To help make work easier and collaborate as a team, we also built a free community Hub called bitsrc. It's free for open source and always will be. Here is an example Scope of utility functions I made with my team.

What now?

Bit is working, but it's also a work in progress.
For example, Bit is designed to be language agnostic and uses external drivers to work with different languages. Javascript is the first one we added, and more should soon follow.

Other features should also be added, such as automatic dependency definition, source code indexing, component quality measurement, semi-automatic semantic versioning and more.

For now, working with Bit and/or bitsrc allows us to create, maintain and reuse a growing set of "building blocks" including Web and React components, utility functions, small modules and more. This not only speeds up work and prevents duplications, it aligns with the basic principles of how software should be composed. One step at a time.

Feel free to try it out for yourselves, contributions on GitHub are always welcome.