Left-pad as a service

this is fantastic! What is your stack? Are you NoSQL or relational? Redis? What is your test coverage? I am sure you hiring only trendy developers. I see huge potential in your service, do you accept private investments? I would like to get in now, before Google or YC snatches you! again, keep up good work and - can't wait for right-pad next year!

I can't speak for anybody else, but you highlighted the origin of my general annoyance.

Applying cross-domain concepts to improve your local domain is awesome.

Applying somebody else's invention from a different domain to your local domain and then acting like you invented a new thing is... annoying.

If various forms of "reinvention" didn't seem to come with a Twitter-cult and snazzy *.io website screaming, "Look at me! Look at me! See how awesome this totally new thing is that I'm pretending to have pioneered!" There'd be no inclination for anybody to respond with, "Um. You didn't invent anything. Please calm down."

If you throw yourself a parade everyday celebrating the genius of having figured out how to wake-up in the morning to attend your parade, then inevitably somebody is going to rain on it.

I don't buy it. You need a place to keep your own repository, and once you have that, keeping copies of other repositories is pretty much free. Keeping up, backing up, and securing N repositories is no more work than doing that for one repository. You can still outsource this, even. There's nothing wrong with using GitHub or Bitbucket or whatever for your repositories, just make sure that you're using your repositories, not relying on other people's.

The only thing that potentially gets harder is refreshing the packages, and I'd argue that's actually a good thing because that's really just saying that packages don't randomly change out from under you. In any case, your package manager should make it easy to refresh them when you want to, just say "go update that dependency to the latest available from the official source" and let it do its thing. If package managers don't offer this, they need to start.

I'm ready to get downvoted to hell with this comment but here we go..:

I feel like only non-javascript devs are bashing against small modules and NPM. All great javascript devs I know LOVE that mentality.

Let me offer some reasons why I (as a current Javascript dev having professionally coded in C/C++/Java/Python/PHP/Scheme) think this is great:

- Unlike most other languages, javascript doesn't come with a battery standard library. So you're often left on your own to reinvent the wheel. I mean, common, in Python you do "'hello'.ljust(10)" but AFAIK there isn't such thing in javascript. Javascript is more like the wild west where you need to reinvent everything. So having well tested libraries that does one thing extremely well is really beneficial.

- Javascript, unlike most other languages, has some pretty insane gotchas. I.e. "'0' == 0" is true in javascript. Most devs have been burned so bad in so many ways in Javascript that it's comforting to use a battle-tested library, even for a small feature, rather than reinventing it.

- And anyway, where should we put that function? Most big projects I've worked on have some kind of "helper file" that has 1500 lines, and then at some point different projects start depending on it so noone likes to touch it, etc. So, yeah, creating a new module takes a bit more time, but remember that it's not about the writing time but more about the maintenance time. I'd much rather have lots of small modules with clear dependencies than a big "let's put everything in there" file.

- I feel arguing about whether something should be in a separate module is similar to arguing without something should be in a separate function. For me, it's like hearing "Hey, learn how to code, you don't need function, just write it when you need it." And hey, I've worked in projects professionally where they had no function and it was TERRIBLE. I was trying to refactor some code while adding function, and people would copy my function inside their 1500 lines file. Let me tell you I left that company really fast.

- It's fair to say that UNIX passed the test of time and that the idea of having lots of small programs is extremely beneficial. It forces common interface and great documentation. Similar to how writing test force you to create better design, modularizing your code forces you to think about the bigger picture.

- As far as I'm concerned, I really don't care whether a module is very small or very big, as long as what it does is well defined and tested. For instance, how would you test if a variable is a function? I don't know about you but my first thought wasn't:

   function isFunction(functionToCheck) {
     var getType = {};
     return functionToCheck && getType.toString.call(functionToCheck) === '[object Function]';
   }

Who cares if it's a 4 lines module. I don't want to deal with that javascript bullshit. Yes, I could copy past that in my big helper file, but I'd much rather used one that the javascript community use and test.

- Finally, it seems like Node/javascript hasn't started that way. Not so far ago with had Yahoo monolithic javascript libraries and jquery. Even the first versions of most popular node library (such as express) were first written as a monolithic framework. But it's been refactored into dozen of small modules with clear functions. And now, other libraries can just import what they need rather than the whole project.

OK, so I told you about the good thing. What about the bad thing?

- Adding dependencies to a project is REALLY HARD TO MAINTAIN. I've had so many bad experience using node because of that. I.e. I work on a project, it's tested and work fine. 2 months later I clone and start the project and everything breaks. Oh, X and Y libraries decided to fuck everything, that other library now depend on a new version of Node, but I can't upgrade node because that other library depend on a previous version of Node. It's complex. I won't go on in explaining my solution to this problem, but enough to say that it's a problem and installing random amateur libraries in a professional project can lead to disaster.

- It takes longer to code. I've touched that earlier. It's a tradeoff about write now vs maintain later. Take a look at segmentio github repo: https://github.com/segmentio. I'd personally love to have that as onboarding experience rather than some massive project with everything copy/pasted a few time. But yes, it took them more time to create those separate modules.

Umm... then you should reconfigure your browser as the site does not specify a font.

It is plain jane flat html and the content is in a

 tag.