Best practices for an API

[tomek-he-him]

There seems to be disagreement in the community as to where data should land.

1. Some say data should come last. Not without reason.
2. There’s a new function bind proposal which can result in very elegant code. There seems to be a lot of excitement about that.
3. At the moment we have many traditional libraries and ponyfills which take data as the first parameter.

These different types of APIs often result in ugly code when mixed together.

Should a library provide three different APIs for different styles then? Go for the most popular (3)? Most flexible (1)? Most hip (2)?

I don’t know if such tips are in the scope of this repo. But I hope for some discussion – because I feel lost :)

[stoeffel]

I would like if libs would provide multiple api styles (like f.e. lodash and lodash-fp). I think the way to go would be to create converter functions between different API styles, but blindly converting every function in a lib can be dangerous if you don't follow a strictly defined API. Btw. I just created such a converter bind-first and bind-last to make "traditional" libs work great with function bind-libs (i.e. trine). I think we will go the same way with 1-liners. There will probably be a 1-liners-curried/traditional/bindable.

[fregante]

I was wondering about this yesterday too, but I thought of callbacks, promises, sync functions, futures, observables, events, ... so many possible different interfaces, so good luck in picking "the right" interface, or just expect wrappers of wrappers of your original API, or publish infinite versions ^0/1/2/3/4/5 of the same lib.