React Meta-Framework Feels Broken, Here's Why (opens in new tab)

(rwsdk.com)

22 pointsdthyresson10mo ago7 comments

7 comments

I'm the author of this article, and this is the second time I've built a framework. I co-created RedwoodJS with Tom Preston-Werner several years ago - and we came up with some novel ideas, but I had a nagging feeling that something wasn't right.

A failed-startup and a kid later... and I'm back. I couldn't let go of the original vision of RedwoodJS, but I wanted to start from scratch. So we built RedwoodSDK, which is a React framework for Cloudflare. It starts as a Vite Plugin that gives you server-side-rendering, RSC, streaming, and realtime capabilities.

Our standards based route feels invisible, with simple pattern matching, middleware and interrupters. You receive a request and return a response. You own every byte over the wire.

There's zero magic. Just TypeScript, modules, functions, values, and types.

dthyressonOP10mo ago

A new blog post argues that today’s React meta-frameworks like Next.js and Remix are too abstract and “feel broken,” adding complexity through magic and indirection. It introduces RedwoodSDK as a simpler, more transparent alternative that prioritizes native web APIs and production-parity development.

codingdave10mo ago

You don't need to (and should not) add a Tl;dr comment when you post something. If you want to tell the story of how you came up with an idea, do a "Show HN". That is the correct way to self-promote on HN.

dthyressonOP10mo ago

That wasn't my intent. I haven't used HN much. Will do next time. Thx!

chipgap9810mo ago

Aren't the "defineApp" and "route" methods in rwsdk also magic? It feels like rwsdk is just being more deliberate about when and where to introduce those magic functions.

I'm a big fan of rwsdk so far. Thanks for building!

gadfly36110mo ago

I think a notable difference is with one, you can read the code in the file and understand what it will return. With others, you need to read the code and then do a mental join of the framework's conventions to know what it'll return.

pistoriusp10mo ago

Nope! They just return standard JavaScript.

A typical worker looks something like this:

    export default {
        fetch({ request }) {
          return new Response('ok')
        } 
    }

DefineApp just wraps that initial entry point into something that allows us to run middleware, match the router, and render out the page or the response object.

Love that you're a fan! Remember... No magicians allowed here.

j / k navigate · click thread line to collapse

7 comments

pistoriusp10mo ago

Our standards based route feels invisible, with simple pattern matching, middleware and interrupters. You receive a request and return a response. You own every byte over the wire.

There's zero magic. Just TypeScript, modules, functions, values, and types.

dthyressonOP10mo ago

codingdave10mo ago

dthyressonOP10mo ago

That wasn't my intent. I haven't used HN much. Will do next time. Thx!

chipgap9810mo ago

Aren't the "defineApp" and "route" methods in rwsdk also magic? It feels like rwsdk is just being more deliberate about when and where to introduce those magic functions.

I'm a big fan of rwsdk so far. Thanks for building!

gadfly36110mo ago

pistoriusp10mo ago

Nope! They just return standard JavaScript.

A typical worker looks something like this:

    export default {
        fetch({ request }) {
          return new Response('ok')
        } 
    }

DefineApp just wraps that initial entry point into something that allows us to run middleware, match the router, and render out the page or the response object.

Love that you're a fan! Remember... No magicians allowed here.

j / k navigate · click thread line to collapse