Seems like a good endeavor. I would probably recommend just starting with an ad-hoc blog post sharing what is known and available and then maybe some later articles on how people could consider packaging their components as hex packages, and then perhaps over time add metadata to the hex package so a proper catalog could be built.

One other hurdle is the current lack of core tech that would let a component author share/colocate related JavaScripts their component might need. I recall the LiveView team talking about that at some point as something they want to offer.

The lack of easy-to-assemble open-source UI components is something, IMO, that makes prototyping new ideas with LiveView more costly in time. Yes, the core tech is all there that would let you custom-build things, but it just feels expensive in time. I’m very envious of the frontend Javascript UI components out there (though I’m sure they bring their own tradeoffs).

It is the biggest gap with Phoenix currently, just tumbleweeds when it comes to a professional UI component framework to start building with.

By the way @zorn I saw your “YouTube vent on Tailwind UI” as I am considering it also and yours is the only feedback I have found on it’s use with Phoenix!

My question is did you persist with Tailwind UI or did you abandon it?

I have also looked at Petal and whilst functional it doesn’t visually appeal to me, very much aligned with daisy UI asthetics.

I also tried Daisy UI and found that it bakes far too much into hard coded CSS, so much that you can’t actually theme it properly (despite their claims) and it looks quite amature in any event to my subjective eye. I gave up on it because of too many issues, for example, drawers/slideouts are viewport high, menus can’t be themed, indicator z-order is higher than drawers and overlays, navbars don’t work with drawers, swap buttons don’t work with drawers where you would expect to use them. It’s a definitive mess. If I have to add active state specific classes in addition to setting the active state on menus tabs etc just to get the damn colour I want it makes Daisy UI an almost pointless framework with more problems than solution, and theming claims that don’t actually hold true. May as well use tailwind directly, hence considering Tailwind UI.

Only the Tailwind UI has what I appreciate as a good design and use of space, anything else tailwind based that I looked at is far less polished visually. Moving beyond the typical components Tailwind UI also does provide many examples for inspiration of good design and layout.

So I’m wondering what’s your thoughts on it after using it in anger?

Your video made it sound like there was a lot of tedium reverse engineering the html into functional components.

I have also looked at Tailwind UI Headless UI stuff as a reference and I saw that there is a ton of JavaScript in them so I am weary of their claims that their html comments truthfully tell what JS to add to make them work properly is in fact the actual truth.

Any insights you have with UI components would be appreciated.

Thanks for getting back to me, given you pivoted out of intense frustration it sounds like I am better off avoiding it also. I also haven’t heard of anyone using Tailwind UI with Phoenix which suggests it’s not actually fit for purpose without a ton of work which defeats the point of using it.

Unless the TailwindUI folks provide first class support in Phoenix it will forever remain irrelevant to phoenix apps as their license prevents anyone publishing a UI Toolkit to wrap Tailwind UI also. Kind of a dud move to limiting their market but it is what it is.

I was aware of primer but I discounted it as I didn’t want a GitHub style for my app.

Interesting that you mention SvelteKit, I have referenced LiveSvelte a few times on here which to me is the killer combo for low bloat single file components. Note that LiveSvelte does not support SvelteKit as it hooks into the Phoenix build quite naturally and is not based on any dark magic, the approach is very simple as per this article.

Here is an example of how nice it is with end to end reactivity between front end and back end.

defmodule ExampleWeb.LiveSigil do
  use ExampleWeb, :live_view

  def render(assigns) do
    ~V"""
    <script>
      export let number = 5
      let other = 1

      $: combined = other + number
    </script>

    <p>This is number: {number}</p>
    <p>This is other: {other}</p>
    <p>This is other + number: {combined}</p>

    <button phx-click="increment">Increment</button>
    <button on:click={() => other += 1}>Increment</button>
    """
  end

  def mount(_params, _session, socket) do
    {:ok, assign(socket, :number, 1)}
  end

  def handle_event("increment", _value, socket) do
    {:noreply, assign(socket, :number, socket.assigns.number + 1)}
  end
end

My thinking is, if you have to reach for something like alpine (which is highly likely on any app of moderate complexity) then the better option is to reach for LiveSvelte given we have a compilation step baked into Phoneix apps anyway and we get a ton of benefits with svelte such as single file components with html, JS and local styles and awesome animation support included.

What I like is a single JS hook for our app, and with svelte being extremely minimal in what it compiles to unlike any other JS framework out there it really fits with Phoenix and liveview.

I also agree with your choice of UI framework for Svelte, Skeleton is the best of the lot after reviewing the main contenders.