Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!
Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style
Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes.
Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better.
Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives
I'll never understand CSP not allowing onclick handlers. Having all your javascript in a separate file makes it very hard to diagnose and understand what is causing the event on the element.
onclick and other in-HTML handlers have some unsafe eval-like behavior for old compatibility reasons (with ES1 and the old web/old DOM) and I feel like the CSP designers were overly-cautious of XSS exploits via DOM manipulation that are hard to do in practice, but still in theory a major security concern.
I wonder if there were a better way to opt-in to "use strict" (and maybe even ESM friendliness) in onclick handlers if that would have fewer CSP concerns. I doubt there are any current proposals to build such tools for HTML, though.
