Next.js 9.3 – Static Site Support, 32 KB Smaller Runtime
nextjs.org
nextjs.org
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.
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!
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
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.
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.
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.
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.
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'm unsure if can prerender non HTML content though which is interesting.
And I think at the time I tried Gatsby I wasn't as familiar with GraphQL as I am now.
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...
That's important to overcome the fatigue learning all the buzzwords
Very fascinating project!