Next.js 10
nextjs.org
nextjs.org
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.
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.)
"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.
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".
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.
You may think that, but it's a standardized term already.
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.
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.
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.
I'm slightly "worried" about Sapper not being at v1.0 yet but... it's been working great for my MVPs
If someone doesn't beat me to it, I'll come back this afternoon and TL;DR the 22 minute video linked here.
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.
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.
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.
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...
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.
Next.js is going to be using srcset under the hood, I'm sure. The whole point of Next.js is to make best practices like this defaults, not to do anything groundbreaking and new.
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...
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.
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.
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.
See https://web.dev/preload-critical-assets/ for more details.
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.
> Overall it’s currently not possible to do this besides following what’s described in the article. Definitely something we plan on tackling eventually!
This tweet from React core team member Dan Abramov in December 2018: https://twitter.com/dan_abramov/status/1079352276433715200
> 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
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...
Also, the unsafe-eval CSP is way too risky.
not true, Elderjs from the Svelte ecosystem does exactly this
- 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
EDIT: described here in "web vitals" https://nextjs.org/docs/advanced-features/measuring-performa...
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
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.
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>
}
>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.
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.
Wish Next.js would have a "scalability issues and solutions" documentation...
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.
> 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 :)
- 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 just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.
I feel like there's a need for something between roll-your-own and what vercel is offering.
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)
Using Express and Next together is relatively common (or at least used to be): https://github.com/shdnx/next-express
I agree cookies can be a bit awkward with Next but I've always found a way around.
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.
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.
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.
Now, what word could we use for people who are not.. well, "developers"? Programmers maybe?
> 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.
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.
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.
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.
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.
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.
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!
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
As a static site, nextjs is probably a little bit more complex than gatsbyjs (with its zillions of fantastic themes)
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.
They both seemed like fine pieces of software. They just don't seem offer separate much their counterparts nowadays that warrants continued feature development.
I just watched your presentation at Svelte Summit and I'm looking forward to how Svelte progresses.
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.
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.
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.
I'm sure there are others that are free; but, this is what worked for me.
Also, doing things like /@[username] is still a huge hack, unsupported.
Try it on their own site:
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.
i personally would've made the entire card an anchor link, but either approach is possible in Next.js
When statically rendered, React is mostly just an alternative templating language.
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.Did Google quit Angular and is using React now?
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’d rather just program react and the browser instead of hoping some framework will do it all for me.
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>
Or I guess Web Components were supposed to solve this problem, too, but I think they missed their window.
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>
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.
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.
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.
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.