Next.js 10(nextjs.org)
nextjs.org
Next.js 10
https://nextjs.org/blog/next-10
205 comments
Whenever the Next.js + Vercel combo gains a new feature, Vercel ensures that it's available in standalone Next.js too – even when deployed to other providers.
That's true for all the features mentioned in the Next.js 10 blog post: Image optimization, Internationalization, but also Analytics.
Since you mentioned the latter: Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
https://nextjs.org/docs/advanced-features/measuring-performa...
Sure, there's obviously a whole UI piece to this as well – but since you interact with Next.js programmatically and there's a quite sophisticated data storage that needs to back all of this as well, Vercel optionally provides you with a pre-built solution.
But again, to be clear: If you want to use Analytics + Next.js elsewhere, Next.js supports reporting them natively – even if not hosted on Vercel.
That's true for all the features mentioned in the Next.js 10 blog post: Image optimization, Internationalization, but also Analytics.
Since you mentioned the latter: Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
https://nextjs.org/docs/advanced-features/measuring-performa...
Sure, there's obviously a whole UI piece to this as well – but since you interact with Next.js programmatically and there's a quite sophisticated data storage that needs to back all of this as well, Vercel optionally provides you with a pre-built solution.
But again, to be clear: If you want to use Analytics + Next.js elsewhere, Next.js supports reporting them natively – even if not hosted on Vercel.
> Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
Perhaps you should link that on the Analytics[0] page instead of directing users to contact the sales team for more information on non-Vercel deployments.
[0] https://nextjs.org/analytics
Perhaps you should link that on the Analytics[0] page instead of directing users to contact the sales team for more information on non-Vercel deployments.
[0] https://nextjs.org/analytics
Great suggestion! We'll add a link right after the conference.
Yes, but that reporting was already part of 9.5?
I'm rewriting a bunch of my Vue components into Svelte, and turning my Nuxt (which were previously React/Next) projects into Sapper, and it's a crazy easy process. My Svelte codebase is tiny compared to my Vue codebase.
I'm slightly "worried" about Sapper not being at v1.0 yet but... it's been working great for my MVPs
I'm slightly "worried" about Sapper not being at v1.0 yet but... it's been working great for my MVPs
Relatively recent news, Sapper is not getting a 1.0.0. Svelte is going in a different direction in the future.
https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=3s
https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=3s
TL;DW - parts of Sapper may be in a future version of Svelte, but looking to add support for mixed static and dynamic pages and improving development speed to change by using Snowpack.
I'm surprised to hear this - more details would be appreciated.
If someone doesn't beat me to it, I'll come back this afternoon and TL;DR the 22 minute video linked here.
If someone doesn't beat me to it, I'll come back this afternoon and TL;DR the 22 minute video linked here.
I'm pretty out of the loop when it comes to Svelte/Sapper. I've looked at it, but never used it. However I did recently spot that they're already working on a successor to Sapper called Svelte Kit. So maybe that's why Sapper isn't at 1.0, and maybe never will be.
https://github.com/sveltejs/sapper/issues/1429
https://github.com/sveltejs/sapper/issues/1429
I feel the same way. We've switched from React to Svelte at work. Going back to React would be a step backwards for us, so much feels needlessly overengineered with awkward APIs. React was a great improvement on Angular, but luckily things are still moving forward.
Well, this sounds a bit typical JS dev talk. React isn't all that terrible, it's actually quite good and battle-proven. It has great libraries, many devs are familiar with it and if you know it well you can be pretty damn productive with it.
Not to say Svelte doesn't have great innovative features, but I myself don't still feel that tempted to jump into Svelte. What some of us don't like, is the infamous JS churn where libraries are changed every year because "this new one is better".
Not to say Svelte doesn't have great innovative features, but I myself don't still feel that tempted to jump into Svelte. What some of us don't like, is the infamous JS churn where libraries are changed every year because "this new one is better".
Some of us are attracted to JS dev because of the rapid evolution and change. React is well-tested and mature, I'm simply stating that for me personally going back to it would be frustrating after developing in Svelte.
React is extremely bloated. I don’t think it can justify its weight on content pages. If all you need are some show hide buttons and a CSS animation, it’s way too heavy. That’s a pretty good reason to look at other tools.
If all you need are some show hide buttons and a CSS animation, do the whole thing in four or five lines of vanilla JS in an inline script tag. You're right that React is the wrong tool for the job, but so is Svelte and so is everything else discussed in this thread.
Which UI component library, if any, do you use with Svelte ?
Sveltestrap[0] but needs Bootstrap for the CSS styling (I personally like the separation but YMMV)
[0] https://sveltestrap.js.org/
[0] https://sveltestrap.js.org/
UI component libraries for Svelte are a little lacking in maturity in my experience. I would recommend including a CSS library such as Bootstrap or Materialize. Tailwind is also popular, but not my cup of tea.
So, React is backwards, but you are using Bootstrap instead? Lol. Webdevs at their best.
There are good alternatives to React that are as actively developed. There don't seem to be good alternatives to Bootstrap that are nearly as actively developed (excluding CSS utility class libraries like Tailwind).
My team recently evaluated 30-40 CSS frameworks to use with a custom component library, and we were surprised when Bootstrap was the clear winner. Other CSS frameworks have gotten buzz over the years, and we assumed something new and shiny would come out on top, but when we evaluated all of them, we saw sporadic commits, many unresolved issues (e.g., see Bulma issue 3074), small bus factors, inadequate support for keyboard navigation, and other issues.
So using Bootstrap with a newer alternative to React is valid. (Though, we're using Bootstrap with Next.js.)
My team recently evaluated 30-40 CSS frameworks to use with a custom component library, and we were surprised when Bootstrap was the clear winner. Other CSS frameworks have gotten buzz over the years, and we assumed something new and shiny would come out on top, but when we evaluated all of them, we saw sporadic commits, many unresolved issues (e.g., see Bulma issue 3074), small bus factors, inadequate support for keyboard navigation, and other issues.
So using Bootstrap with a newer alternative to React is valid. (Though, we're using Bootstrap with Next.js.)
By all means, stick to your React or Java backend or whatever it is you do if that's where you feel most comfortable. No need to feel so threatened by new alternatives.
I've had great success with http://ibm.biz/carbon-svelte for one of my side projects.
Looks great. Thanks.
Technically any static ui library can easily be turned into reactive components in any of the frameworks. I personally use & recommend Tailwind css, you still need to design/build your UI elements and components but Tailwind helps you speed it up.
How are y'all testing your svelte apps/components? Jest+Testing Lib seems to have issues calculating code coverage and there are few quirks like having to do work arounds to test slots that prevent me from totally switching over.
Our test coverage of the Svelte apps is meagre so far to be honest.
Their response to "How do I test Svelte apps?"
"We don't have a good answer for that yet, but it is a priority."
I was interested in Svelte until I read this. When they have a good answer, I'll be interested again.
https://svelte.dev/faq#how-do-i-test-svelte-apps
"We don't have a good answer for that yet, but it is a priority."
I was interested in Svelte until I read this. When they have a good answer, I'll be interested again.
https://svelte.dev/faq#how-do-i-test-svelte-apps
The solution to this, I believe, is making template a function: https://news.ycombinator.com/item?id=25023551
Good point it would have helped if the clearly mention what's in the open source vs what's paid service tied to Vercel. Alsi I'd like a point by point comparison with Google Analytics for their analytics offering, is that in open source?
Seems very disingenuous.
The only thing on the list that's related to Vercel is the analytics platform. Even that is clearly listed as something you can leverage via your own provider.
The only thing on the list that's related to Vercel is the analytics platform. Even that is clearly listed as something you can leverage via your own provider.
Svelte is the lead of virtualdom less `ui=f(data)` language/framework. It's the only one you can mutation DOM without its program being corrupted (though not sure if you try hard, it could be)
There is only 1 thing that would make me switch from Elm to Svelte is template as a function. Make it compose like functions! So that you can have as many as functions you want. With current Svelte, these functions are bunch of files .. unfortunately.
There is only 1 thing that would make me switch from Elm to Svelte is template as a function. Make it compose like functions! So that you can have as many as functions you want. With current Svelte, these functions are bunch of files .. unfortunately.
You are looking at it from the point of view of an app developer, not that nextjs can't do app but a lot of its users are e-commerce businesses
What is DX? New jargon?
If UX is user experience, the user flows of a product/application and how people generally feel about using/interacting with it.
The DX is the developer experience. It follows a similar idea. How do you feel about using git? What about Visual Studio Code versus neovim? How do you like using Elm? What don't you like about.
Think about all the libraries or frameworks you use. Some of them clearly offer a better experience than others, these are the types of things that affect the DX.
Take documentation for example, a piece of tech (whether it be an IDE, library, or CLT) with proper documentation full of examples, usage, and recipes is extremely nice. I would favor tech that has better documentation over others, documentation is just one part of the DX. Not the only part, but hopefully you can start to see what can increase or decrease the DX.
The DX is the developer experience. It follows a similar idea. How do you feel about using git? What about Visual Studio Code versus neovim? How do you like using Elm? What don't you like about.
Think about all the libraries or frameworks you use. Some of them clearly offer a better experience than others, these are the types of things that affect the DX.
Take documentation for example, a piece of tech (whether it be an IDE, library, or CLT) with proper documentation full of examples, usage, and recipes is extremely nice. I would favor tech that has better documentation over others, documentation is just one part of the DX. Not the only part, but hopefully you can start to see what can increase or decrease the DX.
> The DX is the developer experience. It follows a similar idea. How do you feel about using git?
To me, how I feel about using (working with) git is git's UX.
How I would feel working on git (were I to do so) would be git's DX.
Now, for a project that has git as part of its expected dev tooling, how I feel about using git in that particular context would be part of that particular project's DX.
To me, how I feel about using (working with) git is git's UX.
How I would feel working on git (were I to do so) would be git's DX.
Now, for a project that has git as part of its expected dev tooling, how I feel about using git in that particular context would be part of that particular project's DX.
Thanks for the explanation, but it is really unnecessary. Developers are the users for developer tools. UX fits perfectly nice.
It's confusing or always needs further distinction if "UX" when discussing client-side application development is talking about developers. "DX" is useful.
OTOH, when I hear about DX of a software product (especially an open source one), my intuitive understanding is that it is experience of developers working on the product, not of developers that happen to be users of the product (which, if they are the normal users of the product, would just be UX.)
> but it is really unnecessary.
You may think that, but it's a standardized term already.
You may think that, but it's a standardized term already.
It's hard to search for, but it appears to mean "Developer Experience" — https://medium.com/@koba04/performance-and-dx-in-frontend-48...
it's a full of crap metric due to the fact that the definition wildly varies among developers. While UX can be quantified by actual metrics (retention, number of steps, accessibility points), DX is nothing but a bunch of opinions.
[deleted]
Presumably Developer Experience
Developer eXperience
I also am departing from Next.js as the future is now clear - upselling their commercial stuff.
> Nowadays users browse the web using their phones, tablets, and laptops, yet images are still as a one size fits all. For example: sites load a 2000 by 2000 pixel image, but phones are only displaying it as 100 by 100 pixels.
That's what srcset & <source> were invented for.
> Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.
That's why we now have a loading=lazy HTML attribute
> When using the next/image component, images are automatically lazy-loaded, meaning they're only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.
This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page.
I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
> Developers can mark images that are in the initial viewport, allowing Next.js to automatically preload these images. Preloading images in the initial viewport has shown improvements to the Largest Contentful Paint by up to 50%.
How can smart preloading work when the image size isn't known until the JS component runs? If we're back to loading the 2000px image then we're losing a lot of optimization.
If they're relying on client hints [1] then we can get as far as an image as wide as the browser window width, but no more - at the price of poor browser compatibility.
Preloading also has its own costs, as it messes with the browser's prioritization of page content. I've found it easy to prioritize something you know is essential and unintentionally increase load time metrics.
1. https://caniuse.com/client-hints-dpr-width-viewport
That's what srcset & <source> were invented for.
> Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.
That's why we now have a loading=lazy HTML attribute
> When using the next/image component, images are automatically lazy-loaded, meaning they're only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.
This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page.
I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
> Developers can mark images that are in the initial viewport, allowing Next.js to automatically preload these images. Preloading images in the initial viewport has shown improvements to the Largest Contentful Paint by up to 50%.
How can smart preloading work when the image size isn't known until the JS component runs? If we're back to loading the 2000px image then we're losing a lot of optimization.
If they're relying on client hints [1] then we can get as far as an image as wide as the browser window width, but no more - at the price of poor browser compatibility.
Preloading also has its own costs, as it messes with the browser's prioritization of page content. I've found it easy to prioritize something you know is essential and unintentionally increase load time metrics.
1. https://caniuse.com/client-hints-dpr-width-viewport
> That's what srcset & <source> were invented for.
next/image makes use of srcset.
> This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page. >I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
No knowledge of what Google contributed to this, but my experience of running Google PageSpeed Insights on many sites is that this sort of optimization does improve the metrics Google measures.
Also, while I agree in part with most of your points, I still think we should give credit to nextjs for making this easy.
Sure, maybe you don't need a library to use srcset. If you are going to run our own custom build processes (or server endpoints) that generate images in a range of appropriate sizes and write the corresponding front-end code, good for you. Next.js has done nothing to stop any of this.
But many (most?) websites don't bother with any of that and just load one giant image for everyone. If there is a tool that makes using optimized images as easy loading one giant image for everyone, I think that's great.
next/image makes use of srcset.
> This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page. >I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
No knowledge of what Google contributed to this, but my experience of running Google PageSpeed Insights on many sites is that this sort of optimization does improve the metrics Google measures.
Also, while I agree in part with most of your points, I still think we should give credit to nextjs for making this easy.
Sure, maybe you don't need a library to use srcset. If you are going to run our own custom build processes (or server endpoints) that generate images in a range of appropriate sizes and write the corresponding front-end code, good for you. Next.js has done nothing to stop any of this.
But many (most?) websites don't bother with any of that and just load one giant image for everyone. If there is a tool that makes using optimized images as easy loading one giant image for everyone, I think that's great.
>That's what srcset & <source> were invented for.
I don't know Next.js but I just spot checked a comparison to see if srcset is an exact subtitute.
- If I'm reading CanIUse chart correctly, it says IE11 isn't compatible.[1]
- syntax of srcset requires manual and verbose specification of different source images. E.g. from MDN[2]:
Like I said, I'm not an expert. The Next.js Image function doesn't look like useless redundancy with plain HTML5.
[1] https://caniuse.com/?search=srcset
[2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
[3] https://nextjs.org/blog/next-10#nextjs-image-component
I don't know Next.js but I just spot checked a comparison to see if srcset is an exact subtitute.
- If I'm reading CanIUse chart correctly, it says IE11 isn't compatible.[1]
- syntax of srcset requires manual and verbose specification of different source images. E.g. from MDN[2]:
<img srcset="elva-fairy-480w.jpg 480w,
elva-fairy-800w.jpg 800w"
sizes="(max-width: 600px) 480px,
800px"
src="elva-fairy-800w.jpg"
alt="Elva dressed as a fairy">
import Image from 'next/image'
<Image src="/profile-picture.jpg" width="400" height="400">
Like I said, I'm not an expert. The Next.js Image function doesn't look like useless redundancy with plain HTML5.
[1] https://caniuse.com/?search=srcset
[2] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
[3] https://nextjs.org/blog/next-10#nextjs-image-component
Yeah, I mean, screw IE11 users. An unsupported srcset just means that they will not benefit from this enhancement but they will just download a standard size. This is perfectly fine.
As for the syntax, yes, it’s better to always have some generator to create it. WordPress has been doing it for years with a plain `the_image($id)` call.
As for the syntax, yes, it’s better to always have some generator to create it. WordPress has been doing it for years with a plain `the_image($id)` call.
A better way of saying this is that srcset gracefully degrades for IE11. They will miss out on the benefits, but they still get to use a regular <img /> tag.
Next's Image component renders out to the first example. They are ultimately the same thing.
> How can smart preloading work when the image size isn't known until the JS component runs?
From the article:
- Image dimensions are enforced, allowing browsers to immediately render the space needed for the image instead of having it jump in when loaded, preventing layout shift.
- While width and height on the HTML <img> element can cause issues with responsive layouts, this is not the case when using next/image. When using next/image the image is automatically made responsive based on the aspect ratio from the provided width and height.
From the article:
- Image dimensions are enforced, allowing browsers to immediately render the space needed for the image instead of having it jump in when loaded, preventing layout shift.
- While width and height on the HTML <img> element can cause issues with responsive layouts, this is not the case when using next/image. When using next/image the image is automatically made responsive based on the aspect ratio from the provided width and height.
Image dimensions is great, but isn't the same as preloading, which is done via a HTTP header or a <link rel=preload>
See https://web.dev/preload-critical-assets/ for more details.
See https://web.dev/preload-critical-assets/ for more details.
Is srcset commonly used? I am not familiar with it but I'm more full stack than frontend and often feel like front end moves faster than I can keep up with.
> Is srcset commonly used?
It is, to provide a couple of different image sizes so smaller screens/high DPI devices can load the best-sized image for their use.
This is the best article I know on the subject https://cloudfour.com/thinks/responsive-images-the-simple-wa...
It is, to provide a couple of different image sizes so smaller screens/high DPI devices can load the best-sized image for their use.
This is the best article I know on the subject https://cloudfour.com/thinks/responsive-images-the-simple-wa...
I don't know about its popularity, but it works as advertised and my company had used it. What's more important is that it's a correct solution for the problem (unless old browser support is required).
[deleted]
Good points, you know what's even more fun?
Saying you have the only and first solution to a problem and having no comment section and never acknowledging people on twitter, hackernews and reddit.
Saying you have the only and first solution to a problem and having no comment section and never acknowledging people on twitter, hackernews and reddit.
The big elephant in the room most of these frameworks are missing is partial hydration. Instead of hydrating the whole page, only the interactive parts are hydrated, sending the absolutely minimal JS needed to the client.
AFAIK only Marko has this feature today. Since it's developed and used at Ebay they focused on the best SSR+hydration experience from the start.
Imba v2 will also have patial hydration (confirmed by the devs here on HN).
Other than those two, it seems nobody is really taking partial/progressive/lazy hydration seriously. IMO SSR+partial hydration is really the next frontier in web development.
It's possible to do it yourself (I did it recently with a Svelte project) but it results in complicated setups. We need a solution that does it transparently, extracting the needed components and data automatically.
AFAIK only Marko has this feature today. Since it's developed and used at Ebay they focused on the best SSR+hydration experience from the start.
Imba v2 will also have patial hydration (confirmed by the devs here on HN).
Other than those two, it seems nobody is really taking partial/progressive/lazy hydration seriously. IMO SSR+partial hydration is really the next frontier in web development.
It's possible to do it yourself (I did it recently with a Svelte project) but it results in complicated setups. We need a solution that does it transparently, extracting the needed components and data automatically.
The React team is working on some experiments that’s not quite what you’re describing but achieves the goal of sending way less code to the client. I can’t wait until tools like that are more standard.
There is light at the end of the SPA tunnel :)
Since you mentioned Svelte, you may want to take a look into Elder.js, if you haven't: https://github.com/Elderjs/elderjs
https://github.com/LukasBombach/next-super-performance adds partial hydration to next. I was tempted by this some time ago, but ended up leaving it due to concern about straying too far off-piste from next itself.
It is coming soon.
https://github.com/vercel/next.js/issues/10344
https://github.com/vercel/next.js/issues/10344
I think it's coming not soon based on the last comment of this issue.
It's not. That issue is closed and the last comment says:
> Overall it’s currently not possible to do this besides following what’s described in the article. Definitely something we plan on tackling eventually!
> Overall it’s currently not possible to do this besides following what’s described in the article. Definitely something we plan on tackling eventually!
The React team is or was reportedly working on "progressive hydration" which sounds like what you're talking about.
This tweet from React core team member Dan Abramov in December 2018: https://twitter.com/dan_abramov/status/1079352276433715200
This tweet from React core team member Dan Abramov in December 2018: https://twitter.com/dan_abramov/status/1079352276433715200
They've been talking about it for years alongside with SSR streaming. Nothing concrete so far.
I get the sense the React team don't really care about SSR as it's not a massive use case for FB.
The React team has been focusing much more on SSR lately. I think it's likely we'll see big things in 2021.
Good to hear! If that's the case then I'm excited.
I thought it was a massive use case for Facebook. I recall seeing Facebook engineering tech talks about how they write their JavaScript with different types of import statements to optimize what gets rendered in SSR versus on the client. I think this is a similar video: https://www.youtube.com/watch?v=KT3XKDBZW7M
Is this not SSR streaming? https://reactjs.org/docs/react-dom-server.html#rendertonodes...
I could be wrong, but I don't think so, no.
> The HTML output by this stream is exactly equal to what ReactDOMServer.renderToString would return.
I imagine this returns a stream as a convenience for Node servers that are streaming chunks of HTML. I don't think it means that React's SSR is rendering chunks of HTML in an async fashion and returning each chunk to the stream as soon as it's ready.
Also look at the last task of suspense:
> Implement a streaming server renderer
https://github.com/facebook/react/issues/13206
> The HTML output by this stream is exactly equal to what ReactDOMServer.renderToString would return.
I imagine this returns a stream as a convenience for Node servers that are streaming chunks of HTML. I don't think it means that React's SSR is rendering chunks of HTML in an async fashion and returning each chunk to the stream as soon as it's ready.
Also look at the last task of suspense:
> Implement a streaming server renderer
https://github.com/facebook/react/issues/13206
You're right. ReactDOMServer.renderToNodeStream is to support HTML streaming, which can allow the browser to start rendering the (as far as it knows, static HTML) document before it receives all the HTML. This is nice, but probably is not a huge factor if you're using HTTP caching via a CDN or a static site generator (since the CDN will likely support HTML streaming).
I remember thinking when I first saw Marko it's kinda crazy how unknown Marko is given how well they've been doing streaming SSR and Partial Hydration for years. At production scale at eBay.
Is Marko the ONLY framework with this feature? Surely there's some more.
I've been looking at this for months and AFAIK it's the only one that has it OOTB. If you find others, please let me know.
It can be implemented with React and others (I've done it with Svelte) but it's complicated. See this example on how to do it with Preact and Next:
https://medium.com/@luke_schmuke/how-we-achieved-the-best-we...
It can be implemented with React and others (I've done it with Svelte) but it's complicated. See this example on how to do it with Preact and Next:
https://medium.com/@luke_schmuke/how-we-achieved-the-best-we...
Elder.js (Svelte framework) has partial hydration OOTB: https://github.com/Elderjs/elderjs
Alpine.js has partial hydration. ;-)
It works on any string of HTML but it doesn't have SSR so I don't think it counts as hydration.
Also, the unsafe-eval CSP is way too risky.
Also, the unsafe-eval CSP is way too risky.
Highlights (live from keynote):
- On-demand image optimization, lazy loading, via an Image component (responsive sizes, formats)
- Internationalization support (routing via domain or subpath)
- Next.js analytics. Automated performance testing and tracking https://nextjs.org/analytics
- Next.js commerce. Starter kit for high-performance ecommerce https://nextjs.org/commerce
Blog post: https://nextjs.org/blog/next-10
Full changelog: https://github.com/vercel/next.js/releases/tag/v10.0.0
- On-demand image optimization, lazy loading, via an Image component (responsive sizes, formats)
- Internationalization support (routing via domain or subpath)
- Next.js analytics. Automated performance testing and tracking https://nextjs.org/analytics
- Next.js commerce. Starter kit for high-performance ecommerce https://nextjs.org/commerce
Blog post: https://nextjs.org/blog/next-10
Full changelog: https://github.com/vercel/next.js/releases/tag/v10.0.0
Am I missing the part of the analytics docs / announcement where they mention how to send that information to anywhere other than Vercel?
EDIT: described here in "web vitals" https://nextjs.org/docs/advanced-features/measuring-performa...
EDIT: described here in "web vitals" https://nextjs.org/docs/advanced-features/measuring-performa...
[deleted]
Does Next.js do pre-rendering, i.e. if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request? Or will it assemble the template on the server, send it down to the client and then do some amount of interactivity hydration later on during the page load?
What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. As a result we abandoned SSR based frameworks completely and just went with minimal JS on the client and pre-rendered all the pages on the server as HTMLs which loaded pretty much instantly.
Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. As a result we abandoned SSR based frameworks completely and just went with minimal JS on the client and pre-rendered all the pages on the server as HTMLs which loaded pretty much instantly.
Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable.
If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code:
If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code:
export default function ClientOnly({ children, ...delegated }) {
const [hasMounted, setHasMounted] = useState(false)
useEffect(() => { setHasMounted(true) }, [])
return hasMounted ? <div {...delegated}>{children}</div> : <div></div>
}
As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.
You're totally right. Apparently this on the Nextjs team's radar though:
>Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities:
> - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post)
> - Re-generating by listening to events (like CMS webhooks), ahead of user traffic
Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-r...
But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time.
What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.
>Up next, we will be working on a supplemental RFC to address two additional incremental static generation capabilities:
> - Re-generating and invalidating multiple pages at once (like your blog index and a certain blog post)
> - Re-generating by listening to events (like CMS webhooks), ahead of user traffic
Source: https://nextjs.org/blog/next-9-5#stable-incremental-static-r...
But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time.
What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.
Right, actually building all those pages at once necessarily takes time. But on Netlify, most of my build time isn't actually used doing `next build`, it's the un-logged-to-user file transfer to their server / CDN cache invalidation / whatever hosting magic they do after the static files are built.
So at least in my case, NextJS would have to create a way to not rebuild files that haven't changed, and then the hosting/CDN provider would also need to be able to see which files those are and respond accordingly. This all seems very doable eventually though.
So at least in my case, NextJS would have to create a way to not rebuild files that haven't changed, and then the hosting/CDN provider would also need to be able to see which files those are and respond accordingly. This all seems very doable eventually though.
What happens if there are millions of pages?
Wish Next.js would have a "scalability issues and solutions" documentation...
Wish Next.js would have a "scalability issues and solutions" documentation...
For each page, you can set `fallback: 'blocking'`. If set, the page is not built at compile time. Instead, it will be compiled the first time it's requested. So the first request will take longer, then after that it'll be fast.
Alternatively, on a per-page decision you could decide to use server side generation (page built at compile time) or server side rendering (page compiled when requested).
You have options that let you spread out the time, but ultimately it's going to take time to build millions of pages.
Alternatively, on a per-page decision you could decide to use server side generation (page built at compile time) or server side rendering (page compiled when requested).
You have options that let you spread out the time, but ultimately it's going to take time to build millions of pages.
Like acoard said below, I think the recommendation there would be to use their hybrid cache / dynamic rendering option. You do lose a lot of the cool benefits of being fully static in that case though. In general, yes that kind of documentation would be very helpful.
Disclaimer being that I'm talking mostly about 5 - 10 page presentation websites, consistently, I achieve 95+ on Google Page Speed for Mobile when deploying the Next.JS solutions on the Vercel infrastructure. There are helpers for working with images that can generate multiple versions, transform to WebP and other stuff. This is where most of the optimization work goes I think.
> Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air.
There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)
> Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air.
There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)
> if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request?
You can set it up to retrieve all 500 products and render the html on the server.
> What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.
You can set it up to retrieve all 500 products and render the html on the server.
> What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.
Next.js can do both pre-rendering (static output) and dynamic server-side rendering. I can't speak to your questions about internationalization though.
I recently played around with Next 9.5 prerendering. It had about 400 simple pages with artificially slow API responses to get an idea.
- you can prerender a decent amount of pages no probs
- you can prerender only a subset and then have Next render the necessary pages on the server upon request
- as the page is being prerendered, you can send placeholder content, so ttfb is low
- linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled)
- in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix”
So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.
- you can prerender a decent amount of pages no probs
- you can prerender only a subset and then have Next render the necessary pages on the server upon request
- as the page is being prerendered, you can send placeholder content, so ttfb is low
- linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled)
- in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix”
So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.
> I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO.
You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.
You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.
yes, next will prerender everything. you should give it a try.
I have mixed emotions on this framework. If you're doing a simple project, Next is the best around. Also great for marketing pages, etc. But if you have a more sophisticated app, with an API, page routes that need to toggle based on cookies, etc, then you have to integrate something like Express. I've done this several times with Next, and it just doesn't pay off. I've also tried to use it at work, but it changes rapidly, and it'd be too much to expect engineers who aren't keeping up with everything on the clientside to know what to do.
I feel like there's a need for something between roll-your-own and what vercel is offering.
I feel like there's a need for something between roll-your-own and what vercel is offering.
I assume you're referring to what Next describes as a "Custom Server", e.g. taking over the server-side control flow.
Personally, I keep Next stock for the frontend, and just write an entirely separate backend/API server. I would want to do that in any event, just to achieve separation of concerns and avoid lock-in.
Personally, I keep Next stock for the frontend, and just write an entirely separate backend/API server. I would want to do that in any event, just to achieve separation of concerns and avoid lock-in.
Next.js has been very good for not introducing breaking changes in my experience (especially for the JavaScript ecosystem). The changes are more along the lines of lots of new and useful things (e.g. image optimisation) as opposed to problematic maintenance issues.
I agree cookies can be a bit awkward with Next but I've always found a way around.
I agree cookies can be a bit awkward with Next but I've always found a way around.
Would a minimalist framework like mithril.js fill that gap? I've had a pretty good experience when using it for some small to mid sized projects. Since its on the simple side, the updates are infrequent and have been pretty painless to keep up with.
Why do you have to integrate with Express? Genuinely asking – that wasn't my impression.
I think he means if you want to offer React server side you will need some-sort of web framework to serve it. Usually that's Express or Fastify or something like that.
Next.js does server-rendering and has API routes built-in. No need for Express or Fastify unless you like the DX of those frameworks better.
The Parent parent was talking about if you don’t use Next and want a more sophisticated setup then then those are alternatives.
The parent then asked why do you need to integrate [react] with Express and my answer was if you want to do server side (not using Next)
The parent then asked why do you need to integrate [react] with Express and my answer was if you want to do server side (not using Next)
React was not even mentioned in the thread. OP mentioned integration Next with Express, not React.
Using Express and Next together is relatively common (or at least used to be): https://github.com/shdnx/next-express
Using Express and Next together is relatively common (or at least used to be): https://github.com/shdnx/next-express
Do you mind enumerating the specific pain points?
Routing seems like the biggest limitation, but it's a trade off to use their file-based routing which has it's pros too. This precludes page transitions unless you do some really ugly work arounds.
Routing seems like the biggest limitation, but it's a trade off to use their file-based routing which has it's pros too. This precludes page transitions unless you do some really ugly work arounds.
Yeah, I think it's going down the VC wormhole right now. It was a fantastic microframework for doing a few core tasks extremely well. Creating a fully-managed hosting platform is a good revenue stream to support the development. Adding analytics and commerce with vendor tie-ins seems like serious mission creep.
As someone who only really built websites using jQuery / custom vanilla js and good ole CSS2, this stuff feels completely alien to me
I had also avoided modern web up until very recently. I focused only on Django sites and wrote custom JavaScript as necessary.
I even did a 3 month django project with a view that was almost entirely JavaScript—it would have been a perfect candidate for react but I refused.
As a compromise with myself I used es6 js on that and eliminated use of jQuery from my code.
About a month ago I started work on react. I had very similar feelings going in and was annoyed at having to figure out the node dependency thing. And I was aghast at the “tool chain” which is the post processing you need to do on React and other modern front end.
However, I was really surprised at how much better it is to build front end using this rather than html templates and sprinkles of js.
I was also surprised to find out that the django community barely has a pulse compared to what is happening in react.
It’s safe back there, but there is no innovation. Once you see what is happening in modern web, it feels like a ghost town.
I think it’s a pretty good time to get into React right now. CRA just got an update, functional components are mainstream and now there is this nextjs.
I encourage you to give react a try, at the very least it will make you think more about why you’re building the way you are.
I even did a 3 month django project with a view that was almost entirely JavaScript—it would have been a perfect candidate for react but I refused.
As a compromise with myself I used es6 js on that and eliminated use of jQuery from my code.
About a month ago I started work on react. I had very similar feelings going in and was annoyed at having to figure out the node dependency thing. And I was aghast at the “tool chain” which is the post processing you need to do on React and other modern front end.
However, I was really surprised at how much better it is to build front end using this rather than html templates and sprinkles of js.
I was also surprised to find out that the django community barely has a pulse compared to what is happening in react.
It’s safe back there, but there is no innovation. Once you see what is happening in modern web, it feels like a ghost town.
I think it’s a pretty good time to get into React right now. CRA just got an update, functional components are mainstream and now there is this nextjs.
I encourage you to give react a try, at the very least it will make you think more about why you’re building the way you are.
Thanks. I really appreciate the story. I'm a long time Django fan so your story resonates. Maybe I'll give React another try one of these days...
You’re welcome. I wish someone in my position was able to give me this same info a year ago.
The other thing I’d add is that on my “old” projects, my JS is way better now that I’ve practiced so much es6 in React.
The other thing I’d add is that on my “old” projects, my JS is way better now that I’ve practiced so much es6 in React.
Try starting with VueJS... it can be added to a page just like jquery and you get the same reactivity/template/etc support on the page without having to setup a compiler/etc.
Then after you learn that if you want to create a full app, vue (in vue-cli) has config templates that will help you set everything up so you can just start adding the pages to the app. A full app is nice because the compiler and linting will catch a lot of js errors making your app more reliable, allowing you to write larger apps (this is the biggest reason people use these frameworks).
The concepts in Vue are similar enough to React, Nuxt, Next, etc that it's pretty easy to learn the others after you have the basics down.
Then after you learn that if you want to create a full app, vue (in vue-cli) has config templates that will help you set everything up so you can just start adding the pages to the app. A full app is nice because the compiler and linting will catch a lot of js errors making your app more reliable, allowing you to write larger apps (this is the biggest reason people use these frameworks).
The concepts in Vue are similar enough to React, Nuxt, Next, etc that it's pretty easy to learn the others after you have the basics down.
Same. I mean I understand how it works but I ask myself what's the point every time. I've looked into react and I hate how it works and I hate how every 2 months people are begging for some new optimization because its slow and sucks. Then version 5000 is released and fixes that slowdown, but every react site I've ever used is still buggy and slow as hell.
> hate how it works
> its slow and sucks
> every react site I've ever used is still buggy and slow as hell
Next time try to come up with some rational, objective criticism instead of just hurling insults at the most popular frontend framework.
There is a reason people use it, and believe it or not, it's not due to hype.
> its slow and sucks
> every react site I've ever used is still buggy and slow as hell
Next time try to come up with some rational, objective criticism instead of just hurling insults at the most popular frontend framework.
There is a reason people use it, and believe it or not, it's not due to hype.
> but every react site I've ever used is still buggy and slow as hell
This is just as asinine as saying "every Ruby on Rails site I've ever used is still buggy and slow as hell".
No, every terribly coded site youve used is slow as hell.
This is just as asinine as saying "every Ruby on Rails site I've ever used is still buggy and slow as hell".
No, every terribly coded site youve used is slow as hell.
Which means that React attracts people who aren't really developers but they want to jump in on the hype train, right?
No. People have said this about every web framework since PHP5 and its not true. Web development does tend to favor fast iteration which can lead to problems if the tech debt compounds but that doesn’t mean the people aren’t developers, at all.
So what you're saying is that React spawned an army of people who we can call developers, despite them not knowing how browsers and HTTP works, what algorithms are, how to approach developing your javascript app so it doesn't become spaghetti mess in 24 seconds and abusing terminology from systems programming just in order to make their field appear more serious than it is?
Now, what word could we use for people who are not.. well, "developers"? Programmers maybe?
Now, what word could we use for people who are not.. well, "developers"? Programmers maybe?
*laughs in modern web development
OK, so definitely my mind is blown with stuff they did. NextJS is great tool and focus on shopping and using that as a use case to improve your whole framework is fantastic.
I also love youth that I see in the team, I am a little bit older :).
Like others here, I am impressed with Svelte and trying to find how and where to use it. We live in great time where we are showered with amazing tools for development.
Having said that, for more traditional, ReactJS scenarios, NextJS is pretty much without competition (even though there is plenty). New features with localization and image optimization are fantastic and allow next level of mobile websites. If we are ever to break Apple/Google monopoly on appstore, this is a way to do it. I think analytics package is solid addition and if you don't want to pay, you don't have to use it, it is for commercial projects.
Anyhow, I am really impressed with features they did and how it is integrated into their platform. Not huge fan of Vercel name still :) but it is great platform.
I also love youth that I see in the team, I am a little bit older :).
Like others here, I am impressed with Svelte and trying to find how and where to use it. We live in great time where we are showered with amazing tools for development.
Having said that, for more traditional, ReactJS scenarios, NextJS is pretty much without competition (even though there is plenty). New features with localization and image optimization are fantastic and allow next level of mobile websites. If we are ever to break Apple/Google monopoly on appstore, this is a way to do it. I think analytics package is solid addition and if you don't want to pay, you don't have to use it, it is for commercial projects.
Anyhow, I am really impressed with features they did and how it is integrated into their platform. Not huge fan of Vercel name still :) but it is great platform.
There is an online Next.js conference right now: https://nextjs.org/conf/stage/n
It's nice to see that Next has Typescript support.
No matter how nice a framework looks, it's a deal breaker when there's no TS support. It's just too hard dealing with a large Javascript code base.
No matter how nice a framework looks, it's a deal breaker when there's no TS support. It's just too hard dealing with a large Javascript code base.
Yeah and it's first citizen too, it was upgraded from needing a @zeit/plugin to working from scratch in a new nextjs project.
Just add a pages/index.tsx, and run yarn dev, and next will create a default sensible tsconfig.json file for you and run the project!
Just add a pages/index.tsx, and run yarn dev, and next will create a default sensible tsconfig.json file for you and run the project!
Nextjs has the dejavu vibe of docker.
It is a brilliant framework dragged slowly and inexorably into "platform lock-in".
Nextjs has defocused on SSR (which was the original selling point of a server side Reactjs). And all the other cool features only run on Vercel.
It is getting next to impossible to deploy Nextjs (with all its features) on GAE for example...or heroku.
There are other alternatives to Nextjs that are emerging with true developer fit - think databases,etc. Svelte, etc are pretty cool
It is a brilliant framework dragged slowly and inexorably into "platform lock-in".
Nextjs has defocused on SSR (which was the original selling point of a server side Reactjs). And all the other cool features only run on Vercel.
It is getting next to impossible to deploy Nextjs (with all its features) on GAE for example...or heroku.
There are other alternatives to Nextjs that are emerging with true developer fit - think databases,etc. Svelte, etc are pretty cool
Vercel is great at getting out of the way of deployments and just working. But I've deployed Next apps to Linux servers on AWS, GC, DO and it wasn't much more involved that a standard Node deployment - Next with Elastic Beanstalk is pretty straight forward too.
Doesn't it still come with a server that you can just run on Heroku? That's what I'm doing, and although I'm not at v10 yet, I can't recall any major challenges there.
All the server side parts are now deeply linked to Vercel microservices infrastructure.
As a static site, nextjs is probably a little bit more complex than gatsbyjs (with its zillions of fantastic themes)
As a static site, nextjs is probably a little bit more complex than gatsbyjs (with its zillions of fantastic themes)
Is it though? Do you mean that running `next build; next start` as described at [1] no longer works?
[1] https://nextjs.org/docs/deployment#nodejs-server
[1] https://nextjs.org/docs/deployment#nodejs-server
Prediction: Google buys Vercel, kills Angular, steps further into e-commerce
… and people would look into https://svelte.dev which might be everything you need.
They don't have enough funding. Next.js and Gatsby are in an entirely different weight class compared to Sapper.
https://sapper.svelte.dev/
https://sapper.svelte.dev/
And... Sapper is dead btw.
Rich said it recently in a video. The Svelte team is working on the next big thing combining Svelte with Snowpack. The project is called SvelteKit.
https://www.youtube.com/watch?v=qSfdtmcZ4d0
Rich said it recently in a video. The Svelte team is working on the next big thing combining Svelte with Snowpack. The project is called SvelteKit.
https://www.youtube.com/watch?v=qSfdtmcZ4d0
I think retiring Sapper was the right decision. I have a feeling Rollup will meet a similar end too.
They both seemed like fine pieces of software. They just don't seem offer separate much their counterparts nowadays that warrants continued feature development.
They both seemed like fine pieces of software. They just don't seem offer separate much their counterparts nowadays that warrants continued feature development.
Rollup isn't going anywhere! When you poke behind the scenes of newer build tools, like Snowpack and Vite and the custom compiler that powers Remix Run, you'll find Rollup doing a lot of the heavy lifting. And it's the preferred choice of most libraries. There's a reason for that :)
Thanks for the correction, Rich.
I just watched your presentation at Svelte Summit and I'm looking forward to how Svelte progresses.
I just watched your presentation at Svelte Summit and I'm looking forward to how Svelte progresses.
Maybe this can save someone some confusion: When I searched the first result for SvelteKit seems to be another project that is dead.
The project hasn't really been publicly released yet. The repository is still private. The package is up on npm, but isn't ready for widespread adoption yet. I'd recommend sticking with Sapper for now.
https://www.npmjs.com/package/@sveltejs/kit
https://www.npmjs.com/package/@sveltejs/kit
Should be called SveltePack IMO :)
Or even better, Vue.js
I am not sure I buy into all the svelte hype, and even if claims about it's speed/build size are true - the difference isn't enough to outweigh the enormous advantage vue has in terms of a more mature ecosystem/tooling.
I am not sure I buy into all the svelte hype, and even if claims about it's speed/build size are true - the difference isn't enough to outweigh the enormous advantage vue has in terms of a more mature ecosystem/tooling.
Could be. Angular growth has stalled for the past year or so. Polymer is pretty much dead.
OTOH hand why would Google invest in a React-based solution? Google could start from scratch an create the next best thing if they wanted to. To me it's pretty clear the future is a compiler based approach like Svelte, with support for SSR, partial hydration, static generation, and dynamically loading smaller parts of a page (eg: AJAX + hydration). All with a kickass DX.
OTOH hand why would Google invest in a React-based solution? Google could start from scratch an create the next best thing if they wanted to. To me it's pretty clear the future is a compiler based approach like Svelte, with support for SSR, partial hydration, static generation, and dynamically loading smaller parts of a page (eg: AJAX + hydration). All with a kickass DX.
If Google wanted to takeover React, the solution is at the browser level. Fix rendering and state management with native language built ins, and voila, we are out of the stupid frontend hell.
Wtf is hydration? Is that like when websites used to render json payloads on the page on first render?
This field is getting scammy with its nonsense. Create one more stupid word, and I swear I will lose my god damn mind.
Wtf is hydration? Is that like when websites used to render json payloads on the page on first render?
This field is getting scammy with its nonsense. Create one more stupid word, and I swear I will lose my god damn mind.
They could buy Vercel & Next with the intention of rolling their own React replacement to swap in later.
My bet is because of the ecommerce part of the platform (integration /w headless ecommerce companies like BigCommerce).
If that happens I'm out, especially if they bundle it other Google products
Roll it into Firebase maybe
I tried nextjs because I thought it would be a good way to learn React but I found it really confusing. Is it really better to master React first then try nextjs?
This is the resource I used (as someone who's been doing web development for ~20 years) to get a a basic understanding of React. It, plus some side projects, was enough to get me up to speed: https://daveceddia.com/pure-react/
I'm sure there are others that are free; but, this is what worked for me.
I'm sure there are others that are free; but, this is what worked for me.
I think create-react-app is much more beginner friendly. Fewer concepts to learn. Rolling your own or using script tags to begin with is also an option (see this course for an example: https://egghead.io/courses/the-beginner-s-guide-to-react)
And create-react-app would be all I would ever need except that SEO on single page apps that don't have data loaded upon load really sucks compared to server side rendered pages. Is there a way to build a site using create-react-app and enable server side rendering without implementing a whole other framework like Nextjs?
We used React Router's ssr process described here[1] on my last React project. It worked ok, but there's a bit of hoop-jumping to go through if your pages are populated by async data.
[1] https://reactrouter.com/web/guides/server-rendering
[1] https://reactrouter.com/web/guides/server-rendering
Next.js really isn't that bad. If you need SSR, it is definitely the best way to go.
A solid understanding of React is helpful. Mastery of React completely unnecessary.
[deleted]
I can't believe NextJS still doesn't have named routes, resorting to hacks like next-routes or next-named-routes to have a semblance of sanity managing links throughout larger apps.
Also, doing things like /@[username] is still a huge hack, unsupported.
Also, doing things like /@[username] is still a huge hack, unsupported.
It looks like both of those packages are used for creating dynamic routes with named parameters. Nextjs supports this already. Is that what you meant by "named routes", or is that something different? https://nextjs.org/docs/routing/dynamic-routes
[deleted]
They're talking about all the changes right now in Next.js Conf's keynote: https://www.youtube.com/watch?v=1-NzQ9ObsfM
I find it funny that even though it's been reported a number of times, the NextJS routing system is still flawed
Try it on their own site:
https://nextjs.org/index
Resulting in duplicate content to https://nextjs.org/
Maybe duplicate content isn't a problem with modern SEO - but it's a problem for my workflow and is potentially one reason why NextJS won't be on my list for any new projects.
Try it on their own site:
https://nextjs.org/index
Resulting in duplicate content to https://nextjs.org/
Maybe duplicate content isn't a problem with modern SEO - but it's a problem for my workflow and is potentially one reason why NextJS won't be on my list for any new projects.
Cant you just set a canonical URL meta tag? It’s very common for content to be available through multiple urls. (Eg, have a numeric ID and a slug in the URL. Any slug is valid in case of renames, but the ID is the relevant identifier).
I'm not sure if they are dogfooding their own framework, but it's annoying that the cards on the home page won't even let you select their content without going straight to a different page. It's a subtle breakage of `a href` behavior but I see that on a lot of sites where I'd like to copy a value and instead an action fires off when I don't want to.
Its worth pointing out that Next does not provide react components like cards - that is a separate implementation and just not a part of next.js.
this seems to have less to do with Next.js and is more of a design decision. Each card has a native anchor tag inside, and when you tab through these links the card is ignored and the links are focused. The card itself is a 'fake' js link, that redirects when clicked.
i personally would've made the entire card an anchor link, but either approach is possible in Next.js
i personally would've made the entire card an anchor link, but either approach is possible in Next.js
I've been almost exclusively working with NextJS for front-end stuff in 2020. It just keeps getting better and better.
Can anyone compare this to something like Hugo or Jekyll? Why is the more complex JavaScript build chain worth it?
In short With Next you control when things are rendered: SSG/SSR/CSR, so you get much more flexibility and can cover more use-cases. And it is React based, which is a huge plus, especially if you adhere to a modern style.
What use cases does that cover though that Hugo and Jekyll can't? For landing pages and typical business websites for example, some basic ways to create reusable snippets of HTML feel enough for me. I don't want to have to deal with a lot of React, SPA stuff and JavaScript build issues unless it's really worth it.
Next with static rendering (or Gatsby, which I find horribly over complicated) are alternatives to Hugo and Jekyll. If you already know React, they are pretty easy to set up since they handle all the webpack/babel stuff for you, so you shouldn't have Javascript build issues.
When statically rendered, React is mostly just an alternative templating language.
When statically rendered, React is mostly just an alternative templating language.
Looks cool. The scope this asks for in GitLab is too much (everything):
This application will be able to:
Access the authenticated user's API
Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry.The new image solution is strictly more powerful than anything currently offered. Since they also control the initial rendering of the HTML, they can seamlessly opt to embed an image via a data url.
Kinda suprised they didn't do digital commerce first. Ecommerce and selling physiscal products is such a pain in comparison which won't go a way with a storefront.
In Vercel page they tout: "Developers love Next.js, the open source React framework Vercel built together with Google and Facebook".
Did Google quit Angular and is using React now?
Did Google quit Angular and is using React now?
Google does a lot of different things. In this case, it’s part of the Chrome team that has been focusing on this and how to help the web dev ecosystem more broadly.
I've never really trusted these image auto-optimizers. I always just do it my hand so I know what's actually happening.
The problem with doing something like that manually is that it’s painful at scale, and easy to forget. If scale isn't an issue, sure roll your own. But for my uses, I’m more likely to use tooling as a default, preview, then override when the preview doesn’t do what I want/expect.
Their very first release was v1.0.0 [1]; four years later they are at v10. It's official, v10 is the new v1.0.
[1] https://github.com/vercel/next.js/releases?after=1.0.2
[1] https://github.com/vercel/next.js/releases?after=1.0.2
Is support for nested routes going to be added any time soon?
If I don't want a full page reload when clicking a new tab for example? Or if I want to implement the age old header, sidebar main content layout without importing the header/sidebar in all my routes/components?
I'm aware there are hacks to get around this but would be nice if the standard next router supported nested routing with persistent layouts for those who need it : https://github.com/vercel/next.js/issues/8193
If I don't want a full page reload when clicking a new tab for example? Or if I want to implement the age old header, sidebar main content layout without importing the header/sidebar in all my routes/components?
I'm aware there are hacks to get around this but would be nice if the standard next router supported nested routing with persistent layouts for those who need it : https://github.com/vercel/next.js/issues/8193
I’m not a fan of these frameworks. They add another giant layer of stuff to learn and understand.
I’d rather just program react and the browser instead of hoping some framework will do it all for me.
I’d rather just program react and the browser instead of hoping some framework will do it all for me.
Next really doesn’t add a giant layer of anything, it’s almost vanilla React aside from their own routing and the server side functions (which you can start out not using)
Have you tried writing a sample project? It took me a few tries to really understand the problem that these framework solve.
When you're working on a larger scale (be that app complexity or number of users) these things make more sense.
Why are all these frameworks so big. Compiling, boiler plating, templating, huge API's etc.
I just want a real component framework where i can have something like:
I just want a real component framework where i can have something like:
<script>
include "MyComponentFramework.js"
page = new Page();
panel = new Panel();
button = new Button().addCssClass("buttonclass");
Page.addComponent(panel)
panel.addComponent(button)
button.bind('click',function(){
panel.addComponent(someComponent);
panel.rerender();
}
</script>
Basically what your example is describing is jQuery with some functions wrapped around some stuff. Sure, if you want to write a ton of imperative code, you can do that, but people who have been building UIs on the web for a couple decades have been down that road and have collectively determined it’s a nightmare.
Seems like you're asking for UI components (page, panel, button) that you can just use? This isn't the problem Next is trying to solve. You might be better off with something like MaterialUI, Ant, Bootstrap, of any of the many other batteries-included UI frameworks.
Or I guess Web Components were supposed to solve this problem, too, but I think they missed their window.
Or I guess Web Components were supposed to solve this problem, too, but I think they missed their window.
The main thing this is missing is HTML. Sure, you can use bootstrap across the project, but components need to have their custom CSS too.
If you added HTML (or really JSX, but same thing more or less), it might look like:
If you added HTML (or really JSX, but same thing more or less), it might look like:
<script>
include "MyComponentFramework.js"
page = new Page();
function handleClick() {
panel.addComponent(someComponent);
panel.rerender();
}
return
<panel>
<button on-click=handleClick className="buttonclass">
</panel>
</script>
Am I the only developer that feels that React ... and perhaps the whole web paradigm ... is about the worst way to think about and develop client GUIs?
After using Google's new Flutter framework (which is built to develop cross platform apps: iOS, Android, Web, embedded) I felt like I had my eyes open. The structure seems so much more logical and easy to navigate.
The Web (and React) paradigm of putting some code in HTML, some in CSS, and then some in JS, just seems like a step backwards to me after using Flutter where everything is just code. Designers build in Adobe XD or Figma, and then they hit export, and it dumps out FLutter code that a developer can directly read and incorporate into her project. There isn't a bewildering array of different things all being processed by different other things ... dumping out yet more things. Its just code to binary ... that's it.
And that's another thing ... I like the code to binary direct link. React Native's JS logic + bridge to native always seemed like such an inefficient shim. And seeing the framerate of widgets in Flutter its pretty clear we have been leaving some performance on the table for the convenience of making everything in Javascript.
Having said that, I'm sure Flutter on the web is as bulky as any other JS framework, as there it has to run on JS/HTML/CSS like everyone else.
After using Google's new Flutter framework (which is built to develop cross platform apps: iOS, Android, Web, embedded) I felt like I had my eyes open. The structure seems so much more logical and easy to navigate.
The Web (and React) paradigm of putting some code in HTML, some in CSS, and then some in JS, just seems like a step backwards to me after using Flutter where everything is just code. Designers build in Adobe XD or Figma, and then they hit export, and it dumps out FLutter code that a developer can directly read and incorporate into her project. There isn't a bewildering array of different things all being processed by different other things ... dumping out yet more things. Its just code to binary ... that's it.
And that's another thing ... I like the code to binary direct link. React Native's JS logic + bridge to native always seemed like such an inefficient shim. And seeing the framerate of widgets in Flutter its pretty clear we have been leaving some performance on the table for the convenience of making everything in Javascript.
Having said that, I'm sure Flutter on the web is as bulky as any other JS framework, as there it has to run on JS/HTML/CSS like everyone else.
JSX is not HTML, even though its syntax is very similar. It’s a data structure that’s renderer-agnostic. It can be rendered to HTML, or to a live DOM, or to other outputs. IIRC, Netflix uses React to render at least some components on entirely non-web interfaces like smart TVs.
To me, that fact is what makes React (and other libraries like Preact that have a similar interface) more compelling than the template-oriented alternatives. As far as I’m aware, Flutter takes basically the same approach, just with different syntax. I believe the same is true of SwiftUI. And Elm, and the various UI libraries for Clojure.
And as another comment mentioned, you can use a variety of CSS-in-JS approaches, which at least last time I looked is actually the more common approach in the React community.
Add in TypeScript (or whatever static type system in whatever compile to JS language), and you’re basically comparing bike sheds at this point.
To me, that fact is what makes React (and other libraries like Preact that have a similar interface) more compelling than the template-oriented alternatives. As far as I’m aware, Flutter takes basically the same approach, just with different syntax. I believe the same is true of SwiftUI. And Elm, and the various UI libraries for Clojure.
And as another comment mentioned, you can use a variety of CSS-in-JS approaches, which at least last time I looked is actually the more common approach in the React community.
Add in TypeScript (or whatever static type system in whatever compile to JS language), and you’re basically comparing bike sheds at this point.
Semantics.
The fact is you need to change syntax to describe your layout, instead of just using the syntax of the language you are already coding in.
The fact is you need to change syntax to describe your layout, instead of just using the syntax of the language you are already coding in.
Flutter has even more abstraction than what most people are using for web clients. That doesn't come for free, though it tends to always look like 100% upside until you actually use it and see the trade-offs it makes. Ruby on Rails also used to attract a lot of comments like yours until people realized the trade-offs.
Btw, if Flutter makes the web dev paradigm look bad, then I wonder what you think of the iOS/Android/desktop client paradigms where you don't even get much choice like you have on the web. Like using Core Data's "ORM".
You're essentially hoping Flutter spares you from ever having to drill any deeper than the Flutter abstraction on each of your deploy targets which simply doesn't yet match reality. And of all the client dev experiences, it's the web that has the options closest to Flutter, so it's not the one I'd damn first.
Btw, if Flutter makes the web dev paradigm look bad, then I wonder what you think of the iOS/Android/desktop client paradigms where you don't even get much choice like you have on the web. Like using Core Data's "ORM".
You're essentially hoping Flutter spares you from ever having to drill any deeper than the Flutter abstraction on each of your deploy targets which simply doesn't yet match reality. And of all the client dev experiences, it's the web that has the options closest to Flutter, so it's not the one I'd damn first.
Flutter has a very good plugin architecture. You don't actually have to use their widgets if you don't want to. And as for being restricted to the prevailing platform paradigm ... you have as much freedom as the platform gives you. For some things Flutter can't provide miracles ... like to access specific device hardware you are going to have to build a native bridge ... but in the end Flutter is building a binary that is ... as much as possible ... standalone. It even reinvents GUI components instead of bridging to the prevailing OS ones, touch input instead of using the native one, etc., so that you have more control (if you want it).
React doesn't have HTML templates though…? You can also have CSS-in-JS if you really want.
Whatever it's called ... JSX ... fact is you have to dive out of javascript to describe your UI in a different syntax, that's the point.
It’s still not HTML. It’s just syntactic sugar for function calls. You don’t have to use it either way; you can just call `React.createElement` directly if you don’t like JSX.
Analytics, great idea, is a huge disappointment. It's just a Vercel thing and not NextJS, not to mention a "pro/enterprise" paid feature, not cheap either.
A few days ago I saw the YT videos of "future of Svelte" and that video was really about "DX" with no non-sense no BS that just focused on the real next evolution on web/app dev. That DX really resonated with me.
My opinion, I'm not sold on NextJS 10, the "commercial" move kind of turned me off and scares me of platform lock-in, but I'm getting more and more interested into Svelte (v4?) and I'm seriously looking to switch to it from NextJS.
Note: "DX" stands for "Developer eXperience", meaning how joyful, easy it is to get started with the tool and feeling productive.