Comparing Radashi to Radash

If you’ve already used Radash, you’ll naturally wonder what makes Radashi better. First and foremost, Radashi is actively maintained. In my opinion, that alone makes Radashi the better choice.

That said, let me give you an overview of how the two projects compare, given the current state of both, as well as a glimpse into 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, as we’re not done improving the code we inherited from Radash. It’s my hope that Radashi’s quality will become more apparent as you use it.

• 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 Ray Epps (the creator of Radash) will be proud of where we’ve taken Radashi. Maybe he’ll even join the core team at some point. Who knows?

If you have any questions or comments, hop on over to the issue that sparked this post and leave a comment.