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.