6 ms·

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

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 configure. So if Vue ESM is “full-featured without the tooling overhead,” dagger.js is more like “minimal glue you can drop in via <script> when you want to stay as close to plain HTML/JS as possible.”

zelphirkalt 1y ago
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!
- TonyPeakman 1y ago
  Really glad to hear that — thanks for the kind words! dagger.js is meant for exactly that use case: if you normally avoid heavy JS but occasionally need a bit of interactivity, you can drop in a <script> and use just what you need without a build step or big framework overhead. If you give it a try, I’d love to hear how it works out for you. Feedback from people who prefer “as little JS as possible” is especially valuable.
em-bee 1y ago
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 site that does that right now. one thing i like about aurelia is that a template and js code are associated by name, so <this-view></this-view> translates to this-view.js: class ThisView {}, this-view.html, this-view.css, so they all form one unit, and i only need to import the js and specify the class name to load and have everything else defined automatically. if i read https://daggerjs.org/#/module/introduction https://daggerjs.org/#/module/introduction correctly, then you treat each of those as independent modules, that need to be specified separately.
- TonyPeakman 1y ago
  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.

zelphirkalt 1y ago

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!

TonyPeakman 1y ago
Really glad to hear that — thanks for the kind words! dagger.js is meant for exactly that use case: if you normally avoid heavy JS but occasionally need a bit of interactivity, you can drop in a <script> and use just what you need without a build step or big framework overhead. If you give it a try, I’d love to hear how it works out for you. Feedback from people who prefer “as little JS as possible” is especially valuable.

em-bee 1y ago

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 site that does that right now. one thing i like about aurelia is that a template and js code are associated by name, so <this-view></this-view> translates to this-view.js: class ThisView {}, this-view.html, this-view.css, so they all form one unit, and i only need to import the js and specify the class name to load and have everything else defined automatically. if i read https://daggerjs.org/#/module/introduction https://daggerjs.org/#/module/introduction correctly, then you treat each of those as independent modules, that need to be specified separately.

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