4 ms·

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 com

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 1y ago
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 1y ago
  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.
  - em-bee 1y ago
    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.
    - TonyPeakman 1y ago
      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.

em-bee 1y ago

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 1y ago
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.
- em-bee 1y ago
  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.
  - TonyPeakman 1y ago
    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.