Going Native
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 utils
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.