Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap ? #7

Open
conico974 opened this issue Jul 27, 2024 · 1 comment
Open

Roadmap ? #7

conico974 opened this issue Jul 27, 2024 · 1 comment

Comments

@conico974
Copy link

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

@github-actions github-actions bot locked and limited conversation to collaborators Jul 27, 2024
Repository owner deleted a comment from github-actions bot Jul 29, 2024
@ScriptedAlchemy
Copy link
Owner

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants