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.

Sign up for GitHub

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

Jump to bottom

Modularize next.js #349

Closed
nickredmark opened this issue Dec 6, 2016 · 11 comments
Closed

Modularize next.js #349

nickredmark opened this issue Dec 6, 2016 · 11 comments

Comments

@nickredmark
Copy link

nickredmark commented Dec 6, 2016 •
edited
Loading

Hey guys, what you are doing is amazing, a lot of good architectural choices!

Coming from meteorland I'd like to contribute with a big lesson learned: buy-in is real and consequential. You have a framework that magically does everything for you, and then when you want to move on to the next better approach (and you will, because it's javascript-land) you have to give up on the good parts as well as the bad.

The next.js community has the opportunity to do this right, but there is already a somewhat bad sign: next.js has all the code in the main repository, and no other zeit dependency! I think it should be the opposite. next.js should only be wiring things together.

I'd suggest this approach: ask yourself - how would it be if there was no next.js repo but only partial modules, and I had to pick and wire everything together in the app directly? <- make this as easy as possible

I know you, like me, like the unix philosophy (do one thing and do it well), and from how I see it next.js does already too many. At the very least

  • A files-based router
  • A react-component-module-based SSR+front-end-rendering solution
  • A build tool

Now you think "but these are all entangled together". Well, that's exactly the problem. That's what happened with meteor. My recommendation is that you start decoupling these things from each other early enough, or in a year people will face real problems when they want to replace one or more bits of the stack with something else.
@MoOx
Copy link
Contributor

MoOx commented Dec 6, 2016

A monorepo could make this not as painful as an org + multi-repos to keep in sync.

@nickredmark
Copy link
Author

nickredmark commented Dec 6, 2016 •
edited
Loading

A monorepo is exactly what locks one into the whole stack, which is what one should avoid.

Edit: I didn't know what a monorepo is ;) check it out here: https://medium.com/@bebraw/the-case-for-monorepos-907c1361708a#.byyjao2hf

@MoOx
Copy link
Contributor

MoOx commented Dec 6, 2016

What I call a monorepo is a single git repo with multiple packages in it. I don't see how this can lock you and make it unable to use a package or a fork for something specific.
The real thing to work on is to make those packages not relying on each others when possible.

@nickredmark
Copy link
Author

Ok I didn't know the term. Basically it's one repository containing many separate npm packages, which then get published to npm independently? Sounds interesting, I agree, such a setup might favor the right architectural choices.

@MoOx
Copy link
Contributor

MoOx commented Dec 6, 2016

See https://github.com/babel/babel/blob/219f6292679bd040f9cb7e5725c18ddaa805b816/doc/design/monorepo.md

@foxhound87
Copy link

This sounds cool!

Lerna can manage monorepo with multi packages.

@MoOx
Copy link
Contributor

MoOx commented Dec 7, 2016

Let me add a list from my search in MoOx/phenomic#598 (comment)

some infos

@avindra
Copy link

avindra commented Dec 7, 2016

Big ➕ for this one

I'm currently looking to use <Head>, love how you guys implemented it.

Would be nice if I could just import @zeit/next-head or something like that, instead of next, which is quite heavy altogether.

@rauchg
Copy link
Member

rauchg commented Dec 8, 2016

Thanks for your comments.

I'm in complete agreement with you, and this is already our approach.

Some general comments:

  1. The framework is a result of building https://zeit.co. We're not a framework company, we're a cloud hosting company. We'll continue to make the best tool to solve our problem, and share it with the community. Others take the approach of start with the framework, then build the products.
  2. We have no intention of adding more features. Instead, we are expanding your ability to customize and override:
  3. Our main priority is fast loading times and small code footprint
  4. Whenever we see the opportunity to make something reusable, we do. This is the approach I took with styled-jsx.
  5. To address your points:
    • "A files-based router" is serve-static, list, …
    • "A react-component-module-based SSR+front-end-rendering solution" is what Next.js is.
    • "A build tool" is Webpack and Babel, both not of our creation

Finally, modularization for the sake of modularization is not useful. I think modularization is useful when it serves a mechanism for module substitution. In this case, modularizing webpack is important because then you can extend it and learn it independently.

My goal is to provide a good foundation for stability in making high performant websites and web applications with a focus on lightweightness and flexibility.

APIs like getInitialProps, custom server, custom <Document /> are all about that :)

@rauchg rauchg closed this as completed Dec 8, 2016
@rauchg
Copy link
Member

rauchg commented Dec 8, 2016

Oh by the way, I completely agree that <Head> should be its own module

@nickredmark
Copy link
Author

Sounds awesome. In particular #291 is what does it for me.

@lock lock bot locked as resolved and limited conversation to collaborators May 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@rauchg @avindra @MoOx @nickredmark @foxhound87