Luca Schneider

But isn't there an issue with the request-aware CSS when someone navigates to a page client-side vs. server-side so that the order of the CSS stylesheets get mixed up?

Yeah I think that makes sense. Also making CSS request-aware is the right direction and adding some tools and/or rules for users to remember helps in the long run 🙂

This is very complicated and not easy to do. If you mix ambient and lazy css imports with shared styles and default chunking it gets messy quite quickly so that it's very hard to reason about.

I thought so 😅 it makes more sense this way around without any additional effort

But I bet you know that :) Just wanted to clarify. Rspack has a way better webpack API coverage.

A webpack plugin doesn't automatically mean that it works in turbopack. The API's aren't 100% compatible

Good question. No I think this is currently not possible. You could write components that pass the props a certain way to other defined components but not as generalized mixin.

Do you have an example where you would need that?

I would love it when OXC not only supports generating this kind of comment but arbitrary comments

I sign this as Swiss too 😁

@jensimmons.bsky.social

we need your help

@⁠⁠media queries stopped working on our production page

safari now requires a reload to trigger the media query after resize

bugs.webkit.org/show_bug.cgi...
Safari Version 26.3 (21623.2.7.11.6) & Safari TP

the reproduction has no javascript only css:

You could have a font mixin for this case that does more or less what your `fontCss` does, but with less optimal ergonomics, as we need to have the same API as styled-components

Yeah I think this is something that is hard to migrate. We can't cross the static-dynamic boundary with a function. So yak files are only good to create some variations of styles and using them in normal components and not to create dynamic properties & values during runtime.

If you export the function from a .yak.ts(x) file you can use any build time macros/js code you want 😅

Danke fürs heads up. Ich luege au immer chli sini Streams und ich denke für üs wird sich nid gross was ändere mit 2.0 😅 Aber ich bin gspannt

This is exactly how it works :) (e.g. github.com/nvim-treesit...)

And I have to correct myself. For us the template syntax is way easier to handle, aa next-yak doesn't do a lot there and just uses the platform that's available (postcss or lightning css). So we don't need a complete parser

But still. Another perspective or the focus on instrumentation of react could be interesting and create some ideas :)

How do you measure/instrumentize this? Is it during CI and you compile every package on it's own?

React Internals Deep Dive A live series of JSer deep diving into React internals, by reading the actual React source code. This series helps you understand how React works internally and write better React code.

I would read both. There is also this: jser.dev/series/react...
Which I've read a lot and is quite niche.

This is the missing piece. Excited to see what the future holds

Crazy tech. Really nice 🎉

Vite support (github.com/DigitecGalax...) öffnet üs grad sehr viel Tüüre :)

🇨🇭 Das isch au immer guet 😅 mir sind grad sehr viel Sache am baue/usprobiere für next-yak, denn passt solid grad au no drii. Müend nur luege dass d runtime solid anstatt react nimmt, chli patterns aapasse mit de reactivity rules und de grossi teil (transpilation) chan genauso bliibe

In theory we could do both, but we wanted to stay as small and focused as possible to really give the best solution for this specific problem.
Additionally if new CSS features come around we don't have to do anything and they mostly just work

From a technical side I would say that object syntax is easier to compile but template literals are easier to use if you know CSS. Our deciding factor was that we already had styled-components with the literal syntax, didn't want to migrate and saw not many benefits in the object syntax.

About the second part... Yeah we're in the CSS tagged template literal zone and have no plans to move to objects. There are other libraries that do this better (StyleX, pandaCSS, vanilla-extract) than we ever could.

Thank you for the response & feedback. I'm also glad that I can do this during my work time.

Makes sense that it isn't in your toolbox (yet 😉). As we now support vite we're also looking into growing beyond react.

I will try to figure out how easy a solid integration would be.

How about next-yak? (yak.js.org). It has turbopack, webpack and vite support. Disclaimer: I'm one of the creators

How about next-yak? (yak.js.org). Disclaimer: I'm one of the creators

Really nice writeup. TIL how SEA works :)

A cute yak riding on a rusty rocket towards the vite logo. This should symbolize that next-yak now supports vite

Finally, after adding turbopack support, next-yak also supports vite (for rolldown and rollup). Additionally we published a new storybook addon (compatible with webpack & vite).

Read up upon here: yak.js.org/docs/vite & yak.js.org/docs/storybook