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

81–90 of 93 posts

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

#81

Post by em-bee »

TonyPeakman wrote: post #78
em-bee wrote: post #72

Earlier quoted context omitted.

my framework of choice is aurelia. it is probably as fully featured as vue, but at a glance its templating and minimal need for glue code makes it look more similar to dagger.js than vue, to the point that i think it should be easy to convert from aurelia to dagger.js and back. like vue, by default aurelia uses a build step, but serving it directly from a CDN or your own server is possible. i am actually working on a…

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 approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless and decoupled — you can serve each piece d…

dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless

aurelia doesn't need a build step to wire things together. nor does it remove transparency or flexibility. because you can still specify all parts explicitly if you want to.

it should not be hard to create a function that does the same for dagger.js:

a configuration like this:

    {
      "remote_view_module": {
        "uri": "./thispage.html",
        "type": "view"
      },
      "remote_style_module": {
        "uri": "./thispage.css",
        "type": "style"
      },
      "remote_script_module": {
        "uri": "./thispage.js",
        "type": "script"
      },
      "remote_json_module": {
        "uri": "./thispage.json",
        "type": "json"
      }
    }
can easily be generated with a function:

    function load_modules(name) {
      return {
               "remote_view_module": {
                 "uri": "./"+name+".html",
                 "type": "view"
               },
               "remote_style_module": {
                 "uri": "./"+name+".css",
                 "type": "style"
               },
               "remote_script_module": {
                 "uri": "./"+name+".js",
                 "type": "script"
               },
               "remote_json_module": {
                 "uri": "./"+name+".json",
                 "type": "json"
               }
             }
    }
thus reducing 18 lines to one:

    load_modules("thispage")
anyone who needs the flexibility can still specify the parts they want to wire together manually. this is just about making the default easier.

you could even allow some names to be specified and still reduce the code a user needs to write:

    load_modules({ name: 'thispage', style: 'other.css', json: undefined })
that would use 'thispage' as the default name, but override the style and remove json.

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

#82

Post by TonyPeakman »

mythz wrote: post #66
TonyPeakman wrote: post #58

Earlier quoted context omitted.

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…

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 is more to make the “drop-in” workflow the default, without needing to wire up import maps or component bootstrapping code yourself. It’s about reducing the ceremony, not redefining what modules can do.

On the styling point: totally hear you. Shadow DOM can be a blessing or a curse depending on whether you want strict encapsulation or global theming. dagger.js doesn’t enforce Shadow DOM, so you can share global Tailwind styles when you need them, while still having the option to encapsulate components.

If you do want to explore Web Components without the pain of rolling everything yourself, I’d recommend taking a look at Shoelace — it’s a really nice library of styled Web Components that play well with dagger.js. You get encapsulated, accessible components, but with good customization hooks for theming. Could be a good middle ground between Lit’s strict encapsulation and Vue’s more global styling.

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

#83

Post by TonyPeakman »

em-bee wrote: post #81
TonyPeakman wrote: post #78

Earlier quoted context omitted.

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 approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless and decoupled — you can serve each piece d…

dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless aurelia doesn't need a build step to wire things together. nor does it remove transparency or flexibility. because you can still specify all parts explicitly if you want to. it should not be hard to create a function that does the same for dagger.js: a…

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 definitely make the default case much less verbose while still allowing people to override pieces explicitly when they need to.

With dagger.js the initial choice was to keep everything explicit to reinforce the “HTML/JS/CSS are just independent modules” idea, but I agree that adding a convention-based shortcut on top could make the developer experience smoother without removing transparency.

In future iterations, I plan to add more flexible usage patterns to better meet diverse development needs.

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

#84

Post by em-bee »

TonyPeakman wrote: post #83
em-bee wrote: post #81

Earlier quoted context omitted.

dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless aurelia doesn't need a build step to wire things together. nor does it remove transparency or flexibility. because you can still specify all parts explicitly if you want to. it should not be hard to create a function that does the same for dagger.js: a…

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 definitely make the default case much less verbose while still allowing people to override pieces explicitly when they need to. With dagger.js the initial choice was to keep everything explicit to re…

my main interests in a framework is minimalized boilerplate code that only exists to make the framework functions work, so that i can reuse code without the framework without much change or any change at all. and a html syntax that follows the standards. your syntax here has a bit of an issue because characters like * or + may be ok in HTML, but they are not valid in XML or XHTML, so they limit the usability in systems where interoprability with XML or XHTML is needed.

by far the biggest point is however is buildless application. while aurelia and vue and others can be used buildless, it's always a chore to get there because using build tools is still the default. buildless first, or buildless only is a big win. also because it encourages different optimizations that are more suitable for a buildless application. aurelia or vue are not optimized for buildless usage.

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

#85

Post by TonyPeakman »

mkoryak wrote: post #74
Arch-TK wrote: post #73

Earlier quoted context omitted.

>Also, have you read the dagger.js code? https://github.com/dagger8224/dagger.js/blob/main/src/dagger ... It's 1600 lines. I've disassembled, decompiled and reverse engineered more code than that in a day. It's JavaScript. What comments do you need? There's a bit of noise in the first 100 lines, but it's not something you couldn't figure out in half an hour if need be. The version you linked isn't the minified versio…

Yes, there are places to find worse code, but this isn't what I would call clean, readable code. Some of it feels like it was written with the goal of not pressing enter. Can I read it and debug it? Certainly. Do I want to? Certainly not.

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. One of the core goals, though, is low lock-in: your code is still just HTML + JS + Web Components. Even if dagger.js disappeared tomorrow, your markup would continue to work with minimal adjustments.

On code readability: you’re right that the current source is compact and not heavily commented. That was a stylistic choice early on to keep things lightweight, but I understand it can make debugging less inviting. Based on this feedback, I’m planning to provide a more readable version so others can more easily step in.

So the trade-off you mentioned is valid: fewer features, but less surface area and minimal lock-in. The feedback here helps me refine where the ergonomics stop and where maintainability needs more attention.

Thanks again for taking the time to review both the idea and the code — it makes the project better, and I’ll keep iterating with these points in mind.

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

#86

Post by TonyPeakman »

em-bee wrote: post #84
TonyPeakman wrote: post #83

Earlier quoted context omitted.

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 definitely make the default case much less verbose while still allowing people to override pieces explicitly when they need to. With dagger.js the initial choice was to keep everything explicit to re…

my main interests in a framework is minimalized boilerplate code that only exists to make the framework functions work, so that i can reuse code without the framework without much change or any change at all. and a html syntax that follows the standards. your syntax here has a bit of an issue because characters like * or + may be ok in HTML, but they are not valid in XML or XHTML, so they limit the usability in syste…

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.

On syntax: you’re right that +/* aren’t XML/XHTML-friendly. The short, stackable directives were chosen for ergonomics, but I’m considering offering a dg-* variant to improve standards compliance where XML/XHTML interoperability matters.

Appreciate the push here — keeping the buildless path the default while tightening standards compliance is exactly where I want to take dagger.js next.

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

#87

Post by em-bee »

TonyPeakman wrote: post #86
em-bee wrote: post #84

Earlier quoted context omitted.

my main interests in a framework is minimalized boilerplate code that only exists to make the framework functions work, so that i can reuse code without the framework without much change or any change at all. and a html syntax that follows the standards. your syntax here has a bit of an issue because characters like * or + may be ok in HTML, but they are not valid in XML or XHTML, so they limit the usability in syste…

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. On syntax: you’re right that +/* aren’t XML/XHTML-friendly. The short, stackable directives were chosen for ergonomics, but I’m considering offering a dg-* variant to improve stan…

dg-* variant...

if i may make a suggestion here, you could use the type as part of the name:

so +load becomes lifecycle.load

*value would be control.value

+click would be event.click

@raw would be meta.raw

. because i think only _ . and - are allowed. you want to keep - for complex names: control.some-value and _ doesn't feel right.

maybe you want to choose other names. aurelia uses this approach with different names. i didn't want to influence you to choose aurelias names, so i picked those from the table on https://daggerjs.org/#/directive/introduction

keeping the names in line with the terminology you use makes it easy to remember them and also to look them up. (what is a lifecycle? i can just search for it. the only downside is that lifecycle in particular is long, so if that is used frequently, a shorter name might be preferable. maybe just 'cycle')

oh and while we are talking about about verbosity. i saw one router example that looked a bit verbose. but maybe that's because it tries to show all the options you can set on a route.

a minimalist example would be nice to see there in contrast. (maybe there is one and i just didn't find it)

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

#88

Post by TonyPeakman »

em-bee wrote: post #87
TonyPeakman wrote: post #86

Earlier quoted context omitted.

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. On syntax: you’re right that +/* aren’t XML/XHTML-friendly. The short, stackable directives were chosen for ergonomics, but I’m considering offering a dg-* variant to improve stan…

dg-* variant ... if i may make a suggestion here, you could use the type as part of the name: so +load becomes lifecycle.load *value would be control.value +click would be event.click @raw would be meta.raw . because i think only _ . and - are allowed. you want to keep - for complex names: control.some-value and _ doesn't feel right. maybe you want to choose other names. aurelia uses this approach with different name…

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 the value in a more standard, semantic form like lifecycle.load, control.value, event.click, meta.raw. It’s clearer, easier to search, and plays nicely with stricter environments.

I’m leaning toward offering both: the current short symbols for quick prototyping, and a more verbose but standard form (potentially with dg- or dot-namespaced attributes) for projects that need stronger compatibility. Your idea of aligning the names with the terminology we already use makes a lot of sense.

And thanks for pointing out the router example — you’re right, the docs only show the “all options” version. I’ll add a minimalist example alongside it so people can see the simple path too.

Appreciate the thoughtful feedback — this gives me a clear direction for making dagger.js easier to use while staying standards-compliant.

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

#89

Post by em-bee »

TonyPeakman wrote: post #88
em-bee wrote: post #87

Earlier quoted context omitted.

dg-* variant ... if i may make a suggestion here, you could use the type as part of the name: so +load becomes lifecycle.load *value would be control.value +click would be event.click @raw would be meta.raw . because i think only _ . and - are allowed. you want to keep - for complex names: control.some-value and _ doesn't feel right. maybe you want to choose other names. aurelia uses this approach with different name…

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 the value in a more standard, semantic form like lifecycle.load, control.value, event.click, meta.raw. It’s clearer, easier to search, and plays nicely with stricter environments. I’m leaning towar…

your positive responses make me wish i had an opportunity to build my next site with it. not ready for that yet, but hopefully when i get some time to work on my aurelia side project again, i can try making a second version using dagger.js.

actually in recent weeks i have been thinking about building simple sites with just vanilla js, but with some custom functions to enable binding and routing which is the most important stuff. but then i'll probably need iteration, click events, and a few other things, and when i saw dagger.js i realized that my own collection of features would pretty much get me to where you are now...

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

#90

Post by TonyPeakman »

em-bee wrote: post #87
TonyPeakman wrote: post #86

Earlier quoted context omitted.

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. On syntax: you’re right that +/* aren’t XML/XHTML-friendly. The short, stackable directives were chosen for ergonomics, but I’m considering offering a dg-* variant to improve stan…

dg-* variant ... if i may make a suggestion here, you could use the type as part of the name: so +load becomes lifecycle.load *value would be control.value +click would be event.click @raw would be meta.raw . because i think only _ . and - are allowed. you want to keep - for complex names: control.some-value and _ doesn't feel right. maybe you want to choose other names. aurelia uses this approach with different name…

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

The original react router demo as a comparison: https://codepen.io/pshrmn/pen/YZXZqM?editors=0010

Post reply on HN