use native Promise instead of bluebird about node-api

[tjconcept]

I have a refactor of the cursor thing coming up, specifically a simplification relying on the pull-streams patterns instead of Node.js streams.

For one I think pull-streams are superior to Node.js streams (patterns over implementations), but secondly this will get rid of the readable-stream dependency which in turn is dependent on the Node.js EventEmitter. Those represent a significant percentage of the code when bundling e.g. our dashboard.

As an extension of this I consider externalizing the toArray method. It is easily implemented in "user land" (copy/paste-able code will be provided in the examples and the change log) and going forward I would like to advocate using stream-based code (as opposed to buffering) when possible.
This is in part motivated by a desire to remove the mandatory status of limit for collection searches allowing true end-to-end streaming (following the slowest participant).

Removing toArray will kill the direct dependency on bluebird. However the fetch-one library (mostly a switch for browser/node http request code) still has it and as it is not initialized, the only way to "inject" a Promise implementation would be through a global (environment or setting).
This is as far as my plans go currently.

Intuitively I don't like the smell of "global" even if global just to a single package and I value packages that work without configuration or preparation of the environment. I dread issues like: the package is bundled for browsers, a programmer forgets to provide a Promise implementation, and suddenly IE users are complaining, or slight differences in implementations across browsers, or someone loads a script in an old environment.
Honestly I haven't given all of this much thought - and I reserve the right to completely change my mind 😀

Enough for the brain dump. Goodnight.

[danieljuhl]

I will just come with a quick comment. This API library is called node-api, thus assuming it is used in node would be (kind of) safe.

I fully get your point about have a module with everything included. The problem is, that using this library in project, which doesn't use bluebird for Promises, you'll end up with different Promise-types in your project, depending on who started the Promise - paylike or the project it-self.

The next issue with bundling everything in each module is the risk of having multiple versions of the same module, if all of these modules doesn't all reference the same version.

Bottomline - it's your API client, and you decide on the direction.. We'll probably just make our own light-weight Paylike client then 😀

[tjconcept]

This API library is called node-api, thus assuming it is used in node would be (kind of) safe.

I use it mostly in a browser environment 😇, but I would like it to be equally well in both situations. When naming the repo I considered a "js"-prefix, but it didn't seem like the industry standard. I guess "client" might have been better..

I fully get your point about have a module with everything included. The problem is, that using this library in project, which doesn't use bluebird for Promises, you'll end up with different Promise-types in your project, depending on who started the Promise - paylike or the project it-self.

Bluebird is "Promises/A+ compliant", wouldn't that guarantee interoperability?

The next issue with bundling everything in each module is the risk of having multiple versions of the same module, if all of these modules doesn't all reference the same version.

Which issues would you have from this? My experience is that node/npm is quite smart about this, and it is mostly an issue for browser bundles (getting bigger).

[danieljuhl]

Have you ever tried to count files and filesize of a node project? It is not rare that these consist of 100+ MB modules. npm can only dedupe if the required semver matches an already installed version, and you'll see that even very popular modules tend to use old version, simply because if it ain't broken, don't fix it, so a lot of stable and simple modules with a very limited feature set will get to a state, where they are not updated (as it isn't required) and their dependencies will then be outdated or maybe even deprecated.

But no need to go any further - I get your points, and understand your desire to keep this as batteries-included project which also works in browsers.

[tjconcept]

Have you ever tried to count files and filesize of a node project?

Yeah, sometimes it feels like the entire internet is downloaded.

But no need to go any further - I get your points, and understand your desire to keep this as batteries-included project which also works in browsers.

"batteries-included" is a nice term, that's the goal for now.
At some point I would like to get rid of a promise implementation, but as detailed above, it sticks a little deeper than this package. It might be that browsers catch up and I can simply remove the dependency.

Thanks for the discussion and feedback, keep it coming 🙂

[danieljuhl]

It might be that browsers catch up and I can simply remove the dependency.

We are closing in: http://caniuse.com/#feat=promises - and we (the developers) have an obligation to "break the internet" (to a degree - where we still respect our customers and our business) for those not upgrading, to force them in a better direction for all of us.