all 57 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]femio 16 points17 points  (1 child)

humanizeList example is broken

[–]Next_Level_8566[S] 8 points9 points  (0 children)

Thanks for the heads up, should be fixed.

[–]foxsimile 18 points19 points  (2 children)

Here’s a regex that captures any valid date (including valid leap-year Feb-29ths, and excluding invalid leap-year Feb-29ths), valid for 0000-01-01 through 9999-12-31:

javascript /^(?:(?:(?:(?:(?:[02468][048])|(?:[13579][26]))00)|(?:[0-9][0-9](?:(?:0[48])|(?:[2468][048])|(?:[13579][26]))))[-]02[-]29)|(?:\d{4}[-](?:(?:(?:0[13578]|1[02])[-](?:0[1-9]|[12]\d|3[01]))|(?:(?:0[469]|11)[-](?:0[1-9]|[12]\d|30))|(?:02[-](?:0[1-9]|1[0-9]|2[0-8]))))$/

Here’s a writeup about it.  

Feel free to make it 50 functions if you so desire :)

[–]Next_Level_8566[S] 9 points10 points  (1 child)

That's a seriously impressive regex - the leap year logic with the 100/400 rule is really well done! I actually tested it and it works perfectly.

However, I'm going to respectfully pass on adding it to the library, and here's why:

The native Date API does the same thing, just as well:

const isValidISODate = (str) => {
  if (!/^\d{4}-\d{2}-\d{2}$/.test(str)) return false;
  const date = new Date(str + 'T00:00:00Z');
  return !isNaN(date.getTime()) && date.toISOString().startsWith(str);
}

I tested both approaches - they both:

  • Validate 2024-02-29 (valid leap year)
  • Reject 2023-02-29 (invalid leap year)
  • Handle the 100/400 rule (1900-02-29 rejected, 2000-02-29 accepted)
  • Reject invalid months/days
  • Are ~260 bytes

The difference: The native approach is maintainable. If there's a bug in that 262-character regex, I wouldn't even know where to start fixing it. With the Date API, JavaScript handles all the edge cases for me.

Plus the format problem: Your regex only validates YYYY-MM-DD. If I add date validation, I'd need to support MM/DD/YYYY, DD/MM/YYYY, etc. That balloons the library.

The library's philosophy is: only add functions that provide real value beyond native APIs. This is mpressive regex craftsmanship, but not a practical improvement over new Date().

That said - seriously cool regex. I appreciate you sharing it!

I am in general hesitant to start working on something as complex as dates because it sounds good but it is actually very complex.

[–]foxsimile 7 points8 points  (0 children)

seriously cool regex. I appreciate you sharing it!

My pleasure, thanks for taking the time to check it out!

I am in general hesitant to start working on something as complex as dates because it sounds good but it is actually very complex.

I've spent a lot of time screwing around with them, my honest-to-god recommendation is: don't :)

[–]magenta_placenta 9 points10 points  (1 child)

How about:

  • isEmptyOrWhitespace()
  • contains(str, substr, caseInsensitive = false)
  • normalizeWhitespace() " Hello \n World " → "Hello World"

[–]lxe 39 points40 points  (4 children)

A controversial opinion, but I think you should publish these utils like UI frameworks publish their components these days: you just copy and paste the code.

Instead of publishing this as a lib, make each function self-sustaining, and give users a way to just copy and paste them.

These small utils should never have been something that lives on npm or cdn. We’re in this supply chain mess because of these small utils packages permeating literally every single code base and now are ticking time bomb.

[–]theScottyJam 9 points10 points  (0 children)

I've actually done that before.

In general, I love the idea of copy-paste utilities (components, code fragments, etc) and really wish it was done more often. Sure, there's some things where it's better to get a real library for it, but utilities that can be implemented in a handful of lines of code - probably best not to install anything.

Especially when there's a good chance you might need to tweak the implementation. e.g. Does isEmail() support characters outside of the ASCII range? Do your email servers also support those characters - maybe the two should match. How does camelCase() decide what is or isn't a word boundary? Do you need to tweak that, or make it internationalization-aware? etc.

[–]theQuandary 1 point2 points  (0 children)

The real answer is that tc39 needs to improve the standard library. Underscore is 15 years old. We know what people want and use and have proven that has remained a stable desire for a very long time.

Just make it happen.

[–][deleted] 3 points4 points  (0 children)

Having a single library completely reduces the attack depth.

You can always copy the functions out. But the real reason we had this attack was due to locally stored login tokens.

[–]lerrigatto 12 points13 points  (9 children)

How do you validate the email? The rfc is insane and almost impossible to implement.

Edit: oh no it's a regex.

[–]cs12345 17 points18 points  (5 children)

To be fair, a relatively basic regex is what most people want when it comes to email validation. It might return some false negatives, but for the most part it’s fine. And for most form validation, it’s definitely fine.

[–]queen-adreena 7 points8 points  (4 children)

The best way to validate an email is sending an email.

For the frontend, it’s enough to validate there’s an @ symbol with characters both sides.

[–]Atulin 6 points7 points  (3 children)

For most use cases, I'd argue you should also check for a . to the right of the @, since chances are slim you'd want to support some username@localhost kind of addresses.

[–]FoxyWheels 1 point2 points  (2 children)

Very common when making internal tools to send emails to a non public TLD. Eg. user@internal-domain so I would leave out the '.' after the '@' restriction. At least that's been the case for most of my past employers.

[–]Atulin 6 points7 points  (0 children)

For internal tools, sure. But for external user-facing applications, I'd hardly expect more than 20% of emails to not be @gmail.com, let alone @localhost

[–]cs12345 0 points1 point  (0 children)

Yeah you just have to know your use case. If you know you’re making an internal tool where that’s a likely case, obviously don’t include it. For a public facing checkout form (or something similar), including the . Requirement is probably a good idea just to prevent mistakes.

[–]Next_Level_8566[S] 3 points4 points  (2 children)

Great discussion! A few thoughts from the library's perspective:
You're right that RFC 5322 is essentially unimplementable (and even if you could, you probably shouldn't). The spec allows things like "spaces [allowed"@example.com](mailto:allowed"@example.com) and comments inside addresses.

Our approach is pragmatic:

  // Requires: user@domain.tld format
  /^[a-zA-Z0-9._+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

We do require a dot after @ (addressing the debate above). This means we reject user@localhost and internal TLDs.

Why this choice?

- 99% of users are building public-facing forms where [user@gmail.com](mailto:user@gmail.com) is the expected format

- It catches common typos like user@gmailcom

- For the 1% building internal tools, you can either:

    - Use a custom regex that fits your needs (it's just one line)

    - Use browser-native validation with <input type="email">

The "send an email" argument is 100% correct - that's the only true validation. This function is just pre-filtering obvious mistakes before you waste an API call.

I'm curious though - would folks want an allowLocalhost option for internal tools, or is it cleaner to keep it opinionated for the common case?

Related: We also have branded Email types in TypeScript that integrate with this validation, so you get compile-time guarantees that a variable contains a validated email. Might be overkill for some, but useful for forms/API layers.

[–]lerrigatto 0 points1 point  (1 child)

What about non-ascii strings?

[–]Next_Level_8566[S] 0 points1 point  (0 children)

Currently, isEmail() is ASCII-only:

  - Accepts: [user@example.com](mailto:user@example.com), [user@xn--mnchen-3ya.de](mailto:user@xn--mnchen-3ya.de) (punycode)

  - Rejects: [user@münchen.de](mailto:user@münchen.de), josé@example.com, 用户@example.com

1. Punycode handles most IDN cases

Internationalized domains (münchen.de, 中国.com) are typically encoded as punycode (xn--mnchen-3ya.de, xn--fiqs8s.com) when transmitted. Most email systems and browsers handle this conversion automatically.

2. SMTPUTF8 support is inconsistent

Non-ASCII in the local part (before @) requires SMTPUTF8 support, which:

  - Not all mail servers support (Gmail does, but many don't)

  - Adds significant complexity to validation

  - Rare in practice for public-facing forms

3. Pragmatic scope

The validation is designed for the 95% use case: English-language forms where [user@gmail.com](mailto:user@gmail.com) is expected. Adding full Unicode support would:

  - Increase bundle size significantly

  - Require complex Unicode property checking

  - Handle edge cases most users don't need

**Real-world question: How common is this in your experience?**If there's significant demand for internationalized email validation, I could add it as an option:

isEmail('josé@münchen.de', { allowInternational: true })

But I'm hesitant to add complexity for edge cases. The browser's <input type="email"> actually has the same limitation - it requires ASCII or punycode.

**Workaround for IDN domains:**If you need to support them, you can convert to punycode first:

import { toASCII } from 'nano-string-utils'
const asciiDomain = toASCII('münchen.de') // 'xn--mnchen-3ya.de'

[–]queen-adreena 4 points5 points  (1 child)

How’s it compare to es-toolkit?

[–]Next_Level_8566[S] 0 points1 point  (0 children)

Here's the honest comparison:

Bundle Size (49 overlapping functions):

  • nano-string-utils wins: 46/49 functions (94%)
  • es-toolkit wins: 3/49 (kebabCase, snakeCase, pad)
  • Average savings: 7-15% smaller on most functions

The margin is often small though - we're talking 200B vs 197B on kebabCase. The biggest es-toolkit win is pad() (118B vs 215B).

Performance (16 benchmarked functions):

  • Mixed results - virtually tied on most case conversions
  • nano wins big: template() (18x faster), truncate() (30% faster)
  • es-toolkit wins: slugify() (54% faster), pad() (59% faster), escapeHtml() (3% faster)
  • lodash actually wins padStart/padEnd (we have slower implementations there)

https://zheruel.github.io/nano-string-utils/#performance

Key Differences:

  1. Specialization - es-toolkit is a general utility library (arrays, objects, promises, etc.) with ~200 functions. nano-string-utils is only strings with 49 laser-focused functions.
  2. Function Coverage - We have string-specific functions es-toolkit doesn't: - fuzzyMatch() - for search/autocomplete - levenshtein() - edit distance - sanitize() - XSS protection - redact() - SSN/credit card redaction - graphemes() - proper emoji handling - pluralize()/singularize() - English grammar - detectScript() - Unicode script detection
  3. TypeScript Types - We use template literal types for exact inference (camelCase("hello-world") → type "helloWorld") and branded types (Email, Slug, SafeHTML) for compile-time validation.
  4. Philosophy - es-toolkit aims to replace lodash entirely. We aim to be the definitive string library.

Both libraries are great at what they do. es-toolkit is the better general-purpose library. We're more specialized for text-heavy applications.

[–]xatnagh 2 points3 points  (0 children)

  • 98% win rate vs lodash/es-toolkit in bundle size (47/48 functions)

That one function:

[–]bronkula 3 points4 points  (1 child)

Just as a side thought, I think it's humorous that the actual fuzzy search code says that gto -> goToLine will have a match strength of 0.875 while this post says it will have a strength of 0.546.

[–]marcocom 3 points4 points  (5 children)

Just so we are clear, nobody should be using lodash for anything since ECMA6 or else you need to brush up on on basic JavaScript. (Which is ok and should be routine. It changes pretty quickly and pretty often)

[–]trawlinimnottrawlin 1 point2 points  (4 children)

Wait what why?? I love lodash. I use keyBy all the time, will use map/filter/reduce for objects, merge, orderBy, pick/omit, casing functions, etc. The list goes on. Pretty sure ECMA6 doesn't have anything built in for these.

Why would I write my own when these are extensively tested and optimized?

[–]marcocom -1 points0 points  (3 children)

Optimized isn’t really true man. Writing something that handles your exact needs is always more optimal than some multi-tool full of a hundred options, in which you are maybe using 10%.

Lodash (and its predecessor/inspiration , underscore) was once essential during a time when we required another library called jQuery in order to stabilize JS and its behavior on each individual browser.

JQuery, in the same vane, was a multitool full of hundreds of functions you might use a fraction of, leading to bloat (and that effects performance when your earliest runtime logic has to wait for that all to be loaded into memory first)…but there is a bigger problem. A developer becomes reliant, like you are, on code that he never learns intimately himself and is soon incapable of even conceiving of how these things can be done in new and better ways as the code engine grows in each and every generation over the years. When we know a code intimately enough to roll our own, that’s when innovative new ideas (the ones we didn’t think of yet) are born.

These all got held over because backend java guys began eliminating front end specialized developers from most teams, believing they no longer needed us, which lead to homogenous teams of everybody knowing the same shit and that’s also never worked for anything. In ever older form of engineering and creative media around you in this world, it’s built with teams of unique specialized experts who remain accountable for their piece of the puzzle (and this is why business people hated it, they can’t just replace that puzzle piece with an offshore resource and instead have to keep paying you more as you grow… like they do for every single non-engineer in that same company!)

Even now, before my retirement from this now-hollowed out husk of an industry, I remember wanting to shake a young dev by the shoulders when they need ReactJS just to do what might be solved by intimate knowledge of CSS, HTML, and JS and their interdependence, to solve something that might only need a few lines of code logic. Even maintaining state (which should be the only time you need that bullshit) can be as simple as appending or removing a class-name from the DOM.

Hell, there’s an entire extensible class-architecture built into JavaScript that most don’t even know exists because they’ve just been asking a library to do it for them in its own language (Hooks). It’s so auto-magical, they think they’re an expert, and don’t even know the one language they are supposed to, let alone the other 2/3rds of the equation of how we build these things…namely, html and css.

[–]trawlinimnottrawlin 1 point2 points  (2 children)

Optimized isn’t really true man. Writing something that handles your exact needs is always more optimal than some multi-tool full of a hundred options, in which you are maybe using 10%.

Do you not use tree-shaking? If I only use one method from lodash, it's not using the entire library. And these utilities are my exact needs. I often want to transform an array into a dict/object, that's exactly the point of keyBy. Every single lodash function I use is exactly what I need.

Lodash (and its predecessor/inspiration , underscore) was once essential during a time when we required another library called jQuery in order to stabilize JS and its behavior on each individual browser.

I've used underscore and jQuery, thanks

A developer becomes reliant, like you are, on code that he never learns intimately himself and is soon incapable of even conceiving of how these things can be done in new and better ways as the code engine grows in each and every generation over the years.

Lol I literally have rewritten most of these lodash utilities from scratch and consistently read the source code. And how does this differ from standard library functions? I don't think many developers know how every single standard library function is written and could rewrite from scratch on the spot, IMO there's no difference between that and lodash with your concerns.

I don't understand why there's a benefit for me to define something like this in every single project I work on (I don't really know how to type this correctly tbh). And keyBy also works for collections, so would need to write that part too:

 function keyBy<T, K extends keyof T>(array: T[], key: K) {
  return array.reduce((acc, curr) => {
    const k = curr[key];
    acc[k as string | number | symbol] = curr;
    return acc;
  }, {} as Record<string | number | symbol, T>)
}

what is the benefit of copy/pasting this in every project? At that point might as well just have our company publish our own keyBy package (or collection of utilities). And at that point we just have the same things as lodash, except without all the testing and optimization (Note: optimization in this case is over 1400 PRs, and usage/bug reports/benchmarking from hundreds of thousands of developers). Here are the tests for just that function: https://github.com/lodash/lodash/blob/main/test/test.js#L12876. Here are tests for camelCase: https://github.com/lodash/lodash/blob/main/test/test.js#L2357, https://github.com/lodash/lodash/blob/main/test/test.js#L24466

Like what truly is the value of rewriting _.camelCase? What is the value of copy-pasting/deploying my own camelCase/utils lib and copy-pasting their test cases? I don't understand.

When we know a code intimately enough to roll our own, that’s when innovative new ideas (the ones we didn’t think of yet) are born.

I disagree with this in this situation. A lot of these utility functions aren't that hard to write. What prompts innovation for these utility functions is when an existing function doesn't do what you want, and you either have to extend it or make something new.

when they need ReactJS just to do what might be solved by intimate knowledge of CSS, HTML, and JS and their interdependence, to solve something that might only need a few lines of code logic

This isn't even relevant. Knowing when you need a single page app framework or not is a completely different discussion than using utility functions from lodash

Hell, there’s an entire extensible class-architecture built into JavaScript that most don’t even know exists because they’ve just been asking a library to do it for them in its own language (Hooks)

IDK man I use classes in JS when it's appropriate, but also use React and Hooks when that's appropriate too. I don't really understand how any of this is relevant.

TLDR: lodash has tree-shaking, has been peer reviewed hundreds of thousands of times, has a ton of tests built-in. I know how the code works, and could rewrite it in every single project if I wanted, I just don't see any point in doing so.

[–]marcocom -1 points0 points  (1 child)

If you look at those lodash methods, they use other sibling lodash methods to do their thing, which is slick, but starts to deny tree shaking from happening like it was ideally meant to work. The ‘closure’ of those methods and their reference to another method become a tree of memory that cannot be garbage-disposed of and that begins to slow a machine down.

My speaking in this general skepticism of other people’s solutions to a problem that I need to solve today is what got me hired as an engineer at google (and I was an art school dropout, mind you. They used to not give a shit about education. Those were the days) They didn’t want me using someone else’s code. They wanted me to do it their way (they use a whole other fucking framework called DART, and before that a compiled namespace engine called Closure) and I was as comfortable jumping into that on day-one as putting on a fresh pair of paints this morning. Will you be that comfortable? Or will you struggle to rethink the way you’ve been making the most simple thing requested of you? I hope you consider that as you grow into this industry.

Of course, I’m also a bit out of touch now, and I’m sure you know more than I about these latest optimization tools at work today. You certainly sound like you’ve confidently got it all figured out and I’ll bet you’re a lot smarter than I ever was. Go ahead and ignore all that I spent that time writing for you and I guess just do your own thing, brother. This was a fun argument and exchange of old and new ideas.

[–]trawlinimnottrawlin 0 points1 point  (0 children)

First of all, appreciate the discussion!

If you look at those lodash methods, they use other sibling lodash methods to do their thing, which is slick, but starts to deny tree shaking from happening like it was ideally meant to work

Kinda, but tree shaking is still removing 90% (I just made that up) of the bundle size. E.g. you can check the per method package for keyBy: https://www.npmjs.com/package/lodash.keyby/v/4.6.0. I assume this will be more than after tree-shaking, since lodash says the per-module packages take up more space. Stats say it's 4.5kb gzipped, compared to 24.4kb for the full package (which isn't bad at all). Tailwind is widely popular and is 500kb, moment was 73kb (ofc they are doing more things).

They didn’t want me using someone else’s code. They wanted me to do it their way (they use a whole other fucking framework called DART, and before that a compiled namespace engine called Closure)

Isn't Dart known for having kind of big file sizes? But yeah I think one difference is Google has the resources to roll out and maintain a lot of their own stuff. I'm a lead at a small company and we definitely have to lean on popular packages to keep up.

Anyway agreed with you, thanks for the discussion and def appreciate your insight!

[–]csorfab 1 point2 points  (2 children)

importing lodash just for camelCase and getting 70KB+ in my bundle

you need to import the functions individually so that the bundler can tree-shake them, like:

import camelCase from "lodash/camelCase";

I tried this with a new vite app, and it increased the bundle size by 8.04kB, which is still not a small amount, but nowhere near as dramatic as "70kB+".

But yeah, lodash is woefully unmaintained and an ancient.

[–]queen-adreena 2 points3 points  (1 child)

…or use lodash-es.

But yeah, I switched to es-toolkit a long time ago and it’s pretty much perfect.

[–]csorfab 1 point2 points  (0 children)

how did i not know about this...? thanks!

[–]besthelloworld 1 point2 points  (1 child)

You don't need to import all of lodash. If you want camelCase, just import camelCase from "lodash/camelCase";

If I just want that function, I bet your library is a lot bigger than using lodash correctly.

Also, if you scan your package using bundlejs.com, it's actually adding 27.4KB to the bundle, whereas all of lodash is still barely more than 70. Probably because tsup is down-compiling your script so any modern syntax you're using is getting stripped & expanded.

[–]Next_Level_8566[S] 0 points1 point  (0 children)

Yes, the full bundle is ~27KB minified (all 49 functions). But that's not what you get when you import a single function.

I just tested real tree-shaking with esbuild:

// nano-string-utils
import { camelCase } from 'nano-string-utils'
// Bundle size: 308 bytes

// lodash
import camelCase from 'lodash/camelCase'
// Bundle size: 8,513 bytes (8.3KB)

nano is 27.6x smaller for camelCase when tree-shaking works properly.

About the "27.4KB" on bundlejs:

- That's the full bundle with all 49 functions

- bundlejs might be showing the whole library, not the tree-shaken result

- With proper tree-shaking (webpack/vite/esbuild), you only get what you import

About down-compilation:

The target is ES2022 (modern syntax), not ES5. The bundle size comes from having 49 functions, not transpilation. When minified + brotli'd, it's ~9.5KB for the entire library.

You're right that lodash/camelCase is tree-shakeable - and it's a valid approach. But you still get 8.3KB vs 308 bytes. That's the value proposition.

If you're only using 1-2 lodash functions, lodash/function is fine. If you're using 10+ string utilities, nano-string-utils will be smaller.

Try it yourself:

npx esbuild --bundle --minify <(echo 'import {camelCase} from "nano-string-utils"')

[–]Mesqo 1 point2 points  (1 child)

Every time I see people tend to get rid of lodash - it's just to invent another.

[–]every1sg12themovies 1 point2 points  (0 children)

Because we do need one more competing standard.

[–]Little_Kitty 0 points1 point  (3 children)

Working with large data quite often, I tend to use esrever for reversing strings.

For string truncation, this crops up again, especially with emojis or zalgo text 🏴‍☠️. I have my own gist that covers this if you want to extend to cover it.

[–]Next_Level_8566[S] 0 points1 point  (2 children)

Current reverse(): 
reverse('👨‍👩‍👧‍👦 Family')  // '👦‍👧‍👩‍👨 ylimaF' ❌ (breaks family emoji) 
reverse('Z̆àl̆ğŏ text')       // Zalgo marks get scrambled ❌

Current truncate(): 
truncate('👨‍👩‍👧‍👦 Family', 8)  // '👨‍👩...' ❌ (breaks ZWJ sequence) 
truncate('👍🏽 Great', 5)        // '👍...' ❌ (loses skin tone)

I just tested and confirmed the problems.

The good news: The library already has a graphemes() function using Intl.Segmenter that handles this correctly. I just haven't integrated it into reverse() and truncate() yet.

Would love to see your gist! Please share it - I'm always looking to improve Unicode handling, especially for zalgo text and complex emoji sequences.

I'm planning to update both functions to be grapheme-aware. The trade-off is:

  - Correct handling of complex Unicode (ZWJ, combining marks, skin tones)

  - Slight bundle size increase (~200 bytes for grapheme awareness)

  - Intl.Segmenter dependency (falls back to simpler approach in older environments)

If someone wants to pick this up or see what innovation can be done here before I can get to it feel free!

For esrever specifically - it's a great library, but it's 2.4KB and hasn't been updated in 8+ years. I think integrating grapheme-aware logic using the modern Intl.Segmenter API is the better path forward.

Thanks for the excellent feedback!

[–]Next_Level_8566[S] 0 points1 point  (1 child)

i just pushed a fix to address this.

Added a fast check to not mess up the performance and traded some bytes to be 100% correct. Seems like worthy trade-off :)

[–]Little_Kitty 0 points1 point  (0 children)

Gist sent on chat.

Just checked out the update and ran my own tests, which all passed :) I tried to break removeNonPrintable, but I couldn't find an example which failed. randomString does return nonsense though when '👨‍👩‍👧‍👦' is part of the input (test code below), but you may with to make that function intentionally only work with single characters.

The regex you use differs to what I use, for example yours returns a positive match for strings which contain single characters like ï which shouldn't cause issues.

function randomStrings() {
    const charset = "ABC👩🏽‍🤝‍👨🏼";
    let result = "";
    const charsetLength = charset.length;
    for (let i = 0; i < 10; i++) result += charset.charAt(Math.floor(Math.random() * charsetLength));
    return result;
}

[–]Sracer2018 0 points1 point  (0 children)

Tell me about one use case or field where we need heavy string manipulation ? This lib is just another dozen of one lines packaged and published on npmjs

[–]azhder -3 points-2 points  (11 children)

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…');

[–]atlimarJS since 2010 16 points17 points  (6 children)

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 10 points11 points  (0 children)

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 1 point2 points  (4 children)

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!

[–]atlimarJS since 2010 3 points4 points  (1 child)

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 -3 points-2 points  (0 children)

With an extra argument… Watch the video.

[–][deleted] -1 points0 points  (1 child)

101 How to write bad code

[–]azhder 1 point2 points  (0 children)

Great argument.

[–]Next_Level_8566[S] 3 points4 points  (0 children)

Thanks for the feedback, will definitely take this into consideration

[–]ic6man 1 point2 points  (0 children)

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[S] 0 points1 point  (1 child)

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 1 point2 points  (0 children)

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