
Get Static - EamonnMR
https://meyerweb.com/eric/thoughts/2020/03/22/get-static/
======
Jaruzel
Static site generator for non-technical people:

    
    
      1. Write your article in Microsoft Word.
      2. Save as 'Web Page, Filtered'
      3. Upload/Place in html folder on Webserver.
    

Almost everyone has access to a copy of Word, if not I _think_ LibreOffice has
a html save function also.

This solution is 100% wrong for us technical people, but for non-techies who
just want to _get the information out there_ it's a really good option imho.

~~~
Animats
Also available, Blue Griffon, which is an open-source successor to
Dreamweaver. It offers templates and CSS, and what's uploaded is a totally
static page unless you stick in something dynamic like a form.

~~~
petepete
Wow, I didn't realise Nvu had been resurrected. This looks great for basic
publishing.

[https://en.m.wikipedia.org/wiki/Nvu](https://en.m.wikipedia.org/wiki/Nvu)

------
Rauchg
As pointed out in the article, not only do you avoid 502 Bad Gateway, but
rolling static sites is also trivially downtime-free, meaning no 503s
either[1]

[1] [https://rauchg.com/2020/2019-in-
review#s1](https://rauchg.com/2020/2019-in-review#s1)

~~~
prox
I wonder if you can create a fallback easily instead of serving 503 , you get
a static fallback version.

------
bbx
It all comes down to:

    
    
      1. If two users access the same page, do they see the same content?  
      2. How often do you update the content of the website?
    

The reason to ask yourself 1) is to know if the content has to be generated
_on the fly_. If it's a blog post or a hospital "about" page, then the content
is the same for everyone. There is definitely no need to fetch it from the
database on every page load. Like Eric says, "get it down to static HTML and
CSS".

Cases where the content is dynamic are social networks (FB, Twitter), search
engines (Google, any ecommerce search feature), and any logged in content
(cart, likes, friends…). For the latter, I've seen cases where the logged in
content is only fetched via JS after the initial page load. This hybrid
solution probably saves a lot of bandwidth.

The reason to ask yourself 2) is to know how long, as a content creator, you
are willing to wait between updates. I can imagine that updates to a blog post
or a hospital "about" page are allowed to take several minutes. In that case,
static websites are favourable.

I guess the waiting time is correlated with the amount of updates: the higher
the amount of updates, the shorter the waiting time you would want.

The reason why CMSs like WordPress are still popular is because of their ease
of use. I've had several clients ask me specifically for a WP solution. I
guess the issue is that it's hard to detach the dynamically-created content
from a dynamically-served website. There are cache plugins, but I'm still
looking for a custom solution where WP is only used as a non-public CMS, that
then, at a push of a button, gets generated into a static website (or even a
Gatsby one).

~~~
joppy
There is a lot of room between “generate everything from the database on page
load” and “fully static site”. We could expect many people editing crucial
sites at this time are not so technically literate, under time and other
pressure, and do not have the spare time to learn something completely new
such as authoring a static site.

Given those criteria, I think a better solution to these problems would be
some sort of caching layer, either built in to the CMS or perhaps a different
server acting as a reverse proxy.

------
codr7
I've been working on an restaurant order system for a client lately.

Instead of doing the obvious thing and build a database connected web
application hosted in the cloud; I opted for a local application that
generates static files for customer ordering, uploads them to a web server and
polls for orders. On the server there's a simple PHP script that writes a
chunk of JSON to a file when the order is created.

The main motivation was to allow them to continue taking orders in the
restaurant and perform maintenance even if the internet connection isn't
working. Generating files also simplifies the implementation of customer
specific customizations.

And since the database isn't customer/web facing any more and therefore
doesn't need to scale beyond a couple of simultaneous users, I opted for a
simple file based solution.

The fact that the customer order part runs blazing fast is a nice bonus.

~~~
076ae80a-3c97-4
I've done this before too and it works well for a good while. The issues start
coming when the number of files increases to a volume where the hosting
machine becomes slow. Having millions of tiny files takes its toll on even the
best file system. However this can be mitigated by perodically archiving
files. Just something to watch out for.

~~~
codr7
Yep, at some point, given that the system is successful, you will have to
tackle archiving.

Still a lot nicer than paying for complexity you don't need before the system
has even proved useful.

------
bauerd
Put a caching reverse proxy in front of dynamic content, like Varnish. That
way the technically less inclined can keep using traditional UIs. Keep in mind
most people don't even grok the static/dynamic distinction, they just want to
publish content

~~~
guu
Yes, with a properly configured CDN you can continue serving information even
when the application server is overloaded or down.

I would suggest this route for organizations that are already using dynamic
solutions like Wordpress.

------
eyelidlessness
This appears to be well-meaning (which is to say it's not the usual
tautological whinging tech hate for dynamic sites, it appears to come from a
place of concern for delivering important information in a crisis). But it's
also quite a lot to ask _in a crisis_. Stuff like this should set off alarms:

> I can’t tell you how best to get static—only you can figure that out.

Okay. Is this helping? I guarantee anyone responsible for uptime of critical
services is pretty overwhelmed right now, and not going to be immediately
receptive to calls to make huge, abrupt architectural changes without any
guidance.

Edit: this is how it should be done[1] (HN thread[2])

[1]: [https://mxb.dev/blog/emergency-website-
kit/](https://mxb.dev/blog/emergency-website-kit/) [2]:
[https://news.ycombinator.com/item?id=22657571](https://news.ycombinator.com/item?id=22657571)

------
newscracker
This is good advice, and is meant for service based sites that are now more
important than ever. But I’m not sure how many service providers can even
afford to spend time and money on such things and risk more failures in this
process than the current timeouts or other issues. The largest companies
would’ve already optimized these (to a great extent) long before this
pandemic.

One can only hope that in the coming months, websites focus on reducing their
bloat and catering to audiences with restricted bandwidth (if streaming
services are already doing their bit to reduce traffic, so should others).

For truly static websites, the ones without a lot of dynamic or frequently
changing content, what good CMSes exist that can easily adapt to or be used
with SSGs (for self-hosting, not using Netlify or some other site)?

~~~
emptysea
I haven't used it personally but I've heard good things:
[https://www.getlektor.com](https://www.getlektor.com)

Generates static files while also providing an interface for edits.

~~~
bathtub365
Are you suggesting that mission critical sites rewrite in a tech stack that
you haven’t used? That seems misguided

------
mceachen
In case you're in the situation where you're considering moving your site from
a CMS to something static, I did this with PhotoStructure's public site in
December, switching from ghost to hugo. It's fantastic to be able to prop up a
new site in seconds with an rsync command, and revert to prior versions with
filesystem snapshots or standard backup software.

------
dgellow
Something I found during the weekend, if you have PowerShell available (so any
Windows machine, or any macOS with brew installed, or linux if you're willing
to add a pkg source from microsoft):

1\. Take a Markdown document

2\. In PowerShell: ConvertTo-Html -Body (ConvertFrom-Markdown -Path
.\README.md).Html -CssUri "stylesheet.css"

That results in a complete and valid HMTL document that can be published
anywhere with its assets.

ConvertTo-Html: [https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.utility/convertto-
html?view=powershell-7)

ConvertFrom-Markdown: [https://docs.microsoft.com/en-
us/powershell/module/microsoft...](https://docs.microsoft.com/en-
us/powershell/module/microsoft.powershell.utility/convertfrom-
markdown?view=powershell-7)

------
afandian
I use Hugo for a few things. I'd mostly recommend it.

But in the worst case it can take minutes and hundreds of megabytes to update
my blog to S3, even for a simple text change.

Not amenable for quick updates, or updates in the field.

You can add layers of tools to improve it, of course. But then you're back to
it not being much different to wordpress + CDN.

~~~
eddieroger
Updates in the field should be a solved problem with a CI/CD pipeline that is
actually doing the work. I use Hugo to generate a few small blogs, but don't
do any of the generation locally, nor uploading. Quick updates don't feel like
much of a pain in these cases (update the file, commit, push), but agreed that
on a big site it will be a bigger update.

~~~
afandian
I do this too for some sites. But it's what I mean by adding extra tooling.
You can do that, but it creeps closer toward something more Wordpress + CDN
like.

~~~
eddieroger
Oh, I agree. I still prefer it for the relative smallness compared to needing
a DB and such, but I am with you that it is creeping bigger.

------
ChrisMarshallNY
Static isn’t a panacea, but it can help.

I have written sites using CMSes that load lickety-split. The trick is to use
simple, “bald,” basic themes, very few plugins, no JS libraries, and hand-
write your own CSS.

Depends on what the site does, and, most importantly, where the content
originates.

That said, Eric Meyer rocks, and it’s always a good idea to listen to him.

~~~
hilti
Totally agree - the bottleneck are bloated themes. Just started to use
Framework7 for a new site ... I like it's compact design and great features to
design mobile sites.

------
cercatrova
I like React's paradigm of declarative programming, and I like that it has
static site generators like Gatsby, react-static and Next.js. React is
interesting because it combines both a programming paradigm with the method of
delivery, so it's nice that one can decouple that from the other.

------
l0b0
I can't count the number of times when download + rendering time has been the
difference between a useful and a useless response to a "do I still have
time?" query. Imagine being in that situation in an emergency.

------
paganel
I was really wondering if any of the FAANGs reached out to help websites like
[https://www.worldometers.info/coronavirus/](https://www.worldometers.info/coronavirus/),
which while not that fancy cannot really be static 100%, as they update the
virus numbers almost by the minute. They used to have some DB connections
problems a couple of days ago and I think I also saw some 503 responses, but
thankfully things have stabilised for them since then.

~~~
raziel2p
Cronjob that re-generates the static HTML every 1 minute would work just fine
for a use-case like this.

~~~
theshrike79
Isn't that how 4chan works? They just generate static HTML every time
something changes.

It works because the read/write -ratio is so heavily skewed towards reads.

------
SkyMarshal
Extensive list of stating site generators here:
[https://www.staticgen.com/](https://www.staticgen.com/)

------
z3t4
A static site generator gives you many of the advantages from a "CMS" on-the-
fly rendering, while also giving you all the advantages from static hosting.

------
juliend2
If using PHP the way it was initially meant to be used (i.e. includes,
variables, and helper functions where it makes sense, etc.), then it doesn't
need to be 100% static in the way the author is suggesting, to be orders of
magnitude more efficient than a full-fledged WordPress site.

------
acje
[https://jamstack.org/](https://jamstack.org/) "Fast and secure sites and apps
delivered by pre-rendering files and serving them directly from a CDN,
removing the requirement to manage or run web servers."

------
greatjack613
Such a true point.

It amazes me why every site seems to need the latest and greatest framework
just to tell me a paragraph of text.

We have to stop teaching junior devs react and start teaching them more static
site generators.

I personally use hugo and love it.

~~~
nojvek
Nothing wrong with React. React has built in server rendering. With frameworks
like Gatsby that render to static assets and netlify for deployment, this
becomes radically easy.

I’ve seen plenty of new devs take this approach.

------
gridlockd
A lot of the time, you use a CMS so that non-technical people can _manage
content_. I'm also not aware of any static site generator that doesn't
completely fail in this regard.

You can turn some CMS content into static content, but it's pretty limited.
Even something as simple as a contact form is going to fail.

------
SvenAl
Static is not the way to go. There are technologies today which can scale fast
without crashing. You don’t need static sites to handle the load. Checkout a
serverless CMS like Webiny - [https://www.webiny.com](https://www.webiny.com)

------
iddan
Made that choice for the K Health’s Corona updates web application

------
brian_herman__
This guy has a bunch of javascript and PHP running his site its not static
what a hypocrite.

------
AgentOrange1234
Really? People are hunkering down in their homes and have lots of time on
their hands. If a web site is overloaded, they can try again later. Annoying,
sure. Life or death? I am skeptical.

Moreover, “getting static” is nice and a fine way to improve performance, but
it seems to me that really the goal should be, “be available.” What’s wrong
with using a CMS or anything else as long as you have the capacity to meet
demand?

~~~
divan
I feel like few people even know about static site generators, and use general
purpose solutions what anything that includes word "site" in it, whether it's
dynamic social portal or single page static content.

Like, from the practical perspective, if you have a blog with content that is
requested 1000 times per minute, but updates once per month (23 microtimes per
minute), why on earth would you setup a database (with geo-redundant replica,
of course) and run overly complex code to render the same HTML over and over
every single time it's requested? The only possible answer here is being
oblivious of other available options, and I believe author of the post is
trying to raise awareness that there is another option.

~~~
ricardobeat
Most websites are more dynamic than they look. Anything with frequent updates
(news for example), user accounts, any kind of personalization / geo-based
content, or running A/B testing will demand dynamic rendering.

That's not an excuse for terrible performance either way. At this point it's
trivial to handle hundreds (or thousands) of req/s on common hardware if you
just choose the right software to run.

~~~
PKop
even then it's only a question of how long can "stale" data be served, or is
the dynamic-ness worth it?

You can you lamba/cloud functions as webhooks for your CMS to ping when a
rebuild of the static site is necessary. Netlify helps you set this up easily.

Even if you updated a dozen times a day, it would take only a few minutes or
less to rebuild and deploy.

edit: yes per-user data is a primary use case for dynamically rendered sites.

But public pages that all users load make sense as static if possible

~~~
ricardobeat
Not dozens, think millions/billions of combinations for dynamic content. You
cannot pre-render all the possibilities.

------
jkoudys
This advice is a bit misguided:

> get it down to static HTML and CSS and maybe a tiny bit of enhancing JS, and
> pare away every byte you can.

HTML is a language used for building your DOM. CSS is a language used for
styling. JavaScript is also a language that can do those things, and focusing
on the language used isn't going to help.

If the goal is to save space and power you can do it much better with JS. A
lot of server side rendering, html caches, and static content is focused on
good SEO and low latency, not small download size and power consumption.

You can fit a much smaller download into a stripped-down Gatsby site if you
have a nontrivial amount of content. It also makes things like serving only
much smaller versions of any images way easier. You can go even smaller with
vanilla JS if you want.

~~~
dreamcompiler
Specifying content, styling, and layout are what HTML and CSS were designed to
do, and they do it quite well. Throwing the bigger hammer of Javascript at
this problem means anybody who likes to browse without Javascript (which is
quite a few of us in this era of abusive ads and malware) is not going to see
your site properly. It also means you've opened the door for some future
maintainer to introduce a multi-megabyte Javascript library 98% of which isn't
actually needed, and which will _very much_ consume a lot more power on the
client's platform than HTML and CSS.

Never use a Turing-complete language to solve a problem that's already well-
solved with a non-Turing-complete language. Especially when that non-Turing-
complete language is _already present_ on the client's machine. Most
especially when you're talking about static sites for essential public
information.

