This is a terrible, horrible, awful idea, because it flies straight in the face of semantic HTML. In the HTML/CSS/JS ecosystem, behavior and appearance are both part of the nature of an object. It is perfectly reasonable to say "this DOM object represents a book title. Display it with italic text and a gray background, and when it is hovered over, pop up an image of the book cover". There is no reason to divide this information between classes
js-book; rather, both the CSS and the JS should refer to class
book. That way, the markup can just have the one
book class and not have to know anything about whether it's dispatching to CSS, JS or neither.
A worse side effect of the
js- prefix is that it prevents "happy collisions", where a class name meant for one domain becomes useful in another. Let's continue the previous example. Suppose that, differently from what I stated above,
<div class='book'> only displayed the italics on the gray background (that is, it was only used for CSS). Along comes the JS developer, and knows that he wants to add the cover popup to every item of class
book. He should just be able to write something like
$('.book').on('mouseover', addPopup), thus making what was previously a CSS-only class useful for behavior. However, the practice of putting
js- on classes meant for JS would mean that an extra -- and completely redundant -- class would have to be added to all
book items. This benefits nothing, and should be avoided.
If you think you need
js- on your classes, you're probably not testing enough.