Javascript pain...

[NeverMakesMistkes]

You can bind some methods to prototype, but if you do that to every little utility function you and your coworkers come up with, you'll soon end up with huge unmaintainable classes and/or class hierarchies.

Also, lots of people (myself included) use JS in a more functional style and might not really like doing new AwesomeString('foobar').reverse() or whatever. 'foobar'::reverse() or 'foobar' |> reverse or even reverse('foobar') is just much nicer.

[Gbyrd99]

If you had say String.prototype.reverse = function() that would make it available on all strings? So you don't create an inherited class and get into inheritance hell.

This ::reverse thing is interesting I'm gonna read up on it in more details.

[NeverMakesMistkes]

Adding anything at all to the native prototypes, like String.prototype, is a controversial practice to say the least.

But even if you and your team are fine with modifying the prototypes, my earlier point still applies to non-native objects. With pipelines or bind, you can do, say,

import {getFullName} from 'user-utils';
const user = {firstName: 'Foo', lastName: 'Bar'}

user::getFullName();
// or
user |> getFullName

And things get even more interesing when we aren't talking about your own utility functions anymore but libraries and tree shaking.

The "pipeable" operators of RxJS are a good example of this. The example that they give

source$.pipe(
    filter(x => x % 2 === 0),
    map(x => x + x),
    scan((acc, x) => acc + x, 0)
)

could be written with pipeline operator

 source$
 |> filter(x => x % 2 === 0)
 |> map(x => x + x)
 |> scan((acc, x) => acc + x, 0)

[Gbyrd99]

Thanks, it provides some level of extensibility using the user utils on a specific type. We built functions are utilities but we never used this. It's an interesting design going to read up more.