4 ms·

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. htt

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. https://devdojo.com/pines/docs/select https://devdojo.com/pines/docs/select

crooked-v 3y ago
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.
teaearlgraycold 3y ago
Gotta be honest with you. React is still king.
mhitza 3y ago
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?
- badbotty 3y ago
  No idea
- iambateman 3y ago
  It's possible to extract the data-attribute out to it's own thing: document.addEventListener('alpine:init', () => { Alpine.data('video', () => ({ 'show_video': false, ... That way there's code highlighting and syntax checking for JS. I definitely go this route for Alpine about half the time.
- selcuka 3y ago
  > 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`.
toddmorey 3y ago
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.
- lolinder 3y ago
  Yes, they are. Their comment identifies the problem as being: "little 150+ line js programs in your html attributes". HTML attributes are fine, 150+ line JS programs are fine, 150+ lines crammed into your HTML attributes is not fine.
  - egeozcan 3y ago
    To add a bit upon that: 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. Yet, those do not exist today.
    - lolinder 3y ago
      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.
      - egeozcan 3y ago
        The joke was that a sufficiently advanced IDE would make it easy to read anyways.
      - DoesntMatter22 3y ago
        Don't let the tailwind folks hear that. You'll be banished the forest of nothingness forever
danjac 3y ago
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. [1] https://alpinejs.dev/globals/alpine-data https://alpinejs.dev/globals/alpine-data
- badbotty 3y ago
  That looks like a better way of doing it.
- jostylr 3y ago
  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.
tannhaeuser 3y ago
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.

crooked-v 3y ago

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.

teaearlgraycold 3y ago

Gotta be honest with you. React is still king.

mhitza 3y ago

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?

badbotty 3y ago
No idea
iambateman 3y ago
It's possible to extract the data-attribute out to it's own thing: document.addEventListener('alpine:init', () => { Alpine.data('video', () => ({ 'show_video': false, ... That way there's code highlighting and syntax checking for JS. I definitely go this route for Alpine about half the time.
selcuka 3y ago
> 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`.

toddmorey 3y ago

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.

lolinder 3y ago
Yes, they are. Their comment identifies the problem as being: "little 150+ line js programs in your html attributes". HTML attributes are fine, 150+ line JS programs are fine, 150+ lines crammed into your HTML attributes is not fine.
- egeozcan 3y ago
  To add a bit upon that: 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. Yet, those do not exist today.
  - lolinder 3y ago
    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.
    - egeozcan 3y ago
      The joke was that a sufficiently advanced IDE would make it easy to read anyways.
    - DoesntMatter22 3y ago
      Don't let the tailwind folks hear that. You'll be banished the forest of nothingness forever

danjac 3y ago

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. [1] https://alpinejs.dev/globals/alpine-data https://alpinejs.dev/globals/alpine-data

badbotty 3y ago
That looks like a better way of doing it.
jostylr 3y ago
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.

tannhaeuser 3y ago

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.