bartblast
Hologram UI is in the works - the official component library for Hologram - and the waiting list is now open.
A common reaction when I mention this is: “Just generate it with an LLM.”
But there’s more to a good component than markup - accessibility, responsive design, cross-browser compatibility, and the dozen edge cases nobody remembers until someone hits them. And it’s not just individual components, it’s them working together: consistent API, shared design tokens, predictable behavior, reusable composition patterns. A library designed around Hologram’s conventions gives you idiomatic components - not generic ones bolted on.
If rolling your own works, no reason to stop. But not everyone wants to spend time on components when they could be building their actual product.
What you get on the waiting list:
- Early access before the general launch
- Help shape what ships in v1 (input on which components get priority)
- Proceeds sustain Hologram’s development
Join the waiting list: hologram.page/ui
Curious what the community would prioritize - what components do you find yourself rebuilding most often? Forms, modals, data tables, navigation? 
Where Next?
Trending in News & Updates
Other Trending Topics
Latest Hologram Threads
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #ai
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 5- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
jonas_h
Interesting.
I really hope you won’t depend on Tailwind for this as I don’t want Tailwind as a dependency for my projects. If you would use standard CSS it would increase your reach (useful for both Tailwind and non-Tailwind projects) and you avoid compatibility issues when Tailwind introduces breaking changes. (CSS is super stable).
bartblast
I agree - it will be pure CSS, no Tailwind dependency. Easy to drop into any project, and easy to combine with Tailwind or another framework if that’s your stack.
jonas_h
Fantastic!
sezaru
Honestly, I would prefer if you split the components into 2 parts.
One is the the “raw” component, without any UI attached to it, just its business logic, minimum HTML and attributes to decorate it. In other words, something like Headless UI.
And the other is a implementation of a style for these components.
Also, it would be great if the library would work like Chelekom - Phoenix & LiveView UI kit and components where you use a mix task to “install” the components, basically you just install the library for your dev environment, and when you run a mix task for installing a component, it will create its code inside a components directory inside your project. This means that it is very easy for the user to get the component and customize it for its needs with ease
bartblast
The plan is to offer both a default path and an escape hatch:
Batteries-included with strong theming. Default path:
alias Hologram.UI.Comboboxand you’ve got an accessible autocomplete with full keyboard nav and ARIA support dropped into your page. A first-class theming layer (design tokens, variants, slot overrides) should cover most visual customization - colors, spacing, typography, density - without anyone needing to touch source. Structural customization (markup, layout, composition) is where the eject path below comes in.Composability + generators on top of the default path. A mix task that copies a component’s source into your project, with the smaller building-block primitives - effectively the headless layer you described - staying as a library dep. You own the wrapper and can customize it freely, while still getting upgrades to the underlying primitives.
The honest tradeoff with the eject path is drift on the ejected wrapper: once it lives in your repo, package upgrades stop touching that file and you own its maintenance from then on. The primitives underneath keep getting upgrades through the package - but the wrapper is yours to maintain. That cost compounds across many ejected components, so the eject path is best treated as per-component rather than default. Great when you genuinely need to fork the behavior or restructure the markup; not great if you ejected just to change a color, which is what the theming layer is there to prevent.
Probably shipping the batteries-included + theming side first, then layering the generator path on top once I see what people actually try to customize.