Show HN: Flyon UI – Tailwind Components Library

Hello welder,

Thanks for sharing your thoughts.

Obviously, shadcn is the best library.

FlyonUI is designed to combine the best of both worlds: the aesthetic appeal of semantic classes and the powerful functionality of JS plugins.

Why should I use FlyonUI? Using Tailwind CSS alone may lead to cluttered HTML with numerous utility classes, which can be a nightmare to maintain.

Apart from that Tailwind CSS or DaisyUI doesn’t provide any interactive headless JavaScript components like accordion, overlay, dropdowns, etc…

This is where FlyonUI shines.

FlyonUI brings together the beauty of semantic classes and the interactive headless JavaScript plugins, offering you a powerful toolkit to build stunning, interactive user interfaces with ease.

I love the approach of shadcn and the fact that they use Radix primitives, which have a focus on accessibility. But I wish they would have a pure CSS option without tailwind style classes. It took me some time to translate the classes shadcn uses from tailwind to CSS (which sometimes require more research) and the variables for colors, sizes, etc. into the CSS-to-js system I use (which is stitches - yes, its deprecated, but still the best one I know).

Tailwind is nice for prototyping and simple projects, but often I find that it obscures things too much and when I need more control over the CSS it is too abstract and awkward to use.

It was ShadCN which convinced me that there is a lot of utility in Tailwind TBH. Absolutely love the whole 'just copy the component to my repo' concept. Plate JS follows the same and uses the same components but is a WYSIWYG editor: https://platejs.org/

In Shadcn you will have to style the components manually while Flyon UI provides styled-components. You will get Semantic classes as well.

It would be nice if shadcn became the standard and you could copy components from any tailwind component library.

Technically, this would mean that all these component libraries allow you to copy-paste their components, and additionally there would be a 'standard' in theme token naming.

For the AlpineJS / Livewire fans:

- https://wireui.dev

- https://fluxui.dev

- https://www.penguinui.com

Hello Fermigier,

Thank you for sharing your input.

You’re correct that Preline has a dual license (MIT) allowing usage for both personal and commercial projects.

We've confirmed with Preline and they have implemented this license just to restrict those who utilize their code without proper attribution.

FlyonUI utilizes the Preline JS plugins to enhance the functionality of its semantic components.

As a result, it also adheres to the same licenses. For more details, please visit: https://flyonui.com/docs/getting-started/license/

Thank you for the feedback! I'm glad to hear that you found the inclusion of third-party plugins helpful. We understand that seamless integration is often a point of friction, so we've made it a priority to simplify that process.

That's the reason we have said "Easiest Tailwind CSS Components Library"

Hello fmnxl,

Those are nice questions and we asked the same ourselves twice before we started working on this http://flyonui.com/.

Preline is a great library with its beauty. It uses Tailwind CSS utility clasess may lead to cluttered HTML with numerous utility classes, which can be a nightmare to maintain.

Where DaisyUI is the most popular component library for Tailwind CSS, offering a wide range of components with semantic class names. However many projects require interactive features that need JavaScript.

This is where FlyonUI shines.

FlyonUI builds on top of DaisyUI by integrating Preline’s JS plugins, offering headless, fully unstyled components that are accessible and responsive.

We've used an open-source library called datamaps https://datamaps.github.io/ which plots India as you're seeing on FlyonUI.

Which indeed needs to be correct.

Pretty sus in this thread

Yes, if Daisy UI provides support to Svelte, we will surely go for it.

Hello rockyj,

Here are some key points addressing the need for another component library on top of DaisyUI, like FlyonUI:

Additional JavaScript Support: DaisyUI is the most popular component library for Tailwind CSS, offering a wide range of components with semantic class names. But many projects require interactive features that need JavaScript. FlyonUI builds on top of DaisyUI by integrating Preline’s JS plugins, offering headless, fully unstyled components that are accessible and responsive.

Headless Architecture: FlyonUI’s headless architecture allows developers to focus on functionality, providing greater flexibility when integrating components into any UI framework or design system.

Broader Component Set: FlyonUI extends the component offering, with both UI elements and functional components that handle interactive behaviors like accordion, overlay, dropdowns, and carousels, etc.

Third-Party Component Support: FlyonUI provides built-in support for popular third-party libraries like ApexCharts, FullCalendar, Flatpickr, and Toast, etc. This allows developers to extend their UIs with advanced features.

For more details refer: https://flyonui.com/docs/getting-started/introduction/

I really dislike daisy's default colors and changing them is a PITA

Hello kewp,

We appreciate your feedback.

Honestly, we've just shipped our first release and we will be creating guides for the framework integration soon.

https://flyonui.com/docs/getting-started/framework-guides/

However, you can mention localhost in the URL if you're trying on the local machine or you can share stackblitz URL with setup which you have tried.

A huge thanks to our talented design team for their exceptional work and dedication! Their creativity and attention to detail have truly elevated the project

Thanks for the appreciation & suggestion. We will look into it.

Thanks for the appreciation.

Thanks for the appreciation.

8 months actually...!! But worth it. The appreciation and love it is getting already, the efforts are paid off.

Thanks a lot for your appreciation.

You are welcome. Thanks for the appreciation.

Hello littlestymaar,

Thanks for sharing your thoughts.

To deal with the huge number of class lists like this

`fixed flex items-center w-full max-w-xs p-4 space-x-4 text-gray-500 bg-white divide-x rtl:divide-x-reverse divide-gray-200 rounded-lg shadow top-5 right-5 dark:text-gray-400 dark:divide-gray-700 dark:bg-gray-800"` [1]

We've created Flyon UI, to combine the best of both worlds: the aesthetic appeal of semantic classes and the powerful functionality of JS plugins.

With FlyonUI you can achieve this with semantic classes like:

btn btn-primary

for more details: https://flyonui.com/docs/third-party-plugins/notyf/

It's more ergonomic than using stylesheets.

- No external stylesheets. No need to think about optimising the serving of CSS assets (e.g. with CDN)

- Co-locality: work on styling right where the element is, you don't have to figure out which stylesheet affects a particular element.

- No naming headache, as there's no need to give class names to elements in order to style a particular (or set of) elements

These days HTML is served compressed, with gzip/brotli, so long class attributes won't bloat the resulting file size by much.

Stylesheets still has its place of course.

I really agree on that one. Being able to define SOME (and I insist on that point) style directly in HTML is super convenient and can be a huge time saver day by day. But I think Tailwind went too far by trying to entirely replace CSS with countless classes and shortcuts. Just imagine the learning curve and the time spent by devs trying to find the right syntax for a specific transition or such...

I like the approach of tools like Perseid (https://perseid.dev/docs/ui/styling/classes), focusing only on layout design and providing a small set of built-in CSS classes (alignments, positions, margins, dimensions, …) for that purpose. All the rest (colors, shadows, fonts, animations and such) lying in good old CSS declarations.

I had my doubts, but Tailwind's mantra "looks horrible, but you need to try it!" turned out to be true for me.

You can think of Tailwind as the "APL of CSS." A single utility class can generate a lot of CSS for you, which is one advantage.

The key benefit of Tailwind is that it co-locates your CSS with your HTML, reducing cascading issues and improving maintainability.

Like any codebase, you can use your tools to add more structure and meaning.

For example, I like using a tw function like this:

    export const tw = (...classes: (string | undefined | boolean)[]) => classes.filter(Boolean).join(" ");

    class={tw(
      "fixed top-5 right-5 w-full max-w-xs p-4",
      "flex items-center space-x-4 divide-x divide-gray-200 rtl:divide-x-reverse dark:divide-gray-700",
      "rounded-lg shadow",
      "bg-white text-gray-500 dark:bg-gray-800 dark:text-gray-400"
    )}

Finally, the filter in the tw function allows for easy conditional classes:

    class={tw(kind === "something" && "m-4 p-4")}

--

1: https://github.com/biomejs/biome/pull/1362

This is like a backend developer asking someone using a spreadsheet why don't they just build their own database. Or a sysadmin telling you why don't you just run your own Kubernetes cluster. Unless there's like a 10 person team working on the same thing, you gotta take shortcuts somewhere.

Not here to argue that learning CSS properly isn't better, but I legit have no interest in doing so. I can copy-paste that code and be sure it'll look exactly the same on my website. I can't do the same with CSS.

Writing vanilla CSS often involves the hassle of coming up with proper class names, which can become tedious. That's where Tailwind CSS shines, as it allows you to apply styles directly with utility classes. However, repeatedly using the same classes and writing many of them can become cumbersome. To simplify this, FlyonUI introduces semantic classes to streamline your work. For example, instead of writing multiple utility classes for a button, you can simply use `.btn`, and your button styling is ready to go.

A lot of people find tailwind easier to use because it cuts out the steps in CSS where you have to come up with all those names for elements/containers/wrappers etc and define the styles for them all.

The big long lines of classes are often only written once anyway as web development usually makes use of components or partials for repeated elements.

Obviously others can continue to use CSS if they prefer to do it that way.

you've gained:

- fine-grained design tokens (p-63 doesn't exist)

- freedom from having to name things prematurely

- not having to jump back and forth between index.html and styles.css

Thanks for the appreciation.

Thanks a lot for the appreciation & detailed review.

[dead]