Regarding Dependencies
One of my friends questioned some design choices in Sipp, mainly the replacement of NanoId for creating short IDs/slugs for snippets. They make some good points and while I don't think a response is necessary, I thought it might be good to expound a bit more on how I'm currently viewing dependencies in software. In some ways this is an extension of my longer form post on Programming Bowls.
As mentioned in that post, context truly matters. In no way do I think my implementation of creating a short ID is better than what NanoId has done. If anything, I know for a fact it's inferior and I would not trust it if collisions were a true concern. That's where context comes in though: I didn't design Sipp to be a single application that is used by tens of thousands of users. It's not the next greatest dev saas. Sipp is designed to be minimal, self hosted, and customized. In the context of using my own instance I don't see anyone using it but myself and maybe a few other people. So yes I could add NanoId as a dependency, but why? If I could just write something that's good enough for my context, why add the extra dependency?
The whole point of my post on Programming Bowls is to question why you need something. Do I really need two pairs of headphones? Probably not. Is it ok to own two pairs of headphones? Absolutely! If you really enjoy using a dependency and want to, then do it. I personally like to avoid adding extra packages these days if I can, but I don't avoid them entirely. Dependencies can be a good thing, but not questioning the decision to use them?
Snippets was the predecessor to Sipp. It used NanoId, along with countless other dependencies and design features I made years ago when I was Next.js / Vercel pilled. A lot has changed. I realized a lot of the features I implemented with SSR logic would be really hard to rewrite or update if I wanted to move off of Vercel or Next.js. I didn't like that. I don't like being boxed in. My comfort in Sipp is not that it's using Bun alone with zero dependencies, rather it's the fact that I know how to manually swap out every single piece that Bun does and make it work in a totally different environment. It's simple, and designed to be owned by me, not the other way around.
On the flip side I recently wrote a tutorial for my day job around how to use account abstraction with a WebAuthn contract that we just released. I was immensely thankful for Ox and their implementation of WebAuthnP256 as I really don't want to mess with creating keys through navigator. It's not something I would have been able to just magically spin up, and the functionality is something that has to work for the thousands of people who might read or follow the guide. This context is totally different from a small app I wrote for myself.
As made evident through countless opinions, blog posts, and videos: there is no one right way to program. People will make different decisions and that's ok, it's what makes the world interesting. My only urge to developers is to think, to learn, and to avoid my own mistakes that left me boxed in and disappointed.