Surely, when you are writing little 150+ line js programs in your html attributes you have to start considering if Alpine.js is the right tool for the job.
With Alpine if you start having anything bigger than a snippet you should pull the JS out into a component using Alpine.data()[1] which can live in a <script> tag or a JS module.
In particular, scan past the data in that example and you will see things like @keydown.down="if(selectOpen){ selectableItemActiveNext(); } else { selectOpen=true; } event.preventDefault();"
which tells you what is happening right there. So if you eliminate the data outside the component, as one should, I think it becomes a very nice readable interface.
That is ridiculous amount of javascript within an html attribute. Do all major editors/IDE have proper Alpine plugins in order to highlight autocomplete js code within those html attributes?
> Do all major editors/IDE have proper Alpine plugins
PyCharm doesn't seem to have one (I hope I'm wrong). That being said, it is possible to put the code into a proper <script> block. I personally only a trivial amount of code in html attributes such as checking a boolean value with `x-show`.
You might also want to consider whether markup/HTML is the right tool for the job in the first place. Don't get me wrong - I'm as much of an SGML geek as it gets - but there's no point in using multiple serialization formats (HTML and CSS and JS) just for the sake of it when you're coding an "app" as opposed to writing a "doc" and the app ultimately needs JS, and not just for progressive enhancement anyway.
I’m not sure you could implement the same level of functionality in less JavaScript using React or even Svelte. So you’re talking more about the shape of the API than amount of code.
A sufficiently advanced precompiler can extract those JS programs into their own files and a sufficiently advanced IDE can allow you to write even a 1000 line JS program in an attribute with no problems.
Eh, you should still pull the code out even with IDE support. HTML gets hard to read fast as tag size grows, and the example OP linked to is ridiculously large.
From a brief scan, there's also a bunch of stuff in there that seems like it would be more straightforward as `data-` attributes, since you can easily use those as arbitrary selectors for Tailwind styling. I don't know if it's actually more efficient, but it sure seems easier to read to me than dynamically generating the class string based on state.
https://devdojo.com/pines/docs/select