Comment by purplerabbit | Hacker News Reader

Comment by purplerabbit | Hacker News Reader

Both popular SSR frameworks (Next.js + Remix) break the Unix philosophy, and Next.js + Blitz.js is the opposite of the Unix philosophy. (You might think that this is worth it, and you may even be right, but it's something to consider.)

Want a better React stack? Try React + tRPC + Express + Prisma. Each component can be easily swapped out and understood independently (sorry Next.js / Remix), all routing is explicit (sorry Next.js / Remix), development startup time is fast (sorry Next.js), and you still get e2e type safety + minimal boilerplate. I like to call this stack the "NF" stack: "No Framework".

The fanboys will complain. "What about SSR?", they will say. Well, here's the solution: quit fretting about SSR. Your signed-in customers will gladly take 0.05 seconds extra render time for the extra features your devs will be able to deliver after you ditch your complicated SSR framework. Want to do SEO? Make a WordPress site and "SSR" it with Simply Static[0]. Your site will achieve the theoretical minimum Time To First Whatever, your marketing team will be free to actually do their job rather than spending 2/3 of their time trying to get devs to update the landing page, and your devs can move on to something more useful (like creating useful features. Isn't that supposed to be the goal?)

/rant

[0] https://wordpress.org/plugins/simply-static/

(edited to remove some unnecessary negativity)

While your comment has an excellent technical perspective, the tone is a little negative. He's gone and built something brilliant & I think you should acknowledge that whilst also (validly) suggesting an alternative.

I'm personally conflicted: I see the upside of Blitz for sure (and find it impressive) but I also have been ultra-burned by frameworks & certainly would never give up Vite.

As far as I can tell the implementations between TRPC and BlitzRPC are very different. One basically (paraphrasing their own words) abuses Typescript & requires some maintenance, where BlitzRPC appears to be a "Svelte-like" everything is a compiler approach.

There's a real scaling issue with tRPC (they say something like unsuitable for large projects IIRC).

You're right on the tone. I've edited it to make it less negative.

Appreciated! Have an upvote.

It just kinda seems like you've re-invented an ad-hoc framework by gluing various different components together. There can be advantages in this, but there are pretty frequently downsides to this approach too.

It's like back when everybody was going through the "I want to use Sinatra rather than Rails" phase and what happened was a million different half-baked reimplementations of 20% of Rails that were different on each project for no significant benefit.

Sinatra is good if what u build is minimal in business scope.

Why glue it together yourself when a community or someone working full time on it can glue it for you? As a bonus you also get documentation. Since it's open source you can read the code, and it even is based on the stuff you are recommending. If you value your own time it's a no brainer.

It's worth gluing together 1) so everything is explicit, 2) you don't have to write all of the schrodinger's cat "if executing on client, x, else, y" logic inherent in SSR frameworks, and 3) you can avoid Next.js's slowness

This is why I only use operating systems that I have personally glued together from scratch.

Leveraging massive libraries is not "from scratch".

Another thought: You are on HN, so you probably prefer Unix to Windows. Why do you think that is?

Agree completely. I used Next.js for many years, but I probably wouldn't choose it today. SSR adds complexity and blurs the distinctions between client and server and as a result everything is harder - especially tooling and glue code. It also doesn't help that there is a major release so often that whatever configuration you used 6 months ago is now obsolete. I really wish frontend react stacks would stabilize and provide some sanity for businesses to get on with their primary mission of not just building but also _maintaining_ products.

> It also doesn't help that there is a major release so often that whatever configuration you used 6 months ago is now obsolete.

(I'm on the Vercel/Next.js team) Could you share specifically what configuration you found obsolete?

> I really wish frontend react stacks would stabilize

Did you have trouble upgrading versions? Open to feedback. We frequently hear folks who upgrade from Next.js 8 to 12 with minimal changes, for example.

> Both popular SSR frameworks (Next.js + Remix) break the Unix philosophy, and Next.js + Blitz.js is the opposite of the Unix philosophy

Would you mind to elaborate?

Reply on news.ycombinator.com