top | item 45302020

(no title)

TonyPeakman | 5 months 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.

discuss

order

em-bee|5 months ago

dg-* variant...

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)

TonyPeakman|5 months ago

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.