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.
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.
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'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 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.
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.
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.
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 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.
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.
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
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.
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