TonyPeakman

8 ms·

1.
by TonyPeakman 1y ago
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 c
2.
by TonyPeakman 1y ago
Thank you — that really means a lot to me. One of the best parts of sharing dagger.js has been hearing from people like you who’ve been down the same path and thought about building the same set of features. It makes me feel like the projec
3.
by TonyPeakman 1y ago
Hey, I added two more examples about routers for dagger.js: minimal: https://codepen.io/dagger8224/pen/PwZwgWp?editors=1000 nested: https://codepen.io/dagger8224/pen/bNENZNN?editors=1000
4.
by TonyPeakman 1y ago
Thanks a lot for the detailed suggestions — this is super helpful. You’re right that symbols like +/ /@ aren’t valid in XML/XHTML, and the original idea was just to keep things as short and stackable as possible. But I see th
5.
by TonyPeakman 1y ago
Thanks for laying this out — I share your priorities on minimal boilerplate and a buildless-first workflow. dagger.js is designed around that: no bundler by default, just HTML + JS modules, so most code stays reusable outside the framework.
6.
by TonyPeakman 1y ago
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.
7.
by TonyPeakman 1y ago
That’s a really good point — thanks for laying out the example so clearly. You’re right: Aurelia can avoid a build step and still preserve flexibility, and the kind of helper you sketched (load_modules("thispage")) would definitel
8.
by TonyPeakman 1y ago
That’s a great example — I agree, with JS Modules and import maps you can already do a lot of dynamic composition in the browser, even with heavier frameworks like Vue. dagger.js isn’t trying to claim something impossible with ESM; the goal
9.
by TonyPeakman 1y ago
For anyone curious, I’ve put together a collection of comparison demos here: https://codepen.io/dagger8224/pens . They show the same functionality implemented with dagger.js alongside other frameworks (credit to the or
10.
by TonyPeakman 1y ago
Really glad to hear that — thanks for the kind words! dagger.js is meant for exactly that use case: if you normally avoid heavy JS but occasionally need a bit of interactivity, you can drop in a <script> and use just what you need wit
11.
by TonyPeakman 1y ago
Aurelia is a great framework — I really like the way it ties template, JS, and CSS together into one unit. That convention makes it very natural to organize components and reduces boilerplate. You’re right that dagger.js takes a different a
12.
by TonyPeakman 1y ago
Thanks for the thoughtful feedback — you raise valid concerns. The reason dagger.js allows JS expressions in attributes is mostly about lowering the barrier to entry. By keeping everything in plain HTML, you can copy-paste a snippet, view-s
13.
by TonyPeakman 1y ago
As a frontend framework, Svelte apps absolutely run in the browser.However, Svelte relies on a compile step: your authoring code is compiled ahead of time into efficient JS that runs on the client. dagger.js is contrasting itself as purely
14.
by TonyPeakman 1y ago
Glad to hear that! Buildless is the whole idea — drop in a <script>, wire up a few +click / +load attributes, and you’re up and running. The goal is to keep things simple and view-source-able without needing a bundler or toolcha
15.
by TonyPeakman 1y ago
Well put — that lines up with how I see the ecosystem too. For small sites, vanilla JS is fine; once you move toward “app,” you either reach for a framework or start reinventing bits of one yourself. dagger.js is basically me leaning into t
16.
by TonyPeakman 1y ago
That’s totally valid — if you’re comfortable living close to the DOM, zero-runtime + zero-build is the purest path. dagger.js is meant for folks who want to stay mostly in plain HTML/JS but still smooth out a few of those DOM “sharp ed
17.
by TonyPeakman 1y ago
Haha, true — the front page doesn’t always need another JS framework dagger.js is tiny and pretty niche compared to the “big ones,” but I figured it was worth sharing since it’s trying to go backward a bit: no build, plain HTML, Web Compone
18.
by TonyPeakman 1y ago
Totally agree — the ESM build of Vue gives you a great “no-bundler” experience with a full framework behind it. dagger.js sits in the same no-build space, but deliberately strips it down even further: no VDOM, no reactive system, no SFCs. J
19.
by TonyPeakman 1y ago
That’s a good point — the ESM build of Vue is solid, actively maintained, and does give you a no-build setup with the full feature set. dagger.js aims a bit differently: it’s even smaller in scope (no virtual DOM, no reactivity system, no S
20.
by TonyPeakman 1y ago
Yeah, that’s a fair comparison — Dagger.js lives in a similar space to petite-vue / Alpine: no build step, HTML-first, sprinkle behaviors where you need them. The main differences are: pure declarative mode → there is zero API and thi
21.
by TonyPeakman 1y ago
Good catch — thanks for digging into that. You’re right: the domain still has a mix of A records (AWS + GitHub Pages), which explains why some people see different results. I have removed the broken A records and the site works normally now
22.
by TonyPeakman 1y ago
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
23.
by TonyPeakman 1y ago
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 sti
24.
by TonyPeakman 1y ago
Really appreciate you taking the time to look through the docs and write such a thoughtful comment. You’re right — JavaScript carries a lot of quirks and limitations that aren’t going away, and if you’re building full-scale business apps in
25.
by TonyPeakman 1y ago
Thanks! Totally agree — in most real-world apps the “runtime overhead” ends up dwarfed by everything else in the stack, so the build-free ergonomics can be a bigger win. And nice, Mancha looks cool — I’ll give it a read and star. It looks s
26.
by TonyPeakman 1y ago
I removed the broken A record, and it should work normally.
27.
by TonyPeakman 1y ago
In dagger.js interpolation is scoped to attributes and text nodes — anywhere you put ${…} inside the HTML markup, the expression is evaluated against the current directive scope. In your sample code, winner is looked up from the nearest +lo
28.
by TonyPeakman 1y ago
Right — there’s also the dagger DI framework in the Java ecosystem. To avoid confusion: this project is dagger.js, a small runtime-only JavaScript library for HTML/Web Components. Totally unrelated to the Java DI framework other than s
29.
by TonyPeakman 1y ago
Yeah, totally — once you start talking about inlining, loop unrolling, partial evaluation, you’re basically in compiler-research territory. Prepack showed both the promise and the difficulty of doing that well in JavaScript. dagger.js isn’t
30.
by TonyPeakman 1y ago
That's pretty cool.

More ›