
Static web – back to the roots? - arthurjj
https://blog.callr.tech/static-web-roots/
======
neya
I'm at present working with a client who is on Wordpress. It's a huge company
with 100s of employees in just one of their locations and they don't actually
have dedicated manpower to maintain their homepage. This is where I got in.

Once I audited their site, I found a ton of issues, particularly - their stale
Wordpress version, themes and plugins. I updated them all one by one and
migrated them to Wordpress.com which doesn't suffer this upgrading pain.

Then, I found out the theme provider had actually stopped supporting the theme
and there were a bunch of security flaws in it. But, the client wanted
something like push and forget.

So, I painstakingly migrated them off of Wordpress and made a custom Jekyll
site with Jekyll admin running on Netlify. They're immensely happy now knowing
that their site is virtually unhackable (it's just a static site).

Static site builders are more powerful than we think. I have a travel platform
running on it right now actually and none of the end users know its a static
site they're on top of. There's no plugins to manage, no software versions or
security loopholes to keep track of. The only way someone can hack into your
site if they hacked your identity provider (Eg. Netlify). Otherwise, it's
simply just a boon.

~~~
HatchedLake721
What about keeping Wordpress under the hood to manage and update the pages,
but then generate static pages off that?

~~~
cmdr2
I tried this last year for a Wordpress blog with ~1000 articles, and the time
to generate the static pages was too long (several minutes) even for routine
tasks like adding a new article. Simple things like a "New Articles" list in
the sidebar can cause all pages to regenerate. I tried many different
approaches (recursive wget, wordpress plugins, intercept wordpress output in
PHP with ob_start() etc).

Ultimately, putting a Varnish cache seemed like the only logical answer to
speed things a bit more, but that didn't avoid Wordpress security attacks.

For fun though, I built an experimental wordpress-clone dashboard that saved
Hugo-compatible files instead, so I wouldn't miss Wordpress' editing features.
The result was superb (<5 seconds to regenerate the ~1000 articles blog), but
I missed the Wordpress plugins too much to switch to Hugo entirely.

But I still agree with you: "keep wordpress' editing experience, but generate
static sites" is a pretty promising direction IMO.

~~~
ScottFree
> I missed the Wordpress plugins too much to switch to Hugo entirely.

Do you mind if I ask which plugins?

Also, if you're missing plugins, it sounds like keeping the wordpress editing
experience alone isn't going to be enough. The question then becomes, are you
missing plugins themselves or what those specific plugins do for you that
doesn't appear to be available in hugo.

~~~
yurishimo
As someone who does a lot of WP at their day job and has looked into other
platforms, plugins like Gravity Forms are indispensable. It is nearly feature
complete at this point and I have full access to the underlying code for any
customizations in logic or design.

Some hosted form solutions offer features like basic e-commerce which is
useful, but then doing something after a submission is almost impossible or
everything is in an iframe so customization is limited.

If someone could port gravity forms to Craft, I would likely switch all new
projects before the end of this year.

------
dmje
It's an interesting piece, and lots of good reasons to "go static".

But. They're _developer_ reasons.

What almost everyone who piles into this support of static stuff seems to
completely ignore is the _audience_ here.

Who do you think is editing your website? Amy the developer who has no problem
committing stuff to Git or learning Markdown or Dave, who is a marketing
manager and spends most of his life in Word writing press releases and social
media posts?

The entire point of a WYSIWYG editor is that it doesn't require any developer
experience.

If you genuinely think a corporate website can be run out of a Git workflow or
a requirement to learn Markdown, you're basically in the wrong room. This is
the whole "IT bottleneck" that content teams have been battling for years:
it's back to the early 90's days of "yeh, we want to update our homepage but
we need IT to do it for us".

Somewhere in the middle is the holy grail: performant sites that are also
editor friendly.

~~~
eitland
I keep coming back to this: we keep underestimating our coworkers, users,
bosses etc.

Even as an engineer people keep on underestimating me (although sometimes they
overestimate me : ). Here are some examples:

\- telling accounting a number of times that they've forgotten a rather large
PO.

\- telling a network vendor they have a huge hole in their firewall only to be
ignored until I contacted one of their huge customers which I also knew. They
could have saved themselves a good deal of embarassing attention I guess.

\- etc etc

Last year at JavaZone theee was an interesting talk by someone who was an
early employee at a crowd funding company. He was a non-dev but talked about
how he enjoyed being able to update copy in the web app (not just front page
IIRC) directly after the devs had set up git, an editor and explained the
basics.

If you are making the next google you'll want things to be extremely easy-to-
use.

Making a google.com level UX for business apps might be smart. Or it might be
insulting.

~~~
savolai
I've tried Gatsby on a couple of occasions due to the page load speed promise.
With netlify it seemed like using it almost made sense.

I do see the compromises wp puts us into but for me, the benefits of static
seem awfully abstract at the end of the day. If you want me to buy it, please
show me an authoring experience I actually want to live in. I haven't seen one
yet.

It's not about over- our underestimating people. It's about whether the
technocentricity you are selling is worth it. For some of us, it is, sure.

For one, I just hate writing with markdown. Compared to WYSIWYG (i.e. just
writing), markdown's syntax is a distraction. Writing is both visual and
storytelling to me, why should I exclude the visual to a separate stage of the
process? Just doesn't make sense to me.

~~~
Beldin
_the benefits of static seem awfully abstract at the end of the day. If you
want me to buy it, please show me an authoring experience I actually want to
live in._

Authoring is about input to the system, static is about how the contents is
given to the visitor. There is no technical reason a rich author experience
cannot be coupled with a static approach to content delivery.

In fact, the article focuses mostly on page bloat, not so much server-side
processing. The amount of bytes a Web page weighs in at should mostly depends
on its contents, not on the author tools used to create its content.

~~~
savolai
If these are separate to you:

How would you allow a user, while creating a blog post, to add commenting to
the post in a way that enables progressive enhancement i.e. doesn't require
javascript, with static site generators?

If you can't, what is your justification for the sacrifice in accessibility?

If you can fulfill this basic requirement, please show me the experience of
using the system and show me how it is better than wp _as a whole_.

~~~
chriswarbo
I'd probably put the comments and submission form in an iframe; possibly from
a third-party.

~~~
savolai
An iframe is a possibility; the fixed box size is an user experience tradeoff.
I really believe in the vision of a read-write web, i.e. for me the default
should be all involved parties being able to comment on any given content.

Of course this should be possible to turn off for certain content and
moderated, but it still seems artificial to not have the discussion on the
same page, compared to the original post. HN is beautiful, for instance. :)

------
lazyjones
There is a misconception in the article: static websites aren't guaranteed to
be small and dynamic websites aren't necessarily big (in size of assets / load
times).

Most of the bulk in modern websites comes from JavaScript (frameworks,
tracking, ads), images, videos. All these can and are used both with static
and dynamic websites.

Static websites may be mostly hassle-free for developers/devops, but they're
typically more of a hassle for content producers. I don't see a convincing
case for them overall, because one of their bigger advantages - that they are
easier to cache (or rather: to keep cacheable when developers add stuff)
upstream than dynamic websites - is mostly gone from the web infrastructure.

~~~
icebraining
I don't see why they would be more of a hassle. Why would they even care if
the HTML is being rendered on demand or pre-rendered and stored?

Regarding cache, I don't agree - having your site cached by the edge nodes of
a CDN is quite important nowadays.

~~~
lazyjones
> _Regarding cache, I don 't agree - having your site cached by the edge nodes
> of a CDN is quite important nowadays._

How many of the Alexa top 10K or so have cacheable HTML content (not JS, CSS,
images, video) in CDN? Can you provide a few examples?

------
JeanMarcS
There was an article yesterday on a french tech web site about a member of
parliament asking if there was a way to encourage developers to make less
bloated softwares for ecological reasons (less power consumption).

The text was around 5.5ko on a page weighting around 3mo...

Edit : link to the post (in French) [https://www.numerama.com/tech/518848-un-
depute-souhaite-que-...](https://www.numerama.com/tech/518848-un-depute-
souhaite-que-les-developpeurs-codent-mieux-au-nom-de-lenvironnement.html)

Edit 2 : replaced encline with encourage

~~~
eguanlao
What does "encline" mean?

~~~
JeanMarcS
Strictly nothing in this sentence so I replaced it with encourage. Thanks !

(For the record, the word I wanted to use was incite. I don’t know why it pops
out that way)

------
jjjbokma
I currently have a static microblog, which is open source [1]. It's generated
from a single mark down file with some custom stuff to separate articles. I've
been using it for two months and so far I have been able to blog daily [2].

[1] [https://github.com/john-bokma/tumblelog](https://github.com/john-
bokma/tumblelog) [2] [http://plurrrr.com/](http://plurrrr.com/)

~~~
jandearbeider
I tested it and even I am not a fan of mark down I am amazed fast speed,simply
customizing colors, nice templates and git pull I replaced Wordpress for this
system.. \- for the SEO part looks like it beats Wordpress -JSON is in there
also Great job....used on
[http://www.werken.nu/blog](http://www.werken.nu/blog)

------
bArray
My current static setup consists of:

* Nginx [1] - Serve the content with some settings, such as compression and HTTPS.

* Pandoc [2] - Builds the HTML pages and throws a header and footer in there, as well as a comments section [3].

* Bash script [4] - Runs in a screen session, polls git for changes, pulls and rebuilds the content, then builds RSS feeds.

Whilst this works for me, I could see how WordPress could be desirable. Some
online editor, ability to add "plug-ins" (i.e. some bits somebody else coded),
tracking, comments, etc. I think there is space for some static page
generation system/script that adds a light weight editor and the ability to
add other people's scripts.

[1] [https://www.nginx.com/](https://www.nginx.com/)

[2] [https://pandoc.org/](https://pandoc.org/)

[3] [https://github.com/danielbarry/free-
comment](https://github.com/danielbarry/free-comment)

[4] [http://coffeespace.org.uk/projects/site-
creation-v2.html](http://coffeespace.org.uk/projects/site-creation-v2.html) &
[http://coffeespace.org.uk/projects/rss-
feed.html](http://coffeespace.org.uk/projects/rss-feed.html)

~~~
52-6F-62
I do something close to the same, except each MD post is generated on request
so I can update easily if needed. Probably not suitable for anything of
demand, but my site isn’t!

I wrote a slapdash server in Go, stuck it behind Nginx, and can just add posts
ad-hoc. Only requirement is I have to restart the server to rebuild the list
of available posts in memory. After that posts can be edited at will. Post
metadata comes from a four line header.

Deployment is pretty manual. Just store everything in a repo, pull changes in
on the serving machine and run the Go server in TMUX.

No comments or anything, though. And I rarely write anything.

It was mainly an exercise for learning some Go. That may even change yet.

No repos to share yet as it’s not presentable but will gladly do the work to
share in a gist if anyone’s curious.

~~~
bArray
> each MD post is generated on request so I can update easily

> if needed.

You mean each client socket? If so that would be awfully slow for high volume
traffic.

> Only requirement is I have to restart the server to

> rebuild the list of available posts in memory.

This seems quite undesirable too, where does this requirement come from?

> pull changes in on the serving machine

Is this manually pulling or do you fetch in a loop?

> will gladly do the work to share in a gist if anyone’s

> curious.

I'm certainly curious now to see exactly how this Go program works.

~~~
52-6F-62
Haha oh man, I was speaking to you from a few versions ago and didn't realize
it. I've been so caught up in other projects that I've forgotten some of the
changes I've made.

They don't make a ton of difference, but deployments were slightly smoother
than I mentioned.

I didn't include directory structure or any views, but I'm sure they can be
derived—I wanted it simple. I also used Spectre CSS + overrides for the front
so any inline HTML can be assumed to be using classes related to that for any
styled elements. There is a couple elements hard-coded into the server itself
for the home page.

Definitely not an effort in best practices! But have at it, and happy to hear
if you have any input if you're more versed in Go (probable):

[https://gist.github.com/robertfairley/f061df3a6a2fe15d429f82...](https://gist.github.com/robertfairley/f061df3a6a2fe15d429f824a5c38d089)

edit: Also—SSL is handled by Nginx. And god help us all if anybody uses this
file as a model for any business web server

~~~
bArray
If it works then it's not silly! Thanks for sharing :)

If I understand it correctly, you build locally and then upload to the server?
I have this setup for a few webservers that I have limited control over, so
just FTP/POST documents to upload content.

When I have proper control over the server, I much prefer to have the server
build the documents. The benefit is that I can simply write a new blog or
something from my mobile whilst in a meeting, commit and the server auto-
generates the new content. I just need a web browser, GitLab, GitHub and
BitBucket all support some form of basic editor for markdown.

Interesting take anyway. My feeling is that I want to do more experimentation
on my server and build more "rough and ready" web projects, with the knowledge
they will probably fall over more easily and have security flaws. The service
goign down is one thing, the entire server being compromised is quite another.
I think this points towards introducing some container system. I'll have to
learn me some docker.

~~~
52-6F-62
Yeah you pretty much summed up what I was doing. Fun to learn a new language,
make something work to some low expectation I had. And it did/does.

I'll probably try and rewrite in another language again soon. The former
version that looked the same was done in Django—but I wanted less overhead.

But yeah, I build locally via that script, but upload all relevant files via
`deploy.sh`.

For "rough and ready" projects, I've enjoyed playing with ipkn/crow—I wish it
was still maintained.
[https://github.com/ipkn/crow](https://github.com/ipkn/crow)

And yeah, your take has been similar to mine. I'm okay with it goes down. But
the Django system I ran before I was more susceptible to someone breaking in.
This one is pretty well untouchable—which is reassuring.

I can safely as rarely look at or update it as necessary without worry—and I
appreciate the opportunity to be humbled if I'm wrong!

Also yeah—my current setup would also be made smoother by docker, I was _way_
too lazy to dig into it as I don't use it often.

------
infominer
For static site generators:

[https://github.com/pinceladasdaweb/Static-Site-
Generators](https://github.com/pinceladasdaweb/Static-Site-Generators)

[https://staticsitegenerators.net/](https://staticsitegenerators.net/)

I keep all my resources for working with GitHub Pages, here:

[https://infominer.id/web-work/github-pages-starter-
pack/](https://infominer.id/web-work/github-pages-starter-pack/)

and am most familiar with GitHub facilitated Jekyll:

[https://github.com/planetjekyll/awesome-
jekyll](https://github.com/planetjekyll/awesome-jekyll)

MkDocs makes really nice pages that don't require fussing around with
frontmatter, with auto generated navigation based on directory structure.

It also opens your publishing toolkit to python's universe of markdown related
extensions, which you may already be familiar with.

[https://www.mkdocs.org/](https://www.mkdocs.org/)

------
kragen
I think this is a reasonable thing to do. For Dercuano, I hacked together a
basic static site generator in Python 2 in a weekend (70% of the current
static site generator code dates from the first three days, according to git
blame); I've spent more time hacking on the CSS than on the Python, and
immensely more time writing the text than either.

In case it's useful to someone else, as inspiration if nothing else, it's at
[https://gitlab.com/kragen/dercuano](https://gitlab.com/kragen/dercuano), in
the public domain. The latest version of the output is at
[http://canonical.org/~kragen/dercuano-20190525.tar.gz](http://canonical.org/~kragen/dercuano-20190525.tar.gz).

~~~
jjjbokma
Why Python 2 if I may ask?

I wrote my static site generator in Python 3.7 by manually translating the
Perl version I had written earlier. Both are available at github
[https://github.com/john-bokma/tumblelog](https://github.com/john-
bokma/tumblelog)

Example of this set up: [http://plurrrr.com/](http://plurrrr.com/)

~~~
kragen
No real reason for using Python 2 — it was just an expedient choice in the
moment.

Amusingly, your tumblelog.py is about the same size as dercuano.py, while the
intersection of features is almost exactly empty. We managed to do even the
most basic things differently — for example, yours reads a single long file
with % lines separating the entries (like a fortune file!) and produces a
passel of output files, while mine reads a passel of input files and produces
a single multi-megabyte output file. This diversity of choices perhaps
demonstrates the need for experimentation to see what works best for different
people and in different circumstances. (Or it could just mean I'm insane.)

------
claviska
> WordPress was one of the most visible early proponent of WYSIWYG, but others
> joined.

I added inline editing to Surreal CMS back in 2013, but obviously it’s not a
well-known brand (the keyword is “visible” I guess).

People love inline editing, especially non-devs. When you abstract content
into forms or markdown you often end up with results that look different from
what you intended. I get feedback from new users weekly about how easy inline
editing is for them.

Fortunately, TinyMCE, CKEditor, ProseMirror, et al all support it and the
trend is finally shifting. But as a developer, I can attest that inline
editing isn’t easy to get right — even when the underlying lib supports it.

I suspect that’s why we still see forms for content in CMSs.

------
alfonsodev
Aren't static pages similar to a cache ?

Wouldn't you obtain the same benefits while still keeping Wordpress if you
would use something like Varnish[1] or CloudFlare Edge cache[2] ?

[1] [https://www.varnish-
software.com/wiki/content/tutorials/word...](https://www.varnish-
software.com/wiki/content/tutorials/wordpress/index.html)

[2] [https://wordpress.org/plugins/cloudflare-page-
cache/](https://wordpress.org/plugins/cloudflare-page-cache/)

~~~
jakozaur
Static website is a controlled cache to the extreme, when you prepopulate
cache when you create the content.

Benefits on top of regular cache:

\+ maintenance cost: you need to upgrade wordpress, why my static website
doesn't require any work over years

\+ security: small vulnerability surface

\+ cost: hosting even popular static website is cheap

------
techntoke
Agree. Hugo is a great tool for static sites, and GitLab offers free pipelines
for the conversion and SSL with Let's Encrypt. Don't forget to gzip your
content as the final step.

------
mathgladiator
What I love best is that you don't need much to get started with generating a
static web site, and you can be confident that once you deploy you don't have
to worry that much about security or other production issues.

This greatly lowers the bar for entry, and I was doing this back in the 90s
with Microsoft Access 95 and VBA for my school's website.

------
eitland
Bonus:

If you write plain, valid HTML your site will just work across all mainstream
browsers and it will probably work reasonably wrt accessibility as well, -out
of the box.

It will also be reasonbly fast. You might be able to eke out more performance
from a site that has a lot of interaction but I'd not take that for granted.

------
whiddershins
All I want in life (as far as web authoring goes) is a wysiwyg editor for
static html that creates fairly clean code and can provide responsive
templates.

I just want to type text and drop images in and see it in real time, and then
I would like to be able to define one or more areas on a page that contain
dynamic content.

That dynamic content can be served up when visitors reach the site, or can be
compiled by the static site generator periodically, I really don’t care about
that step.

I don’t want to abstract “templates” from content. I don’t want to abstract
anything. I just want to type and drop in other media without extra steps.

Why does this not exist? Am I supposed to be using Dreamweaver? I just don’t
get why all these other solutions are so disjointed.

Edit: Maybe I want to be using blocs

~~~
arithma
I've recently purchased a license for Bootstrapstudio for $60 and I want to
send a vote of confidence. Does exactly what you're describing. I wish they
had a bit more integration for templates for webapps but you can only do so
much at the end of the day.

There are similar other offerings (one that comes to mind is reactstudio, but
has a bit more going on there with code and flow.

------
sandGorgon
the biggest problem with JAMStack (everything including Gatsby, Jekyll, Hugo,
etc) is that there is no single place with a nice source code repo, CMS system
_and_ hosting.

Basically, to get your JamStack to work - you need to use Github + Github
hooks -> Contentful/Cosmicjs -> Netlify.

I believe this is a missing and a killer product. People think "oh why
reinvent Github". But a business guy who wants a fast website does not know
what github is - he/she just need a single place to do everything.

the workflow that would work is - upload my code to dashboard (using git/FTP
upload). Write content in CMS and see the website change within a few seconds.
Reupload new code, and the website changes within a few seconds.

~~~
huy-nguyen
You should check out Gatsby Preview which is currently in some sort of limited
public beta. [https://www.gatsbyjs.org/blog/2018-07-17-announcing-
gatsby-p...](https://www.gatsbyjs.org/blog/2018-07-17-announcing-gatsby-
preview/)

------
zzo38computer
I hate WYSIWYG (although I am not trying to prohibit anyone from writing/using
them if they want to, only to say that you should not be forced to use
WYSIWYG), but certainly for a lot of stuff, static web pages (especially if do
not require script and a lot of other external resources) would be helpful,
and sometimes gopher would do better, too. (Use of other protocols is also
sometimes helpful for non-static stuff too, such as telnet/SSH for interactive
sessions, or remote virtual table protocol (or maybe a better protocol and
implementation can be made up), for remote database queries.)

------
revskill
Static web is fine for some use cases.

For an admin dashboard, static web is stupid.

~~~
sintaxi
Static is perfect for an admin dashboard since it doesn't have SEO
requirements.

Static doesn't mean there isn't any dynamic content is just means the assets
are static files that can be cached both server and client side. Dynamic
content can be fetched by the client, it doesn't need to be fetched and
delivered by the server.

~~~
anthuman
I guess that's one definition of static webpage. My understanding was that
static webpages are static. Meaning it has no dynamic content and that
everyone accessing the static page sees the same thing.

If dynamic content is client side driven, it wouldn't be "static" as each
client could see a different page.

For example, even if you your webpage just displayed the client side time, it
would be dynamic since people in different time zones will see a different
time regardless of the time being generated on the client side.

Whether it is a static class or a static webpage, static has a well
established meaning in the CS world. But I haven't done web development since
college and it is possible the meaning of static webpage has changed as
technology changes.

~~~
sintaxi
Static is a term to describe the assets that are delivered to the client. It
means every user is delivered the same assets which means the server doesn't
have to do any logic. The assets can be delivered from a CDN and cached on the
client indefinitely.

Sending every user `document.write(new Date());` is static because its
identical for everyone. The fact each user sees something different is
completely irrelevant.

------
reacharavindh
but sometimes you legit need dynamic capabilities. I'm now pondering about
selling a few items through my website(built with Hugo). But, how? So, I'm
stepping into Wordpress realm because that's where the payment processing
stuff are.

Anyone here know/have done a shopping website built with Hugo and a simple
third party service for payment processing?

~~~
thirdsun
I currently run a static website with a shop using Shopify's JavaScript SDK.
All the benefits of Shopify's excellent backend and admin interface while
still using a performant website that can be designed however I please.

Another option is Snipcart, which explicitely works as a drop-in shop for
_any_ website[2].

[1] [https://shopify.github.io/js-buy-sdk/](https://shopify.github.io/js-buy-
sdk/)

[2] [https://snipcart.com/](https://snipcart.com/)

------
nudpiedo
What I understand: the most used solution, Wordpress, is an attractive market
but has a slow UI and experience, please consider using my markdown solution
which I positioned in a different page than this article.

------
pacifika
The main issue I have with static sites is that publishing from mobile isn’t
simple. That said I also have this issue with WordPress, so I’m using Known
now

~~~
indigodaddy
I checked out Known and it looks quite interesting. Surprised I’d never heard
of it. How are you liking it? Is it well maintained/frequent releases?

------
sys_64738
Disable Javascript and you too can surf the WWW like it's the 1990s!

------
mrzool
Admittedly just bikeshedding, but the author is using a blockquote tag instead
of an h2/h3 right under the h1 title for the summary of the article. Makes me
think he probably doesn’t have that firm of a grasp on the fundamentals of
semantical HTML and markdown, let alone web development in general.

This is, by the way, something I see a lot out in the wild, especially in
Medium articles but also in READMEs on GitHub. Please stop using blockquote
tags for emphasis purposes.

~~~
icebraining
The lede is not a heading, why should the author use an <h*>?

~~~
mrzool
I see your point, an h* would probably also be inappropriate. What would you
use? Just a normal p tag with some styling?

~~~
ravenstine
`role="heading"`?

~~~
detaro
no, that's the same as <hX>

I'd probably go with just a styled text, maybe with an aria-label.

