For the curious developers only wishing to learn and experiment with a lot of different libraries in a single project; this is fantastic.
Let’s address the elephant in the room
There is also a darker side to this micro-library approach if we consider relevant uses in the real world at a larger scale.
“But there is also a darker side to using this approach if we widen our gaze”
When writing code to solve a specific type of problem with real-life time constraints and expectations, for example at our day-job, the current model of having to make the appropriate library selection, bootstrapping everything, wiring the libraries together in a good way is demanding. Also having a true responsibility of keeping them all up-to-date within your projects onward can seem daunting and repetitive. Experience reveals that this just does not scale well as the portfolio of often similar applications grow in size.
This type of library-composition/wiring complexity is something we would really want to keep outside of our applications, and right now we have it embedded into every application or component . By design!
This is currently the price we pay for using small libraries instead of frameworks.
“This type of complexity is something we really want to keep outside of our applications”
So, should we just be using a framework then?
Well no. We would still like the option of choosing the open source alternatives that we prefer, freely. We also like small high-quality libraries, we just want to make them easier to use at a larger scale by re-using our library compositions.
Here at VG (the largest newspaper in Norway) we have given this specific problem space some attention the last few months and have experimented with finding an approach that can work for us without having to fall back into a restrictive framework.
Some general observations of the situation:
- People share their patterns and solution proposals as boilerplate or starter-kits on Github or Yeoman to help others.
- We are no longer practicing DRY as a consequence of boilerplate sharing. 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.
- For the wide usage of popular micro-libraries across many applications to be managable, we need an approach that addresses this better.
- We need to get started with our projects quickly, and move fast toward production-ready builds.
- We need a way to share our library composition patterns ready for immediate consumption.
We need something better.
We are now presenting our current solution to this problem: Roc . An ambitious concept of which we have made a working implementation. And it is open source. It is currently in a pre-release alpha stage and we think it is an awesome start to solve these problems.
Roc solves getting started quickly, with developer experience taken care of and an established path to production
- Accessible : A self-documenting Command Line Interface (CLI).
- Simple : new, dev and build as simple commands.
- Managable : Configure all building and runtime settings in the same place using the same syntax.
- Flexible : Create your own packages and templates.
Once you have a setup that works really well for you, why not formalise this as building block that you can re-use in the future?
Roc provides a way of grouping your favourite libraries from npm into single CLI-powered packages .
Originally published on tech.vg.no