TL;DR - Runnable only solves the small-picture problem. The best solution to the bigger-picture problem would make Runnable obsolete, because it's an anti-pattern to begin with.

---

The small version of the problem is that it's hard to find these snippets spread out across the internet, and then figure out if they work, and then copy-paste them into your program. Runnable solves the finding problem.

But the bigger version of the problem is that you shouldn't be copy-pasting these snippets into your codebase all the time, no matter how small they are. If they are useful enough that you find yourself looking them up often, or they are useful enough that they merited being posted on someone's blog, then they are useful enough to make into a package and share them properly. The node.js module system with npm gets extremely close to this goal. And for client-side Javascript, component[1] does the same thing.

[1]: https://github.com/component/component

This is one place where other client-side Javascript package managers completely fall over. There are multiple different "types" of packages.

1. There are the typical "big libraries"

- jQuery
- superagent
- mocha
- d3
- backbone
- underscore
- angular.js
- etc.

2. Then there are "plugins", which are pretty big in scope themselves. They have to be big enough to be "plugin-worthy", influenced mostly by how annoying it has been to install plugins in the jQuery days, via copy and pasting them into your /libs folder. These are things like:

- backbone marionette
- jQuery waypoints
- underscore string
- any jquery plugin
- any angular plugin
- etc.

Most package managers, with that kind of thinking in mind, stop there, at the "big library" and "plugins" level. Bower has this shortcoming. It's great for quickly grabbing a copy of jQuery and a few jQuery plugins, but it doesn't actively encourage making smaller modules, which is critical to solving the big-picture need Runnable is trying to solve.

3. The third type of package are tiny modules that at first glance you are tempted to just stick right into your /utils folder. These are so small that in old-school package managers it would be more hassle just to make them into packages. (This is why it's crucial for package managers to have as little beaurocracy as possible by the way, to avoid that line of thinking.) These are things like:

- https://github.com/matthewmueller/uid
- https://github.com/yields/has-transitions
- https://github.com/pazguille/shuffle-array
- https://github.com/ianstormtaylor/to-snake-case
- https://github.com/jwerle/to-csv
- https://github.com/segmentio/canonical

Those tiny modules are the kinds of things you find StackOverflow answers for all the time. People keep having the same problems over and over again, and eventually the answers get voted up. Things like, "how do I convert a camel case string into a snake case string?".

As soon as you take those simple tasks and package them up in a way that installing them is as easy as:

$ component install ianstormtaylor/to-snake-case

Then you start to see crazy gains in productivity and quality of your code. When you do that you aren't copy-pasting some shoddy StackOverflow answer into your codebase, so that the onus is now on you to maintain it. Instead, you're just dependning on an open-source component that is packaged along with tests to make sure it continues to work. It's visible by tons of others, can be improved when bugs crop up, and you don't need to maintain yourself if you don't want to.