Here's a summary of the themes expressed in the Hacker News discussion:
Domain Name and Accessibility Issues
A significant portion of the initial discussion revolved around problems accessing the project's website, daggerjs.org. Some users encountered a GoDaddy domain parking page, while others had success. This was attributed to DNS propagation delays and varying DNS records resolving to different IP addresses, including those hosted on AWS and GitHub. The project author provided an alternative Codepen link while the DNS issues were being resolved.
- xupybd: "Website looks dead. I get Godaddy domain parking."
- mdaniel: "I'd guess people are getting different results because of the varying A records..."
- chrismorgan: "No, it’s still broken. DNS is offering six choices, two of which are broken."
- TonyPeakman: "Hey xupybd,thanks for reporting the issue,you may refer to the alternative site: https://000712133.deployed.codepen.website/#overview/introduction"
- xupybd: "Hi Tony, Looks like it's up and running now. Propagation delay probably got me in New Zealand. Cool project BTW."
- jodacola: "FYI: daggerjs.org is resolving to a GoDaddy domain parked page right now."
Project Positioning and Ergonomics
The project is explicitly positioned as having "Alpine/Vue-like ergonomics" but with a key differentiator: no build step and a Web Components (WC)-first approach. This focus on simplicity and direct browser compatibility was a major talking point.
- TonyPeakman: "Positioning: Think Alpine/Vue-like ergonomics but no build and WC-first."
- nivethan: "Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step."
Performance and Simplicity Focus
The author emphasized a focus on "simplicity and startup latency over framework features." They actively discouraged users from posting synthetic benchmarks, instead inviting them to test with real pages. This deliberate trade-off of fewer features for better initial performance resonated with some.
- TonyPeakman: "Size & perf: Focus is on simplicity and startup latency over framework features. I’m not posting synthetic benchmarks; if you have a real page you want me to try, I’ll profile it and share results."
Web Components and Interoperability
The project's direct support for native Web Components and its ability to interoperate with other component libraries like Shoelace and FAST were highlighted as strengths. This commitment to the web standards ecosystem was seen positively.
- TonyPeakman: "Interop: Works with native Custom Elements. I’m preparing examples with Shoelace/FAST."
Security Considerations
The author addressed security by mentioning that directives are sandboxed and do not use eval. They encouraged users to report any potential injection risks for quick patching, demonstrating a proactive approach to security.
- TonyPeakman: "Security: Directives are sandboxed; no eval. If you spot an injection risk, please open an issue and I’ll patch quickly."
Stated Limitations and Future Scope
Transparency regarding the project's current limitations was provided, explicitly stating that complex state management, SSR/streaming, and large SPA routing are not the primary goals. This sets expectations and clarifies the intended use cases.
- TonyPeakman: "Limitations: Complex state management, SSR/streaming, and huge SPA routing aren’t first goals."
Skepticism Regarding Project Longevity and Viability
A notable theme was apprehension about adopting a new, unproven JavaScript framework. Users expressed concerns about vendor lock-in and the potential for the project to become abandoned, referencing the history of similar frameworks. The timeline of a year with continued commits was cited as a potential indicator of stability.
- mkoryak: "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."
Alternative Approaches and Desires for Optimization
The discussion branched into broader desires for JavaScript development. Some users expressed a preference for highly optimized, compiled solutions that minimize output size and maximize efficiency, even if it means embracing build steps. This contrasted with the project's "no build" philosophy. Other users also discussed preferences for specific syntax and reactivity models.
- taosx: "I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible."
- harrygeez: "I’m in a similar boat like you. I would love for a React-like library that compiles down to direct JavaScript DOM transforms. Of course Svelte exists but I don’t want to mark what is reactive or not and I can’t go back to html templates after using typed JSX."
- jeswin: "If what you're looking for is JSX and TypeScript (but without magic or reactivity), there's something I wrote here: https://webjsx.org"
- Scaevolus: "Isn't that what Svelte was aiming to do? It's moved on a ways since then, but you can still see the fundamentals in its demos: https://svelte.dev/playground/hello-world"
Existential Commentary on JavaScript Frameworks
Towards the end of the discussion, there were some broader, somewhat jaded comments about the sheer volume of JavaScript frameworks available, suggesting a saturation point.
- wffurr: "Seems like it’s been a while since a new JS framework landed on the front page."
- ivape: "The last decade gave us enough JavaScript for a lifetime."
Naming Conflicts and Aliases
Mention was made of existing projects with the name "Dagger," including a Java dependency injection framework and a CI toolkit, highlighting the potential for confusion.
- malfist: "Dagger is also a compile time java dependency injection framework"
- mdaniel: "And a very cool CI toolkit https://github.com/dagger/dagger (Apache 2)"
- mdaniel: "Link to the DI mentioned by the parent comment https://github.com/google/dagger (also Apache 2)"