I'm pretty sure I found a way to always win this one as hounds when I was a kid.

I reserved go/poop years ago, but the ability to name a project with that name is diminishing

What happens to your go links when you leave Google?

This one is still up. I just checked it. I was underwhelmed by where it linked to.

Nothing shorter than dogself.com ?!

Seems neat. I wouldn't use it for personal stuff because I'd be afraid of getting locked into a framework that might not exist next year.

Once this project is about a year old, if it still has any commits, then I'd consider it.

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).

Ive done this before, I have used a bespoke micro framework to build a webpage. A couple of years later I wanted to update it, but discovered that I couldnt do it because of a bug in this framework and the framework also didnt exist anymore. I could fix the bug myself by reading all their code, or I could start over and use something that would still exist next year.

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

Its written like the developer has a limited supply of lines of code. No comments, ton of declarations on the same line, and lines that run longer than most widescreen monitors.

Its all super compact and dense. I would not want to try to fix a bug here.

Suggestion: Add a build step that runs before your code is published to npm so that you can have readable source AND small source.

>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.

Yes, there are places to find worse code, but this isn't what I would call clean, readable code.

Some of it feels like it was written with the goal of not pressing enter. Can I read it and debug it? Certainly. Do I want to? Certainly not.

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.

no prob. I have written code like that, and there is some allure to cram as much logic as possible into a single line.

The problem is that the nice feeling you get from writing it is inversely proportional to the nice feeling I have when reading it.

Haha, that’s a great way to put it . Writing one-line code does feel clever in the moment, but you’re right, the “writer’s joy” often turns into the “reader’s pain.” Striking the balance between elegance and readability is the real art of coding.

Exactly — that’s a good way to frame it. One of the reasons I kept Dagger.js tiny and runtime-only was to minimize those risks: no exotic build chain that might break, and nothing beyond plain JS/HTML that the web already guarantees to keep working. HTML + Web Components + a few attributes. That’s about as low-lock-in as a framework can get.

Totally fair — longevity is a real concern, and I’ve had the same hesitation with new tools myself.

The nice thing about Dagger.js is that it’s intentionally very small and HTML-first. If the project disappeared tomorrow, your markup is still just plain HTML + attributes, and your components are still standard Web Components. There’s very little “lock-in” compared to bigger frameworks with proprietary syntax or build pipelines.

That said, I do intend to keep it alive — it’s under active development on GitHub, MIT licensed, and easy for others to fork or extend. If a year from now it still looks useful, I’d be glad for you (and others) to take another look.:)

What enterprise uses a free open source github project to make bespoke toy html from markdown?

"It won't scale" is how over engineered code gets written

I've used similar software before and it surprises you how many open source dependencies I've seen in enterprise

I see this is clearcam. What is clearam? The readme mentions it a few times so it's probably not a typo.

typo I've just fixed lol, thanks for the heads up

I find that AI is really good at the easy stuff like writing tests for simple class without too many dependencies that we have all written hundreds of times.

Things go wrong as soon as I ask the AI to write something that I don't fully grasp, like some canvas code that involves choosing control points and clipping curves.

I currently use AI as a tool that writes code I could write myself. AI does it faster.

If I need to solve a problem in a domain that I haven't mastered, I never let the AI drive. I might ask some questions, but only if I can be sure that I'll be able to spot an incorrect hallucinated answer.

I've had pretty good luck asking AI to write code to exacting specifications, though at some point it's faster to just do it yourself

Ok, I tried to read something, also on mobile. It's not really possible to scroll one screen at a time, which makes reading anything really hard.

Seeing only one item at a time(on Mobile) is deal breaker for me. I don't know what other stuff is in the feed, and there is no way to easily know without scrolling through a bunch of stuff I probably don't care about.

The images don't really add much for me. I look at the title to decide if this is something I want to read about.

Maybe there is a way to turn off this one thing at a time, but I didn't stick around to find it.

Good luck, it's looking polished and works nicely

Ok, I want to add a pencil icon here, the pencil should be #ccc, here is #ddd, there is rebeccapurple, and over here it should be the same color as the container color.

Please write a nodejs server that produces those tiny images, don't forgot to correctly set the caching headers...

Yeah, this is what I was referring to and is my main use for embedding SVGs.

For really simple ones, the size of the icon isn't a whole lot bigger than a CDN/object storage URL. And if you reuse it a couple times, it might even be a net bandwidth reduction.

Honestly, when people are making use of CSS to "reach into" the svg dynamically, or like your example, to color it dynamically, I'm not opposed to the strategy.

99% of the inline <svg> usages I see are people using js includes to inline an SVG which is itself stored in a .jsx file. This is just as lazy and wasteful as it would be if Styled Components were built not to generate classnames and a single stylesheet, but instead with all the rules simply inlined in style attributes on every element.