Arrr good stuff. Only a deleted line of JS-code is a good line of JS-code.

Furthermore, once Phoenix v1.8 arrives and starts using TailwindCSS by default, I don’t think calling this stack anything more than just LiveView is very useful…

The acronym PETAL played it’s role before, when we had to compose our own stack on top of LiveView.

Now, as LiveView comes with all the necessary elements built-in (JS commands, TailwindCSS set up by default), I think the PETAL acronym can be retired and we don’t need any replacement for it.

Same here. I never understood the appeal of AlpineJS for a LiveView project. When I started using LiveView (long before LiveView.JS) I decided to use JS hooks to keep things simple, cause I didn’t want to add a JS framework. Later on, because everyone was talking about Alpine, I gave it a try out of curiosity. I tried to replace my hooks with AlpineJS. I really had a hard time trying to make it all work, and I came to the conclusion that LV hooks are more flexible and better suited than Alpine for a LiveView project, also because they can hook into LV life-cycle events directly. So I stripped the “A” from PETAL a long time ago. Even more so now that we have LiveView.JS. I suspect Alpine is something so many people were using mainly because so many people were using it.

This is great and I’ve been thinking about this a lot and recently refactored a lot of the Alpine in Metamorphic (including creating the glide photo effect with JS commands).

Though there’s still a few things that I’m not sure would be as easy to do with JS commands, like counting the number of characters in a form as you type. AFAIK that’s still easier/better experience with Alpine but it’s definitely getting closer!

I tried Alpine I think last year for a few weeks and ripped it out. Tabs can be done via CS and everything is pretty much instantaneous. No JS of any kind is required.

In production, I’m using nested css elements handled by radio buttons.
css

#radio-page-1 { display: none }
#radio-page-2 { display: none }
#radio-page-3 { display: none }
#radio-page-4 { display: none }
#radio-page-5 { display: none }
#radio-page-1:checked ~ &--wrapper >  #display_control > #page-button-1 {border: red 0.2px solid; color: red;}
#radio-page-1:checked ~ &--wrapper > #display_control > #page-button-1:hover {color: white;}
#radio-page-1:checked ~ &--wrapper > &--subgrid1 {display: grid;}
#radio-page-1:checked ~ &--wrapper > &--subgrid2 {display: none;}

html

<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-1" checked value="1">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-2" value="2">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-3" value="3">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-4" value="4">
<input type="radio" phx-update="ignore" name="radio-page-group" id="radio-page-5" value="5">
<div id="main--wrapper" class="main-wrapper">
  <div class="main-subgrid1"></div>
  <div class="main-subgrid2"></div>
</div>

Here is another example done using z-index instead:

Modals can also be done via css, but I think Phoenix.JS is a bit cleaner.
https://sheer.tj/phoenix_live_view_modals.html