* Bamboo started as a fork of Panda. The vast majority of the codebase has been refactored. However, their test suite has been incredibly useful to identify all the edge cases.

* Bamboo's API is a subset of Panda. One of Bamboo goals has been to introduce more consistency to how we write styles (without introducing lint rules). Bamboo dropped JSX factories, template literals and style props.

* Strict API is also what allows us fold 100% of styles.

* Strict API is also what allows to prune unused styles.

* Bamboo resolution is _strict_. Missing tokens will produce build error.

Over the last year, we have been obsessed with performance. We have optimized every layer of our infrastructure to the point where profiling the application increasingly started to surface bottlenecks in client-side (bundle size, and metrics like TBT, LCP, and INP). That's where CSS-in-JS comes in.

6 years ago, we started with styled-components. Then zero-runtime alternatives emerged and we started to experiment with them, eventually landing on Panda CSS. Panda took us a long way, but... they aren't _actually_ zero-runtime. Panda extracts CSS at build time, but it uses ~15KB runtime to map those style objects at runtime. This overhead surfaced repeatedly when profiling pages with lots of components (server-side and client-side).

That's where I ended up writing Bamboo to solve this.

Bamboo folds styles at build-time achieving _near_ zero-runtime (0.5KB vs 15 KB). If you write:

it becomes:

at build time.

If the variant is dynamic, then bundle is inlined with pre-computed map of classes.

That's the main idea behind Bamboo.

Thanks to folding, we were able to improve our server-side and client-side performance.

I built CSS-in-JS Arena as a sanity benchmark to track how we compare to Panda, but also to any other emerging frameworks.

Comments URL: https://news.ycombinator.com/item?id=49346044

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=49306426

Points: 2

# Comments: 1

Several open-source projects have already proven SynthID to be ineffective.

I guess whoever is the policy maker is assuming that some protection is better than none and that most people will not reach for such tools.

Related problem: Using AI to write compilers that optimize runtime code. I did this for Zod.

https://github.com/gajus/zod-compiler

Zod schemas, compiled at build time into raw boolean chains. 2-74x faster. No code changes. The plugin swaps Zod with compiled parse.

I wrote almost none of the optimizations. Claude did, in a loop, over 100+ iterations.

It works because the compiled version can be diffed against real Zod. Correctness isn't a judgment call. Same as scriptc.

This applies to every program with a reference implementation and a benchmark. Compilers, serializers, formatters, query planners, etc.

Excited for faster Internet.

https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...

Just a handful of settings to save a whole lot of trouble.

https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...

We've been using it (in beta) for months now. It makes for a very enjoyable developer experience.

With teemux, a persistent MCP server gives multiple AI agents access to logs as needed—without interrupting your development flow.

tee (Unix command that splits output) + mux (multiplexer) = teemux