[dkyc]

From "framework fatigue" to "new framework" in five paragraphs.

Personally, I find all these minimalist, back-to-the-basics frameworks a bit misguided. It's always reeks a bit of "well my farts don't smell" – other developers' frameworks are bloated, dependency-overloaded and too complex. My new framework is simple, based on a powerful idea, and just right.

Imo, the best way to build a truly good web app in 2025 is to embrace both server-side rendering and client-side rendering, by sharing the same rendering logic between client and server, like e.g. SvelteKit, Next.js and others do.

[wry_discontent]

Using Next.js is malpractice. I've never had a worse experience with a web framework (and I'm using that word extremely loosely here).

[skydhash]

I’m ready to bet that anyone that chose Next is now battling a ball of mud and a buggy one with that.

[wry_discontent]

We had a nontechnical person choose Next, against my recommendation but I didn't have the authority to override that choice, and it's been a total nightmare.

It's extremely messy. Hostile to debugging. Hostile to testing. Bad HMR. All this to offer us RPC and filesystem based routing (neither of which I even want in a framework).

[ramon156]

No, fameworks are relatively opinionated towards the goal the creator had, which is usually in a README.

They're all tools that need more context to decide on when you use them.

For example, in my use case (SaaS) I focus on something that makes refactoring a breeze. Type-safe end-to-end is important there, so I use orpc+react for most projects. If you don't like contract-first APIs you're going to hate this, but it makes me think out what I actually want in my frontend before I write the database. This kind of [mocking -> real data] way of coding makes you proactive when designing the app

[srcreigh]

My favourite SSR framework is built in to React. It's called `renderToString`