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

Next.js eject #1691

Closed
sedubois opened this Issue Apr 11, 2017 · 4 comments

Comments

4 participants
@sedubois
Copy link
Contributor

sedubois commented Apr 11, 2017

Similar to create-react-app, it would be very helpful if Next.js offered an "eject" functionality. This would reassure users who would otherwise fear being "locked" in Next.js once their project outgrows what Next.js can do for them, or e.g in the sad even that Next.js wouldn't be maintained or in favor any more. Paradoxically having an "eject" could help Next.js attract more interest.

Also see this discussion for longer context.

@arunoda

This comment has been minimized.

Copy link
Contributor

arunoda commented Apr 11, 2017

@sedubois sorry. That's not our goal.

We wanted a way expose a better way to run React without any config.
For CRA, it's seems doable because it's basically a thin wrapper around Webpack.
But Next.js is more to that.

Our way to customizing it based on custom babel and webpack config. We can keep improve them.

If you feel, Next.js is not enough after you've build a big app. You can either custom it via babel or webpack. Otherwise, fork Next.js and use it as you like.

@arunoda arunoda closed this Apr 11, 2017

@kunokdev

This comment has been minimized.

Copy link

kunokdev commented May 5, 2017

Maybe it would be good to have a convenient approach upon customization since at some point it is unavoidable. Now I do not mean to eject current features, instead it would be really good to have a proper way to add more features as they come without breaking core logic. How I see it is for Next.js to focus on stability and to be core of application, abstraction of current problems and good solution for JS fatigue. But new features in JS world will keep coming, and it will be hard to keep Next.js both edge technology and stable technology. It is discussable to have a place in Next.js world for new features that can be added, edited or removed in a modular approach. and to have a stable core that abstracts JS fatigue and complexity for long term. In my opinion, too much abstraction without ability to change things at some point is kind of risk.

@sergiodxa

This comment has been minimized.

Copy link
Contributor

sergiodxa commented May 5, 2017

@kunokdev you can customize the webpack and babel configuration easily. Many examples use that to support Flowtype, TypeScript, etc. and customize Next.js

@kunokdev

This comment has been minimized.

Copy link

kunokdev commented May 5, 2017

@sergiodxa How I see it, Next.js could be a convenient framework that abstracts many build issues from the very start of the project, thus making it great for creating prototypes (still following one-command-to-start mindset) and yet a framework that allows you further customization on top of convenience, therefore allowing your application to grow into any direction without need to at some point replace the core, Next.js itself. Maybe even considering making Next functionalities as modular and replaceable as possible. And as I see it, that is very important in frontend world because of constant changes, allowing framework to replace features without constant need to do refactory.
For example, if framework adopts new features which would replace old ones, upgrading application from one version to other would be painful. However, as modular, it would be known which module needs to be replaced. And that scenario is unavoidable at some point since Next.js actually covers a lot of ideas and automating them.

I think it is very known at this point, that one of the biggest problems in frontend world is that as new techniques appear, we constantly change frameworks or ideas we follow. We constantly build new frameworks for new ideas. Then community learns new frameworks and evolves, dropping old frameworks behind. That is not ecological and we should consider how do we make our tools adopt new ideas modularly rather than building new tools so often.

@lock lock bot locked as resolved and limited conversation to collaborators May 11, 2018

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