1. 11

I expect many to disagree with the guide and that’s fine—it’s not 100% my opinions either and a lot of links are to the author’s projects. I just think it’s cool that there are some people thinking about simplifying JavaScript development.

  1.  

  2. 3

    I think this might be a parody, since almost every point is opposite the current conventional wisdom (simplify with arrows, promises, usw)

    1. 3

      If you’re asking seriously, it’s not a parody as the author is a friend of mine (and we’ve talked about this) and you can see this philosophy in his code and other Node programmers such as mafintosh, Max Ogden, Dominic Tarr, etc. They all love their callbacks and streams.

      The reason why this guide was made is because it is against most modern conventions so I thought I’d share a different point of view.

      1. 1

        I appreciate these suggestions - not many people go with caution.

    2. 1

      Kinda bizarre that they aren’t advocating Promises to make life simpler, but yeah this is an interesting read.

      1. 2

        I’ve found that the crowd Yoshua codes with (mafintosh, Julian Gruber, Max Ogden, Dominic Tarr) in general doesn’t use Promises. Not sure why but that explains their absence.

        1. 1

          I guess because you need to polyfill them in the browser, and also the standard Node libraries don’t use them.

          1. 1

            That is why libraries like bluebird have promisify and promisifyAll type of helpers, which wrap the normal node-callback style API and give promise based API. Kind of reminds me of C++ libraries exposing C API so people outside of C++ ecosystem can use them.

            1. 1

              Yes indeed, and along with that, you add another dependency (bluebird), and extra “stuff” like promisify calls to your codebase. Perhaps it’s worth it to do so, perhaps not. In either case it’s a step away from the minimalist philosophy advocated by this document, which is why I think promises are not included.

              1. 3

                Eh, a minimalist life philosophy may mean that buying and keeping soap is extraneous–that doesn’t make such an approach hygenic!

                Promises are a feature that, in Node for a while now, can be relied on to be there in the core package. And they’re a hell of a lot neater than callbacks.

                The more I look at it, the more places I disagree. LevelDB instead of PG? Some weird shell script (installed via npm no less!) for handling Nginx?

                Not convinced, but hey, that’s just like, my opinion, man. Other good stuff in there too though.

                1. 1

                  If you’re writing a web server or something that isn’t going to be a dependency I can see a case for using promises. But if you’re writing an npm library for public consumption, I think there are a few reasons not to use promises:

                  • Exposing promises makes your library inconsistent with the core libraries (like fs).

                  • Along these lines, if a consumer of your library prefers callbacks to promises, it’s more difficult to opt out. However if you use callbacks in your library, there exist tools like promisfy or to let a consumer easily wrap your library with promises. For this reason I think putting promises into a library makes it overly opinionated.

                  • A library that uses promises requires consumers to polyfill if they are using browserify and slightly older browsers. (This is even worse if the library uses promises internally but doesn’t expose them as part of its API because the polyfill requirement isn’t obvious.)

                  • Besides requiring more work from end-users polyfills also increases byte size.

                  • Finally, regarding polyfills - if callback-based library X depends on one’s promise-based library P, and a consumer downloads library X, users of that library X might not realize they have to polyfill promises because of the indirect dependency on library P, which can lead to an unpleasant surprise.

        2. 1

          Lots to disagree with here. But one part I agree with:

          If you ever need composable async in Node, consider using streams.

          Not that I am an expert in Node anything, but this is my preferred way of keeping my head above water in data-processing JS. There are a lot of benefits to thinking in streams.