This is an inaccurate over-simplification. If you just use HTML and CSS, you can also have really bad Lighthouse scores. For example, vanilla `<img>` will ship the same image to every device, regardless of viewport size. Vanilla `<img>` doesn't enforce setting `width` and `height`, which makes your layouts shift. Slow-loading images and layout shifts are the very things that will downgrade the "100" score he's currently proud of.
Frontend performance is basically an iceberg[1]. We tend to look at the top and that's where the fashionable "silver bullet" currently is (whether Rust+wasm or HTML+CSS or a JS framework). Then we find deeper in the iceberg that even a `box-shadow` property[2] can ruin our day, and let alone images, YouTube and Twitter embeds, and all the things that make the web more interesting and powerful than a black page with white text.
Oh and it gets even more fun! A Lighthouse score in itself is an over-simplification. There's more to a great experience than the initial impression the site makes, like what happens to FPS when you scroll or click around[2]
Oh boy, YouTube embeds! I went through checking the Lighthouse score on a few of my pages a while back, and the ones that had videos were performing pretty badly.
It turned out that embedded YouTube videos were pulling down something like 1mb of JS, just to show the thumbnail, before the user even clicked Play.
I ended up making a static thumbnail with a hover-over "play" icon that would replace itself with the real embed when it was clicked. Got the Lighthouse score up and saved all those unnecessary downloads. But it was pretty amazing to me that while one arm of Google is pushing for web performance, another is building this YouTube player that auto-downloads a megabyte of JS just to show a thumbnail.
> Vanilla `<img>` will ship the same image to every device, regardless of viewport size.
You can have responsive images with vanilla <img>[0]. You can even lazy load images with just `loading="lazy"` attribute[1]. I'm pretty sure I can optimize more things.
I'm mostly agree with this blog post. Plain HTML+CSS is really good for simple webpages, like landing page or portfolio that requires less update. But for a blog with pagination? I don't think so. Imagine updating each page in plain HTML. SSG can help my life easier.
The point is that "just HTML+CSS" is not the recipe for performance. You get into the same nuance as any other technology: how you use HTML+CSS is the recipe for performance. In fact, his image in this blog post doesn't have `width` and `height` set, so had it been higher up on the page and part of the "Largest Contentful Paint", not sure we'd have a 100 here.
This is where frameworks can be really helpful, and I wouldn't dismiss them. It gets quite tedious to keep up with the new attributes, cross-browser and cross-platform differences, image optimization CDNs and so on :)
At the same time though, in my experience, performance optimizations follow paretto's law: try to get 80% of the way with 20% effort. There are pitfalls both with and without frameworks (e.g. it's equally easy to accidentally plop a hi-res image into a Next.js app), but generally speaking, limiting the tech stack means there's less potential stack-specific pitfalls.
If "I'm gonna restrict myself to HTML and CSS only" gets them 80% of the way to their performance goals then IMHO, that's a perfectly valid approach.
As far as images go, the reality is that most mainstream sites with image/video content are heavy sites with multi-second page load times, despite literal millions of dollars being spent on engineer salaries. In that context, does it really matter if a random blog decides to just use pngcrush and a dumb img tag for the occasional eye candy imagery, instead of whatever is the state of art multi-resolution technology?
Definitely. But notice he's not using the <picture> tag in this post for his image. "Just HTML+CSS" cannot possibly be connected to the 100 score conclusion (same for dismissing WordPress, which could have yielded that element as well.)
I fail to understand why you wouldn't set dimensions for an `<img>`tag or use a `<picture>`tag with `<source>` elements for appropriate variants using just HTML and CSS.
(I'm doing this all the time, also with perfect Lighthouse scores. That is, there's often also a bit of PHP involved for includes and setting some meta tags, and a bit of non-essential JS sprinkled in.)
Removing the dimensions from the image tags is absolutely the wrong thing to do.
If you do this, then a browser/user/client that wants that information simply doesn't have it - you can't create bits from thin air.
If you leave the metadata in, then any browser that wants it can use it, and any brower that doesn't want it can ignore it.
I can code up a Greasemonkey script in a few minutes that will strip the width and height attributes from img tags, but nobody on earth can write a script that will magically detect what size the author wants them to be if they don't send that data to you.
The width and height attributes we have been discussing set the size that the image will be displayed at, which are not necessarily the size of the image transferred.
Those are two very different things. My statement holds - if an image has size (a, b), but the author wants it to render at size (c, d) but does not send that data, the client has no way of magically determining c and d.
Furthermore, even when the actual image size is the same as the width and height attributes, there's the obvious problem of you needing to completely transfer the image itself before determining the size, which blocks rendering (or forces you to re-compute layout a second time, which both increases latency and decreases throughput).
Designers trying to assert pixel-perfect control of layout is part of why the web sucks so much today.
Sending a high resolution image to a user with a low pixel density display is wasting their bandwidth and battery. Sending a low resolution image to a user with a high pixel density display isn't giving them the good experience they paid for when they bought a high end device.
Optimization is about giving all the users the best experience you can on a website. It doesn't necessarily change the design at all.
Well on my low latency nordic cellphone connection, it's always nice to receive a lower resolution image. Especially if I don't have the resolution to display it
It would be good if more browsers and websites implemented the prefer- reduced-data setting that Chrome and Edge have right now, but you do have that option in Chrome for Android right now. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Just meant to be humorous, does your brain not provide any illumination, while at it, do you have time and energy left to address other then software in itself, for adding to the cycle of aggregate rentier-ism?
While I really like the idea of serving raw HTML and CSS, I think that on the authoring side, a static site generator that ingests Markdown and generates HTML is a more practical way to go.
I think writing raw HTML can work fine for small pages, and arguably it can be better than Markdown for pages with a lot of design elements, like landing pages. But for the typical blog post, or especially if the blog post has code snippets that you want to have syntax-highlighted, a static site generator is way easier to work with.
With the pace of change, I do worry a bit about the longevity of some of today's static site generators, but the Markdown itself is pretty darn portable.
Most near-trivial to rewrite to each other's format though, which means you can get any static generator to ingest your favourite flavour with only a one-time step possibly (but almost certainly not) required to teach it how to ingest a format that isn't a perfect match for what it expects.
A couple of years back, I helped move Fastmail’s blog from a home-grown thing from the mid-2000s that used Markdown.pl, to Ghost. It was nowhere near trivial. Line break behaviour changed, handling of indentation changed, treatment of raw HTML and Markdown characters within HTML tags changed… I fixed everything I noticed, but there was a lot of incompatibility, and old posts would have looked uniformly bad without some of the fixes we applied.
To be fair, the mid-2000s are fifteen+ years ago, which might as well be a century ago when it comes to both markdown, static site generators, and even the web in general.
I've been through similar pains myself, but not in the last five years: there's been plenty of tooling to strict-format all content prior to starting any conversion, and plenty of tooling to convert from one flavour of markdown to another (although, mind you, sometimes that means converting away from markdown first, then converting that back to your new flavour).
Yep there are definitely some differences, especially once you start to go off the beaten path by including HTML in the Markdown, or using whatever flavor of template language the SSG provides.
I've got some older posts that use Jekyll's {% highlight %} directive, and I know that won't work if/when I change SSGs, but to me that's a small price to pay for not having to author those in raw HTML! :)
I don't like Markdown, because it too often takes what I meant and changes it to what I think I meant.
I'm OK with ambiguity between implementations, but this one is a deal-breaker for me, and I've not encountered a Markdown implementation which doesn't do it.
more specific: when i want something left alone or displayed as is, markdown does its own thing and wrecks it completely. and there is usually no easy way to negate it. no, pre-pending each line wit 4 spaces, only to get nowrap now, which works like shit in small displays, is not easy. it makes the user think and do extra work at minimum.
Sure, it's super easy when your page doesn't have even a header and/or a footer. Try having a top-menu in your design, or some banners/ads, and then you need to change ALL the pages to change a single url. This is how we used to do things long time ago, and it sucked BIG TIME, and that's why people invented server-side includes and cgi and mod_php and all of that... it saves time, and your time costs much more than hardware...
A static site generator requires a toolchain, being platform-aware, updating dependencies, etc. Sometimes I think of these things as labor for a new employee (if you need to onboard a new maintainer) on a new system (if you need to switch hosts or upgrade the disk/OS).
It's probably about 2-4 hours for an experienced developer to figure out how to setup and maintain a static site generator assuming no unexpected problems, then get familiar with the syntax and structure, so hopefully the labor savings from using a static site generator is worth that.
"I looked at static site generators like Jekyll, Hugo, 11ty, but all of these require tooling installed, have a build step and will ultimately need some updates or be abandoned by their maintainer." - from the article
Yes and to that point you could use something like Hugo, generate a static HTML site. Then with that static site in HTML/CSS you are no worse off the solution the author proposes even if that generator became completely abandoned and unusable the next day. But in the meantime your work would be a LOT easier if you are doing anything at all with headers/menus/accessibility
If you know what you want you could write a trivial script which
just pushes a Markdown file through pandoc(unless you just write
html), concatenates it with the files for the header and footer
(& maybe an inlined stylesheet) and appends a link to the index
file. The result will be the same but applying changes on all pages
is a matter of seconds.
Nothing against a lightweight stack, but simplicity doesn't
necessarily have to exclude functionality.
He mentions that SSGs require tooling and dependencies.
And if all you need are dynamic headers and footers, just wrap those in 'php include' tags and rename the files to .php. It's still HTML and CSS that's getting rendered.
I’m not a web guy—- this should be safe from php vulnerabilities I would think, because there is no db and it’s just taking advantage of very limited/basic features of php right?
The number of vulnerabilities is vastly reduced due to the static nature of the site. You aren't buying anything on it, or inputting other kinds of data that needs to be written to a database. It may as well be a read-only site.
I've used both server side rendering and server side includes. A static site generator beats both. Just have a listener that will re-generate the site live when you write new content, then just ssh/ftp the generated content to the server when you are done, or if you are fancy you can use version control and push to a repo with a CI toolchain that will regenerate and ssh/ftp it for you.
> So... if I don’t use any templating system, how do I update my header, footer or nav? Well, simply by using the ”Replace in files” feature of any good text editor. They don’t need frequent updates anyway. The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
>The benefits of using a templating system is not worth the cost of introducing the tooling it requires.
Other people use static site generation, you use search and replace in your editor - not much of difference. Your approach is slower in long term, but with your on average 1 article per year it will take some time until you reach the threshold.
Eh, I don't think a person can ever write enough articles and rewrite their layout enough times that search+replace overhead ends up bigger than the upfront time it takes to read jekyll/hugo/whatever docs (plus debugging idiosyncrasies, etc). And even if search and replace was slower overall, you might be looking at a difference of minutes over a period of decades (i.e. it wouldn't actually matter in any practical sense).
Far too often I see people spend days to save 2 seconds (and then proceed to not realize the savings over a long enough timespan)
In reality the time saved isn't the only significant factor
though, humans aren't machines after all. I'll gladly "waste" a
bit more time if that time makes the process more enjoyable in
the end.
You forgot to mention the main benefits! Your website does not fingerprint my device, nor present me with a dark pattern infested "do you want us to send your data to 50 ad networks" popup.
"Tooling" can mean many different things, it can be an over-engineered flow including a dozen of different tools, or it can be a few custom made scripts to glue together html for you... but anyway, it's one time setup, you invest 2 hours of your life once and if done right it can happily run your site for decades, plus if you did it before it's no brainer usually... hell, I even have some old wordpress sites that I haven't touched in 10+ years and they autoupdate and work just fine, even make a few bucks here and there (but it certainly helps a lot if one knows what they're doing when making the sites).
Back in the old days of web development in 1999 there was a great app called Adobe Pagemill for making changes across thousands of HTML pages. It was great.
These days you can do the same thing with about 5 lines of Python.
> it saves time, and your time costs much more than hardware...
And the user's time doesn't?
If you can shave off a bit of loading/processing time for every
request you will have improved the experience for countless
people. Sure, using just HTML+CSS is a bit extreme, but for many
sites the removal of some social media embeddings/trackers and
switch to static site generation could improve it by an order of
magnitude.
> it's super easy when your page doesn't have even a header and/or a footer.
It's not that hard even with.
My stack consists of HTML/CSS, and a small program to stitch headers and footers onto documents generated with markdown.
If anyone would like to see it, it should be in the Sourcehut page linked in my profile. The program is a hacky (but functional) piece of garbage however.
I did this. Had a header template, a footer template and a bunch of pages. My build script was basically ‘for page in pages cat header page footer > ouput’. Worked fine for its purpose (which was limited in scope).
That's just about what mine does as well, except pages will inherit headers above them in the directory structure, so I could make the top bar pretty without JS.
This is the exact thing I experienced and have been dealing with the past couple days. I wanted to create a small collection of pages as my website, intending to keep everything as small and simple as possible since it was (mostly) just to display some basic info and "posts". Well as soon as I wanted that menu for pages it was a whole new can of worms.
Sure, I could just copy/paste/replace content as it changes. But I don't want to have to be doing that any time I decide I want to change or add something. And I'm known to be a source of human error.
I ended up going Node+Express+EJS for the includes and certain more dynamic content on pages. It works well enough, page sizes are still small. Also considered some static site generators but at the time they seemed like overkill for what I wanted. Maybe there's a tool out there that will compile to plain old HTML files that I'm unaware of, I don't keep up much on front-end things.
to cover slightly more use cases, you could go for <?php include "header.php"; ?> like it's 2002, and then have that file just be plain html also. Of course if you're gonna pitch a solution that's impractical in most cases, you might as well go for the most extreme variant of that solution and not bother with that
I swear this same exact post gets re-dressed and upvoted weekly.
Is there anything worth discussing here? The entire thesis of the post is "my blog is maintenance free". Ok, and? Is blog maintenance really a noteworthy topic?
How many times can blogs rephrase "use the right tool for the job"?
This comment presents a caricatured perspective of those it opposes by using a made-up quote (it doesn't seem to have actually been said by anyone anywhere), and it doesn't really do anything for the discussion that wasn't already covered by the parent comment it's attached to.
Please, folks, don't encourage people to post low-effort noise by upvoting comments like this.
I agree it could have been phrased more nicely, but it actually pointed out something valid, which I didn't catch at first. The author hasn't written any posts in 5 years, and has ~15 total since 2010:
As someone who blogs regularly, I'm more interested in the toolchain of people who HAVE done significant writing. I read blogs for at least a decade before I wrote one, and it's harder than it seems, and coercing a good result out of tools isn't easy.
Basically, the author's strategy is not likely to last (though it's not impossible). My blog started out very minimal, but as you write, you bump into the need for more automation and tools. My site looks very simple and minimal, but there is a surprising amount underneath.
When I was writing those tools I often wondered if we should just go back to Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! I remember trying it briefly in the early 2000's. Although his blog also rotted due to CityDesk rotting! It's a hard problem.
That's an understatement. It's the kind of comment that should be in the grey. Comments that amount to pile-ons and smug dismissals—like the one above—are far more welcome here than they used to be.
> Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server!
Among the things that Microsoft first started pushing to GitHub around the time that they formed the .NET Foundation was Live Writer. <http://openlivewriter.com> Dave Winer's Frontier is open source, too, but has also rotted. Brent Simmons, the creator of NetNewsWire, set out within the last couple of years to recreate it as a modern Mac app, but dropped the project last summer.
> Although his blog also rotted due to CityDesk rotting! It's a hard problem.
I'm convinced that we've missed the obvious and have been doing it all wrong, due to predilection for certain systems and ways of working. If you have a personal homepage, you should have among the stuff hosted there a document that describes how your site is updated. This document should be less of a blog post than an SOP. But now make sure it's specified with enough rigor that you can feed the same document into a machine that can perform those steps automatically. The reason the "WordPress setup from 2004" works and "old-ass blogger.com site" work is because they're closer to this ideal than Jekyll or Hugo or the others are. The caveat is that the hosted services make it really hard to actually look over the procedures that the machine will run, and if they let you, then you'd find that they were spread out over multiple "documents".
Whatever the case, the thing not to do is to have this sort of thing live out-of-band elsewhere as a tool that requires its own configuration and setup (with both the tool and the configuration being subject to rot) accompanied (if at all) by a terse README. (Otherwise, if you're keeping that sort of thing elsewhere, then your homepage is not really a true digital home, is it? It's a Potemkin palace, and the place where those other things live is your real home.)
Yeah it's definitely a problem that you have this "elsewhere" thing that rots. Having some kind of online editor is one way to solve it, although it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?) [1]
I think a simpler way to solve it is with the now standard "infrastructure as code" pattern. For example, use Github Actions and similar platforms to build your blog.
Basically check in a spec for a container (Dockerfile) into VCS. It's done off of your machine, and it will "never" rot. You still have the cloud portability problem, and the "shell scripts and YAML are gross" problem. But those are solvable, especially for the relatively simple case of building a blog. I'm working on that:
> now standard "infrastructure as code" [...] check in a spec for a container (Dockerfile) into VCS
This is an example of the "predilection for certain systems and ways of working" that I referred to.
> it also tends to rot (who hosts that? Are you limited to PHP? Are you upgrading PHP? Did that company get sold?)
That's not really what I meant. My reference to WordPress was probably more misleading than I intended.
I really mean it when I say a human-readable document that's more SOP than blog post—it's not a metaphor. Consider a static site generator for an existing site, and consider the steps it performs on the input to produce the output. Specify these steps as a single, written document—one that you can print out, even. If you're doing it right (in contrast to how we "have been doing it all wrong" up till now), then you should be able to ask yourself, "Is this document suitable for publishing a copy of it on my site itself (or printing it out and dropping at the bottom of a filing cabinet)?", and you should be able to answer "yes".
(This is where the reference to WordPress came from—it's not exactly a "single document", but it is a bunch of PHP files that you could conceivably stitch together and consider to be one and which you can take a peek at so long as you're self-hosting. But even then it's not something generally available as another piece of content on your site, because WordPress doesn't "reveal itself" as such, i.e. there's no associated HTTP resource by default that's associated with the underlying WordPress-in-PHP engine itself, so its likeness as an example is strained.)
That still doesn't solve hosting and portability, but it's a separate matter from the authoring tools (etc) experiencing rot. In practice, this can be covered by the inclusion of an annex to the above SOP (or a completely separate set of procedures) that describes how to get your generated files onto whatever host you're currently using. (In software terms, this section would describe an "adapter" and its use.) Static site pages are already pretty portable by their nature, and you don't really move around enough to worry about it, really, but if you do move, then just document the new process by speccing out a new adapter.
The takeaway is that if these processes are too elaborate to be documented in this way, then it won't work. But if that's the case, then they're already too complex, period—which rules out Docker and pretty much anything else that's "standard" in the devops world right now. I've prototyped something like this, and describing the whole thing that fits into a document weighing <500kB without even trying is pretty easy. My prototype is actually currently at 109kB, but that just covers the build SOP. Albeit, that is both man- and machine-readable (i.e. machine-executable), so it's detailed to a high degree of rigor. That's one long document that includes stuff like formally describing how the SHA-1 algorithm works, how Markdown gets processed, how templates and includes work, and so on. The adapter doesn't really exist, though; since it's a static site, it's just a note that says, essentially, "use rsync; here's the hostname and the exact command-line flags". In the document specifying how building the content from source works, I punt on specifying YAML, because a drastically simpler subset (i.e. colon-separated, key-value fields on separate lines) was able to accommodate 100% of how my frontmatter already looked.
I don't think relying on underspecced and inscrutable commercial systems like GitHub Actions is especially simple, resilient, or healthy. It seems to be subject to exactly the sort of rot mentioned before. Basically, what you said about VCs' blogs.
Hm I think we're coming at this from different angles... the whole "SOP" terminology confuses me, though I guess you mean "standard operating procedure".
I'm a programmer so when I hear "document on how to update something" I hear "untested set of manual steps". I don't understand why it isn't a shell script instead ...
----
I actually don't want to preserve an authoring experience forever. I expect that my authoring experience will change [1].
What I want to preserve is the data. Both the source data and the generated data. I have one git repository for each. And everything else is basically Unix tools that I can compile myself.
I bet it's all going to work, basically due to the "Lindy Effect". I can build everything from source even if people don't maintain it.
I actually wouldn't rely on Docker itself, I meant more a "spec for a container", but Dockerfiles now have multiple implementations like OCI.
The point of the shell layer is to NOT rely directly on Github Actions APIs, even while using the service. It's indeed a problem that all these cloud services have weird SDKs and command line tools.
However when you look UNDERNEATH these cloud services, you get a KERNEL and a SHELL. That is the "timeless API" I'm writing to. I already did that with continuous builds, and it would be similarly easy to port my blog toolchain to the MULTIPLE clouds this way, so I don't rely on one. (It wouldn't be easy for all problems, but it's easy for building static content.)
I realize this is all outside the norm and 99% of writers aren't going to use this toolchain. But it goes very well with the Oil shell project. Unix and document authoring are very closely related. Historically the first use of Unix was to create patent documents at Bell Labs.
I don't quite understand what you are getting at so I think you must have a much different use case. If you have an example then that would help. It seems like you might be talking more about a blog that lots of people are editing?
----
[1] Actually it JUST did after 4 years and at least a hundred posts. I used vim for 4 years, and now I switched to the online editor StackEdit because it has realtime preview. I wrote the last 2 blog posts in StackEdit and it worked great.
However the data remained exactly the same. Unix is data-centric, not app-centric. Apps are the things that rot.
> when I hear "document on how to update something" I hear "untested set of manual steps"
Why "untested" and why "manual"? I mentioned "detail" and "rigor" more than once and that it's possible to take it and feed it into a machine that will "perform those steps automatically".
I don't think kernel+shell are all that timeless of an interface to write to. They only barely pass for being portable in the here and now. (Oilshell's existence as a project is a testament to that. Its breadth and the depth of the pitfalls it has to avoid is another one.) Most of the time portability is an illusion that comes from most people around a given project being part of the same technological subculture, so they happen to use a common implementation. When you stray outside of that is when you run into breakage that no one is otherwise aware of. See also <https://pointersgonewild.com/2019/11/02/they-might-never-tel...>.
> I don't quite understand what you are getting at so I think you must have a much different use case [...] It seems like you might be talking more about a blog that lots of people are editing?
Nope, the use cases we're talking about are the same. I don't know where the lots of people editing parts comes in.
What I'm talking about is conceptually very simple (maybe too simple, leading to an assumption that there's a lot more to it). It's a document that describes in detail, just like any other tech spec, precisely how to process a given input and turn it into a directory of static resources that you are used to dealing with, i.e., the output of a static site generator. The only difference between it and other specs is that in this document you specify things with enough rigor that you can effectively "execute" the specification itself. I've heard Rob Pike say in a few talks that some of the Golang backends come from a tool Ken wrote where they can feed in PDF manuals from microprocessor vendors and get a working Go assembler out of them, but I'm not intimately familiar with that tool. See also <http://www.moserware.com/2008/04/towards-moores-law-software...> where some RFC-style diagrams constitute a part of the implementation of a working TCP/IP stack.
> If you have an example then that would help.
I might do a short (? I'd hope) screencast next weekend if you're interested in providing some feedback. Asynchronously and pre-recorded, not live. My first assumption is that when you see what this is all about, then you're going to be pissed off. Based on your description of your current setup, though, that impression may not be accurate.
> Apps are the things that rot.
This is where my comments about "predilection for certain systems and ways of working" and how "we've missed the obvious and have been doing it all wrong" come from. In trying to solve these problems, there's way too much emphasis on apps, CI configurations, or whatever mindtrap is ensnaring people at the moment. The "obvious" approach I refer to is first adopting a mindset where it's an imperative to include a functional specification as described. I.e., add it to the set of things that you intend to publish on your site. Once you do this, it's hard not to notice that there's now an overlap between your data and the "app" you're using to publish it. So the second thing to do is to eliminate the part that's most susceptible to rot.
The only difference between it and other specs is that in this document you specify things with enough rigor that you can effectively "execute" the specification itself
Hm if you have a concrete demo then sure I would watch it and give some feedback. (e-mail in profile) It sounds like literate programming for a shell script to me :)
The kernel + shell is the best we have, since there are multiple implementations going back years. For example FreeBSD and Linux are totally separate projects and codebases, and implement a very very large common subset (POSIX, which has absolutely everything you need for text processing and document authoring).
For example, I just tried out NearlyFreeSpeech, a very inexpensive pay-as-you-go hosting service, and I found it runs FreeBSD. If I really wanted to make my blog portable and timeless, I would port it to NearlyFreeSpeech, which I estimate would probably be one day of work (really, I only use the Python stdlib, etc.). But I'm comfortable enough that Linux is going to survive until in some form or another until I'm dead ... or if it doesn't, there will be some migration path for the bazillions of other users.
The point is multiple implementations: Unix has multiple implementations, CommonMark has multiple implementations, and so does HTML/HTTP. Those things aren't going away.
The reason that Spolsky's blog rotted is because he built it in a custom tool (which he wrote), which was built on VB6, which was built by a company which changed its strategy ... etc. The stack was too high, and too proprietary.
He switched to WordPress, but I'd argue that stack is too high too, even though it's more open source.
So I'm happy with my solution but sure I would look at different ones. But my feedback might be that it should be "tested" in the real world. Just like the HTML+CSS solution is NOT tested because the OP didn't actually write many blog posts with this toolchain!
Well, this is a motherfucking website without the swearing, so I guess it could be useful to people that would be offended by that? Although, to be fair, the intersection of people that would switch to raw HTML but are offended by swearing is nonexistent as far as I know...
My output is HTML and CSS, but my stack is React with Next.JS. I just tell Next to not emit JS at build time.
This is the best of both worlds. You get an excellent dev experience with TypeScript, fast refresh, the world of React components (granted many don't work when reduced to being static HTML), and I can also opt back into React on a page by page basis if I have the need.
With Next's static site generation and export, the output is just HTML and CSS (and optionally JavaScript), no need for a server.
Beautiful site! Do you write your articles in markdown or something like that and render them into pages at build time? Is your source available by chance? I've been wanting to do this exact thing but while the Next.js docs are great, what would really help is to just see an example site that does exactly what I want to do. All the good examples are either too trivial to be useful or to complex to be useful.
Thanks! I am using MDX for the articles. I don't really like it though. MDX is fiddly and causes some headaches here and there. I am exploring other options.
Why can't HTML some kind of templating system, or even simple includes? Then I wouldn't need to use a static generator and could just author HTML directly.
e.g. (with hypothetical <extends> and <block> tags)
Look into custom elements and web components, HTML already has amazing stuff built in, supported in every browser, and maybe even being used on some of your favourite sites!
The main issues are the ergonomics of authoring and maintaining consistency around a site. A minimal static site generator would keep internal links and boilerplate consistent. Connecting that with markdown, Org mode, or reStructured Text would help with the ergonomics. But then you lose the goal of having no necesary tools.
Anyhow, if there's one general purpose tool that predates the web and will probably be around when it's replaced by some other content publishing standard, it's Emacs. You could do a lot with a minimal SSG in Emacs and Org Mode, and it would be forward compatible with whatever is in the future, as well as backward compatible to whatever you like.
> A minimal static site generator would keep internal links and boilerplate consistent.
Maybe not. There's an argument to be made that says you should treat a blog as a series of pages, each modeling something corresponding to what you might call a "publication event" in the real world, e.g. printing a magazine or passing around a physical memo. The consistency angle is probably overvalued (not worth its cost). When a newspaper or magazine changes its masthead, old issues don't get updated. You might say that this reflects a limitation of the physical medium and that you would if you could (as is the case with digital editions), but what does it get you, really? Your links to external sources are already going to lead to wildly different forms of presentation outside your control.
If an internal link leads to a page published in 2014, and it still matches the way it looked in 2014, is that a problem? (And if so, e.g. due to changes in fashion/trends that have led to it being intolerable, it's worth asking, "what makes it so?", "was it ever really tolerable, even in 2014?", and "is the material I'm publishing right now guilty of the same thing—its presentation only squeaking over the threshold of acceptability because of something else that's currently en vogue but soon won't be?")
OK, but blogging isn't the only type of site you might manage like this. Documentation, for example, you want to update your links properly when you change the name of a function or whatever. Or perhaps you have a catalog naming files by SKU and those can change.
And, if you're just blogging, and you want to have the permanence you're talking about, you still need to ensure that all your links are properly linked, which requires some tooling.
Yes, I remember seeing this idea. Some blog was making new design for each of the post. I really liked that, but I did not see it getting popular ever back in the days when FB was not yet a thing and websites used uniques designs instead of the cookie-cutter so popular today.
This. But also, the point here IMO isn't just about performance but about tooling choices. There's so much tendency in the dev community (and has been since 1996 when I started doing web stuff) to jump on the latest thing without thinking about context or applicability. Perl then CFM then asp then Flash then js then...it goes on.
Thing is, you don't need some jamstack hellhole of complexity if you're serving simple content pages. Need a common header, just do a find replace as he says or write a php include.
It's always been the same: choosing overcomplex solutions may be fun and groovy - and good to learn and interesting - and this may be enough of a reason to do it, but it's always worth asking what you're trying to achieve and whether the toolset fits. So often that doesn't happen, and almost always the simplest solution is the very best one.
Plain HTML+CSS is really good nowadays. You can for example lazy load images with `loading="lazy"` attribute. You don't need JS anymore just to lazy load images. You can use plain CSS for simple interaction like opening and closing menu, toggling pricing plan, etc.
If you're curious with what you can build with plain HTML+CSS, check out my side project[0]. It's a collection of free landing page templates in plain HTML+CSS (no JS). No frameworks, no preprocessors.
Not needing to write markup at the time of content generation even better than writing HTML, though. Use any of a million static site generators and get the benefit of writing what you want to write in the most efficient format for that, without needing to program the typesetting markup while you're writing.
HTML is in no way the best tool for write content. But it is the best tool to serve content in a browser.
The browser is the bitch. Out of control, bloated, willingly so, in interaction with layers of scripting on both sides. The server and client are bait. There should be a serious effort to tackle the world of academics and their use of analog tools for digital publishing. Nothing is better mined and searched(for any entity not meta-rapers that "employ" slave coders as battery-chickens) as text. There should be a tendency to reductionist auto-censuring or have coders but one ambition? Being scooped up by corporations for scraps so they can piggy back on their wild efforts for cents on the dollar?
Ya well my stack is just HTML, who even needs CSS. It has everything yours has with the benefit is having a single file.
Why just HTML you ask? Well all the reasons that they provided plus the fact it's only HTML files.
This whole stack argument is silly, just let people use what ever they want to use. If someone wants to use a giant complex webpack setup, that's perfectly fine. Sure there is obvious downfalls and longer term maintenance can be a hassle, but it's what they enjoy.
If you want to use just HTML and CSS, go for it, but why are we bragging?
Sorry to be so negative on this one but I'm kinda triggered by these "look its that easy" kinda blog posts that fail to adress the common task at hand entirely.
This works for your personal blog with a super minimalistic design. This is completely unfeasible for client projects, or at least it will break your neck in the long run. And chances are your abysmal lighthouse score on WP had more to do with a bloated, mashed together WP setup than with the technology itself.
I've found a nice middleground to be writing a custom static site generator for each site. They can be quite small (here's one[0] in ~50 lines). Usually it just loops through a directory and turns Markdown files into HTML (with header injected), and syntax highlighting.
Also, if you're really committed, you might be surprised how app-like you can make HTML+CSS, using things like checkbox and :target hacks[1]. The UI demoed in the video on this site[2] has no JS. These techniques pretty much require a generator, and there are obviously tradeoffs.
> You don’t need Wordpress, or Hugo to put a blog online
It took me about 25-30 minutes to publish my website with Hugo, from scratch. I can't even estimate how long will it take if i try to build something like the current one.
> Angular, React or Next.js to put a web page online. Raw HTML and CSS do the job.
If you see someone who uses Angular for a blog, go straight to the DEA and report him/her.
My approach of theoretics goes in that direction, more or less accentuated on different goal settings. Your approach must work for you as for sheer efficiency. You will spend more time on relevant issues, if so desired, of producing meaningful content.
Now include hardware into the same philosophy, the long term into shelf live, a single programming language worked on by dedicated knowledgeable individuals ideally. You are on our side of things.
A page (web/print) should be written, locally, off-line, in the same editor of always, in open-source code, preferably the blob of compiled code at it's nucleus, if there is any neeeded also. Content should have a seven hundred year lifeline, readable, view-able in minimal software allowances. Then it cannot be said too often, hardware-software is in-extricable.
For all those that think phishing in the public domain for the soul of the crowds, well, that is fine, but nothing the matter. And be prepared for a frustrated life-time of scratching your itches.
Theodore Kackzinski, people who vouch for the "hundred year", robust hardware, for the fashion of the ages, they seem to be on the right side of history. That same observation de-obfuscates the evidenced in what is going on in AI, and statistics, mining data. ...when the data are repeats, high-level, junk, outright meaningless, no amount of AI or tweaking using computer power will assert anything but junk outcomes.
People scale badly, that makes for the most efficient workflow to be a-synchronous, for nuggets of which as an individual we have as a rule none, and few individuals very little, that sort of data merits a long life-line, that data need to be tailored for the above allowances as you point rightfully out.
You might be fake, or limited in your ambitions, but from what I read, I must concede you make sense before any back-ground check is at order.
I use Markdown and HTML, CSS, and Python (just stdlib, no packages) to generate static files. I think that will last just about the same length of time.
Admittedly I need a Makefile, and Make is pretty impoverished for this use, and I want to replace it with something else. Shell isn't quite good enough because I don't want to rebuild the entire site on every edit, and I don't want to remember which files to rebuild. http://www.oilshell.org/site.html
I use something very similar on my website, except with a few twists - MultiMarkdown (instead of Markdown) for HTML, Perl for piping MultiMarkdown produced HTMLs through some regex changes, and redo instead of Make for rebuilds.
I've seen redo (and talked with apenwarr about it) although I think my brain is still stuck on static/declared dependencies. That doesn't apply to every problem but it definitely applies to a blog.
Is your build parallel? That's one of my main requirements. I'd be interested in seeing the redo files if they're public.
My website is probably a lot simpler than yours. All the "do" files are at the root level. But I have to state that there is no "redo" syntax really. You just take the scripts that do things and save them to files with a "do" extension.
Well yes, but your website has a dozen pages, wasn't updated in 6 years, and is as interactive as a sheet of paper. Do consider that some people tackle slightly harder problems.
The one thing I really feel like I'm missing out on, in my own no-build-system Github Pages site, is an RSS feed. A couple of people have emailed me asking if there's a way to be notified if I make a new post, but I don't see how I can do it without bringing in an external service.
This is the sort of the thing I may eventually go with. (And I hadn't seen this one, so thank you!)
But it feels more than a little like I'm essentially adopting a build system, since I have to run this manually each update. The idea was I wanted a stack which I could not touch for 10+ years, and nothing would go out of date and stop working. I don't think I have that safety for anything involving NPM...
I agree wholeheartedly with this sentiment and have elected for the same thing on my website. The only difference is that I wrote a simple template based static site generator (https://github.com/JosephNaberhaus/naberhausj.com/tree/maste...) to keep my HTML sources in accordance with DRY.
What I don't understand is how the linked page is downloading 1 MB of resources which unpack to nearly 2 MB. This page shouldn't need more than 100 KB.
It's the image of the Wordpress source and poor Lighthouse score. It's a poorly optimised PNG and a single file at 1 Mb instead of multiple sources for multiple screen resolutions. Of course, it does go with the thrust for simplicity in the article...
is this something created programmatically? I'd like to create a blog but I don't want to have to type all all the necessary schema.org tags myself. Any ideas here?
edit: God, I can't even get this text to format properly. I'm such an idiot.
I am pro github pages. Used it for 5 years, no complaints. [1]
However, I've chosen to also use Jekyll. Github pages explicitly supports/couples with Jekyll [2], so I view the combination as a single dependency as opposed to an extra. For deployment, I push to a git branch and github builds and updates my site in the 10-60 second time frame.
I don't understand his point. HTML/CSS are fine if you know them but a lot of people have better things to do than learn those, so they use wordpress/medium/whatever instead of mocking about in html/css. Also, his blog is only text and has no functionality, so yeah, sure use html/css, but most apps like youtube/twitter have a lot of functionalities and they need js.
"And because my sources are in git, pushed to GitHub,GitHub Pages is my host."-right, and if github is hacked so are you. So much for not worrying about security.
```
You don’t need Wordpress, or Hugo to put a blog online, or Angular, React or Next.js to put a web page online. Raw HTML and CSS do the job.
That being said, you’ll need to pick up some tooling or framework if you want to build a web app or add more interactivity or customization to your web pages.
```
So often people forget not everything sitting on the web has the same needs. saying 'you don't need a framework' ignores that, maybe i do infact need one, because otherwise i'd have to write it myself.
I feel like there should be some better way to recognize and promote solutions that are future proof. Like transpilers and site generators that only produce vanilla code for deployment. Because it wouldn't matter how dated the tool is. Sticking to vanilla only is not the only option.
But I guess there could still be vulnerabilities in HTML that may need to be addressed? Like cross domain or cookie security...
But then again, same for a vanilla stack.
It definitely seems like maximum future-proofness should be more of a thing.
The thing, auto-censureship should fit in, as well as the code a-n-d hardware life-lines, including how to reproduce the workflow outside of corporate claws.
My Wordpress blog has a system font stack (that's vanilla Wordpress with the current theme Twenty Twenty One), and a Lighthouse score of 100 Performance, 100 Accessibility, 100 Best Practices, and 98 SEO.
The only plugin that's relevant for that is WP Super Cache.
I don't know what the author did with his Wordpress, but even the awful Twenty Twenty theme with the broken fonts wouldn't give you a 19 score in Performance.
This is almost my stack, but I added PHP for rendering Markdown files (via Parsedown) and use include statements for common components like headers. I use an Apache server on a 512mb VPS and deploy by ssh and a git pull.
The only downside I have notice is that I can't easily put JS demos _within_ my rendered markdown, but I can work around it by stitching together multiple markdown files. Not pretty, but it works.
I worked in a project from 2010 to 2014 which was just HTML and CSS.
It was a University portal for teachers, students and admin staff that handled almost everything in the campus: grades, attendance, class schedule, downloads, renting books in the library, making room reservations, lunch vouchers for staff, a helpdesk system for students and staff, getting a free email account, etc.
The goal was to be simple enough for non-technical students and older teachers. Most things were one click away from the home page, which was just a bunch of colorful icons. You clicked one icon and could see schedule, grades and attendance. The teacher could edit grades and attendance of the whole class in a single screen.
There were no special requirements to drop JS. We just removed JS at some point and never added anything again.
Frankly it worked pretty well. The design was made by a professional rather than using off-the-shelf stuff.
What killed it was a migration to Bootstrap around 2015 after I left. For no reason. The layout ended up looking outdated compared to what we had, and the animations and javascript dropdowns were too heavy for the University's ageing computer fleet. The extra whitespace from default tables made everything too big to fit in a screen. Kind of a pity.
But by this point everyone was moving to phones anyway, so the university spent a couple million in an iOS/Android app.
That's impossible. You're going to need a backend, which at that point it stops being HTML+CSS and becomes LAMP or something.
The only thing I can think of that can be done in pure HTML+CSS that would drive any sort of revenue and could be considered a business is an affiliate marketing site. I suppose you could also run a survey site and collect feedback via mailto link, but that's really old school.
I've found for little blog sites like what the author talks about, templating is still really handy. https://sergey.cool is a very slim one that supports Markdown. There's no way I'm going to type up all a blog post and add in `<p>` tags as I go.
Well, that's fine if you're running a completely static blog. I keep my stack as slim as possible, but I still need CGI and a DB to maintain a comments section. I also have just a bit of server-side scaffolding to ensure that there's a standard look and feel to the site.
Comments used to be almost table stakes, but in the last decade or so, things have shifted so that I estimate that only somewhere around 5–20% of the blogs I encounter have them.
I've been using the same Middleman + Slim setup as a static site generator for 7 years now. Still outputs HTML+CSS for speed but with some nice writing features.
Version everything in your Gemfile, use rbenv, and and you're set.
I appreciate folks who do this, and they're not wrong that it works for them and their use cases.
But all the other complexity that comes along with the web and web development don't exist just because of those use cases.
Nothing wrong here, although the litany of "look i'm just using html and css" gets to be a bit much sometimes and it sort of irks me to see yet another and another posted on HN and up voted with nothing new to say about it.
I'd say probably Turbolinks is your best bet there. You basically drop it in, and then it prefetches all the links on your page, and when you click them, it replaces the DOM. It works quite well actually, Rails has been using it out of the box for years and years.
Sure, but all the problems come from the server side. You could suffer data corruption, power outage, domain name theft, whatever. I agree css and html is great but the author made this post specifically to feel superior about his theoretically perfect website, and i figure it's my job to inform him it's not theoretically perfect.
> How could you possibly consider writing HTML and CSS by hand? Those are just the output.
You know, HTML is rooted in SGML and digital humanism. The entire point of it is that you use it as a simple means for self-publishing of digital text (and HTML 5 "standards" portray it in that role, in case you've never had a look).
Granted, that isn't quite apparent when looking at the trainwreck that is HTML/CSS/JS. The solution (with SGML at least) is that you use your own custom markup vocabulary, including custom Wiki syntax for markdown and other short form syntax, and then convert that into result markup for delivery. The idea being that nothing can be as lasting for your specific purpose than your own text format.
But the self-proclaimed web heads didn't get it. They made CSS so absurdly powerful and "meta" to cater for the historic shortcomings of HTML, which is just a format for casual academic publishing locked in 1991. Not considering that you can, in fact, define your own elements and meta rules. Or at least, I don't have another explanation for the fact that everything around HTML has to change ad absurdum while HTML has to stay the same while it quite obviously isn't a good fit for the vast majority of content on the web. And that for some reason you absolutely have to send the same HTML to your mobile that you send to your desktop, and that CSS absolutely has to be the place to shift, re-layout and hide content for these different purposes.
no one that lived through the SGML/XML days would describe it as anything close to "simple." That's why the world has developed countless ways to get away from it all... JSON, yaml, markdown, etc. etc.
The world prefers ad hoc rather than formal and verified. Worse-is-better strikes again.
Which is ironic now that we have garbage like GraphQL and TypeScript moving us back to formalism, but built on top of dynamic ad hoc structures. Guys... this... this is bloody fucking ridiculous. It's like trying to build a house out of wet tissue paper.
Yes I did know that and I have had a look. Sass and CSS-in-JS were a godsend at their times. I give that all up so I don't have to type `sass watch` in the terminal once?
You make sense. The high-leveling and not refactoring adds to the service industry of jobs and con-Z-umerism. Since they look in the mirror showing of, the mirror answers "awsome" for any new flimsy blob addition. It all starts with both: hardware and software, both should be tuned within your philosophy. See my initial post on this page.
> "When I publish a new page, I need to link to it manually from the index page. I’m OK with that. It’s done in one line. It also allows me to have more control over when I want the page to be “published”."
I've sometimes wondered whether pg's essays are done with just HTML and CSS — it kinda looks that way, [0] but I'm not expert enough to be able to tell.
Those poor Lighthouse scores are what you get when you put no work into refining your site's performance. This is especially true for an out-of-the-box Wordpress implementation. I have a React project with 100s across the board, but I wouldn't necessarily recommend a React implementation if high performance is key.
This doesn't even touch upon the topic of good developer performance, which is just as important as a set of Lighthouse scores. It's far easier to jump into an app with established build tools and documentation than it is to wade through a block of static HTML. Though if you're the only one working in your zen garden, have at it.
The site still fails Lighthouse, including the test for "Includes front-end JavaScript libraries with known security vulnerabilities." But wait, I thought it was just HTML and CSS!
Frontend performance is basically an iceberg[1]. We tend to look at the top and that's where the fashionable "silver bullet" currently is (whether Rust+wasm or HTML+CSS or a JS framework). Then we find deeper in the iceberg that even a `box-shadow` property[2] can ruin our day, and let alone images, YouTube and Twitter embeds, and all the things that make the web more interesting and powerful than a black page with white text.
Oh and it gets even more fun! A Lighthouse score in itself is an over-simplification. There's more to a great experience than the initial impression the site makes, like what happens to FPS when you scroll or click around[2]
[1] https://rauchg.com/2020/next-for-vercel#realistic
[2] https://ishadeed.com/article/new-facebook-css#using-an-image...