Why Radashi?

[xml]

Hi, Radashi team! Thank you for great open-source tooling.

I'm new to both Radash and Radashi. And, when I read the docs for Radash, it's clear to me why it exists. And, because it has great docs, and relatively recent releases, I feel comfortable adopting it.

I'm lots less clear on why a person would adopt Radashi instead, particularly given that Radashi's docs are just... Radash's docs. It's oddly... not mentioned? Except to say:

Radashi is an actively maintained fork of Radash, the fastest growing Lodash alternative with 100K+ weekly downloads.

And like: if that one is the "fastest-growing Lodash alternative"... and if that one has 4.1k stars and this one has ... 108? ... then... why wouldn't I just use that one? I think it's necessary to explain the sitch, somehow, somewhere, to accelerate the transition.

Then there's the list of Radashi benefits but... it's not really clear why those aren't also just the same benefits as Radash? I'm guessing that some of those benefits are kind of a polite sub-tweet about Radash, perhaps especially about being "actively maintained"?

I hunted around: I see the open issue and discussion on Radash about whether it's being maintained, and because none of the maintainers have responded to them, I think I understand the basic issue, and what prompted the maintainers of this project to start a new one. And, I see 13 contributors and lots of commits.

So... I think it would be helpful (especially for those disinclined to hunt as I did) to say it out-loud, here on this repo. Something like:

Why does Radashi need to exist, when there was already Radash?

We are eternally grateful to Radash for bringing Lodash into the world of Typescript. And, we would have loved to simply contribute to improving Radash. But, (since late 2023), the Radash project has gone mostly inactive, and maintainers are not even responding since September 2023 to an open discussion and issue - nor to direct email inquiries - about whether it's being actively maintained. Let alone to the many other open issues and PR's. From this, we can sadly only conclude... future progress depends on a new community and a new repo.

That could reasonably go anywhere: onto the Readme, into the new docs, or even just here as an Issue for anyone inclined to seek it. But, I think that you'll see slow adoption until you come right out and say why this exists, why it is a pro-community move, and why it's not just a 'copy-cat' or 'unconstructive bike-shedding' or something negative like that.

To be clear, I'm assuming the best. I think this project just wants to be explicit in explaining why this is, in fact, the best approach. Leaving it implicit creates FUD, and slows uptake. FWIW.

[xml]

p.s. - I'd be happy to submit a PR to this effect. Just wanted to see if that's constructive and aligned to reality/project goals, etc...

[aleclarson]

First off, apologies for the lack of clarity. The current readme is probably not as thorough as it could be, but I wanted to keep it short so I can focus on the process of getting Radashi ready for its first true release (coming very soon).

I'm hesitant to dedicate a section to explaining why an actively maintained version is better than one that isn't. With respect, isn't it obvious? I invite you to take a look at our generated changelog to see the many improvements that have already been made in @sodiray's absence. We'll also have comprehensive release notes with high-level explanations (starting with the next release).

Why Radashi?

Okay, so let me give you an overview of how the two projects compare, given the current state of both, as well as my vision for the future. I will try to be comprehensive in listing the differences that I believe make Radashi the obvious choice:

• Explicit design philosophy

  • To help guide our decision-making, I've tried to articulate “the ethos of Radashi” as a set of design principles.
  • This is a living document, and so I expect it to evolve over time according to the community's feedback.
  • I believe that having such a document will make it easier for contributors to understand the project's goals and direction, and therefore make it easier for them to contribute features aligned with the project's vision.
  • It can also assist in resolving any disagreements that may arise between contributors.
  • The ethos will have its own page in the docs, but you can check out the first draft to get an idea of what it's about.

• Higher code quality

  • This is the trickiest-to-prove benefit of Radashi (other than the fact that it has less bugs, because we fixed them).
  • While our predecessor Radash's code is of mostly good quality (no shade intended), I and the other contributors have been able to make many improvements.
  • I believe this gap in quality will only widen over time. It's my hope that Radashi's quality will become more apparent as you use it. Although, we're not done improving the code we inherited from Radash.

• More functions

  • We are actively looking to introduce new functions that cover popular use cases.
  • The community has the final say. If there's demand for a function, and that function adheres to Radashi's ethos, then that function will certainly be added.

• Benchmarks

  • Every pull request is compared with the main branch using our benchmarking suite.
  • This ensures that the PR doesn't introduce any regressions.
  • It also ensures that perf-related PRs are statistically significant.
  • There are plans to add comparative benchmarks with Lodash as well, wherever we support the same use case.

• Bundle impact

  • When a PR adds or modifies a function, the minified byte size of the function's new and old implementations are compared and subsequently reported in the PR.
  • This helps us avoid introducing any unnecessary bloat.

• Welcoming new maintainers

  • The last thing I want is to be the project's sole maintainer.
  • I've made the barrier to joining the core team lower than most projects, because I want as many passionate contributors as possible to help steer development.
  • This is my attempt to avoid issues of unresponsiveness as much as possible. Radash was a one-man show, and the project suffered from burnout as a result.
  • To alleviate security concerns that may arise from having a large team of maintainers, I'm currently the only person with the ability to publish to NPM. It's my hope that this will change in the near future, so I can stop being a bottleneck in the release process.

• Nightly beta releases

  • Every night at 5:00AM UTC, a radashi@beta release is published to NPM if any PRs were merged that day.
  • This means you'll be able to use your contributions or others' the next day.
  • This allows for a swift development cycle and being able to use the latest and greatest features or fixes without waiting for a stable release.
  • I plan to do the same for breaking changes, publishing a nightly radashi@next release based on the next branch.

• Bigger vision

  • Shortly after the project's first true release, I plan to turn my focus to a bigger vision for Radashi.
  • I'm not ready to share what that is yet, but I will say that it's focused on making Radashi as easy as possible to customize.
  • This vision also includes making Radashi less dependent on the core team, allowing the community to collaborate without gate-keeping, while still using Radashi's codebase and ethos as a common ground for collaboration.
  • There will be a blog post on this when the time comes.

• Translated docs

  • We plan to support multiple languages so we can appeal to a wider audience and attract non-English speakers to contribute to the project.
  • To kickstart this, I'm going to use an LLM for the initial translation. This will run in a GitHub action every time the docs are updated.

• “Browser support” page

  • The docs will be explicit about which browsers are supported by Radashi without the need for legacy transforms.
  • This page will be updated every time the docs are updated, so it's always relatively up-to-date.
  • As part of our automatic linting process, we verify that this browser support is not broken.
  • You can find the page here.

• “Lodash parity” page

  • The docs will have a page dedicated to comparing Radashi and Lodash where overlap exists.
  • This should help Lodash users make the switch to Radashi.
  • When the page is ready, you'll be able to find it here. (I'm almost done writing this page. It's generated from a Supabase table where I keep track of which Lodash functions have been implemented in Radashi.)

• Other small things

  Such as... (click to expand)

  • Protected main branch: PRs must pass automated checks before they can be merged. I will never push fixes or features directly to main, even though I have that privilege.

  • Conventional commits: I've added a commit message linter to ensure that all commits follow the conventional commits specification.

  • RFC process: New features and breaking changes are often submitted as an RFC to encourage community involvement in the decision-making process

  • Preview releases: If you can't wait for a PR to be merged, the PR author can comment /publish to publish a preview release of the PR to NPM for immediate use

  • Generated changelog: Essentially a filtered commit history that excludes non-code changes to make it easy to see what's new

  • High-level release notes: These will include high-level explanations and code examples for the changes in each release

  • Contribution scripts: Scripts like pnpm add-function have been added to streamline the contribution process

  • JSR.io package: If you use Deno or you just resonate with the JSR.io philosophy, you can use the JSR.io package instead of the NPM package

  • Better tooling: I've switched the project to use Vitest for testing (instead of Jest), Biome for linting/formatting source code (instead of TSLint/Prettier), and PNPM for package management (instead of Yarn).

  • Easier to copy-paste: If one of Radashi's functions isn't meeting your needs, you can easily copy-paste it into your project and change it as you see fit, because our functions always import from radashi just like your project does.

In the end, I hope that @sodiray will be proud of where we've taken Radashi. Maybe he'll even join the core team at some point. Who knows?

Let me know if anything's still not clear. Thanks!

P.S. Thanks for prompting me to write this out. I'll include it as a page in the docs and link to it from the readme for anyone curious like yourself.

[xml]

Wow. Thanks for detailed response. EDIT: the [Comparison Post](https://radashi.js.org/blog/vs-radash/) is great. Everything is in-context there.