Replies: 1 comment
-
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
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
In response to this thread, I've reserved the
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.
For now, I think having The one exception is that platform-specific libraries are welcome (i.e. 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).
I'm not currently concerned about limiting the number of functions in 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
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 ✌️ |
Beta Was this translation helpful? Give feedback.
-
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:
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:
Looking forward to hearing your thoughts.
Other references:
Beta Was this translation helpful? Give feedback.
All reactions