Live data from Hacker News

Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

daggerjs.org

31–40 of 93 posts

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#31
post #12

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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me. Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using U…

> 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

Right, but that is what basically every JS framework is going for these days. Its refreshing to see somebody trying to go back to old school non-compiled js/html where every front-end is open-source(ish)

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#32
post #12

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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me. Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using U…

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. Also I don’t really like the “island” like template syntax of Vue, Svelte, etc

I also meant more advanced optimizations beyond what svelte does, like: inlining, loop unrolling, partial evaluation that would trickle down to the frameworks as well. I am aware that some of these and others are very hard to do on javascript as prepack shows.

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#34

I don’t get it. The native js Dom api has a lot of sharp edges but do people hate it that much abstract away from it? Personally I rather have zero runtime code along side zero build by learning truly native js dom

Three reasons spring to mind:

1- the DOM APIs are very verbose, excepting perhaps replacing chunks by setting innerHTML, but

2- manual DOM manipulations aren't composable without also using web components

3- naive manual DOM manipulation can potentially be slow by way of triggering needless layouts/repaints or inefficient use of the APIs

Web components didn't exist when the major frameworks came about, and the ones before them handled composition rather poorly if at all (such as backbone). Angular, ember, react and company all sought to provide a cohesive story for code reuse and composition. Many had their own performance stories, though it was always a secondary concern to everything else.

I've done a bit of everything, including pure vanilla JS, just jQuery, vanilla + web components, all the way up to next, ember, angularjs and angular, and more. If you're building a web site, vanilla JS is fine. If you're building a web "app", you'll pretty quickly appreciate what a framework can bring to the table. If you don't, you'll also quickly find yourself building your own mini framework and runtime to manage things.

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#35

> daggerjs.org is parked free, courtesy of GoDaddy.com I think your site broke? Also, I'd scoop up daggerjs.com while you're at it.

Thanks for reporting this issue, it's fixed now. Welcome back to scoop up dagger.js :)

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#36
post #12

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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me. Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using U…

Thanks for your comment.That's right — the compiled/optimized end of the spectrum is powerful, and I think Prepack showed just how far you can push that. However, dagger.js is intentionally the opposite: it trades the simplest usage for zero build, instant setup. My focus is “drop in a and go,” not competing with compiler-driven stacks. In practice I see them as complementary — one for squeezing every byte/cycle, the other for minimizing friction and complexity.

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#37
post #31
post #12

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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me. Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using U…

> 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 Right, but that is what basically every JS framework is going for these days. Its refreshing to see somebody trying to go back to old school non-compiled js/html where every front-end is open-source(ish)

Really appreciate that. The “old school” vibe is deliberate — I wanted to lower the barrier so that you can share a snippet or inspect a page and actually learn from it, the way we used to with plain HTML/JS. Frameworks are great, but sometimes it’s nice to have a path that prioritizes openness and simplicity over machinery.

Re: Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

#39
post #12

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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me. Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using U…

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

That’s a good comparison — Svelte also started from the “write less, ship less” idea, and I have a lot of respect for it.

The big difference is that Svelte achieves that by compiling away the framework, whereas Dagger.js avoids compilation entirely. You don’t install a CLI, you don’t run a build — you literally drop a from a CDN and wire up directives in plain HTML. It’s closer to Alpine/htmx in that sense, but with a focus on working alongside Web Components.

So in spirit, yes — both try to reduce overhead. Svelte optimizes post-build output; Dagger.js tries to remove the build step altogether.

Here is a dagger.js version Hello world demo:https://codepen.io/dagger8224/pen/raOXxee?editors=1010

Post reply on HN