Seems like it’s been a while since a new JS framework landed on the front page.

TonyPeakman 2 days ago | parent | next [-]

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 Components. More of a “view-source-able” experiment than a contender for the next React/Vue.

▲

ivape 2 days ago | parent | prev [-]

The last decade gave us enough JavaScript for a lifetime.

▲

Nickersf 2 days ago | parent [-]

Exactly, we also have to think about support and maintenance when building and shipping products. It's always nice to play with new things to keep the learning fresh and see what people are up to. I started with php and .NET Framework ASP and in the early-mid 2010's when the reactive JS frameworks started coming around I just never found my jive with them and just started working at C#/.NET shops and am using Blazor Server now. For my domain of web application development the .NET web application ecosystem works great. Looking at the dagger.js docs and examples found myself thinking, this is more Java(SCRIPT) development. It's going to inherit the same issues as JavaScript (weak typing, no runtime reflection, no binary build output, locked into vendor interpreters with mixed feature support), and that's not mentioning all the oddities with the way object prototypes are implemented and interact with each other. I think the ambition and result of the project are amiable. The author did good work, but it's good work on a thing we need less of in my opinion.

	▲	TonyPeakman 2 days ago \| parent [-]
		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 the .NET ecosystem, Blazor is a very natural fit. dagger.js isn’t trying to compete with that class of frameworks. The goal is much narrower: keep a build-free, HTML-first option around for cases where shipping something lightweight, inspectable, and easy to embed is more important than squeezing out type safety or runtime guarantees. I completely agree that we don’t need everybody moving deeper into JS just for the sake of it. But I do think there’s value in keeping a spectrum of tools alive — from strongly-typed/.NET style systems to small runtime-only JS libraries — so developers can pick the right trade-off for their domain. Thanks again for the honest feedback; it helps clarify where this approach makes sense (and where it doesn’t).