Next.js 10.2(nextjs.org)
nextjs.org
Next.js 10.2
https://nextjs.org/10-2
60 comments
What turns me off about NextJS is its "opt-out" telemetry.
You have to do a bit of magic at the system level "npx next telemetry disable" to turn it off (which you can only figure out by an internet search).
This seems very disingenuous on part of Vercel.
Make it an "opt-in" or don't fricking track. Conduct a yearly survey or use some other means if you are so interested in improving the framework.
I am open to other framework suggestions.
Counter-opinion here: I am the maintainer of one of the most popular plugin for Next.js, and I am cruelly lacking data about how the users of my plugin use it, that would allow me to choose better defaults for it.
I don't have access to the Next.js telemetry data, but I could definitely need to ask the Next.js team from time to time: "so, are your users more using Yarn workspaces? Or npm link? Or something else?", etc.
For the same reasons some people complains about Ubuntu removing some features because they say "people don't use it", while people using those features tend to disable the telemetry. Sometimes, telemetry is useful.
It is not to spy on users, it is about making the best technical choices to ensure the best Developer Experience.
_edit: typos_
I don't have access to the Next.js telemetry data, but I could definitely need to ask the Next.js team from time to time: "so, are your users more using Yarn workspaces? Or npm link? Or something else?", etc.
For the same reasons some people complains about Ubuntu removing some features because they say "people don't use it", while people using those features tend to disable the telemetry. Sometimes, telemetry is useful.
It is not to spy on users, it is about making the best technical choices to ensure the best Developer Experience.
_edit: typos_
It's not really about the user spying though, it's about the decision of making the user default of "yes, please track my usage so you can make your product better". I would rather have you ask the question first even though I mostly say yes, but transparency is key here.
I agree with this, just ask for consent, it's that simple.
Also, about removing features based on telemetry, of course people are going to disable or block data collection and you will make decisions based on incomplete data. If you must remove something, do it because it makes sense and it fits within your vision for the future of the project you maintain.
Also, about removing features based on telemetry, of course people are going to disable or block data collection and you will make decisions based on incomplete data. If you must remove something, do it because it makes sense and it fits within your vision for the future of the project you maintain.
Perhaps it would be better if there was a trusted co-op that ran a telemetry service that package maintainers could opt into and create integrations which could properly anonymize and provide open data for analytics. Similar to how npm shows the number of downloads.
I don't think anyone disagrees but lately the society has been talking about something called consent. That matters with software as well.
I hope users of OSS can get over this sentiment. With decent and anonymized telemetry data maintainers can make better decisions that benefit the majority of users. Without it, it is the loudest users who get the most attention.
There are major OSS projects with no telemetry that are hamstrung by their lack of insight about which platforms and systems their software is running on.
Everyone should have the right to turn it off, but I think this is going to become the norm.
There are major OSS projects with no telemetry that are hamstrung by their lack of insight about which platforms and systems their software is running on.
Everyone should have the right to turn it off, but I think this is going to become the norm.
Huh, TIL. Although the data it collects is seemingly benign [0].
[0] https://nextjs.org/telemetry
[0] https://nextjs.org/telemetry
How bizarre. I've never heard of a framework with built-in telemetry, much less opt-out. I'm surprised this doesn't limit its reach in certain industries.
And this isn't just for their official hosting service? That would be much more understandable
And this isn't just for their official hosting service? That would be much more understandable
It's extremely easy to disable the telemetry. Much more importantly, every time you start nextjs, half of the output is a big warning telling you exactly how to disable the telemetry.
NPM had a similar thing: https://docs.npmjs.com/cli/v6/using-npm/config#send-metrics
I remember discovering this a few years ago and was so annoyed that it was on my default and had to have this in my .npmrc:
I remember discovering this a few years ago and was so annoyed that it was on my default and had to have this in my .npmrc:
metrics-registry = null
send-metrics = false
that command just sets an environment variable `NEXT_TELEMETRY_DISABLED=1`, I wouldn't necessarily consider it system level magic.
I feel like the biggest piece of this announcement was buried at the bottom of the article:
> We're excited to announce Tobias Koppers, the author of webpack, has joined the Next.js team at Vercel.
> We're excited to announce Tobias Koppers, the author of webpack, has joined the Next.js team at Vercel.
Lee from Vercel here. Happy to answer any questions :) If you have any suggestions for how we can improve Next.js, let me know!
One thing I would love to see is React router style routing. I know some people love the file based routing, but for complex web apps I just end up having to hack my own routing onto catch all routes. For example, there is no way to build sub-routers without doing it myself. (Imagine an account dashboard with a common area, but additional tabs for other sub-pages)
Also, a global getServerSideProps ran on all pages would be great. I use getInitialProps in _app.tsx now to make a server side request to get initial user info (e.g. the current user name, access level, etc), but this method is ran on both client and server requests so it has some hacky stuff like returning early if window is undefined or if the requested url ends in .json (when next tries to load a new page on the client side)
Also, a global getServerSideProps ran on all pages would be great. I use getInitialProps in _app.tsx now to make a server side request to get initial user info (e.g. the current user name, access level, etc), but this method is ran on both client and server requests so it has some hacky stuff like returning early if window is undefined or if the requested url ends in .json (when next tries to load a new page on the client side)
Thank you for the feedback! There is a workaround to use React Router with Next.js (https://gist.github.com/tannerlinsley/65ac1f0175d79d19762cf0...) and we're working on layouts support for Next.js, which will improve the routing story. And agreed on a better solution for global data fetching. This is being investigated as well.
It would be great if you guys can take another look at https://github.com/vercel/next.js/issues/18318 , lots of folks seem affected by it.
Basically, there is no way to produce a truly static / SSR ( `next export`) build with i18n; this means one cannot host a multi-language site on a free hosting solution like GitHub pages.
Basically, there is no way to produce a truly static / SSR ( `next export`) build with i18n; this means one cannot host a multi-language site on a free hosting solution like GitHub pages.
Thanks for the feedback! Next.js' i18n support adds a routing and language detection layer, which can't be easily replicated with `next export`. We're open to contributions for this, but it is a difficult problem to solve. Feel free to leave implementation suggestions on that issue.
Hey Lee, thank you for all your work! Big company here in Portland, and we just went all in on Next.js – so far our development speed has increased, and junior devs are easily onboarded.
One request would be an official state management extension – coming from Vue and Vuex, this is something I miss. We're currently using Redux Toolkit, but would be great to have something official for Next along the lines of Vuex, Reframe, or Elm.
* update (writing this between lots of meetings :| )
One huge value we get from Next is the opinions and conventions. Large dev teams benefit from this – which is why we've been using Ember and Ember Data for years, and Rails before that.
Having an opinionated state management that plays nicely with Next on the client AND the server is what I'd like to see. We're doing quite a few workarounds currently with Redux to support managing state from within the components and during `getServerSideProps`. If all my dreams came true, it would be nice to persist state conditionally in Redis or Mongo.
Sorry for the rambling thoughts – just loving Next, and incredibly busy building our new core IP with it.
One request would be an official state management extension – coming from Vue and Vuex, this is something I miss. We're currently using Redux Toolkit, but would be great to have something official for Next along the lines of Vuex, Reframe, or Elm.
* update (writing this between lots of meetings :| )
One huge value we get from Next is the opinions and conventions. Large dev teams benefit from this – which is why we've been using Ember and Ember Data for years, and Rails before that.
Having an opinionated state management that plays nicely with Next on the client AND the server is what I'd like to see. We're doing quite a few workarounds currently with Redux to support managing state from within the components and during `getServerSideProps`. If all my dreams came true, it would be nice to persist state conditionally in Redis or Mongo.
Sorry for the rambling thoughts – just loving Next, and incredibly busy building our new core IP with it.
Vercel has a library for state management that's similar to React Query. https://swr.vercel.app/.
Note this is specifically for server caching state: https://leerob.io/blog/react-state-management
Hey! Thanks for the kind words and glad you're enjoying Next.js. It's (basically) impossible for us to recommend a _single_ state management solution for all users, because state management means different things to different folks. Depending the industry and scale of your application, it also changes your state management needs.
I wrote an in-depth guide on this here: https://leerob.io/blog/react-state-management
I wrote an in-depth guide on this here: https://leerob.io/blog/react-state-management
I like having the choice, for us immer and context usually is all we need beyond state & props so would not like to be forced into something opinionated. Free to choose just like you decide how to interface with your backend/state. Don’t turn this into a rails or danjo, please :)
I totally understand. The old Redux adage is "don't use it until you need to". Most apps won't need a big, opinionated state management – but when you do, it's nice having something robust, verbose, opinionated, and rails or django-like.
What kind of deep integration are you looking for with a preferred state framework?
If I closed my eyes and designed the API first, it would look like the `/pages` convention – just add state "slice" files in `/store` (like `src/store/user.ts`) and then use either React hooks inside the component (like `useStore` or `useMutation`) or use something (like `getServerSideState`) on the server.
Your state "slices" would export initial state, types (optionally), and an object containing getters, setters, and mutations (using Vuex concepts).
Your state "slices" would export initial state, types (optionally), and an object containing getters, setters, and mutations (using Vuex concepts).
This isn’t so much about 10.2, but about Next’s plans/roadmap for static sites, particularly whether there are plans to provide official support for partial hydration.
I like a lot of what Next brings in terms of DX polish. But I ultimately decided not to use it for recent projects, where the majority of the content is truly static. Next sends this content in HTML, then sends it again in JS. This not only adds unnecessary page weight, it also increases the uncanny valley before TTI.
The current solution to this in Next is to mark an entire page as non-interactive. This means a page will send either no JS at all, or all of it. This isn’t ideal.
There are several experimental projects exploring partial hydration with Next, but without official support they’re risky. There are also emerging projects like Astro providing similar functionality to Next with partial hydration as a core feature.
I’d imagine the most obvious way to achieve something similar in Next will be SSG with React Server Components, but who knows when that will be stable.
Anyway, curious if Vercel has anything to share on the topic.
I like a lot of what Next brings in terms of DX polish. But I ultimately decided not to use it for recent projects, where the majority of the content is truly static. Next sends this content in HTML, then sends it again in JS. This not only adds unnecessary page weight, it also increases the uncanny valley before TTI.
The current solution to this in Next is to mark an entire page as non-interactive. This means a page will send either no JS at all, or all of it. This isn’t ideal.
There are several experimental projects exploring partial hydration with Next, but without official support they’re risky. There are also emerging projects like Astro providing similar functionality to Next with partial hydration as a core feature.
I’d imagine the most obvious way to achieve something similar in Next will be SSG with React Server Components, but who knows when that will be stable.
Anyway, curious if Vercel has anything to share on the topic.
> I’d imagine the most obvious way to achieve something similar in Next will be SSG with React Server Components, but who knows when that will be stable.
Sooner than you might think!
Sooner than you might think!
That’s cool! On a similar note I’m curious if you’ve encountered Astro[1] and if you have any thoughts on where Next/Astro overlap and where they might not.
1: astro.build
1: astro.build
Hey Lee, been following your work for a while.
Could you please add your vote for "getStaticProps" for individual components also. That way I can use this component in multiple pages for example to statically rendering a tweet etc. (maybe useful for your blog too :) )
I think equivalent of this feature in gatsby is staticQuery https://www.gatsbyjs.com/docs/how-to/querying-data/static-qu...
Same question I asked in r/nextjs https://www.reddit.com/r/nextjs/comments/mmqoqm/how_to_async...
related discussion https://github.com/vercel/next.js/discussions/13390
Could you please add your vote for "getStaticProps" for individual components also. That way I can use this component in multiple pages for example to statically rendering a tweet etc. (maybe useful for your blog too :) )
I think equivalent of this feature in gatsby is staticQuery https://www.gatsbyjs.com/docs/how-to/querying-data/static-qu...
Same question I asked in r/nextjs https://www.reddit.com/r/nextjs/comments/mmqoqm/how_to_async...
related discussion https://github.com/vercel/next.js/discussions/13390
getStaticProps for individual components will be solved with React Server Components! http://vercel.link/rsc
next/image has been terribly slow to generate optimized images since 10.0.7.
This issue is a blocker for several people, including myself, and there hasn't been any team response on GitHub yet: https://github.com/vercel/next.js/issues/23637
This issue is a blocker for several people, including myself, and there hasn't been any team response on GitHub yet: https://github.com/vercel/next.js/issues/23637
You can also use any external service for optimizing images if you prefer not to use the built-in WebAssembly solution (which uses Squoosh (https://squoosh.app/). This was announced with the 10.1 blog post: https://nextjs.org/blog/next-10-1#nextimage-improvements
Specific PR improving memory usage: https://github.com/vercel/next.js/pull/23565
Let us know if you're still seeing this issue after updating to 10.2 on the issue linked. Thanks!
Specific PR improving memory usage: https://github.com/vercel/next.js/pull/23565
Let us know if you're still seeing this issue after updating to 10.2 on the issue linked. Thanks!
Sort of Next related, but I was looking into these frameworks today and it seems all of the easy hosting services jump from free to $20 for what seems to be elaborate static hosting. Is there a middle ground for hobbyists that are running commercial software without spinning up your own VPS (Vercel doesn't look kindly on commercial on their free plan).
You can deploy Next.js anywhere that runs a Node.js server through `next start`. Further, we're recently updated the documentation to include Docker deployment instructions. Hope this helps!
https://nextjs.org/docs/deployment#docker-image
https://nextjs.org/docs/deployment#docker-image
I've been using Render (build by some Dev Ops engineers from Stripe)
https://render.com/
Static hosting is free. Servers or DB's start at $7
Static hosting is free. Servers or DB's start at $7
I use serverless-next.js [1], it's super convenient, deploys to AWS lambda@edge, cost scales with your traffic.
1: https://github.com/serverless-nextjs/serverless-next.js
1: https://github.com/serverless-nextjs/serverless-next.js
Cloudflare pages?
Just checked this out, looks promising, unlimited bandwidth is nice too.
I use Netfliy and its Nextjs build plugin that automatically creates serverless functions for the api routes, does ssg and deploys. All under the free plan.
https://www.netlify.com/blog/2021/03/16/try-the-new-essentia...
https://www.netlify.com/blog/2021/03/16/try-the-new-essentia...
> Improved Accessibility: Route changes are now announced by screen readers.
This is the type of thing I'd never think about but should Just Work out of the box.
This is the type of thing I'd never think about but should Just Work out of the box.
Out of the box, specifically at the browser level, especially since route changes affect the History API (unless I'm mistaken)
Correct. This is specifically for client-side routing. More information here.
https://github.com/vercel/next.js/pull/20428
https://github.com/vercel/next.js/pull/20428
Cookie based redirects will be super nice for my team and I. We’ve been doing those with useEffect with firebase auth for a bit which didn’t perform badly but could perform better, and now it will!
Awesome! If you use it and have any feedback, let us know :)
I recently tried using Next instead of Nuxt, but I seem to recall I couldn't export optimised images when doing a statically generated site.
Has this changed, or are there any plans to change it?
Has this changed, or are there any plans to change it?
You can still use `next/image` when outputting a static site, as long as you use `next start`. Using `next export` removes the server entirely, meaning you can't optimize images on demand.
There's an open issue to explore optimizing images at build time, but for now, you can use https://github.com/cyrilwanner/next-optimized-images
There's an open issue to explore optimizing images at build time, but for now, you can use https://github.com/cyrilwanner/next-optimized-images
I ran into the same issue when trying to run next export. The linked library has worked great. I wanted to simply have a srcset generated at build time. I don't know why Next Image can't support this out of the box.
Can someone explain these frameworks to me? Is Next.js and Gatsby in the same scope? I know they use React under the hood, but are the components rendered server-side? Does that mean no JS is delivered to the client?
Next.js is a hybrid React framework. It aims to improve the developer experience on building web apps by having solid defaults, extensible configurations, and performance optimizations included in the framework.
You can user server-rendering on a per-page basis, as you see fit. Same with removing all JavaScript if so inclined.
More info here! https://nextjs.org/learn
You can user server-rendering on a per-page basis, as you see fit. Same with removing all JavaScript if so inclined.
More info here! https://nextjs.org/learn
It claims 60% faster subsequent builds (63% for Scale), but how much can an ordinary side-project gain? (let's say, 100 component files?)
I run a pretty complex web app and haven't upgraded to webpack 5 yet with Next. I have some custom webpack stuff so hopefully the migration isn't too painful, but I will report back with the compilation time improvement once done.
Support for webpack 5 has been a multi-month rollout ensuring backwards compatibility. If you do run into issues, please add a reproduction here and we will investigate!
https://github.com/vercel/next.js/discussions/23498
https://github.com/vercel/next.js/discussions/23498
Also in the blogpost is the great news: "We're excited to announce Tobias Koppers, the author of webpack, has joined the Next.js team". Thanks for hiring him to ensure webpacks continued support and development!