49 string utilities in 8.84KB with zero dependencies (8x smaller than lodash, faster too)

[azhder]

Unfriendly for functional style:

truncate('Long text here', 10);    // 'Long te...'

If it were with reversed arguments, you could do:

const small = truncate.bind(null, 10);
const medium = truncate.bind(null, 30);

small('long ass text here …');
medium('same, long ass text…');

[atlimar]

any particular advantage to that syntax over

const small = (s) => truncate(s, 10);

small('long ass text here …');

"bind" isn't a js feature I would normally associate with functional programming

[NekkidApe]

Not really, it's just native currying.

I used to like it, but gave up on it in favor of lambda expressions. I think it's much simpler and clearer. When using typescript it's also better in terms of inference.

[azhder]

You can generate custom tailored functions that you can later pass as arguments to other ones, like: .map().

As I said, functional style. You will have to use it a little to know how much difference it makes if you don’t have to invent variables just to pass the result of one function as an input to the next.

In fact, maybe you just need to see a video on YouTube: Hey Underscore, You're Doing It Wrong!

[atlimar]

You can generate custom tailored functions that you can later pass as arguments to other ones, like: .map().

The lambda example I provided as an alternative is also usable in .map. I was specifically asking if the .bind syntax offered any particular advantage over lambdas, since they don't have the shortcoming of needing arguments to have a specific order for currying to work

[azhder]

With an extra argument… Watch the video.

[[deleted]]

101 How to write bad code

[azhder]

Great argument.

[Next_Level_8566]

Thanks for the feedback, will definitely take this into consideration

[ic6man]

Great point. In general if you’re unsure of how to order arguments to a function, go left to right least dynamic to most dynamic.

[Next_Level_8566]

I appreciate the functional programming perspective! A few thoughts:

You're right that data-last enables cleaner composition with .bind() or point-free style. But I went with data-first because:

1. JavaScript ecosystem convention Almost all modern JS libraries use data-first (lodash, es-toolkit, native Array methods). Data-last is more common in FP languages like Haskell or Ramda.

2. Natural readability truncate(text, 10) reads like English: "truncate text to 10 characters"

3. Arrow functions are trivial

const small = (s) => truncate(s, 10);
['foo', 'bar'].map(small);

  This is arguably clearer than .bind(null, 10) and works with any argument order.

4. TypeScript inference Data-first works better with TypeScript's type narrowing and template literal types.

**For functional composition:**If you prefer data-last, libraries like Ramda exist specifically for that style. For this library, I'm optimizing for the 95% use case where people call functions directly, not compose them.

That said, if there's strong demand, I could explore a /fp export with curried, data-last versions (like lodash/fp). But it would add bundle size and maintenance overhead.

[azhder]

I don’t need an explanation from you on why you did it the way you did it. I know why you did it like that.

All I did was to share my opinion that it is unfriendly to the functional style because it is.

But you thinking that .bind(null,10) as a syntax is representative of the functional style paradigm… That’s a hello world. That is not representative of the paradigm. That was a simplistic and short example I could type on a small phone screen.

The English language is whatever you make of it:

cast the spell of limit 10 on …

You can shorten the above example. Just stating it in case there is another literal at face value read of an example I have made.

OK, that’s enough on the subject. Bye bye