1. 4

  2. 3

    If you need any proof of the misguidedness of this, the entire “isArray” example.

    Why? Because that “code snippet” is built into the blasted language already.

    This is exactly the reason that there is a whole train of thought that modern Javascript developers aren’t programmers, because they rely on little snippets instead of learning their own language.


    Also, the front page of the author’s site appears to be broken. Maybe they forget to npm install --save express-xyz-front-page?

    1. 5

      To be fair, that version was added in ES5. So it’s handy for anyone looking to patch that in for old browsers. And foo instanceof Array doesn’t work across iframes (which is why it gets casted to a string by that package), which is a nifty bit of trivia that I doubt many people know/think about regularly.

    2. 1

      What about security? Maybe you could have trusted reviewers sign every version of every micropackage?

      1. 1

        every reason he lists is a reason to make packages with commonly used code. They are not a reason to have a package per function. The need to have them be a package per function is unique to javascript and the browser and it’s lack of dead code optimization intersecting with the need for shipping less stuff to the browser.

        1. 3

          as it turns out, Joe Armstrong of Erlang once wrote a post to the Erlang mailing list in which he said:

          I’m proposing a slightly different way of programming here The basic idea is

          • do away with modules
          • all functions have unique distinct names
          • all functions have (lots of) meta data
          • all functions go into a global (searchable) Key-value database
          • we need letrec
          • contribution to open source can be as simple as contributing a single function
          • there are no “open source projects” - only “the open source Key-Value database of all functions”
          • Content is peer reviewed

          i dunno. maybe it’s not so crazy? i haven’t decided.

          1. 2

            I’m getting close to a module per function in my Scala projects. I want to avoid having circular dependencies between classes (with a few specific exceptions). Having them in separate modules with explicit dependencies between them enforces that.

            1. 1

              If you’re running it through the Closure compiler, you can indeed get dead-code removal (see docs). Of course, that’s not common practice.

              1. 2

                Rollup.js also does this

                1. 2

                  As does Webpack 2 (currently in beta). However, both Rollup and Webpack 2 require the use of ES6 modules in order to take advantage of their tree-shaking features.

                2. 1

                  yes I was a little abbreviated there, but Closure does give you this, provided all the rest of the javascript is also in Closure. For most of the javascript ecosystem this is not true so it’s not really a solution either.