It can be, but I’m not running a server in production: I’m using the static site generation feature in Next (comparable to Jekyll or Gatsby). It takes an input (Markdown in my case) and spits out a bunch of HTML files that are later deployed on a CDN. No server-side runtime required.
It's primarily used with a server, correct. However, you can use `next export` which will generate only static assets (like HTML, JS, and CSS). Certain features aren't available that require a server (like i18n routing) but you can still do a lot!
You could just create a static HTML site yes, but getting it generated for you from Markdown files is super handy. To generate it on the fly it needs to be powered by some kind of server (e.g. Node, PHP, Python etc). Nodejs was just a good choice of platform for this kind of thing.
how that would work for static websites? let’s say I generate website from markdown files, and server (let’s say hosted on Amazon S3) does not support any backend languages. so how your suggestion would work?
> you don't need any sort of server-side build process
OP is already using a server-side build process to generate the static site. Inserting the HTML at the same time they built the site would add very little extra code to their build process, and nothing to their static hosting requirements.
If nothing else, would OP consider inserting a <noscript> tag in each generated index.html that linked to the raw Markdown in their Github repo?
You won’t need to really run server all the time, you can run locally and use it as a lightweight CMS, and run only when you need to edit and generating anything. You can choose to only upload the generated HTML files to GitHub.
See my explanation on my reply to the original post.
I wonder if this approach could be used for more "static" sites as well? This sounds great for JavaScript-heavy web apps, but what if there's server-side HTML generation involved?
It is. But you can't really run an HTML file locally without at least setting up some type of server (if you plan to make requests). And I know setting up a server is extremely easy, but it's almost impossible for someone who hasn't programmed before.
He wrote "can be generated". You can use KaTeX for setting up complete static web pages with no JS/server-side prozessing at all. Example from my blog:
Sorry, what I meant about serving HTML from the server was the construction of HTML documents using server-side code. There will always be static pages served with apache or whatnot :)
I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown.
It was great. Until the webhost took away PHP anyway.
Being able to deploy a bunch of HTML files to static hosting services, no runtime like PHP etc. required.
If you use a CMS, it has to run somewhere. If you don’t want it on a server, you probably don’t have the same config on your dev machine. Most CMS require you to configure root domain paths etc. and they are different on your local machine. It’s all a lot more complicated than using an SSG to transpile a bunch of markdown files to HTML on a dev machine and upload them.
Exactly my thoughts, why not generate HTML in the server dynamically and send it across? I’m pretty sure such similar things are being done since the 90s.
The idea is that having it server-side allows for the page to be cached by a CDN (e.g. CloudFlare), so you end up serving static HTML, with better performance and SEO than JS-compiled markdown.
I guess I don't see a reason not to generate it on the server. I have a section of my website with some essays, for example, which are formatted from Markdown source plus a bit of HTML templating. The essays don't frequently change, and neither does the template. Why would I want to regenerate the page on the client side every time someone reads it instead of just generating it once and serving up static HTML?
reply