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.
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.
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 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.
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
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.
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)
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.
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.
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 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.
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).
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’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.
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.
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 :) )
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!
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.
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!
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.
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.
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!
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!
