Functional composition leads to code maintainability. Also, if I can achieve the same process with native code as with hand-written code, I will always prefer native code (unless I face a performance barrier and hand-written code can help). part was the first library I wrote which I felt got me really close to reusing native code in a pattern which supports functional composition.
“But native functions are too slow!” Yeah, that part sucks. But I no longer look for opportunities to
micro-optimize before writing something maintainable. But that previous life informs me if I actually have
a performance issue to solve:
.bind(), any iterator, loops vs. function calls, unravelled loops, etc.
Besides, native functions can get better with environment improvements. My handcrafted code… probably not.
I was missing a simple bridge between those native functions (like
Array.prototype.reduce) and my
use of them in the
part pattern. With part-native, I may have
built my bridge. I’m currently putting it through some exercises in my
repo. By far, my favorite usage involves syntax like this:
If the method exists in the environment,
part-native will find it,
.borrow() it (using
part) and cache it.
This might also be useful for capability detection. Anyway, look for imports of
part-native instead of
part in future repos.