Next.js 9.2(nextjs.org)
nextjs.org
Next.js 9.2
https://nextjs.org/blog/next-9-2
15 comments
> Maybe that's just the cost of doing JavaScript in 2020
That is the cost of doing JavaScript any year.
You can find the same statement you wrote pretty much for every year since JavaScript frameworks became popular.
That is the cost of doing JavaScript any year.
You can find the same statement you wrote pretty much for every year since JavaScript frameworks became popular.
> There are features/patterns in Next.js that made sense 6 months / a year ago but are now not preferred
Do you have an example of what changed? We haven't really made any breaking changes for quite some time and have been improving on the existing feature set. Smaller bundle sizes with no code changes etc are part of this.
If you take the getting started readme of Next.js 3 years ago it still works today.
Do you have an example of what changed? We haven't really made any breaking changes for quite some time and have been improving on the existing feature set. Smaller bundle sizes with no code changes etc are part of this.
If you take the getting started readme of Next.js 3 years ago it still works today.
We're very committed to introducing only the necessary changes and features. On top of that we have an extensive integration test suite to ensure no features are broken when upgrading.
I was intentional about saying "not preferred" instead of "not supported". You are correct, there have not been any breaking changes, which is very helpful.
When new features and changes roll out (like CSS support in 9.2), they are _good_ improvements. I'm simply stating the rate of change is drastic. Which, as mentioned, is both good and bad.
Here's a solid example. If I were trying to integrate a Firebase API to my Next.js app before API routes, the recommendation might have been to run a monorepo where one app is Next.js + custom server and the other is a Node.js API (deployed with now).
Next 9 and API routes made that unnecessary. Now you can just embed an API route under /pages to talk to Firebase.
Now, if you search for "nextjs firebase example" you might find three or four different ways of doing it on Google. As you said, they all still _work_, but they're not idiomatic Next. It can be hard to dumpster dive through Spectrum chats and GitHub issues to find the new "recommended way" of doing things.
This is a very minor gripe. You're doing amazing work, Tim!
When new features and changes roll out (like CSS support in 9.2), they are _good_ improvements. I'm simply stating the rate of change is drastic. Which, as mentioned, is both good and bad.
Here's a solid example. If I were trying to integrate a Firebase API to my Next.js app before API routes, the recommendation might have been to run a monorepo where one app is Next.js + custom server and the other is a Node.js API (deployed with now).
Next 9 and API routes made that unnecessary. Now you can just embed an API route under /pages to talk to Firebase.
Now, if you search for "nextjs firebase example" you might find three or four different ways of doing it on Google. As you said, they all still _work_, but they're not idiomatic Next. It can be hard to dumpster dive through Spectrum chats and GitHub issues to find the new "recommended way" of doing things.
This is a very minor gripe. You're doing amazing work, Tim!
next.js is such a joy to work with, congrats on the new version! It's constantly improved, the team is very responsive on github, looking forward to getStaticProps and getServerProps to make offline website generation even better.
I started using the development preview of getStaticProps and was really impressed with the implementation. Being able to combine static and dynamic resources in an app so easily is a gamechanger. Keep your landing pages statically generated and make the logged in parts of the site dynamic! Or statically generate your blog and build a API-driven routed section of your site with ease!
Nice that they've added CSS Module support. I've been using them for my react projects and find them a good solution when you don't need lots of dynamic styling.
It's really disappointing that Next continues to push forward with all these innovations that I'd love to take advantage of, but can't for the single reason that it doesn't support nested layouts or routing. Every page transition requires blowing up the entire layout, you can't have a persistent header for example. And there's no way (that I've found yet) to build any kind of skeleton loading screen during transitions.
This is a really basic issue that negates all the good they've got and it's frustrating.
This is a really basic issue that negates all the good they've got and it's frustrating.
I wrote a little naive hook for pulling this off in our app: https://gist.github.com/SirensOfTitan/6067c1c1aa791287361578...
...essentially we listen for route changes in our top level layouts using that hook to coordinate which parts of the page to keep active and which to show spinners on.
I’d imagine there are more robust ways to do this too: I think I saw a plug-in that uses element ids to figure out how to morph the page.
...essentially we listen for route changes in our top level layouts using that hook to coordinate which parts of the page to keep active and which to show spinners on.
I’d imagine there are more robust ways to do this too: I think I saw a plug-in that uses element ids to figure out how to morph the page.
Have you looked at this: https://nextjs.org/docs/advanced-features/custom-app
Not sure if it exactly allievates the problem you face, but that's where I ended up when trying to share layouts in a sensible fashion.
Not sure if it exactly allievates the problem you face, but that's where I ended up when trying to share layouts in a sensible fashion.
I have been a web dev 25 years. It is nice to see JavaScript based backends mature. One day we will have Ruby on Rails or Django of JavaScript world :)
Next.js examples use npm, but I have seen a lot of new projects to go with Yarn. Is this battle yet decided?
Next.js examples use npm, but I have seen a lot of new projects to go with Yarn. Is this battle yet decided?
To answer your question: in terms of optimization, yes. Npm has pretty much closed the gap. However, depending on your package management strategy, I’d go with Yarn until/unless npm offers a better solution for monorepo package management. Npm currently forces you to more or less manually manage symlinks, which can be painful. Yarn workspaces on the other hand, although it does require some ritual, seems to just work.
The only thing that's (slightly) concerning to me is the rate of change. It's a double-edged sword. There are features/patterns in Next.js that made sense 6 months / a year ago but are now not preferred. An example would be API routes and dynamic routing improvements.
These are definitely welcome (and good!) changes, but it makes a lot of old examples become out of date fast and it feel like "churn" - even when the features are helpful.
Maybe that's just the cost of doing JavaScript in 2020.