[TonyPeakman]

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 directly from a CDN, mix and match across projects, and avoid any assumptions about file structure or bundling.

The trade-off is exactly as you noticed: dagger.js doesn’t auto-bind a .js class to a .html and .css file. It gives up that convenience in exchange for transparency and flexibility in how modules are loaded.

That said, I think your idea of a convention layer on top of dagger.js (similar to Aurelia’s “unit” model) is interesting — it could make sense as an optional helper for people who want stronger coupling between files.

[em-bee]

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.

[TonyPeakman]

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.