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

▲

mkoryak a day ago | parent | next [-]

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.

▲

Arch-TK a day ago | parent [-]

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

	▲	mkoryak a day ago \| parent [-]
		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.

▲

TonyPeakman 2 days ago | parent | prev [-]

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.