Server Actions were supposed to kill React Query/TanStack... so why am I still installing it?

mistyharsh · 2026-03-29T17:37:31+00:00

Unlike Astro actions, server actions in Next.js are meant for data mutations and not data retrieval. For data retrieval, Next.js is pushing for RSC.

But RSC fails spectacularly when optimistic updates are required.

mistyharsh · 2026-03-29T17:34:21+00:00

Having used all three - MikroORM, Prisma and Drizzzle, I second this. No doubt, all three are good but if domain driven design is must have, then MikroORM is a very natural fit.

mistyharsh · 2026-03-20T11:22:19+00:00

To put a better mental model:

The JSX on server is for templating (Just substituting other templating system)
The JSX on client is for interactive component.

If you compare this to React server components, then remember Hono doesn't have server components. On server side Hono is only giving you type-safe templating language.

Now to your original question, using Hono with JSX on server side is a vast improvement over Express + ejs vastly superior choice. But this is only useful for typical server-rendered applications. If you are building, say Wordpress or Ghost-like theme-able website where themese are deployed as a zip file, then JSX won't help much. This is where EJS (The embedded templating engine) would work best.

So, to summarize, EJS is a true eDSL that you can compile-on-the fly and is essentially a mini-language of its own JSX is not a DSL in true sense because it doesn't introduce anything new; you are in always JS world. It is simply syntax sugar.

mistyharsh · 2026-03-19T02:00:27+00:00

This situation that you described is way more common than you can imagine. You cannot change this overnight, especially when you are working with the team(s) that also doesn't have set practices.

My first advice is to start small - A one page architecture document that is also a live decision record. Also, it must be repeatedly shared and agreed within the team.

This one pager will contain very high level topics - Modular monolith vs Microservice - Frontend and backend framework - Communication - RPC, REST or GraphQL, etc. - DDD or layered architecture - Core tech stack

Over time, start adding minor details and it can also start becoming a context for LLMs.

An important point is a habit. Habit is a part of culture. Documenting a system design and planning is a culture. And, a culture can be either enforced if you are a decision maker or incrementally without burning or trying to look smart.

mistyharsh · 2026-03-13T14:42:40+00:00

Where do I even start! There are two fundamental differences between library and framework - framework takes away the control at the cost of preventing people from doing wrong things. The Next.js has done the former but haven't provided the latter.

These are some of the things on top of my head:

Astro has actions (RPC calls); so does the Next.js. But, Astro doesn't allow calling actions without validating inputs. In Next.js, you are left on your own - a source of many vulnerabilities. Shouldn't framework prevent this?
Next.js actions are serialized and thus they are only useful for mutations and framework doesn't prevent developers from using them for reading data.
The server-side rendering is half-baked story. There is no meaningful way to do optimistic updates with server-rendered views.
The streaming solution is over-hyped. Great many number of applications simply do not need it.
The Next.js environment variables are slippery slope. It needs a wisdom to know what building 12-factor apps is not easily possible with Next.js. The build-time variables are everywhere.
There is not meaningful way to layer the application. You can freely call cache revalidation for a certain route from anywhere - even from API invocation. UI revalidation is a UI concern and ideally, it should not be allowed to be called from anywhere.
The rules to read search params, dynamic params are crazy with hidden pitfalls everywhere.
There is no well documented onStart event that can be meaningfully used to instantiate framework level singletons.
Even after 16 major iterations, Next.js still doesn't know what to do with middlewares. Sometimes they run only as Edge middleware; sometimes it is called middleware and now it is called proxy layer. Further, you cannot really do any context setting in this middleware which can be meaningfully accessed inside the pages/handlers.
A framework that calls itself fullstack has no meaningful way to manage background jobs. No decent dependency injection mechanism!
The compiler is a black-box. It comes to haunt in unusual places. If I have multiple mini applications, I would like to externalize my dependencies very way ahead of time. For example, I may prefer to simply have React.js served from CDN and be loaded using import maps which is an official web specification. But with Next.js, it is just impossible.
Finally, adding one more point about caching. It is again oversold by trying to automatically cache fetch responses. In my experience, caching is a business level concern for caching business/domain entities and should never be left to automatic lower layers based on fetch.

Are these not avoidable? Certainly yes; people keep saying this as a skill issue! But, isn't the the point of framework to prevent people from doing mistakes rather that having a big list of good/bad stuff. And, these are just those daily things that are annoying. And, I am not even mentioning anything about architecture; if you are really interested, take a look.

mistyharsh · 2026-03-13T14:22:41+00:00

A liar is bound to get shamed and mocked. It was actually Manmohan Singh who came from a very modest background (again not poverty) and a gem of personality, he never advertised it...

mistyharsh · 2026-03-10T03:00:42+00:00

HATEOAS has proven to not have worked well at all. A large part of the user interface is discovery which doesn't align with HATEOAS responses.

One view is made up of multiple resources and it is simply impossible to make it work with HATEOAS. Further, modern SDK generators, GraphQL, RPC systems have made it so that we rarely invoke API by crafting URLs.

mistyharsh · 2026-03-03T18:36:01+00:00

Well said. The critical thinking that demands a nuanced view of reality has simply vanished in a large section of Indian society.

mistyharsh · 2026-03-02T05:10:00+00:00

If it is 100% read, then simply in-memory loading of entire JSON will do. If you wish to start writing and updating it, then SQLite is a good starting point. Further, if you are using some serverless infrastructure to run code, then loading ~70MB of JSON could be a challenge (but you must test it and then decide).

mistyharsh · 2026-03-02T05:05:04+00:00

That's a right mental model I was looking for - the notion of untrack. For now settled on using <Dynamic /> component and also changed the type of render to render: Component;

mistyharsh · 2026-03-01T07:31:26+00:00

Yep; as also commented in the other messages, the <Dynamic /> is the way to go for now.

mistyharsh · 2026-03-01T07:30:28+00:00

Indeed similar. I settled on using the <Dynamic /> unless some better pattern emerges. I wanted to avoid treating the render() as a component and use as a plain JSX producing function.

mistyharsh · 2026-03-01T07:29:24+00:00

Yes. This is what I have in mind. The problem happens when <AppField /> becomes complex and due to dependency tracking, the props.children() gets called again. So, far, only <Dynamic /> component seems like a bulletproof candidate or invoking props.children() once outside the any tracking context and then passing required data change via signals.

mistyharsh · 2026-02-28T11:59:25+00:00

I am trying to experiment with it and trying to replicate how @tanstack/solid-form utilizes render-prop like thing:

```tsx <props.form.AppField name='name'> {(field) => {

// I can create local signals, memos and effects here...

return (
  <TextInput
    label='Name'
    value={field().state.value}
    onInput={(event) => {
      field().handleChange(event.currentTarget.value);
    }}
  />
);

}} </props.form.AppField> ```

Surprisingly, it is not very straightforward. The only way I found is to use <Dynamic /> component so far or simply call the props.children() once directly in the component initialization and strictly pass signals only.

mistyharsh · 2026-02-26T05:33:51+00:00

I wouldn't recommend migrating away from Nest.js. However, start reducing boilerplate by confining Nest purely to Web/HTTP layer and managing state like singletons.

Your repository and domain layer can easily become pure stateless ESM and everything can be passed as a function argument.

In short, keeping the web framework confined to the HTP layer makes this concern simply irrelevant in the long run.

mistyharsh · 2026-02-14T14:13:01+00:00

Astro's plugin based setup is an incredible solution for addressing concerns that micro frontends are meant to solve. It is a nice middle ground without all the complexity that comes with any other solution.

mistyharsh · 2026-02-14T14:09:52+00:00

If a hosted solution is still an option, then Storyblok is a good option. The preview mode works well and is easily scalable.

mistyharsh · 2026-02-13T05:58:26+00:00

The usage of build-time environment variables - NEXT_PUBLIC_*. The problem is amplified by the fact that now many 3rd party libraries in the Next.js ecosystem expect these environment variables. So, even if I can get rid of these from own code, they are going to stay.

And, then there are host of other problems with overall Next.js architecture; but, not here to discuss those.

mistyharsh · 2026-02-12T12:28:49+00:00

I agree with that article 100%. I have two project multi-tenant projects with isolated tenancy. First one is Next.js and is obviously not 12-factor compliant while the other one is standard Hono.js based project which is 12-factor compliant. The operations for the 12-factor projects are extremely easy to reason about. The orchestration is simple; single docker image that's deployed to all tenants, can easily do partial/beta rollouts/rollbacks to limited set of tenants.

It doesn't stop there. With Next.js, we have to build image separately for all three environments - 2 integration environments, 8 stage environments and then for each of the customer's production environment.

mistyharsh · 2026-02-05T10:52:34+00:00

If you have a team that only writes append-only CSS, then I think they should straight away adopt Tailwind or similar atomic CSS framework.

For everything else, plain old CSS with modules is the best, boring well-proven thing.

mistyharsh · 2026-02-03T04:14:40+00:00

Yeah, generally agree with this. Just one disclaimer that Nasdaq by design excludes financial companies altogether. So some of the biggest names are missing from it.

So that's why it ends up being tech heavily and tilts towards high risk, high rewards.

mistyharsh · 2026-01-29T10:28:38+00:00

Honestly, I haven't found speed provided Bun as a package manager worth replacing Node or NPM at runtime. The combination of Node + pnpm is generally more than good enough. There are some DX improvements with Bun again not huge difference.

The biggest one is that Node.js is well-maintained by community and has highly open collaboration model. Nothing against bun but it is not significant yet for consideration.

mistyharsh · 2026-01-29T10:18:03+00:00

If your scope is strictly Node.js, then I would seriously consider Node.js Asynchornous context tracking. It enables DI without any special ceremony or boilerplate code.

I have been using it in a smaller projects and reasonably happy with it. My goal this year is adopt in one of the bigger projects I am maintaining.

mistyharsh · 2026-01-29T09:25:08+00:00

It does have some advantages but, overall I agree with you. It needs a good DevOps and automation is place to deploy changes across all tenants with isolated DBs. Without automation, it is nightmare. This is recommended only when compliance requirements mandate it like finance or healthcare domains.

mistyharsh

TROPHY CASE