8 ms·

Counter-argument: A good micro-module removes complexity. It has one simple purpose, is tested, and you can read the code yourself in less than 30 seconds to k

• oblio 10y ago
  I don't agree with the explosion of micro-modules. There's a reason the vast majority of languages doesn't have them, at least not at function level. IMO in the Javascript world they're only there in order to minimize script size for front end work. See lodash & lodash-something1 / lodash-something2 / ..., where there's an option of using the whole module or just including 1-function long scripts, precisely to avoid the script size issue. Is there a solution for this? I know that the Google Closure compiler can remove dead code, ergo making inclusion of large modules less costly in terms of code size. Am I missing some ES6 feature that also helps with this?
• raverbashing 10y ago
  No, no, no Left padding is (almost in all languages) built-in, even C can do it with printf (edited) The problem is not having a library that offers that, but having this micro-module thing as a whole NPM module. No other language does that. If it was inside a string helpers, that's great. But don't make me one single module for just left-padding (or is-integer-number)
  • baudehlo 10y ago
    JavaScript much to my dismay has no sprintf. It's one of the most annoying omissions ever for server side work.
    • mayank 10y ago
      require('util').format gets you pretty close.
      • baudehlo 10y ago
        No it really doesn't. It is so far away from even Perl's printf (considered ancient by most JS programmers) that it is not even funny.
    • galistoca 10y ago
      es6 has one
      • baudehlo 10y ago
        No it doesn't. It comes with template strings. Any sprintf type functionality requires you to call functions on the input. It is a tiny tiny step forward.
    • deleted 10y ago
      [deleted]
    • lukeschlather 10y ago
      The biggest thing I've run into is that there's no built-in `mkdir -p`. There is, of course, a module that is literally just mkdirp.
  • joshmanders 10y ago
    Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016. JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.
    • raverbashing 10y ago
      I wanted to say that it's built-in in pretty much every other language apart from JS
      • joshmanders 10y ago
        But alas, here we are, talking about the JavaScript language and it's ecosystem. It's easy to say "I don't see why there's a need for an 11 line module to pad left on a string" when your language of choice has a robust standard library with such abilities built in.
    • GFK_of_xmaspast 10y ago
      I've never thought of C as being a particularly good example of "extensive standard library."
    • brudgers 10y ago
      C didn't get a standard (or a standard library) until 1989. It had been around for 17 years at that point. Two years after its invention, JavaScript was standardized in 1997. That's almost twenty years ago.
  • nathancahill 10y ago
    I think there's two points related to that: 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart). 2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back as you care to support. As pointed out in sibling, a proposal for padLeft is included in ECMA2016. But we'll still need Left-Pad for years after it's adopted.
    • jestar_jokin 10y ago
      Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination". Also, the Haxe language, which compiles to JS, has DCE. Micro-modules is certainly a solution if you don't want to use pre-processing or compilers. So is copy/pasting, or manually writing your own util libs, which seems safer than relying on third parties to provide one-liners for you.
      • nathancahill 10y ago
        Eh, to date, a large part of the JS community still recommends including .js files in script tags in HTML. So, while this has been possible for a while, there hasn't been widespread adoption.
      • sillysaurus3 10y ago
        I'm not sure dead code elimination works in that situation. Consider: var obj = { a: ... b: ... c: ... } If a, b, and c are functions, there is not necessarily a way to determine at compile time whether they will be used at runtime. var prop = webrequest(); obj[prop](); In that scenario, a, b, and c cannot be eliminated. But it would be worth testing Google Closure Compiler to see what it does in what scenarios. I've heard ES6 modules solve this problem, but it seems like dynamic access to an ES6 module might still be possible, which would cause the same problems for DCE. Perhaps no one writes code that way, so it doesn't necessarily matter. But what about eval? There are lots of tricky corner cases. It seems better to use small atoms than a monolithic package.
• peterjmag 10y ago
  Another interesting argument for micro-modules: https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328 https://github.com/sindresorhus/ama/issues/10#issuecomment-1...
  • deleted 10y ago
    [deleted]
  • AgentME 10y ago
    Wow, I feel like I could have written this. Back when I used Python, I had a folder full of functions I would copy-paste between my projects. (And maybe some of the projects contained unit-tests for the function. I didn't always keep those tests in sync.) Updating them was a pain because inevitably each one would get slightly modified over time in each project separately. Eventually, I bundled all of them into a bundle of completely unrelated utility functions in a folder on my computer somewhere, and I would import the folder with an absolute path. Sharing the code I wrote was a pain because of how much it referenced files on my local computer outside of the project. I never considered publishing my utility module because all of the stuff was completely unrelated. I'd rather publish nothing than a horrifying random amalgram that no single project of mine was even related to all of the subject matter present in it. With npm and the popularity of small modules, it was obvious that I could just cheaply publish each of my utility functions as separate modules. Some of them are about a few dozen lines, but have hundreds of lines of tests and have had significant bugfixes that I am very happy that I haven't had to manually port to dozens of projects. I don't miss copy-pasting code across projects, no matter how many claim I've "forgotten how to program".
    • Klathmon 10y ago
      I feel exactly the same. There is something about JavaScript that makes people go a little crazy both for and against it. I've never seen so many programmers advocate copy/pasting code before... But regardless of how many insults get thrown around, or how many people seem to think JS is useless or that it's a horrible language, its probably my favorite (and I've done professional work in non-trivial applications from C and C++, to Java and go, to python, Ruby, and PHP to BusinessBasic and even some lisp). I'm going to keep writing stuff in JS, and I'm going to keep loving it. Regardless of how many people are telling me I'm wrong.
• monochromatic 10y ago
  Padding a string is a one liner. I'm perfectly happy to write it, test it, convince myself that it works, and then forget about it and just use it.
• ksenzee 10y ago
  > every line of code I write myself is a commitment That's true. However: Every dependency you add to your project is also a commitment. When you add a dependency, you're committing to deal with the fallout if the library you're pulling in gets stale, or gets taken over by an incompetent dev, or conflicts with something else you're using, or just plain disappears. If you add a dependency for just a few lines of code, you're making a way bigger commitment than if you'd just copy/pasted the code and maintained it yourself. That's why so many people are shaking our heads at a 17-line dependency. It's way more risk than it's worth. If you need a better stdlib for your language (some of us write PHP and feel your pain) then find one library that fills in the gaps and use that.
  • joantune 10y ago
    OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.
    • ksenzee 10y ago
      You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.
      • jessaustin 10y ago
        ...you're making your code incompatible with anything that requires a higher or lower version of that library. Actually that's not correct when using node/npm (or anything else in the ecosystem like browserify). That is one of the impressive things about this platform: any number of different versions of the same module can be required by the same app. It would be nuts to do that in your own code, but as long as the craziness is in your dependencies it really doesn't matter.
        • 10y ago
• deleted 10y ago
  [deleted]
• thedudemabry 10y ago
  I agree with the points you've made, but I would also posit that adding a dependency using this mutable package manager is making a commitment to maintain the integrity of that dependency, which is arguably more work than maintaining the handful of lines of code.
• ars 10y ago
  What's wrong with copy/paste? Why do you need an external dependency on something so small?
• pfooti 10y ago
  Completely agree here - the problem isn't micro-modules. It's partly just a lacking standard library for javascript and largely just exposing issues in npm that the community was pretty ignorant of until just now. The whole "amaga, it's a whole package for just ten lines of code" is just elitism. Given the number of downloads on things like left-pad, it's clearly useful code.
  • STRML 10y ago
    Agreed as well. In fact, I would posit that this wasn't even really a problem until npm@3 came out and made installing dependencies far, far slower. Yet it was necessary; a standard project using babel + webpack installs nearly 300MB (!!!) of dependencies under npm@2, and about 120MB under npm@3. Both are unacceptable, but at least npm3 helps. I want to plug ied (https://github.com/alexanderGugel/ied https://github.com/alexanderGugel/ied) here, which both installs about 5x faster than npm@2, yet deduplicates as well as npm@3.
• CmdrKrool 10y ago
  I wouldn't mind so much if these micro-modules were written in a style of thoroughness; heavily commented, heavily documented with pre-conditions, post-conditions and all imaginable inputs and outputs explicitly anticipated and formally reasoned about. I don't mind over-engineering when it comes to quality assurance. Looking at that left-pad module though - no comments, abbreviated variable names, no documentation except a readme listing the minimally intended usage examples. This is not good enough, in my opinion, to upload to a public repository with the objective that other people will use it. It is indistinguishable from something one could throw up in a couple of minutes; I certainly have no reason to believe that the future evolution of this code will conform to any "expectation" or honour any "commitment" that I might have hopefully ascribed to it. [EDIT: I've just noticed that there are a handful of tests as well. I wouldn't exactly call it "well tested", as said elsewhere in this thread, but it's still more than I gave it credit for. Hopefully my general point still stands.] The benefits of reusing other people's code, to a code reuser, are supposed to be something like: (a) It'll increase the quality of my program to reuse this code - the writer already hardened and polished this function to a greater extent than I would be bothered to do myself if I tried right now (b) It'll save me time to reuse this code - with the support of appropriate documentation, I shouldn't need to read the code myself, yet still be able to use it correctly and safely. Neither of those things are true for this module. It's not that the module is small, it's that it is bad. (True that npm's mutability is a problem too - this is just a side-track.)
• wrboyce 10y ago
  I'd say you're playing fast and loose with the term "edge case" there. I call that a bugfix, for a feature that does not work.
• gizmo385 10y ago
  You're just trading in the complexity of the code you'd have to write for the delayed complexity of dealing with dependency issues down the line. It's a waste of a trade off for tiny things like this.
• esailija 10y ago
  It doesn't handle edge cases, it doesn't perform well and it isn't well tested. There is also no documentation. Obviously 30 seconds wasn't enough for you to verify anything at all about this module (namely that it's complete garbage). And just because some random guy didn't get something as trivial as this right the first time, doesn't mean nobody else can. Also the de facto standard library lodash already has padding utilities, made by people who have a proven track record.
• drinchev 10y ago
  Completely agree. Combining this with isomorphic code, cross-browser development and micro-services. I even wrote a blog post couple of days ago about it [1]. 1 : http://www.drinchev.com/blog/increase-your-dependencies/ http://www.drinchev.com/blog/increase-your-dependencies/