Luca Schneider

@Meligy @Cameron_C2 @boshen_c github.com/oxc-project/ox…

@Meligy @Cameron_C2 @boshen_c This is the breaking change of the latest version. Oxlint now reports if you specified a rule that doesn't exist

@Cameron_C2 @boshen_c after upgrading to latest #oxlint, I started seeing this. I can't see any relevant info in changelog. Do you know where I can see what happened to each of these? Thanks a lot.

@timneutkens Will try to create one tomorrow. Thank you for being so active :)

@Mad__Kat Can you share a reproduction? This is not our experience. It's same-size or smaller than Next.js with webpack for all applications we run.

Lot of performance and DX improvements in this release! 🚀

@Meligy We, as developers of it, aren't just not so good in marketing to promote our solution in a meaningful way

next-yak looks like a great alternative to move from styled-components on next.js, but very few stars to recommend it to a big project github.com/DigitecGalaxus…

@Meligy We have it in production for a very large ecommerce page since more than a year and it works flawlessly. If you have any issues, just create a PR, we're happy to help out :)

@JannikWempe @devongovett Yeah but as everything, it's about tradeoffs. If your application becomes larger, the margins grow and maybe the difference is suddenly way bigger. System that can adjust to changing requirements win more often. How much you want to spend it for complexity is not absolute

@Mad__Kat @devongovett This! It's not worth it to introduce a lot of complexity for marginal speed improvements (if at all).

Nice to see Parcel mentioned as an inspiration for Turbopack's incremental architecture. Kinda funny though because I'm actually considering removing a lot of that in the next major version. 😅

@devongovett @typescript We're seeing exactly the same number for our very large e-commerce monorepo 30s before, 6s afterwards on a new m4 pro

Recently migrated to the new TypeScript Go compiler in the React Spectrum monorepo (~600,000 lines). On my M3 Max MBP: Before (tsc): 29s After (tsgo): 6s Pretty impressive, @typescript!

@devongovett Enough fast Simplicity beats crazy fast complexity anytime.

Memoization in general assumes that the function being memoized is slow in the first place. In the world of JS-based bundlers, that was true. But esbuild showed that you can do a complete production build in milliseconds with no cache. In that world, adding caching actually becomes a bottleneck. In some cases it's even slower to serialize and deserialize from the cache than just rebuild from scratch. Tracking every possible thing that could invalidate the cache is also super difficult (in some cases impossible), uses a large amount of memory, and is a huge source of bugs. So yes, O(changes) is better than O(app), but at what cost to complexity? If full builds are fast enough, is it necessary?

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

ik several reasons why app router is hated because it breaks every mental shortcut engineers expect from a router. People see a folder /app/dashboard and think, “okay, a page, easy.” No. That file is a server component segment. That layout is a suspense boundary. Every fetch you place inside it is an async landmine. One tiny fetch in a child layout can suspend the parent, trigger Flight payload waterfalls, and your client components hydrate in the wrong order. Debugging this is brutal. Flight payloads are opaque JSON structures representing React elements. If something fails, you get undefined or cannot read property X of null. Good luck tracing it. Nested layouts? Forget it. Passing useParams, usePathname, or context through multiple segments can fail silently. The parent segment may not have resolved, leaving child segments with undefined. Streaming SSR tries to help. It flushes partial HTML while children suspend. But this introduces fallback flickers. The UI shows a placeholder, then swaps content, then sometimes remounts unexpectedly. That’s what people see and hate. Caching is another nightmare. Each segment has its own cache. Fetches inside server components are cached per segment. Revalidation only affects the segment, but nested async children may cascade refetches, streaming new Flight payloads, breaking client hydration. Engineers hate this because it’s non-intuitive, inconsistent, and easy to break without realizing why. Suspense boundaries, streaming, and client/server separation compound the pain. Client components must be explicitly marked. Server components cannot access client-only hooks or state. Cross-boundary communication is fragile. One wrong assumption, one misaligned fetch, and hydration breaks silently. In short, people hate the App Router because it forces engineers to think differently. You can’t reason about pages anymore; you must reason about trees of async segments, Flight payload serialization, per-segment caches, streaming SSR, suspense boundaries, and incremental hydration. It is fast, future-proof, and minimal on client JS, but it is opaque, brittle, and extremely difficult to debug. That’s the reality. No hype. No fluff. It works beautifully when you understand it, and it breaks horribly when you don’t. That’s why engineers rage, and that’s why they swear by the old Page Router when the app is small.

@kdy1dev We've never met, but thank you for all of your work. You're a great person and when you want to visit Switzerland anytime, just write me. I'm happy to show you around 😊

2025년 회고 kdy1.dev/2025

@muyiwa_dev Just to point out, you pay a runtime cost for styled-components whereas other modern solutions rely on doing things at build time

How on earth are front-end devs enjoying Tailwind. Styled-components for the win. It is just more and more code for something so basic.

@rickyfm We're in the middle of migrating and it showed a lot of hidden issues/bugs or just potential problems

To rephrase this: React Compiler finds bugs in your code, tells you about them, and doesn’t add new bugs by compiling buggy code

@aberba Thank you 😊

Congrats 👏

And if you look at the horizon, you might spot our next big release 🚀

The pull request can be found here: github.com/DigitecGalaxus… Performance can be improved, but we're waiting for feedback and issues before we tackle that.

We've merged and released an initial turbopack support for next-yak 🎉🎉 All features work out of the box aside from imports in .yak.ts files. It also tackles long standing issues and should work generally better than the webpack version.

@s6n_jp Can we add support for `next-yak` (has the same syntax as styled-components) there as well?

Biome will be able to format your styled`` and css`` blocks github.com/biomejs/biome/…

@thdxr @KagiHQ is the only way forward and I'm more than happy to support them

man how can you let sponsored results take up the whole screen