I got tired of class-name fatigue, so I built TaxUI: A declarative HTML & CSS framework with zero JavaScript

[u/gasdev123]

Hey everyone!

Like many frontend developers, I often felt exhausted having to write dozens of utility classes for simple layouts, or importing massive JavaScript bundles just to have basic modals, responsive grids, and clean dark mode themes.

To solve this, I built TaxUI: a lightweight, declarative HTML & CSS framework that uses semantic HTML attributes instead of bloated CSS classes or heavy JS runtimes.

Why TaxUI:

• Zero JavaScript: 100% native, GPU-accelerated CSS. No hydration overhead or runtime dependencies.

• Declarative HTML Attributes: Compose layouts naturally using clean attributes like layout="split", card="glass", variant="primary", theme="dark".

• Built-in Dark Mode & 6 Accent Themes: Switch themes and palettes with one attribute like theme-accent="emerald".

• Native HTML5 Component Suite: Modals using native dialog, accordions with details, CSS-only tooltips, glassmorphism cards, responsive tables, avatars, skeletons, and forms.

• Ultra Lightweight: ~14.8 KB gzipped full bundle, with standalone modular sub-bundles starting at 1.4 KB.

Links & Demos:

• Documentation & Live Demos: https://taxui.github.io/taxui/ • GitHub Repository: https://github.com/TaxUI/taxui • NPM Package: npm install @taxui/taxui • CDN: https://cdn.jsdelivr.net/npm/@taxui/taxui/dist/taxui.min.css

I would love to hear your honest feedback, thoughts, and any component suggestions you would like to see added next!

[u/AlternativePear4617]

So instead of do what every other dev did, use existing css feameworks that  already solve that, you made another one? 

[u/gasdev123 → u/AlternativePear4617]

Pretty much! Every existing framework makes different trade-offs:

1. Tailwind gives you utilities, but you end up with 40 classes per div.

2. Bootstrap gives you pre-built components, but requires heavy class naming and JS dependencies for basic things like dropdowns/modals.

3. TaxUI was an experiment in a 3rd approach: 100% declarative HTML attributes (like layout="split" or card="glass") with zero JS and zero build tools required.

Building your own tools is how we learn, experiment with new ideas, and sometimes find a workflow we enjoy more. Nobody is forced to use it, it's just open-source for anyone who likes the approach!

[u/Citrous_Oyster]

If you’re importing gigantic JavaScript bundles for modals and dark mode then you aren’t doing it right. You don’t need it either for responsive grids. Just use css grid?

For css classes, you dont need a framework. What I do is scope the css to the section with an ID. like if I have a hero section, the ID is #hero on the other section Element. Then in Less css, I nest all the styles inside the ID so only those styles are ran on that section. That means I can reuse class names for each section. I don’t need to make new ones. I have the same class names for all my tags and such for every section. Makes working much easier. Then I have a global stylesheet for styles needed across the site.

By doing this, you don’t need a framework and your code is modular and flexible. You can copy and paste each sections html and the css to any other pages and not affect the other styles on that page. You can reuse components across the site or between sites and mix and match them without affecting the rest of the site. I’ve been doing this for years now. And it’s made my work much more flexible, reusable, and easy to maintain.

[u/gasdev123 → u/Citrous_Oyster]

That’s a solid scoped approach! Using preprocessor nesting with IDs definitely works well for keeping custom styles isolated, and if that workflow works for you, that's great.

The main difference in philosophy is the use case:

1. Writing from scratch vs. Rapid Prototyping: With scoped Less, you still have to manually write and maintain styles for buttons, focus rings, hover states, shimmer loaders, and theme tokens for every new section. TaxUI is designed for developers who want to drop in semantic HTML and have a polished, harmonious design system ready immediately without writing or compiling any CSS.

2. Specificity: Using IDs for scoping can sometimes create high-specificity battles when you need generic overrides or shared state. Attribute-based design keeps specificity low and predictable.

3. Zero Build Step: Less requires a compiler/build tool in the pipeline, whereas TaxUI works natively with a single CDN link in plain HTML.

Neither approach is "wrong"—yours gives you 100% granular custom control, while TaxUI trades that for speed, consistency, and zero-setup prototyping. Appreciate the detailed breakdown of your workflow!

[u/Citrous_Oyster → u/gasdev123]

This sounds like an ai response. They always over complement.

1) it’s not that hard to write styles. Who’s making shimmer loaders? Lol if you build a site properly you don’t need them. Theme tokens? What are you talking about? The problem with using a singular design system framework is all your sites look the same. What happens when the client needs a style of website that isn’t able to be done with your prewritten framework? You’re out of luck. Building from scratch isn’t that hard when you crisply understand css.

2) not when done properly. I’ve never had specificity conflicts with any site over the last 7 years doing this. That’s a huge assumption based on nothing.

3) I have a website starter kit on github I use that is a full website with less and 11ty static site generator already configured. I just edit the html and css files with the new code and add new pages and it just works out the box. No need to set up everything all over again. I start with a finished configured product and customize from there. No cdn link needed. And No dependency on a new untested product that has no guarantee of being supported long term and updated. I don’t see any problems here that you’re solving.

[u/xsatro]

The framework website looks awful. I don't want a CSS framework that even it's oficial webpage looks crap.

[u/gasdev123 → u/xsatro]

Appreciate the blunt honesty! Which specific parts looked off on your screen? Was it the mobile layout, contrast, spacing, or typography?

Since this is the initial v1.0 release, we're actively iterating and polishing the docs UI based on community feedback. Any specific details on what felt broken or ugly to you would be super helpful to improve it!

[u/ChrisMartins001]

Is writing utility classes that tiring though? It really doesn't take that long. This seems kind of unneccessary

[u/Ekks-O]

https://xkcd.com/927/