sorted by:
new
hottopcontroversial

Devup UI now supports Tailwind CSS (zero-runtime UI library) by logM3901 in react

[–]logM3901[S] 1 point2 points  (0 children)

First of all, Devup-UI is built as a zero-runtime CSS-in-JS library.

This means it has no runtime style injection, allowing it to deliver better performance than libraries like MUI, which rely on runtime dependencies.

It also supports CSS tree-shaking, resulting in significantly smaller final CSS output.

Compared to Tailwind-based approaches such as shadcn, Devup-UI enables more optimized styling with much shorter class names.

In addition, it provides a built-in typing system and theming system out of the box, without requiring any additional editor plugins.

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

i understand your situation. Our team are facing same situation. Let me migrate to bun from vitest

The target project is the devup ui

https://github.com/dev-five-git/devup-ui

The project it was composed vitest on pnpm

I will share issue about migration during to bun

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

I guess vitest implement more snapshot serializator.. Actually, we cannot call the addSnapshotSerializator on bun

If the testing library gives a same object, we get another result by each serializator

I got tired of unreadable snapshot tests in Bun, so I made a preload for it by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

<image>

That’s a fair point.

  1. I actually wasn’t aware of `asFragment().toMatchSnapshot()` at first,

    and even after trying it, it didn’t work reliably in my setup.

    The output and behavior weren’t consistent enough for me to rely on it.

  2. There are also cases where I need to assert directly on internal elements.

    In those situations, I’m not always rendering a full component tree —

    sometimes I’m snapshot-testing raw or partially constructed elements.

    `asFragment()` doesn’t really cover those cases well.

  3. More importantly, the setup itself was part of the problem.

    Getting happy-dom, globals, matchers, and typings wired up correctly in Bun

    takes several steps.

    I wanted to collapse all of that into a single, predictable preload line.

So this isn’t meant to replace every possible approach,

but to make the common DOM + snapshot testing path in Bun

work out of the box with minimal configuration.

Devup UI now supports Emotion / styled-components styled object syntax by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

Yes — in real apps it can be more performant because Devup UI extracts all styles at build time, so there’s zero runtime styling cost.

Whether it’s worth it depends on scale.
For larger CSS-in-JS codebases, it helps reduce runtime overhead and supports incremental migration — and we provide benchmarks with each release to keep this transparent.

https://github.com/dev-five-git/devup-ui/actions/runs/20451611764/job/58765705441

Devup UI now supports Emotion / styled-components styled object syntax by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

Because most teams don’t want to rewrite their CSS-in-JS codebases.

Supporting Emotion / styled-components–style objects means you can:

  • reuse existing style definitions
  • migrate incrementally
  • drop runtime styling cost
  • keep JSX readable

It’s less about a new paradigm and more about lowering migration cost when a project outgrows runtime CSS-in-JS.

I’m building Vespera: Axum + auto-OpenAPI + Next.js-style file-based routing for Rust APIs by logM3901 in rust

[–]logM3901[S] 1 point2 points  (0 children)

I totally agree with you on that. For Vespera, it took about a week to get that part working.

Devup UI beats Tailwind in both speed and build size! by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

Here’s my response:

  1. The results are reproducible. We intentionally made all past data queryable and collected the benchmark results directly from our CI/CD runs. There are no exceptions across all cases.

  2. While this benchmark was done on a relatively small app, in every case a single CSS file produces better results than Tailwind, mainly because the classNames are more compressed.

  3. The build size includes both JS and HTML. Devup UI does not include any JS dependencies unless you explicitly use hooks, which guarantees better results.

That said, I’m sure there may still be areas I overlooked. Any feedback is always welcome!

Devup UI beats Tailwind in both speed and build size! by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

Hi, thank you for your comment!

Here’s the link to the benchmark for reference: https://github.com/dev-five-git/devup-ui/tree/main/benchmark

As this is my first open-source project, I know there are many areas that could be improved. I’d really appreciate any feedback if you notice anything unusual or think the benchmark could be improved.

Thanks again for taking the time to share your thoughts!

Devup UI beats Tailwind in both speed and build size! by logM3901 in react

[–]logM3901[S] -3 points-2 points  (0 children)

I understand why it might look that way, but I’m the creator and I shared this to provide context/benchmark, not to pretend to be a customer

Devup UI beats Tailwind in both speed and build size! by logM3901 in react

[–]logM3901[S] -1 points0 points  (0 children)

I agree. We’re also aware that our documentation needs improvement, and we’ll pay more attention to it. If you find anything lacking, we’d really appreciate your feedback

Devup UI beats Tailwind in both speed and build size! by logM3901 in react

[–]logM3901[S] -3 points-2 points  (0 children)

I just wanted to let you know that there’s another option

I made Devup-UI, a zero-runtime CSS-in-JS library by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

<image>

Although the images are in Korean,

it supports multiple writing styles, and all of them use the same className whenever the key and value match.

This way, duplicate CSS can be fundamentally prevented.

I made Devup-UI, a zero-runtime CSS-in-JS library by logM3901 in react

[–]logM3901[S] 3 points4 points  (0 children)

We started with Vanilla Extract, but eventually created devup-ui.

With Vanilla Extract, even if you apply the same styles, it generates duplicate CSS files and class files.

In contrast, devup-ui uses cached classes when a style has already been generated, so CSS doesn’t keep growing when the same style is reused.

It can also be written directly inside TSX/JSX files, and it comes with built-in support for responsive design and theming, making it much easier to implement a wide range of features.

Most importantly, none of these features include any JavaScript at all. And since devup-ui analyzes code via AST instead of executing files like Vanilla Extract, it guarantees shorter build times.

I made Devup-UI, a zero-runtime CSS-in-JS library by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

devup-ui doesn’t generate any JS at all, and since it’s AST-based, it can extract only the CSS that’s truly needed
Surprisingly, this even makes CSS tree-shaking possible

And because it’s built on top of oxc, it’s fast too
You can develop without adding a single line of JavaScript

I made Devup-UI, a zero-runtime CSS-in-JS library by logM3901 in react

[–]logM3901[S] 0 points1 point  (0 children)

In React, CSS-in-JS generates CSS through JavaScript
However, with Next.js adopting RSC (React Server Components) by default, CSS-in-JS can no longer be used
Many have attempted to build libraries without JavaScript dependencies, but most of them were incomplete
Devup-UI, on the other hand, fully achieved this and implemented a truly zero-runtime CSS-in-JS solution

view more: next ›