ScriptedAlchemy / rsnext

MIT License
52 stars 0 forks source link

Roadmap ? #7

Open conico974 opened 1 month ago

conico974 commented 1 month ago

What is the update you wish to see?

Don't know where to post this exactly so i created an issue What's the plan for this project exactly ? I saw some of your tweet, and i don't really understand what's the roadmap here.

Looks like you want to make it possible to deploy next more easily anywhere ( which is great ), but i don't know to which extent you're planning on doing it in this repo ?

Will this also include features like ISR for serverless ? What about the middleware, being able to run it in node ? Run it separately in front of the server ? It looks like you want to add support for the app router as well. Is there any plan to make partial prerendering work in the same way as in vercel (Which means having a separate layer to deploy in front of the server) ?

Implementing all of this would make it diverge a lot from the upstream next repo.

Or maybe the goal here is only for the bundling layer to allow all of this, and keep all of these concerns for other project like OpenNext ?

Is there any context that might help us understand?

None

Does the docs page already exist? Please link to it.

No response

ScriptedAlchemy commented 1 month ago

Hey.

So to start, we want to swap out the bundler. From there, we have a few directions that could be taken.

The two primary ones in my mind are:

1) We could combine this with another RSC framework thats in-house, which has every existing feature of next.js & astro (ISR, PPR, RSC, Islands, SSG) and during consolidation - we keep the existing api of next.js but essentially replace the insides in such a way that a user would not notice. Doing this would attract more internal manpower.

2) We get it to a unlocked state and allow the community / cloud providers to co-maintain it and they can do whatever they wish, while we provide compiler support, but not much product support.

Personally I have no current use for next.js at the moment. If someone wants it changed, it can be changed. If you want middleware to run on node. that can be done.

Im not too concerned about diverging from upstream, id be more than happy with keeping the api so it can hook into the next ecosystem. All the internals, they can stay or go. As long as most of the features work that people use and nobody notices any difference in api.

If someone wants it to work a certain way, those changes can be merged. But we do not have a ton of use for next.js and without something like a reorg of our other meta frameworks, we will most likely give the project to someone who has more vested interest.

This will largely depend on demand from users and we will respond accordingly. For now we will replace the build, then talk to cloud providers and see what it is that makes life difficult and what features are actually used.