Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

daggerjs.org

Post reply on HN
Print view View original

61–70 of 93 posts

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

#61

Post by TonyPeakman »

pyrolistical wrote: post #29

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

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 edges” — e.g. inline state with +load, simple event handlers with +click, template interpolation. The idea is to reduce boilerplate without hiding what’s really happening underneath.

So it’s less about abstracting away the DOM entirely, and more about lowering the friction for small tools/demos where you don’t want to write a ton of document.createElement calls.

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

#62

Post by TonyPeakman »

zdragnar wrote: post #34
pyrolistical wrote: post #29

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 b…

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 that middle ground: accept the verbosity/sharp edges of the DOM, but try to smooth just enough of them with directives (+click, +load, interpolation) so you don’t accidentally start building your own mini framework. It stays runtime-only, works directly with Web Components for composition, and tries not to hide what’s really happening under the hood.

So it’s not aiming to replace React/Angular, more to give people a lightweight option before they hit the point where those make sense.

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

#65

Post by TonyPeakman »

leke wrote: post #64

Buildless! I'm already interested.

Glad to hear that! Buildless is the whole idea — drop in a , 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 toolchain.

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

#66

Post by mythz »

TonyPeakman wrote: post #58
mythz wrote: post #17

Earlier quoted context omitted.

Using the full vue.js doesn't have a build step either. I started out developing UIs using petite-vue, unfortunately ended up rewriting it to use full Vue.js after running into too many of its limitations and issues, which given that it's abandon-ware wont ever be resolved. As such I'd strongly recommend against starting projects with PetiteVue and just use the ESM build of Vue.js which also doesn't require a build s…

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 SFCs), and is designed to pair directly with Web Components and plain HTML snippets. The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can…

> The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can literally view-source and drop it into a page.

You should be able to drop in code dynamically on any existing website with JS Modules, I show an example of this in one of our release notes to showcase the versatility of JS modules [1], which:

   - Dynamically adds an Import Map with references to Vue, an external lib + Vue component library
   - Dynamically creates and mounts a new Vue Component on the fly
   - Drops in a fully functional and editable Data Grid with API bound forms, API + form validation, etc
Basically you should be able to do most things on a deployed page as can be done in your "no-build" ESM Web App.

I did try building web components with Lit [2], unfortunately WC's encapsulation and shadow dom made it difficult to enable theming and maintain shared global tailwind styles, so ditched it and went back to Vue. Although it's a good option for creating encapsulated components that don't need to share styles.

[1] https://docs.servicestack.net/releases/v6_06#js-modules-quic...

[2] https://lit.dev

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

#67

Post by zelphirkalt »

TonyPeakman wrote: post #59
zelphirkalt wrote: post #42

Earlier quoted context omitted.

If I had to use one of these modern JS frameworks, I think Vue without build step would be one of the candidates. No shitty webpack configuring, no minimizer, no bundler, no friggin uglyfier, no juggling modules. None of the crap, just write your JS and serve the script, done.

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. Just HTML with attributes like +click / +load, and it plays nicely with native Web Components. The trade-off is fewer features, but also less surface area and almost nothing to conf…

Your post and comments definitely made me interested in trying it out! Usually I use as little JS as possible, but maybe I have a need for something soon, and then I might try your library/framework!

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

#69

Post by TonyPeakman »

efilife wrote: post #68

why is svelte marked as non client side on your website?

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 runtime, build-free — you drop in a script, no compilation needed.

So it’s less about runtime location (Svelte is client-side too) and more about how you get there.

Svelte → compile first, then run in browser

dagger.js → no compile, just run in browser

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

#70

Post by mkoryak »

Arch-TK wrote: post #52
mkoryak wrote: post #7

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.

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…

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.

Post reply on HN