I want to make sure this is on your radar --
https://github.com/jaredpalmer/after.js
Are there any ideas in Jared's project that are worth adopting in Next?
(I'm not GitHub issues is the best place to put this, but I don't know where's better)
I don't understand why the author isn't contributing back to Next.js -- and felt the need to create his own framework taking nearly all of Next's ideas and just using React Router instead of Next's router. Next already has a router replacement created by the community, Next Routes -- he could do something similar.
This ultimately hurts the community by splitting the repos between Next and After - and the efforts on these projects for some minor issue the author has with Next.
We don't need another JavaScript framework...
We don't need another JavaScript framework...
Why not? Next.js is a very popular framework now and has to be careful of breaking changes. I see no problem with someone experimenting and approaching problems from a new angle. This industry is based on constant evolution and learning... no one wins if the framework space becomes homogenized.
I have been fetching data the way that After.js does for almost a year now with Razzle--so it felt like it was time abstract this technique into a 'framework.'
After some early prototypes of After.js, I invited both Michael and Ryan to the repo to get some feedback. A few days later Ryan DM'd me that Next might be moving to React Router in the future. I reached out to Guillermo as well and he confirmed this was the case and that they planned to move Next.js to React Router in v5, but that it could be weeks away. So I continued tinkering with After.js.
After I got HMR and codesplitting working, I felt compelled to share it with everyone. To the extent that it "re-creates" Next.js, \ As for why I do not actively contribute to Next.js.... I did in the early days. Then I moved to NYTimes' kyt, and then I built Razzle to serve my specific needs. Generally speaking, I don't spend my time fixing bugs or contributing to projects that I don't use day to day. I think that Next.js is an awesome project, but I just have some different opinions about a few things, and that's okay. To me, this is the best thing about GitHub. We can all make incremental improvements, share ideas, and explore new technology in the open.
@jaredpalmer would you mind to elaborate the things you dislike/disagree about Next.js (besides the router) , i'm comparing js frameworks and would be useful to have your opinion, i don't know if you already made it public somewhere else. thanks!
Aside from the router (which is the big one), my other issue is blocking and loading state. Next blocks render until the page data is ready. Even with the progress bar at the top, this has always felt laggy to me.
React Router lets you block on server render, but then not block on client transitions if you don't want to. Even in v5, I would be very surprised if next moved to this approach as it would break every single existing next app (because props returned by getInitialProps would be need to be set to undefined or null until it completed on all client transitions).
You can avoid the render when doing a client transition if you want to. Just don't define a getInitialProps
or don't do anything if it's running client side, render a application shell or a loading state and then fetch your data in componentDidMount
.
It will require more code and logic, but it's totally possible to do that if it helps the app feels smoother and can be implemented per page instead of in the whole app. So if a page can fetch data fast in getInitialProps
can block the render and if it's slow can be implemented to fetch on componentDidMount
.
As with all other open source projects in this space (example given: razzle, nuxt.js, after.js, gatsby) I'll be watching them just because I'm curious what other people come up with, just like Jared has done with Next.js 馃槃So to answer the questions in the issue description: yes it's on our radar.
To answer the second question, sure there might be bits that could flow back into Next.js, react-router support for Next.js is something we've talked about before but just haven't implemented yet.
With regards to the first comment about Jared not contributing his ideas back into Next. Personally I understand his point of view. And chances are not everything he wanted to build would be suitable for adoption into Next.js 馃檹
I hope this answers all of your questions 馃槃 so I'll close the issue 馃憤
@timneutkens Thanks for following up.
Most helpful comment
I have been fetching data the way that After.js does for almost a year now with Razzle--so it felt like it was time abstract this technique into a 'framework.'
After some early prototypes of After.js, I invited both Michael and Ryan to the repo to get some feedback. A few days later Ryan DM'd me that Next might be moving to React Router in the future. I reached out to Guillermo as well and he confirmed this was the case and that they planned to move Next.js to React Router in v5, but that it could be weeks away. So I continued tinkering with After.js.
After I got HMR and codesplitting working, I felt compelled to share it with everyone. To the extent that it "re-creates" Next.js, \
As for why I do not actively contribute to Next.js.... I did in the early days. Then I moved to NYTimes' kyt, and then I built Razzle to serve my specific needs. Generally speaking, I don't spend my time fixing bugs or contributing to projects that I don't use day to day. I think that Next.js is an awesome project, but I just have some different opinions about a few things, and that's okay. To me, this is the best thing about GitHub. We can all make incremental improvements, share ideas, and explore new technology in the open.