4 ms·

Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step. I've started to think something like petite-vue and twin

Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step. I've started to think something like petite-vue and twind would let you build small internal tools quickly, there are some major downsides to it which is why I haven't committed yet.

mythz 1y ago
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 step, has the full feature-set, is actively used and maintained, etc. Either way developing Web Apps (using Vue) without a build step using JS Modules is now my preference which I've written about in my Simple, Modern JavaScript post [1] [1] https://servicestack.net/posts/javascript https://servicestack.net/posts/javascript
- zelphirkalt 1y ago
  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.
  - TonyPeakman 1y ago
    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.
- TonyPeakman 1y ago
  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 literally view-source and drop it into a page. So I see them as different tiers on the same spectrum: Vue (ESM) if you want a mature, batteries-included framework without a bundler; Dagger.js if you just want minimal runtime directives and WC interop with almost no moving parts. Appreciate you sharing the blog link — I’ll check it out. Always happy to see more people pushing the “modern JS without a toolchain” approach.
  - mythz 1y ago
    > 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-quick-look https://docs.servicestack.net/releases/v6_06#js-modules-quic... [2] https://lit.dev https://lit.dev
    - TonyPeakman 1y ago
      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.
TonyPeakman 1y ago
Yeah, that’s a fair comparison — Dagger.js lives in a similar space to petite-vue / Alpine: no build step, HTML-first, sprinkle behaviors where you need them. The main differences are: pure declarative mode → there is zero API and third-party code & tool dependency. Web Components first → you can wrap functionality as native Custom Elements and Dagger will happily coexist. Directive model → simple +click, +load, etc., instead of reactivity syntax or x- attributes. Distributed modules → small script modules you can drop in from a CDN when you need them. So it’s playing the same role (buildless, quick internal tools / embeds), but with a slightly different philosophy: keep everything view-source-able and make WC interop a first-class story.

mythz 1y ago

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 step, has the full feature-set, is actively used and maintained, etc. Either way developing Web Apps (using Vue) without a build step using JS Modules is now my preference which I've written about in my Simple, Modern JavaScript post [1] [1] https://servicestack.net/posts/javascript https://servicestack.net/posts/javascript

zelphirkalt 1y ago
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.
- TonyPeakman 1y ago
  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.
TonyPeakman 1y ago
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 literally view-source and drop it into a page. So I see them as different tiers on the same spectrum: Vue (ESM) if you want a mature, batteries-included framework without a bundler; Dagger.js if you just want minimal runtime directives and WC interop with almost no moving parts. Appreciate you sharing the blog link — I’ll check it out. Always happy to see more people pushing the “modern JS without a toolchain” approach.
- mythz 1y ago
  > 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-quick-look https://docs.servicestack.net/releases/v6_06#js-modules-quic... [2] https://lit.dev https://lit.dev
  - TonyPeakman 1y ago
    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.

TonyPeakman 1y ago

Yeah, that’s a fair comparison — Dagger.js lives in a similar space to petite-vue / Alpine: no build step, HTML-first, sprinkle behaviors where you need them. The main differences are: pure declarative mode → there is zero API and third-party code & tool dependency. Web Components first → you can wrap functionality as native Custom Elements and Dagger will happily coexist. Directive model → simple +click, +load, etc., instead of reactivity syntax or x- attributes. Distributed modules → small script modules you can drop in from a CDN when you need them. So it’s playing the same role (buildless, quick internal tools / embeds), but with a slightly different philosophy: keep everything view-source-able and make WC interop a first-class story.