๐Ÿ‘‹ I'm Alex & I tweet about web dev stuff Creator of @trpcio, work @square, scout @a16z

Malmรถ, Sweden
Alex / KATT ๐Ÿฑ retweeted
Replying to @TkDodo
good news re Suspense, just met w/ @rickyfm @en_JS @acdlite * we care a lot about SPAs, team misjudged how many people rely on this today * still recommend preloading but recognize not always practical * we plan to hold the 19.0 release until we find a good fix more to come
20
98
730
299,229
I'm migrating a big app to app dir and doing things that I used to do in `getServerSideProps` in my `layout.tsx` leads to 15-30s reload times in the dev server when changing the `page.tsx` - is this normal? Is there workarounds to improve this? Has anyone written about it?
14
3
52
22,668
Some stuff that helps a bit - Listing most of my package.json's dependencies in `serverComponentsExternalPackages` reduces the number of modules and improves the perf - Removing tailwind helps a bit - Deleting my imports to my backend helps a lot (not really an option)
3
7
2,680
I'm hoping turbopack will save me For now, I'm blocked.
1
2
2,123
Co-sign If you use suspense in your ("client") components and don't refactor your data fetching before updating to React 19, your app will become sluggish due to an optimization that I think most people likely would never even notice
Now I definitely need to blog about the React 19 changes around suspense and sibling pre-rendering. I haven't seen anyone so far apart from the react core team who thinks this is the right tradeoff. v19.0.0 isn't out yet so maybe there's a slim chance to get them to reconsider
6
14
185
89,314
I try really hard but I can't see how this is a feature and not a bug or feature regression
1
1
39
4,236
Great summary by @sophiebits, thank you ๐Ÿ™
Replying to @TkDodo
discussion at React core team meeting today โ€” a few notes: * this was not motivated by RSC/Vercel but actually the FB site which is faster this way due to less CPU load * this simplification enabled several newer changes and would need weeks+ of work to put back even if desired
7
2,967
Alex / KATT ๐Ÿฑ retweeted
new blog post ๐Ÿ‘‡ it breaks down a few approaches to configuring "live types" in TypeScript monorepos. you should never need to run `build` while developing! 1. tsconfig paths 2. custom export conditions 3. publishConfig (*my recommended solution) colinhacks.com/essays/live-tโ€ฆ
22
41
348
63,026
Alex / KATT ๐Ÿฑ retweeted
TypeScript 5.5 RC is now out to try! We're looking for feedback on inferred type predicates, JSDoc imports, regex checking, ${configDir}, isolatedDeclarations, build optimizations, and more! devblogs.microsoft.com/typesโ€ฆ
6
110
507
81,631
That's why I use only `console.log()` for debugging
Visual Studio's breakpoint circle is horrendous
5
48
4,445
I was always a bit skeptical when we started throwing around the term framework in JS-land b/c to me the term meant more than what we typically offer. This post sums it up well. Hopefully, we'll eventually get one in JS/TS that enough people buy into for it to survive
The todo application. ๐Ÿ˜… But, seriously, here's the thing... When Laravel and Rails developers say "full stack", they mean something totally different than when Next or Remix (React Router?) developers say "full stack". In Laravel and Rails, it means there are built-in, opinionated solutions to things like validation, interacting with a database, authenticating users, scheduling background work, sending an email. In Next and Remix, it seems to mean that there is simply the bare ability to run code on the server at all and an advertisement for Clerk. ๐Ÿ™ƒ From my perspective, Next and others are really, really great at the GET part of web development. Get data from some backend, show it on the page quickly. ๐Ÿ‘Œ They are not mature for POST, PUT, and DELETE, especially when things start getting non-trivial. And, I don't think this is really unique to Next or a single framework. It's something that seems to pervade current JavaScript as a whole - note the current proliferation of "starter kits" that try to bring some sanity to the full-stack story. I think this has had actual consequences in the JavaScript ecosystem... Rails and Laravel were built with the express purpose of allowing a single developer to build the next GitHub... or the next AirBnb... or the next Shopify. Prototyped from beginning to end. That's what I'm passionate about. Empowering a single developer or small team to build something amazing. I built the 1.0 of Laravel Forge, Envoyer, Vapor, Spark, and the backend of Nova by myself. $40M in revenue over 10 years from my home office. That's an empowering tool for a solo founder. I don't see a full-stack story in JavaScript yet that would allow me to realistically sit down and build something like Forge or Vapor from start to finish. Maybe I'm missing it. ๐Ÿคทโ€โ™‚๏ธ The MVP start-ups I do see fully built on current JS meta frameworks are much thinner. The stereotypical API call to an AI service. Not much meat on the bones. Laravel / Rails have been building their modern front end story with Hotwire, Livewire, Inertia, and more... Next and others are building their modern back end story. Smart people on both sides working on these problems, so I'm confident we'll both get to where we want to go. ๐Ÿ’ช
4
26
5,235
Also, DHH could take some notes from the respectful tone of voice user by Taylor here ๐Ÿ˜…
13
666
Last week or so I've worked on some fun features for @trpcio: - allowing queries to be async iterators that are streamed back - adding SSE-support for subscriptions so you don't need websockets anymore (and it even works for serverless)
9
6
86
8,977
google using trpc at aitestkitchen.withgoogle.com ๐Ÿ‘€
3
10
152
17,802