Discussion: How Far Should More Helper Functions Be Integrated?

[baxyz]

Hi everyone,

Today, I'm looking for your opinions on an idea that's been on my mind.

As a developer in the industry, I often find myself needing to rewrite the same code repeatedly due to licensing constraints. To address this, I created sidekick libraries designed to complement core libraries like radashi. These helpers are crucial but often missing from primary libraries, even though they usually follow the same ethos (lean, simple, etc.).

For example, functions such as:

• URL manipulation: add/remove leading/trailing slashes, combine paths, etc.
• String manipulation: labelize, etc.
• Promise: throw if empty response, etc.
• ...

After 10 years of repeatedly recoding, I’ve finally developed a library to cover these gaps. Now, I’m at a crossroads: should I invest more time in this standalone library or explore the possibility of integrating these functions into an existing library like radashi?

Note: This library is called helpers4 and is still in its early stages, lacking professional polish.

With tree-shaking, the need to limit the number of functions to avoid bloat feels less relevant now. While I fully support radashi’s ethos of balancing utility and simplicity to remain lean, should we still limit the number of helper functions as much as possible? Or simply, how far should we go?

Some approaches to consider:

• While remaining lean, allow helpers on non-primitive types (like URL) and on human-centric manipulations (string, array, ...).
• Should we consider a tiered approach for the library, such as a basic version and an extended one? Or plug-able libs ?
• Could categorising functions by types (objects, strings, etc.) be beneficial, allowing us to embed more functions in an organised way? For example, import {labelize} from "@radashi/string". This also opens the possibility of having functions with the same name across categories (whether that’s a good idea is another discussion, but it's worth noting that libraries like FontAwesome follow this approach).
• Is it better to maintain a basic library (radashi) and have separate ancillary libraries?

Looking forward to hearing your thoughts.

Other references:

• The ethos of Radashi #20
• Reference complementary packages in the docs #157

[aleclarson]

Hey @baxyz, welcome to the community! The more people like you here, the better.

You bring up some great questions. I'll try to address each individually, but first let me explain my vision somewhat. As of now, I'm leaning toward keeping the core radashi package dedicated to the most popular utilities. If you have ideas for potentially niche utilities, I think it would still be valuable to open a PR for each of them, to help gauge the community's interest. I want Radashi to remain open to unconventional ideas, so the library can evolve with the JavaScript ecosystem or even be a leader of it.

While remaining lean, allow helpers on non-primitive types (like URL) and on human-centric manipulations (string, array, ...).

That sounds right.

I would add that functions using anything defined in the WinterCG “Minimum Common Web Platform API” are 100% acceptable. Basically, as long as the code works the same in web browsers and Node.js, there's no reason it can't be in radashi core.

Should we consider a tiered approach for the library, such as a basic version and an extended one? Or plug-able libs ?

In response to this thread, I've reserved the radashi-edge package on NPM, which could extend radashi core with more experimental and/or niche functions. I think this would be a good compromise that allows radashi core to stay focused without limiting the Radashi ethos to a single package.

Could categorising functions by types (objects, strings, etc.) be beneficial, allowing us to embed more functions in an organised way? For example, import {labelize} from "@radashi/string".

I think usability would suffer if we took this approach. The potential benefits don't seem worth the added complexity. At least, that's my current stance.

Is it better to maintain a basic library (radashi) and have separate ancillary libraries?

For now, I think having radashi core and radashi-edge will fit our needs best. As you can probably tell, I'd like to keep the number of packages low, as I believe it's best to keep things simple.

The one exception is that platform-specific libraries are welcome (i.e. radashi-dom, radashi-node) for cases where there's no hope of an isomorphic solution, but those packages are probably out-of-scope until we've grown the maintainer team to support the increased maintenance burden that would result (or until radashi core is in less need of development).

That said, I'm definitely open to ideas for ancillary packages. Feel free to start a discussion with any you have, so we can discuss each one in isolation.

Lastly, we're open to the idea of “complementary packages” that are maintained by a third party, but still mostly adhere to the Radashi ethos. I'd like to keep a list of such packages in the docs, but for now, it's being kept in this discussion. This list could also include “advanced versions” of existing Radashi functions, since we're hoping to align our APIs with the most popular/advanced/modern package on NPM that solves the same use case, as this will make it easy for Radashi users to migrate to those packages in case the simpler Radashi version doesn't meet their needs later on (which also gives us a reason to lean toward minimalism).

With tree-shaking, the need to limit the number of functions to avoid bloat feels less relevant now. While I fully support radashi’s ethos of balancing utility and simplicity to remain lean, should we still limit the number of helper functions as much as possible? Or simply, how far should we go?

I'm not currently concerned about limiting the number of functions in radashi core, as long as each function is considered to be helpful for a popular use case.

Beyond popularity, there's a concern of “function similarity” and being able to easily distinguish between functions. In other words, it's desirable to avoid using synonyms of existing function names. We'd also like to avoid inventing our own terms. Put simply, we want to limit the frequency of questions like “Which function was it that does this thing?” or “What does function X do again?”. Since we inherited functions from Radash, we're already failing at this in places, but it's also hard to completely avoid this problem if we also value keeping function names simple.

I believe both the popularity and similar naming concerns naturally limit the number of functions that can fit into radashi core, and this should be enough to curtail its immensity.

Now, I’m at a crossroads: should I invest more time in this standalone library or explore the possibility of integrating these functions into an existing library like radashi?

If I were you, I'd open a PR for each function, or for ones you're less sure about, start a discussion to gauge the potential fit.

If that sounds like too much effort, I totally understand and you can always start a single discussion with a big list of proposals instead. Of course, that's not ideal, but it's nonetheless acceptable, since our time is limited.

---

Let me know your thoughts ✌️

[aleclarson]

Hey @baxyz! Pinging you in case you forgot about this thread :)

[baxyz]

Hi Alec,

Thank you so much for your detailed and insightful response! I really appreciate you taking the time to address my questions and provide such valuable feedback.

I'm excited to take your advice and will indeed be submitting my functions one by one as PRs to gauge the community's interest. However, due to my current schedule, I might only be able to start this process in a month or two.

Looking forward to contributing to Radashi and being part of this vibrant community!

[baxyz]

Hey @aleclarson, started 🎉

Category	New Helpers	Discussion	Status	PR
URL	6		PR Review	#328
String	1		TODO
Array	2		TODO
Function	2		TODO
Object	1	1	TODO
Promise	4		TODO
Observable	1		not relevant for radashi	∅

[aleclarson]

Love it! #328 seems promising. I'd like to better understand the use cases. I'll ask some questions over there. Looking forward to your other PRs 😄