The modern days of JavaScript has us shifting away from the more traditional and rigid frameworks. Instead we are now in a fast-moving trend of using a large number of micro-libraries from npm that are combined within our own projects.
This approach yields great flexibility and freedom of choice for us as JavaScript developers. We get to pick the exact building blocks that we would like to use in order to build our apps and components. With tools like Babel and Webpack one really can use the latest technology to get things done. Adding libraries to our project with npm is easy and almost instant. Yeah!
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.
Having the sum of dependencies and dev-dependencies approaching three digits within a JavaScript project today is not unusual. Many of the applications end up with very similar, but still different setups. For example applications created by different developers may end up with 80% of the same library versions and then combined in slightly different ways with the same end-goal in mind. Many libraries also couple with your business logic. Keeping on top of this is challenging for even the most talented and disciplined of developers.
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:
- For certain types of applications, very popular patterns and choices emerge in the JavaScript communities. Take React + Redux for example, typically built using Webpack.
- 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
Roc is
- 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.
Roc works now, so try it out using some of our pre-made extensions! It’s super-easy.
Follow us by watching the repository on Github and @vgtech and @roc_js.
We have also written about how you get started on your first React + Redux project in detail here.
Originally published on tech.vg.no
