I didn't see this game

https://www.iggamecenter.com/en/rules/foxh

Back when I was a Googler, I used to play a little game where I would think of a random word and then check if there was a Google internal project code named for it. It was a bit hard finding stuff that wasn't some system or project, and often there would be multiple ones. I actually found one that I thought would be a nice name and reserved the go link for it, but naming anything after it never panned out, when I finally got to design a system from scratch my manager wanted a boring descriptive name like "consolidated data system" (it was a bit more specific but that was the vibe).

Side note: I noticed that more "boring" and less sexy projects had cooler names a lot of the time, and my theory was that people were compensating for doing unsexy work.

Thanks to both of you for the thoughtful discussion — I really appreciate seeing different perspectives here.

On the “lock-in” concern: that’s a fair point. dagger.js is still young, and it’s reasonable to be cautious with any new project. One of the core goals, though, is low lock-in: your code is still just HTML + JS + Web Components. Even if dagger.js disappeared tomorrow, your markup would continue to work with minimal adjustments.

On code readability: you’re right that the current source is compact and not heavily commented. That was a stylistic choice early on to keep things lightweight, but I understand it can make debugging less inviting. Based on this feedback, I’m planning to provide a more readable version so others can more easily step in.

So the trade-off you mentioned is valid: fewer features, but less surface area and minimal lock-in. The feedback here helps me refine where the ergonomics stop and where maintainability needs more attention.

Thanks again for taking the time to review both the idea and the code — it makes the project better, and I’ll keep iterating with these points in mind.

>Also, have you read the dagger.js code? https://github.com/dagger8224/dagger.js/blob/main/src/dagger...

It's 1600 lines.

I've disassembled, decompiled and reverse engineered more code than that in a day. It's JavaScript. What comments do you need? There's a bit of noise in the first 100 lines, but it's not something you couldn't figure out in half an hour if need be.

The version you linked isn't the minified version.

Edit: and yes, I did see the code before I wrote my first comment. I wanted to make sure it was in fact relatively straightforward and not some 50k line monolith.

What is the risk here?

Are you worried that in a year it will be missing a feature you want?

It's client side javascript, aside from DOM based XSS (which if reported, you can probably fix yourself), there isn't much to worry about from the security perspective. The web doesn't normally deprecate things so it's probably going to work in a year too.

This is a tiny project which already requires that you know JavaScript, so you can't even claim that you can't maintain it because you don't know the implementation language. It doesn't depend on some build step (which often is the thing that breaks after a year).

This is great and all but won't scale (as in, enterprise scale). I understand the knee-jerk reaction but at this point it misses the point about what is trying to be achieved here