Hmm... you're not really gaining anything over using a standard class selector though. I know in your example you start off by selecting on ul tag and directly referencing children etc, but you could just as easily get around that but adding classes and selecting those, rather than a data attribute.
I don't really see much benefit to using a data attribute as a selector, other than very minor aesthetic improvement (subjective, because I find the .find('[data-...]') syntax quite messy). The real benefits are in adding essential data for that individual object for referencing in your JS. I'm working on a project that is using polymorphic objects quite heavily, and I'm outputting my polymorphic_url to a data-update-url attribute for use in AJAX calls, for example.
I think you might have missed the point. The goal here isn't aesthetics, but rather the decoupling between your HTML structure and your JS. At the end of the video Chris completely changes the markup and everything still works. That's the benefit.
but what's the difference between using .find('[data=...]') vs just using a class of 'todo' or 'todo-toggle' etc on your element and using $('.todo') or $('.todo-toggle')? Same applies, you can still swap our a ul for a div or whatever and it would still work, you'd just have to move the class to your new element just as you would with the data-behaviour attribute. The only difference I can see is code aesthetics. In fact, using the css class as a selector could improve DRY as you're likely going to have to define a CSS class in order to style your todo, or todo-toggle etc anyway.
What's the functional difference between:
I'm not saying this approach is wrong, just that unless I missed something, I can't see what you gain. For me, it makes more sense that the definition of the type of the object/element, i.e. the class, should be in the class attribute, and the object/element specific data should be in data attributes. Effectively defining classes in a data attribute just seems a bit off to me.
Class names tend to change. Especially for bigger teams. There might have a designer going in there changing markup and css, but still wants to the same behavior. Personally, I've been liking the idea of using js specific classes (.js-todo-toggle for example), but data attr's are good too.
Agreed, this was my point that was hard to get across in a simple example. It's not hugely beneficial on small projects or teams, but it adds up the larger a project becomes.
As soon as you have a designer or two fiddling with the .todo class in CSS and moving things around, you're likely to see things break really quickly. They won't understand how they broke functionality and it's much harder to track down when things go wrong.
I'd say the main benefit of using data attributes instead of classes is that it's a clear separation of responsibilities. Designers can fiddle with all the classes and IDs they want so long as you remind them not to mess with the data attributes. It's just a little easier recognizable than "js-" prefix.
Is selecting by attribute not an order of magnitude slower than selecting by class? I get the reasoning behind it, but it just seems to be hacking data-attributes to act as classes/IDs - it's very explicit, but it seems to miss the point of data-attributes very slightly (I suppose you could just run a script on build that converts to classes, mitigating any performance hit, but anyway...)
Basecamp follows this approach and doesn't have any troubles. It will always depend on how intense your JS ends up being, but you can also cache the results of these queries in the constructor and reference their results for faster access.
At the end of the day, if you're not doing that much constant manipulation, you're not going to run into any performance problems with this. Obviously when you're doing a lot, you're going to want to know exactly how the browser handles each manipulation.
this would invoke the constructor on every page right ? is that ok or should one try to only run if the data-behavior is on the current page ?