For all its virtues as the lingua franca for developing Web apps, JavaScript hasn’t always lent itself to modern and efficient programming practices. Not long ago, for instance, shortcomings in the language led many developers to write JavaScript programs as huge, monolithic entities instead of building them from common and reusable software building blocks, also known as “modules.”
JavaScript is more amenable to such Lego-like modularization than it used to be, but the practice still isn’t as widespread as some would like. So NPM, a startup mainly known for eponymous open-source software that installs and manages JavaScript programs, has decided to give things a nudge in the right direction.
Its new initiative is called Private Modules, and at first glance it mainly looks like a premium code-repository service, similar in many respects to GitHub’s services. NPM already offered a free Javascript-only repository service for open-source code. Private Modules introduces a paid option for developers or companies that want to keep their JavaScript private.
But that’s not the interesting element here. Where GitHub’s paid options limit users to a specific number of proprietary-code repositories—$7 to $50 a month gets you between five and 50 private code repositories—NPM has gone, well, unlimited. A flat fee of $7 a month for individuals, or $5 a month per person at an organization, gets you as many private JavaScript-storage buckets as you want.
Why unlimited? Because, NPM CEO and founder Isaac Schlueter says, it will encourage companies to build and use individual JavaScript code modules, each of which can now live in its own repository.
All Mod(ule) Cons
“There’s a broad trend where people are switching from building monolithic apps to small modules that can be pieced together,” Schlueter told me in an interview.
Such modules vastly simplify the process of both building and updating programs. Much the way it’s far simpler to replace a light fixture than to completely rewire your house, it’s much easier to pull out and replace an old code module with a new one than it would be to rewrite a much larger monolithic program.
See also: How Node.js Stays On Track
NPM’s move here basically reinforces the notion of modularity at the repository level. It’s an idea you might even sum up in a slogan: “One repo, one module.”
Edmond Meinfelder, director of Web and mobile engineering at DocuSign, uses NPM Enterprise to manage the company’s massive—and monolithic—JavaScript codebase.
“We have a huge legacy code base, but we’re just starting to refactor it and break it down into small modules,” he said. “Modules are easy to understand, easy to write tests for, and make creating new functionality much easier.”
While Meinfelder said DocuSign will continue to use the Enterprise option since it’s tailored to large companies, he plans to use Private Modules as an individual. Furthermore, he said that NPM’s move in this area helped DocuSign realize that it’s worth the effort to break its JavaScript programs down into modules:
On Private Modules, you could host all the modules of an app without worrying about going over your pricing plan. Private Modules shows companies and individuals that its within their price range to build apps the right way.
More Modules … And Fewer Users?
When the announcement made Hacker News Tuesday, however, some individual developers were less enthusiastic about the new direction. One major concern: Private Modules might effectively limit the number of users who can work on non-open-source projects. GitHub’s premium pay-per-repository model, by contrast, encourages unlimited collaboration on a limited number of repositories.
“Everything looks pretty awesome, except the payment model… With NPM’s model all my collaborators will have to pay for NPM private modules as well,” one commenter noted. Another suggested that NPM’s per-user payment scheme might turn off small companies:
Sounds like a big pain to have to pay individually for each person on a team if your company wants to use private modules. We’re generally willing to throw money at problems like those private modules solve, but if we have to do it a dozen times it probably isn’t going to happen.
Schlueter remains confident that NPM is moving in the right direction by encouraging practices that have been spreading among developers for decades.
“If we want to look back to the historical roots of this decision, even the shift from Multix to UNIX was about splitting up code into independent parts,” he said. “From the GNU Revision Control System to Git, the trend has been for things being broken into smaller pieces. NPM is a really good example of that in practice.”
Lead image by David Hamilton for ReadWrite (via Build with Chrome); photo of Isaac Schlueter courtesy of NPM
