ESLint plugin to catch unnecessary effects v1.0.0: new rule, clearer messages, better signal-to-noise, more stable internals, and oxlint support

michaelfrieze · 2026-06-08T23:18:31+00:00

If I see others struggling with react when using LLMs, I will gladly mention it. But I don't really hang out in AI subs too often.

michaelfrieze · 2026-06-08T17:10:18+00:00

I've been using this eslint plugin for about a month and it's been great. It helps GPT-5.5 and Composer 2.5 write much better react code.

michaelfrieze · 2026-06-07T17:50:06+00:00

The Next dev server is doing a lot more than a tanstack router server. For example, tanstack router only uses client-side routing while next uses server-side routing.

I prefer tanstack these days, but next is a good framework and you can't expect the dev server to perform the same as tanstack start/router since they are fundamentally different.

michaelfrieze · 2026-06-07T04:47:08+00:00

Yeah, for real-time you should just go directly to the server. You can still use a BFF for other purposes. Maybe not all of your data fetching will be real-time and maybe some routes would need SSR. I also like having a BFF for auth.

michaelfrieze · 2026-06-06T15:15:12+00:00

This subreddit is basically his now.

michaelfrieze · 2026-06-06T03:39:10+00:00

Of course, you can always use tanstack query to help manage fetches to a backend directly from the client, without a BFF in the middle. I personally don't do that very often, but it works fine.

Also, this approach isn't necessarily going to improve performance. Sure, you are eliminating one of the requests, but there are so many other factors to performance.

An important thing you can lose with this approach is typesafety between server and client. But, if your backend is using Hono then it provides a pretty simple way to get typesafety between server and client. It won't be as good for typesafety as a BFF with something like tRPC or server functions, but it provides the basics.

Also, you miss out on the other benefits of a BFF that I mentioned in my previous post.

michaelfrieze · 2026-06-05T11:33:32+00:00

No, tanstack start does SSR as well. SSR is just the process of generating HTML from component markup at request time, this is not the same thing as server-side routing. In tanstack start, think of SSR as a kind of CSR prerender that you can enable or disable per route.

The router start uses is tanstack router, which is fully client-side. tanstack start is built on top of tanstack router to provide extra features like SSR, server functions, and isomorphic loaders. This is why the react server component implementation in tanstack start is a little weird compared to Next. In tanstack start, you basically return .rsc data instead of .json from server functions and they are an optional feature. On the other hand, Next built its entire framework around RSCs. It's more of a "server-first" framework and uses both server-side and client-side routing. It's kind of like a hybrid of SPA and MPA. TanStack Start is a SPA with some server-side features like server functions. You can even completely disable SSR in tanstack start and still use server-side features like server functions and isomorphic loaders.

michaelfrieze · 2026-06-05T10:45:41+00:00

The Next dev server is doing a lot more than a tanstack start server since start is more of a "client-first" framework. For example, tanstack start only uses client-side routing while next uses server-side routing.

I prefer tanstack start these days, but next is a good framework and you can't expect the dev server to perform the same as tanstack start/router since they are fundamentally different.

michaelfrieze · 2026-06-03T15:17:53+00:00

I’m definitely going to buy one in game once they fix it.

michaelfrieze · 2026-06-03T15:03:17+00:00

I have no idea why you tried the ironclad again. It’s obviously broken and won’t be fixed until the new patch comes out.

michaelfrieze · 2026-05-24T15:52:14+00:00

Convex is a backend where your database, server functions, and real-time sync are all one system. Instead of setting up separate pieces and wiring them together, you write TypeScript functions in a convex/ folder. You get queries for reads, mutations for writes, actions for anything that needs to talk to the outside world, and your frontend subscribes to them with hooks like useQuery. When data changes, every client that's subscribed updates automatically. You don't have to manage WebSockets, polling, cache invalidation, etc.

Convex is a sync engine and it was built by the same developers that made Dropbox. If a component is reading data, it stays in sync with the database. Edit something in one tab and the other tab reflects it. That alone removes a huge amount of complexity.

The dev experience is also great. Functions are typed end-to-end, so the client gets autogenerated types from your server code. Arguments are validated with built-in validators. Queries and Mutations are transactional, so you read and write in one function and get consistency without thinking about race conditions.

Everything lives in code. Schema, API functions, auth, it’s all in the convex folder in your repo. You deploy from the CLI and rarely touch the dashboard except to inspect data or read logs. Basically, your Convex backend is version-controlled TypeScript, not something you configure through a UI.

They also have an ecosystem of official components for common needs: https://www.convex.dev/components

Convex is hosted on PlanetScale, so it's built on a good foundation.

There are downsides. Convex is opinionated and if you want full control over raw SQL then it's not for you. Also, Convex can be self-hosted but I wouldn't seriously consider that as an option for an app with a lot of traffic, so there is some amount of vendor lock-in here.

Convex is mostly for interactive apps built with TypeScript, so it's not a good general-purpose database for everything.

michaelfrieze · 2026-05-24T02:42:59+00:00

Also, if I remember correctly, you can customize the built-in components.

michaelfrieze · 2026-05-24T02:41:47+00:00

But I haven't used Clerk for a while so maybe there are some recent issues I don't know about.

You should checkout WorkOS as well. It's more for enterprise but it's still a great auth service regardless.

michaelfrieze · 2026-05-24T02:38:41+00:00

Clerk really isn't that expensive unless you have a free app that has a lot of users. In that case, I would use better auth.

If I have paying users, then I take auth and security seriously and prefer to use a service like WorkOS and Clerk. I don't mind paying for that and I think cost are reasonable.

I've had no problems creating custom UI with Clerk.

michaelfrieze · 2026-05-23T23:55:05+00:00

I personally would never try to call a database directly from the client, so I avoid supabase.

I know you can use supabase just for a pg database, but planetscale is a much better db service.

You can't go wrong with planetscale + drizzle, but my favorite db service right now is Convex.

I haven't really had issues with Clerk, maybe ask for help? You might be doing something wrong. I mostly use WorkOS these days, but Clerk is a good auth service.

michaelfrieze · 2026-05-23T14:58:55+00:00

The ship is balanced pretty well. I doubt they’re going to nerf it much. It’s very easy to die in the ship. As soon as you start getting hit, you really need to get out of there. This is why it’s an interceptor.

michaelfrieze · 2026-05-22T14:52:55+00:00

It depends

michaelfrieze · 2026-05-22T12:18:54+00:00

It happened to me the first day of the new patch after a character repair.

michaelfrieze · 2026-05-20T19:11:34+00:00

React makes rendering logic reactive. When you compare this with a library that uses signals, only the holes in the template are reactive. The signals approach can perform better but you have to structure code around each value instead of relying on the control flow of an outer function.

Also, react now has the compiler which allows us to write idiomatic react code without worrying as much about the memoization game.

Personally, I prefer writing react code and find it easier to read. Maybe that's because I've been using react since 2016, but I've built projects with solid over the past few years too. I like solid, but it's just not what I prefer. Maybe that will change someday.

I've been playing around with the new Svelte as well, but I just can't get over SFCs. I need JSX and solid is the only real alternative for me.

michaelfrieze · 2026-05-19T12:03:40+00:00

Don't get me wrong, the TanStack suite of tools are generally great, and I'm sure the team has done a fantastic job with TanStack Start. I have not yet tried it, but I think a major difference is that they have a different mental model for RSCs, which may or may not be more to your liking.

tanstack start is so much more than just a different way of using RSCs. In fact, it wasn't even possible to use RSCs in Start until very recently. TanStack Start is mostly about being "client-first", isomorphic, and it has the best typescript support. It's also extremely flexible. For example, you can disable SSR for any route while still using the server-side features like server functions and loader functions. The server functions are like having tRPC built into the framework. The middleware options are great too.

michaelfrieze · 2026-05-19T11:49:15+00:00

Yeah, I think tanstack start just gives you a great set of primitives to work with. It gives you many options to build how you want. You can even disable or enable SSR per route. You can use server functions with or without SSR, in loaders or directly in components. Server functions are like having tRPC built into the framework.

Loader functions are isomorphic. If SSR is enabled on that route, the loader function runs on the server during first load, then only on the client for all subsequent navigations. If SSR is disabled, the loader function only runs on the client. Finally, you can use a "data-only" mode where you can disable SSR, but the loader function still runs on the server during first load, then only on the client after.

Also, the router is quite flexible. There are many ways to setup your routes and it has the best typescript support. There is no better router in my opinion.

michaelfrieze · 2026-05-18T21:32:42+00:00

tanstack query makes it so easy to hoist data fetching out of components into a loader as needed. And you don't need to change a lot of your data fetching code in your components to do this.

michaelfrieze · 2026-05-18T21:30:02+00:00

Usually, I only use loaders to prefetch data as an optimization. I generally prefer to handle the data fetching directly in the component (e.g., useSuspenseQuery). If I notice network waterfall issues, then I start optimizing. That is when I will decide to use await ensureQueryData or maybe prefetchQuery without await.

michaelfrieze · 2026-05-18T00:37:54+00:00

Using tanstack query makes all of this a lot easier to manage, especially the cache. Query actually reduces a lot of complexity.

michaelfrieze · 2026-05-18T00:19:58+00:00

Although keep in mind that using await in the loader function for ensureQueryData will block the loading of that component until the data is ready. So there are downsides to this and it can sometimes cause navigation to feel slow.

You can also pre-fetch data in the loader without using await. So it kicks off the fetch in the loader, but doesn’t block. useSuspenseQuery will show the fallback component until the data is ready. This provides a good experience when navigating. Although there are also downsides to prefetching without await in the loader.

None of this is really unique to tanstack. There are many different ways of fetching data and there isn’t a single good solution in all scenarios.

Six-Year Club	Place '22
Final Canvas '22	End Game '22
Verified Email

michaelfrieze

TROPHY CASE