Tiny libraries. Doing one thing well. A blessing and a curse…?
Adding libraries to a project with npm is easy and almost instant: curious developers can learn and experiment with different libraries in a single project.
Say “hi” to the elephant in the room
But the micro-library approach has a darker side when considering relevant real world uses at a larger scale.
Writing code to solve specific problem types with real-life time constraints and expectations (i.e. at your day-job) can seem daunting and repetitive: making appropriate library selections, bootstrapping everything, properly wiring libraries together, taking responsibility for updating them within your projects, etc.
Experience has shown this model does not scale well, with portfolios of similar applications growing in size.
Example package.json from a popular React starter-kit
For example, applications created by different developers may share 80% of their library versions in slightly different combinations to accomplish the same goals. Many libraries will also couple with your business logic to some extent.
Even the most talented and disciplined developers will find managing this a challenge.
The elephant exposed!
This type of library-composition/wiring complexity should be kept out of applications, right? But no, it’s embedded into every application or component by design!
That’s the price we pay for using small libraries instead of frameworks, right? So, should we just be using a framework?
A free choice of open source alternatives would be preferable; and we also like small, high-quality libraries, but only if they can be made easier to employ at larger scales by re-using library compositions.
Here at VG (Norway’s largest newspaper) this specific problem has been given some attention over the last few months. We’ve experimented with approaches that work for us without having to fall back into a restrictive framework.
Some general observations…
- To help others people share patterns and solution proposals as boilerplate and starter-kits on Github or Yeoman.
- As a consequence of boilerplate sharing we are no longer practising DRY (Don’t Repeat Yourself). We are duplicating boilerplate/glue everywhere. This mutates individually within our projects, leading to repeated efforts all over.
- Boilerplates are points of inspiration and ideas, few are tested and fit for production. Their code becomes your code, and ends up within your product space.
- The wide usage of popular micro-libraries across many applications needs to be better management.
- Projects should start quickly and move fast toward production-ready builds.
- Library composition patterns must be shared for immediate consumption.
We need something better.
Our current solution to this problem is Roc. We already have a working implementation of this ambitious concept, and it is open source. Currently in a pre-release alpha stage, we think it’s an awesome start to solving these problems.
Roc makes it easy to get started quickly, developer experience is taken care of, and there is an established path to production.
- Accessible: a self-documenting CLI (Command Line Interface)
- Simple: new, dev and build as simple commands
- Managable: all building and runtime settings configured in the same place using the same syntax
- Flexible: create your own packages and templates.
Once you have a setup that works well for you, why not formalise it as a building block and reuse it next time?
Roc works now. Try some of our pre-made extensions – it’s super-easy!