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)
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.
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...
Thank you — that really means a lot to me. One of the best parts of sharing dagger.js has been hearing from people like you who’ve been down the same path and thought about building the same set of features. It makes me feel like the project is on the right track.
What you described with vanilla JS plus a few helpers is exactly how dagger.js started — I just wanted to save myself (and hopefully others) from having to reinvent the same binding and routing layer every time.
If you ever try it out on your side project, I’d be truly grateful to hear how it feels. Feedback from thoughtful developers like you is what helps me make it better.
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)