Headless Component Library

[Zer0PointModule]

I see NiceGUI uses Quasar, but that can make it harder to achieve a highly custom or generally more modern look and feel by default.

Has there been any consideration of using a headless UI library instead? For example, in the Vue ecosystem:

https://github.com/unovue/reka-ui

For a tool like NiceGUI, this seems to align well with the right priorities: flexible, unopinionated components with accessibility handled well out of the box. Styling is definitely possible with NiceGUI as it is today, but a headless approach could make that process easier and more natural when building custom interfaces.

[falkoschindler]

Thanks for raising this — it's a fair observation that Quasar's defaults can be opinionated, and customization sometimes means pushing against the grain.

Just to make sure we're on the same page about terminology: "headless" libraries like Reka UI, Radix, or Headless UI provide component behavior, state, and accessibility (ARIA, keyboard nav, focus management) without any visual styling — you bring your own CSS/Tailwind. That's very different from what NiceGUI ships today, where ui.button('OK') gives you something that looks good out of the box.

A few thoughts on why we're not planning to replace Quasar with a headless library:

1. Batteries-included is a core value. A big part of NiceGUI's appeal is that simple code produces polished UI immediately. A headless foundation would require users to style every component themselves, which is a fundamentally different product.

2. Surface area. Quasar covers a lot: virtual-scrolling tables, date/time pickers, uploaders, editors, notifications, layout scaffolding, etc. Headless primitive libraries intentionally stay narrow, so we'd end up reimplementing a lot of what Quasar already gives us.

3. Customization is already quite flexible. Between .classes(), .props(), .style(), Tailwind, and Quasar's CSS variables, you can restyle things pretty deeply. If you're hitting specific walls, we'd love concrete examples — that's often more actionable than a framework swap.

What we could imagine is a set of opt-in, unstyled primitives living alongside Quasar for users who want to build a fully custom design system. But that's a significant undertaking and we'd want to see real demand before going there.

Curious: is there a specific component or customization case that prompted this? That would help us understand whether the gap is "Quasar is in the way" or "a particular thing is hard to style."

[Zer0PointModule]

Happy to expand on this, and thank you for the thoughtful and well-reasoned reply.

In general, when I look at the documentation and demos, I personally do not find the default look and feel very appealing. To me, it feels somewhat dated, to the point where I would hesitate to use the default styling even for internal tools. If I had to pinpoint why, I think it is largely the Material UI aesthetic.

That said, I do want to stress that I really like what you have built. Based on the documentation, NiceGUI looks like an excellent fit for the kinds of internal tools we need to build, and I fully intend to use it regardless, because functionality is ultimately the top priority.

And yes, you understood my point correctly: a headless UI library ships with little or no opinionated styling out of the box, but that does not necessarily mean it has to feel visually unappealing. For example, if you look at Radix UI, the components may be minimally styled, but they still feel modern and well-considered:
https://www.radix-ui.com/

One point I think is still worth considering is that adopting a headless foundation does not necessarily conflict with the “batteries-included” philosophy. In principle, NiceGUI could still ship with a polished default theme and ready-to-use components, while also making it easier for users to opt out of that styling and build their own design system on top of unstyled or lightly styled primitives.

Something like shadcn/ui could also be interesting in that context, since it is not purely headless but still gives a lot of flexibility in achieving a more custom look and feel.

[falkoschindler]

Thanks for the detailed follow-up — the "looks dated" critique is fair, and it's something we've been circling in a couple of other threads:

• Improve the default appearance of NiceGUI apps #5198 is the ongoing conversation about improving NiceGUI's default appearance. One idea there is a set of officially maintained theme presets (e.g. ui.theme.element_plus()) that globally tweak defaults — shadows, corner radii, density, primary color — to shift the overall feel without swapping frameworks.
• Immediate method to make the UI modern and more attractive for AI coders with no web experience? #5470 is especially relevant: @ehfd and @evnchn shared before/after results from asking an AI agent to produce a modern Tailwind look via default_props, default_classes, default_style, and ui.add_head_html. A nice data point that the existing styling hooks can get pretty far; the missing piece is more about curated presets and discoverability.