Modern Javascript development – a rethink

Tiny libraries. Doing one thing well. A blessing and a curse…?

What’s the reasoning behind Roc, a modern JavaScript toolkit?


vg1Modern JavaScript projects are shifting away from traditional, rigid frameworks, towards large numbers of micro-libraries from npm.

Yielding great flexibility and freedom of choice for JavaScript developers, this approach lets developers pick the exact components to build apps and components with. Tools like Babel and Webpack let you get things done using the latest technology.

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.

Yeah! 🙂

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.

packagejsonExample package.json from a popular React starter-kit

Dependencies and dev-dependency totals approaching three digits within a JavaScript project are no longer unusual. Applications can end up with very similar, but still different setups.

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!

vg4This 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?

Well, no.

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.

VG Hackday, hacking getroc.org from scratch using Roc.

VG Hackday, hacking getroc.org from scratch using Roc.

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…

  • Popular patterns and choices emerge for some applications in JavaScript communities – React + Redux, for example, typically built using Webpack.
  • 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.

Roc is…

  • 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?

vg7Roc can group your favourite npm libraries into single CLI-powered packages.

Roc works now. Try some of our pre-made extensions – it’s super-easy!

Follow us by watching the repository on Github and @vgtech. Watch out for another post on getting started on your first React + Redux project in detail.

More to read about Software engineering
SUBSCRIBE TO OUR UPDATES
Menu