Next.js 9.3 – Static Site Support, 32 KB Smaller Runtime(nextjs.org)
nextjs.org
Next.js 9.3 – Static Site Support, 32 KB Smaller Runtime
https://nextjs.org/blog/next-9-3
31 comments
This is really cool. Many many years ago, I worked on a project that attempted to provide functionality like this, but with the limitations of browsers (IE 6 was still by far the majority share), libraries and my own talents, it was too ambitious to achieve. It warms my heart to see that vision realized in real products today.
Thanks so much! We’re really just getting started. There’s going to be a lot of advances in the next couple months.
[deleted]
Wow, this is incredible! I'll have to try it out.
I've used Next.js for the first time about 3 weeks ago to launch a small experiment. It was also my first introduction to react.
I must say, it was a pleasure to use. Great tutorials and the deployment using "now" was easy. Even attaching my own domain to it took less than 10 minutes.
Really recommend trying it out if you're interested in frontend development!
I must say, it was a pleasure to use. Great tutorials and the deployment using "now" was easy. Even attaching my own domain to it took less than 10 minutes.
Really recommend trying it out if you're interested in frontend development!
I'm in the market for an SSG for documentation of a larger project (and therefore I'm looking for something quick and easy to maintain). Hoping to keep it within the JS ecosystem so that would rule out Hugo and Jeckyll. Is Next.js easier to use than Gatsby, or is there an even simpler alternative I haven't come across yet? Ideally I'd be able to point this library to a glob of .md files and generate HTML + RSS.
Both Next.js and Gatsby are great to work with. If you're looking to stay in the JS ecosystem, you'll be happy with either choice.
As for which is "easier", it comes down to your skill set and preference. If you're familiar with GraphQL and enjoy it, you might prefer to use Gatsby. You can use GQL to fetch your Markdown files. If you're not as familiar with GQL, then it could be seen as a barrier to entry.
The biggest advantage Gatsby has over Next.js is its plugin system. For example, you're a simple config change away from an RSS feed -> https://www.gatsbyjs.org/packages/gatsby-plugin-feed/
The biggest advantage Next.js has over Gatsby is that it's a hybrid React framework. You can mix SSG and SSR together in the same application. This could be very beneficial if you want your main marketing site, SaaS app, and documentation to all live in the same project.
A great example of MDX (Markdown) + Next.js for production docs would be the StaticKit site -> https://github.com/unstacked/statickit-site
As for which is "easier", it comes down to your skill set and preference. If you're familiar with GraphQL and enjoy it, you might prefer to use Gatsby. You can use GQL to fetch your Markdown files. If you're not as familiar with GQL, then it could be seen as a barrier to entry.
The biggest advantage Gatsby has over Next.js is its plugin system. For example, you're a simple config change away from an RSS feed -> https://www.gatsbyjs.org/packages/gatsby-plugin-feed/
The biggest advantage Next.js has over Gatsby is that it's a hybrid React framework. You can mix SSG and SSR together in the same application. This could be very beneficial if you want your main marketing site, SaaS app, and documentation to all live in the same project.
A great example of MDX (Markdown) + Next.js for production docs would be the StaticKit site -> https://github.com/unstacked/statickit-site
I built my personal website with nothing but Express and JS template strings: https://github.com/brundonsmith/website. It's so simple to do that I almost question the necessity of "static site generators" in general (Next.js of course does much more than static site generation).
Interesting approach, how every page is a JS file that builds the HTML page as a string; structurally it looks almost the same as how React/Next.js do it.
With that setup, I imagine it's fairly trivial to add a "static site generator":
- Run the local server that serves the rendered pages.
- Run a Node.js process that will take a given array of all page routes; make HTTP requests to those local URLs; and save the rendered HTML into folders, for a complete static site.
With that setup, I imagine it's fairly trivial to add a "static site generator":
- Run the local server that serves the rendered pages.
- Run a Node.js process that will take a given array of all page routes; make HTTP requests to those local URLs; and save the rendered HTML into folders, for a complete static site.
Yep, that's what it already does :) And a neat property is that I could freely move different render functions between static, request-time, and client-side if I wanted to.
People tend to think of React rendering and the like as this special, mysterious process. But the only special thing about it is the way it efficiently reconciles and updates an existing DOM to match a new DOM. That initial render is really no different from PHP. Static site generators are just PHP with a prewarmed cache.
People tend to think of React rendering and the like as this special, mysterious process. But the only special thing about it is the way it efficiently reconciles and updates an existing DOM to match a new DOM. That initial render is really no different from PHP. Static site generators are just PHP with a prewarmed cache.
Ah, I didn't dig deep enough to see that it already does what I described, heheh. So it's a static site generator as well as a server that dynamically renders. I like the sound of being able to "partially compile", having the choice to leave some routes rendered at request-time or client-side.
I heard the analogy (equivalence?) before, that statically rendered sites are caches that are invalidated at build time.
Makes sense, and thinking of it as a strategy that can be partially applied - rather than as an all-encompassing framework or tool - is insightful, so it can be mixed and matched with dynamic rendering as needed.
I heard the analogy (equivalence?) before, that statically rendered sites are caches that are invalidated at build time.
Makes sense, and thinking of it as a strategy that can be partially applied - rather than as an all-encompassing framework or tool - is insightful, so it can be mixed and matched with dynamic rendering as needed.
What you described here is basically how Next.js works :)
The blog post mentions the 3 APIs that make this possible:
- getStaticProps (Static Generation): Fetch data at build-time.
- getStaticPaths (Static Generation): Specify dynamic routes to prerender based on data.
- getServerSideProps (Server-Side Rendering): Fetch data on each request.
The blog post mentions the 3 APIs that make this possible:
- getStaticProps (Static Generation): Fetch data at build-time.
- getStaticPaths (Static Generation): Specify dynamic routes to prerender based on data.
- getServerSideProps (Server-Side Rendering): Fetch data on each request.
> I could freely move different render functions between static, request-time, and client-side if I wanted to
You can do the same thing with Next.js, and you can move between client-side and static with Gatsby
> But the only special thing
I think there might be more to unpack here, but when using react being able to typecheck and lint my jsx is pretty sweet. React also makes it much harder to create cross site scripting vulnerabilities.
You can do the same thing with Next.js, and you can move between client-side and static with Gatsby
> But the only special thing
I think there might be more to unpack here, but when using react being able to typecheck and lint my jsx is pretty sweet. React also makes it much harder to create cross site scripting vulnerabilities.
I've used Eleventy which was pretty solid. I'm curious about Next.js though since it seems like it does almost everything out of the box that I want.
I'm unsure if can prerender non HTML content though which is interesting.
I'm unsure if can prerender non HTML content though which is interesting.
I personally find Next easier to use than Gatsby, but I don't think I could really make a strong technical argument for choosing Next. It might just be familiarity and personal preference at this point. I think it might be easier to use Next for mixed static and SSR sites than it is with Gatsby?
And I think at the time I tried Gatsby I wasn't as familiar with GraphQL as I am now.
And I think at the time I tried Gatsby I wasn't as familiar with GraphQL as I am now.
I’m using Docusaurus V2 on https://supabase.io and couldn’t be happier. It’s still early in its development but has everything that you need from a React SSG
Gatsby is widely used for documentation sites (check out sites on the showcase https://www.gatsbyjs.org/showcase/?filters%5B0%5D=Documentat...).
Typescript is rebuilding their docs on Gatsby right now and wrote up their reasoning behind the choice here: https://www.gatsbyjs.org/blog/2020-01-23-why-typescript-chos...
Typescript is rebuilding their docs on Gatsby right now and wrote up their reasoning behind the choice here: https://www.gatsbyjs.org/blog/2020-01-23-why-typescript-chos...
[deleted]
I once read that Next is much closer to regular React than Gatsby, which brings in many concepts of its own.
Looks awesome congrats to the team. I'm hoping preview mode will also work with Contentful.
I love Next.js! I used it for building a personal finance tracking tool: https://github.com/nviennot/easy-finance
The new `getServerSideProps` function addresses my biggest pain point with Next.js. I found it super awkward that if you wanted to make a website with data from a database, you basically needed two webservers: one to access the database and expose it over the web via a raw format like JSON, and then a Next.js-powered one to take that JSON and make it into HTML. For a lot of projects that separation can be nice, but for small sites or prototypes it's too much effort. Now I can easily have the Next.js server access the database directly.
Nuxt.js solved this with asyncData ages ago
Love the team behind it and their outlook on engineering and design. Look forward to using 9.3 and view getStaticProps as a major step forward.
Nice, with SSG support Next becomes basically Gatsby on drugs.
Next.js do is more favorable if you don't want to be locked-in.
That's important to overcome the fatigue learning all the buzzwords
That's important to overcome the fatigue learning all the buzzwords
Nuxt.js has had "SSG" for a long time
I’ve been interviewing and encountered my first company using that and was my first exposure to it.
Very fascinating project!
Very fascinating project!
I work on TinaCMS, a toolkit for building content management into your website, and we just implemented an open-authoring system on our own docs. People can contribute to our docs without ever leaving the website. You just click "Edit this post" and it will create a fork and enter inline-editing mode. Any changes are committed back to your fork and then you can open a PR from there.
https://tinacms.org/blog/introducing-visual-open-authoring