I use a very similar stack to host my personal website that contains a blog and a collection of other pages. Here are the similarities between my stack and that of the author of this post:
- No JavaScript except for loading MathJax only on those pages that contain mathematical equations.
- No cookies, no banners, no account creation, no ads, no affiliate links.
- All content and code is stored in a Git repository.
- The HTML files are served using Nginx.
- The website is hosted on a Debian system.
- No load balancer, no database, no cache server, etc.
However, there are some differences too. Here are the differences between my stack and that of the author of this post:
- All my content is written in plain HTML. Some of the content in my website goes back to 2001 when the obvious way to write content was in plain HTML. I know that Markdown can be easier to write and read and I do use Markdown for GitHub READMEs. However, for my website, I just stayed back with HTML.
- I have my own small Common Lisp program to generate the static HTML files. It picks all the content HTML files, puts them within a common HTML template to ensure headers and footers are consistent across pages, generates a blog post list page, generates RSS feeds, etc.
By the way, I use Emacs for editing HTML. Its HTML+ mode has a pretty good collection of key sequences for editing HTML. For example, the key sequence C-c 2 inserts "<h2></h2>" and places the cursor in between the tags so that I can start typing the heading immediately, C-C C-o enters an arbitrary tag along with its closing pair (if applicable) and places the cursor in between the tags, C-c C-e automatically closes any open tag, etc. These key sequences along with automatic indentation of nested HTML elements by Emacs does a really good job at making editing plain HTML very convenient.
Yep I recently did exactly this for my personal site as well (including initially writing HTML by hand), but instead of lisp I wrote a ~100 line python script[0] so that I could write future content in Markdown instead of HTML. Yes I'm aware of Jekyll and Hugo and such, but even those were too complex for my personal site. It only took about an hour of my time to write it, and now anytime I push markdown changes to my git repository, GitHub Actions runs the markdown through the python script and generates the site which is hosted on GitHub pages.
It just takes a directory structure with markdown files, and converts each file to HTML while adding a header and footer. I use it on a few sites now, and honestly I should redo the code but it works conveniently and I have other stuff to do.
It really is not great code. It even shells out to markdown to do the rendering - bad for all sorts of obvious reasons. (but the right choice for my use case).
If you want to use it, be my guest. Just know that it's bad and ugly and you could write it better yourself in not very long.
Jumping on the bandwagon of the guy that jumped on the bandwagon, because you mentioned potentially re-doing your own code at some point so might be interested: my personal site [0] looks very much like this (and is also written in Rust), but uses the comrak [1] crate to convert blog posts from Markdown to HTML on the fly before formatting with the header/footer theme. Using comrak lets you write in-line HTML (so you're not stuck with only Markdown syntax if you want to do something fancier like code blocks or <math></math>), and the whole site ends up <150 LoC, including route definitions.
It handled the one potential HN hug-of-death event I've had without issues while running on the smallest DO droplet offered, and has basically been issue-free since I got it up and running.
I may very well do something similar at some point, though I've also thought about using it as an excuse to redo whenever I want to learn $LANGUAGE, or writing a markdown (or subset of markdown) interpreter at some point.
Definitely going to read through the code more closely as well - I've been meaning to find some short and well written Rust.
> instead of lisp I wrote a ~100 line python script[0] so that I could write future content in Markdown instead of HTML. Yes I'm aware of Jekyll and Hugo and such, but even those were too complex for my personal site.
Why does this kind of "complex" matter? By all means code if you enjoy it, but it sounds like minutes of coding saved you seconds of installing something that already exists, and got you a setup that is less standard and so harder to maintain.
The real "complexity" that matters, as someone who has used most modern static site generators and front-end js frameworks, is in not knowing how or what broke, and how to fix it, when inevitably something breaks. E.g: with jekyll if you develop or modify content on a windows box, test locally, and then push to GH Pages, but Pages builds the site using unix, and some ruby gem or jekyll plugin doesn't work consistently across them, and it takes a good bit of experience and googling around the errors to find a fix or a workaround.
If you essentially made your own static site generator, at least you would know what went wrong and come up with the straightest line to the resolution (even if that's just modifying the build output by hand in an extreme case).
If we compare like with like and assume that in both cases you're developing locally on windows and running on GH Pages, something established like Jekyll has a much better chance of working consistently on those different OSes than a hand-written script, IME.
Yeah, absolutely. But we're talking about optimizing for complexity ("do I understand this?") rather than compatibility/features/functionality/security/community support/any of the other things you get from using established frameworks.
I'm not defending the decision, but I have worked with several folks who have this approach to using their own tools — and at times I lean in this direction too, until I have encountered breakages more often than I care to "understand them" by using my own tools — and hence trying to dissect the motivations behind that choice.
I have found lots of static site generators more focused on blogs than a more traditional personal website. While they can be used for non-blog sites (I use Hugo for my own site), I can see how they can be daunting when first approaching them and seeing nothing but blogging examples and templates.
I've also stuck with plain HTML for my personal website, and stayed away from stuff like Markdown. It feels like too often, with Markdown, I'd be figuring out questions like "how do I get Markdown to emit the HTML that I want?"
It's not like Markdown saves me that much typing over HTML in the first place, and the HTML is a lot easier to think about.
And yes... Emacs is my HTML editor of choice, too.
I don't really get the saving or convenience of Markdown, esp., if you are already used to typing HTM. (HTML for simple things is easy and short enough, and fancy things are beyond Markdown anyways.)
Here's my stack:
Hosted webspace (yes, like it's the 1990s!) Apache/Unix, simple PHP templates for headers and footers, basic navigation, etc w/o JS, for the blog a custom (server-side) script generating virtual article locations, navigation, meta data, basic chrome, and a RRS feed from a simple data-file and reading static HTML for the content from static files. BBEdit for editing. No analytics. (The webspace comes with Webalizer, but this stopped working some 10 years ago. I don't care.)
And yes, there are special pages with full-fledged JS apps, as well, or blog posts featuring complex things, so nothing is chiseled in stone. If there's a purpose to it. However, a visitor should be able to get an idea what a page is about without JS.
I use it because I'm just too tempted to play with extra formatting with html+css, that's probably the only reason. Also my main notes app (Obsidian) is markdown.
I have to admit that I like the 'bare' feeling of Markdown...it just looks a little bit 'cleaner' to me (quotes here because that is super subjective).
To be perfectly honest, that sounds terrible. Like, just completely awful. I definitely don't want to do that.
HTML by itself is easy enough to work with. The syntax for HTML is pretty basic. A little verbose sometimes, but since the late 1990s it has not been hard to find a text editor that will do things like autoindent and insert closing tags automatically.
Markdown introduces a ton of weird syntax to save you a little bit of typing. That's a good tradeoff when you are striving to keep people engaged with your site... that's the reason why Markdown is used on places like Stack Overflow, Reddit, a bunch of blogs, etc. Asking people to learn how to use BBCode is a kinda tall order compared to Markdown.
However, the cost-benefit of Markdown is completely different on a my personal blog. I'm using somewhat more complicated stuff on my blog... a few standard elements like boxes that say "note", a couple charts here and there with D3, occasionally something interactive, maybe some math with KaTeX. It's not super-complicated stuff, but it's stuff that's often no fun to try and write in Markdown. Even <table> is nicer in HTML than Markdown.
I would rather deal with one simple syntax (HTML) rather than a weird mix of two syntaxes (HTML + Markdown) where one of them (Markdown) has bunch of weird edge cases. As far as I can tell, the main benefit of Markdown for personal blogs is that it's slightly less typing. Not exactly a killer feature in my eyes. (It's also very frustrating when trying to write technical documentation.)
Having written a heck of a lot of raw HTML, Markdown, LaTeX, [gnt]roff, Docbook, and probably a few other markup formats:
- Markdown is quite close to plain-ASCII writing. (AsciiDoc or reStructured Text might be even better).
- Markdown + pandoc gives a tool for producing numerous output formats or endpoints, including PDF, ePub, and others.
- Markdown avoids fiddly bits like balancing open/close tag pairs.
- Markdown supports features such as footnotes and tables of contents which HTML does not have simple and easy equivalents for.
Yes, there are things which are possible in HTML which Markdown itself doesn't readily provide. Off the top of my head: underlined text, coloured text, and nested superscripts. That said, these are either infrequent needs or are better accomplished through other means (e.g., styles, code-highlighting within code blocks, etc.).
Markdown does allow for about 99.9% of my HTML-tagging needs, with a lot less overhead and cleaner syntax. Which is a win.
If I were to move in any direction, it would probably be LaTeX for more complex source documents.
Markdown syntax IMO is pretty fiddly. I find myself messing with spacing, or with line breaks between list, or things like that. On the whole I find Markdown more annoying than HTML... Markdown is just less typing.
"Markdown" doesn't support TOCs or footnotes any more than HTML does... both TOCs and footnotes are non-standard extensions to Markdown that your particular Markdown engine may support, in ways which are frequently incompatible with other Markdown engines. I found it no trouble to put footnotes in my HTML-based static site generator anyway. I don't expect TOCs would be any different, but I don't use TOCs on my site. Superscripts of any kind are a Markdown extension in the first place, and I'm always so unsure where the superscript ends that I have to try different things and reload the preview until it looks right (this is one of those fiddly bits that drove me away from Markdown).
I guess if you want to target PDF + ePub and others, yes, use something like Markdown. I'm putting video content or interactive content in my blog often enough that it's just not something that would work anyway.
Don't get me wrong... I love using Markdown for stuff like READMEs on GitHub. It's just that for something like my blog, where I put a bit more care into things, Markdown really gets in the way.
In the case of superscripts, the issue is that Markdown doesn't have a concept of nested elements.
In HTML superscript and subscript tags may simply be nested:
10<sup>10<sup>10</sup></sup>
Markdown implementations ... vary, but typically either a ^<text><whitespace> or ^<text>^ block indicates superscript. That .. doesn't permit nesting:
10^10^10
or:
10^10^10^^
... either way is ... ambiguous or undefined. HTML's start/end tag syntax wins.
More generally, where simply writing text, the notion of having bounded blocks and pairs can become confusing, especially where <div>, <section>, or <article> tags are used. I'll frequently find myself unbalanced in those. To the extent that Markdown allows me to Just F*cking Write and not worry about markup ... that's a win. Ironically, for all its reputation for fiddlyness, LaTeX's use of a double carriage return as a paragraph delimiter affords a similar simplicity to much straight prose.
Markdown extension of course vary, but my point remains that using Pandoc (my usual approach), I have as first-class ready-at-hand elements tables of contents and footnotes, both of which I use extensively. I don't have a good formula-entry capability, for which I'd turn instead to LaTeX. I'd also argue that basic table entry in Markdown beats HTML, and is moreover very easy to script given structured input, e.g., with a sed or awk one-liner.
The fact that you seem to be focusing on short content rather than longer pieces may explain some of our differences of views. My typical focus is essay-to-book-length text-heavy documents. If I'm kicking out a short HTML fragment, sure, just code it up directly. Where I'm writing a work which is not specifically intended for the Web, but which could include HTML among other formats, Markdown and LaTeX start making far more sense.
I find complaining about hypertext references to streamline discussion and avoid duplicate content a ... curious gripe in the context of hypertext-authoring tools, but power to you.
When I'm writing HTML, there isn't a ton of nesting. It's mostly <h2> <h3> <p> <figure> at top-level. No parent tags. This is standard HTML, the <html> and <body> are implicit. Sections are implicitly delimited by header tags. Open and close tags are generally no more than a few lines apart. I'm strongly in favor of "semantic" tags in general (and so, for example, I do not use <cite> <em> or <i> interchangeably, even though they are all styled the same) but AFAIK the <section> tag does not really serve a useful purpose, semantically, because sections are already delimited by header tags (and screen readers and the like understand this).
Anything like an <article> or <main> or whatever is going to get handled by the template. I only write the contents of each article, and let tooling handle the boilerplate. Just like how you don't write navigation bars or TOCs in markdown, you let the tooling do that for you.
Re: tables, to each their own... I find tables in Markdown to be a bit fragile and easy to screw up when I'm changing them. I don't like having the columns shoved into one line of text. And any time I'm sticking tables in a document I'm likely to want to adjust the styling a little. Tables are easily the thing I hate the most about markdown.
> Markdown extension of course vary, but my point remains that using Pandoc (my usual approach...
Using some particular markdown tooling you get TOC and footnotes... and using some particular HTML tooling I can get the same thing.
For particular pages I often add small snippets of CSS or JavaScript, which I can just stick in <style> tags at the top, or <script> tags at the bottom, because it's just standard HTML.
I hope you are aware that nearly every markdown renderer respects full HTML right? As soon as you open a HTML tag, you can just treat its insides as HTML. That way you can just write prose when you are in content mode. If you want to switch to dev/designer mode you simply have to open a HTML tag.
When you can simply think of markdown as a syntax tooling on HTML that is widely human readable (by non-web developers!) without stopping you from having the full power of HTML whenever and however you like it, how is that not a win?
> As soon as you open a HTML tag, you can just treat its insides as HTML.
That is not entirely true. There are some edge cases to consider and while considering edge cases, we first need to decide which Markdown flavour we want to use. Some of us also need to consider if we are willing to commit to that Markdown flavour for the next 10, 20, 30 years or so because we do not want to "fix" our content again when some content rendering breaks due to edge cases when we switch from one Markdown renderer to another. The multiple flavours of Markdown handle several edge cases in different ways.
Let us pick CommonMark as the Markdown flavour for this comment. Here is an interesting edge case that is relevant to your comment. Consider the following Markdown input:
<div>
*foo*
</div>
The above Markdown input is rendered as the following HTML output:
So as soon as we open an HTML tag, we can't just treat everything inside it as plain HTML. The content within the HTML tags may get interpreted as Markdown as shown in the second example above. Now granted, all of this is clearly specified in the CommonMark specification and these edge cases are handled in this manner for good reasons (such as providing a way to use Markdown syntax within HTML tags, in the above example). But one has to understand the specification very well and keep these edge cases in mind while mixing HTML and Markdown.
For many people, these edge cases are not a problem because they write simple Markdown that would probably get rendered the way they expect, without any surprises. I can understand why many people prefer to use Markdown to write their website content. But there are also some of us, who find this extra complexity to be not worth it, especially because editing plain HTML files is nearly as easy, if not more, with a good editor (Emacs, in my case).
> I hope you are aware that nearly every markdown renderer respects full HTML right?
Yeah, I'm aware.
> That way you can just write prose when you are in content mode. If you want to switch to dev/designer mode you simply have to open a HTML tag.
When I want to just write prose, I can use a WYSIWYG word processor. When I want to make a post on my web page, I can write it in HTML. I rarely benefit from having a third option... markdown, the "mediocre at all things" format, which is not good enough to replace a word processor from the 1990s and not good enough to use in place of HTML when I'm making my web page.
I do actually use markdown... for small snippets of notes. I have all my Emacs setup to edit markdown quite nicely. If the notes start getting too large and detailed, I copy and paste the notes to a word processor, so I don't have to deal with markdown's awful syntax. If the notes evolve into a blog post, I'll rewrite them in HTML--I always rewrite notes anyway, before posting. It's much more common that I start blog posts in a word processor, rather than markdown, though.
> When you can simply think of markdown as a syntax tooling on HTML that is widely human readable (by non-web developers!) without stopping you from having the full power of HTML whenever and however you like it, how is that not a win?
This argument is taking for granted the idea that people like markdown syntax, when I thought that I had been pretty clear that I don't like markdown syntax. I think it's just kinda mediocre at lots of different things, and in the end, is worse than just using plain HTML... except for a few niches, like READMEs on GitHub and comments on Reddit.
To be clear, markdown is not a win for using in my website because it makes my tooling more complicated, and it delivers no benefits.
I can understand why some people like it... surely you can try to understand that some people don't, and we don't just dislike markdown for no reason.
Yes, 100 times yes if you are really delivering documents to the browser.
It is a totally different thing if one is delivering 'web application'.
Web application is about manipulating data, having lists, text fields and editing content.
Delivering documents is about documentation, blogs, prose, maybe just image browsing.
If company is crapping JS/tracking all over content that can be delivered as a document it is annoying.
Just don't say that everything should be sans JS - because there are legitimate uses of JS and even those heavy JS frameworks if one is building rich editing experience.
> It is a totally different thing if one is delivering 'web application'.
Why? I think the unspoken alternative to boring is gross negligent incompetence.
It really doesn’t have to be that way. The web is 30 years old, JavaScript is 25 years old, and the mature DOM is 23 years old. Surely by now somebody can figure out how to dynamically add text to the screen with less than 10mb of JS taking less than 10 seconds to execute.
As a counter point I have written an OS GUI that is 2mb unminified and loads in the browser in about 55ms (give or take 5ms) including full state restoration. That’s pretty fast. Looking at various benchmarks JavaScript is now executing as fast as Java in many micro-benchmarks.
If this stuff is really that fast why we do we tolerate such incompetence writing frontend code? It’s like incompetence is built in by default as the standard expectation and everybody hires accordingly.
I have been doing this a long time and one of the largest problems I encounter is an absence of basic communication skills. I look at your comment and see HTML is too hard and if we had something else it wouldn't be too hard. Too hard is empty defensive posturing that announces some form of gap, typically insufficient training/preparation. When people hear too hard they only see you and a goal with a giant mystery in the middle that you cannot articulate. Are you claiming people lack the proper training?
Anyhow, assuming you are not trolling, my point is: writing plain HTML is not productive, as I need to repeat myself all the time. I can't create my own abstractions for reuse, as I would in most programming languages.
> Why? I think the unspoken alternative to boring is gross negligent incompetence.
That's.... that's just silly. How would you deliver, say, Trello as a boring website? Or Google Maps? Or Grafana? Do you really think the developers of these apps are grossly negligent?
Regardless, why does the experience differ so significantly? It clearly isn’t due to execution speed of the technology. Is it a leadership problem, a training problem, or something else? What’s missing?
> That's.... that's just silly. How would you deliver, say, Trello as a boring website? Or Google Maps? Or Grafana? Do you really think the developers of these apps are grossly negligent?
Of those, I've used only Google Maps. Like Google itself, GMaps was great when it started! And they continue adding new knowledge to it that makes it more useful. But, like Google itself (though not as bad), when it comes to the interface it feels like there's mostly change just for the sake of change, with little thought given to whether it's good or bad change, so long as it's new.
(I compare it to the StackExchange empire, which seems to suffer a similar churn mostly for the sake of the appearance of motion and of novelty.)
I still use only jquery "as a framework" and if I wasn't lazy could probably just move to more modern ecmascript. I stick to simple layouts and CSS and "POST" rather than make everything dynamic unless it absolutely needs to be. Of course I just work on my own and friends' websites and never really branched out from my day job of embedded coding.
Who paid for that OS GUI? How often did the requirements change? How many stakeholders your OS GUI has? Is it done project or is it "constantly evolving"? If it is constantly evolving how many developers are working on it? What is team turnover or is it only you working on it?
It is easy to throw "gross negligence" when you work on some pet project where you don't have to change direction every week. You don't have 10 customers wanting things which are mutually exclusive.
"Boring" is nice although my experience with Hugo is that it takes a nontrivial amount of effort to get it working in the first place, such that I couldn't use it for putting project documentation on github.io and definitely wouldn't call it "boring" in the sense used in the article. It is definitely a more complex scheme even if that complexity is front-loaded and you get to keep everything boring on the server and the client (with the exception of MathJax, for good reasons). (Aside: consider Katex!)
With Hugo, I ended up fighting with themes that wouldn't render correctly, and all the mess that is shortcodes. Shortcodes are nice in theory, but there should be a larger set of "standard" shortcodes that are expected to work across most themes (some nice subset of what Bootstrap gives you) and instead of custom syntax, it seems like you should be able to use standard HTML with custom tags.
Anyway... my experience with Hugo made me feel that I would even have an easier time wrangling a Wordpress installation. It's equally possible to archive a Wordpress site by taking a snapshot of the HTML, and I've done it, it's just that the "boring" web (as the author puts it) moves the failure points to your personal computer, rather than the server you run your site on.
Hugo/Jekyll were thoroughly overkill for my little blog, so I went looking at the absolute simplest static site generators I could find (with a minor preference for something written in rust). I landed on Zola, and hand-coded myself a set of templates. It has been working out pretty well.
There are so many options because creating a simple site generator is actually almost trivial, given there are great markdown-to-html converters, code highlighting libraries etc. that do the hard work for you already.
My own websites are all written in markdown using a little Go framework I wrote myself. Extremely simple, does exactly what I need, has none of the Hugo complexity (Hugo started simple as well but kind of added too many features over time). Highly recommend doing this for anyone who enjoy programming and writing their own tools.
https://getpublii.com is a great free, open-source option for less-technical users who want to generate a static blog that can be deployed to any web host (or Cloudflare Pages, Github Pages, Netlify, AWS, etc)
What's the boring-est way to run Jekyll locally? My main problem with Jekyll is that it required installing (and keeping up to date, I assume) a Ruby environment.
That’s worth mentioning, but I was looking to run the static site generator locally because the workflow of committing to Git, waiting for a build, etc. is too slow for iterating (and also difficult to debug when stuff inevitably doesn’t work as expected).
I have to admit that I found Hugo easier to work with from scratch. I am not used to working with Ruby, so I found setting up Jekyll to be quite an adventure... (now, truth be told, using GitHub to build my pages is definitely easier than having to use my own server with Hugo, but the _initial_ configuration of Jekyll appeared to be more complex for me)
I scripted up a dumb little Python+Jinja transformer with a dumb yaml file for vars. Its like 50 lines of code. Ifs really boring. I also use a little pandoc in my build script
KaTeX does not support LaTeX commands like \label, \eqref, \notag, etc. As long as one does not need them, KaTeX is good. But if one needs them, MathJax becomes necessary.
I often do need these commands, especially while writing proofs, solutions, or long mathematical posts. See https://susam.net/blog/integrating-factor.html for an example. These commands make it convenient to refer to previous results using equation labels and numbers in long articles.
One can work around the missing support for these commands in KaTeX by writing their own HTML to simulate the same functionality but it is nice to have MathJax do this for us automatically.
Basic question: does it share any code in common with MathJax? If not, why not just run MathJax once server-side rather than on the client? Does MathJax have browser-specific accommodations, or does it not map to HTML at all, or is it something else?
Both MathJax and KaTeX let you run once server-side, if that's your fancy.
They map to a combination of HTML and MathML, with a bunch of CSS rules.
KaTeX's JavaScript code is a mere 68 KB when gzipped. IMO, that's worth it, so I don't have to fuss about with Node.js as much when generating the site.
I like Hugo and made my personal website with it because:
1. It's supported on most free hosting like netlify.app (I use fleek.co for ipfs support)
2. It allows me to do anything I can do without it in a very similar way just with added templating, handling navigation, etc
3. I didn't know or care to look for comparable alternatives when I started using it and know I'm too invested in after making my own theme and converting all my wordpress to markdown with the added Hugo cherries on top
Yeah for a one-person personal site Hugo seems like overkill.
For a site that is just a collection of static pages, I think it's just as easy to write directly in HTML. HTML is no more difficult than learning some other markup language, especially if you have an editor that helps you.
It may be overkill at first, but run a site for long enough, and the static generator starts to make a lot of sense.
I originally had static HTML, but that was well over 10 years ago at this point. Soon you want to wrap your pages with a template to get rid of boilerplate and keep your site consistent. Then you want auto-generated indexes, and maybe you want to check for broken links, add width/height to <img> tags, etc.
My personal website has hundreds of pages on it, not counting the auto-generated index pages. Automation is a necessity at this point. It is still written in HTML... I never adopted anything like Markdown, and I've abandoned any use of custom syntax like Hugo's or various templating systems, at least, outside the static site generator code itself.
The problem with straight HTML, as opposed to one of the markdown-to-HTML pipelines, is that if you want to change something, it's really difficult (bordering on impossible, depending on how consistent you've been).
I migrated my blog a year and change back from Blogger to self hosted Jekyll (a rather consistent theme on this post...), and having the content, the "scaffolding" (HTML templates and such), and the render pipeline being separate means that it's trivial to change things if I want to.
As a recent example, I realized a few months back that my blog didn't render at all with Javascript disabled. That's not OK to me (it was a quirk of how the template I bought did a "gradual fade in" once the content was loaded - looks good, requires JS, I do not care about that sort of thing). To eliminate JS requirements, I had to eliminate that fade, and I had to change image embedding for a lot of things such that it didn't use lazy load - there was some JS based lazy load that meant post thumbnails and such didn't load. All I had to do was change the templates, re-render, and re-upload the site (I rsync stuff up). That would be harder to change in HTML.
The same goes for images and such. I end up with several versions of each image used - if your browser supports picture sets, it will "pick the best" based on what the browser thinks is reasonable, in terms of size and formats. I currently render to a few different resolutions of jpg (or png) and webp from the original source images. If I want to change that, add a new resolution, or add a new format, I just update a config file, re-render, and I'm done. That sort of thing helps with keeping the site "modern," if you care about it.
For an absolutely basic "few pages" site, sure, you can do HTML. But for anything with regularly updated content (I have ~260 blog posts and nearly 6000 images), it's well worth having some helpers to separate content from layout/formatting/features/etc. Despite that, it's still very much a personal only site, I'm the only author, it (now) renders without JS, sets no cookies, etc.
FWIW you can use any SGML processor to separate-out boilerplate from content files using entities (text macros), and more advanced forms of HTML templating. Makes sense since HTML itself, originally conceived as an SGML vocabulary, lacks these authoring features since present in the larger SGML context/toolchain. You can also typecheck your documents and even format markdown into HTML using SGML's SHORTREF feature; checkout [1].
Whenever I am reading about something in the vain of "boring tech" they miss the following:
1) The first is that many developers don't understand how to do anything simply. Doing things simply normally means actually thinking about what you are doing before hand and it doesn't feel productive.
2) Many developers don't understand how the underlying tech works. I've been working with developers that are working on a web product and I am absolutely sure they haven't done the w3cschools (or similar) HTML and/or CSS tutorials. Which are really basic things (here is what a h1 is for)
3) There is no-incentive for developers to do things simply. Much of the industry wants to pay people who know how to build something in <complicated enterprisey product> or <complicated opensource product>. They don't want people to provide solution built on "boring tech".
I don't see any of those changing anytime soon unfortunately.
Many developers don't understand any basics.
We're 20 years since HTML4 and still many developers are using `<a />` instead `<button />`...
It's of course only one from many examples.
A lot of people (devs, designers, pms etc.) don't understand... nothing.
They don't understand that someone may have poorer eyesight, that many people have slow Internet speed etc.
I'm getting tired of using the Internet, practically to every site I have some criticisms (forcing to open links in a new tab...).
> Many developers don't understand any basics. We're 20 years since HTML4 and still many developers are using `<a />` instead `<button />`...
I have literally been doing this for the last year when reviewing PRs. "What is the difference?" I am asked. One is an anchor and one is a button and they mean different things and are supposed to be used for different things.
It is infuriating to simply link the first or second result on google and quote just to throw it in peoples faces. I feel like a dick quite frankly but nobody bothers.
I used to be eager to point this out, and often wrote to site owners with a list of notes. Some thanked and corrected, others ignored.
But now I don't have the strength for it anymore, sometimes I feel like I'm the only one who cares about quality.
Now I've even limited the use of the Internet as much as possible, because practically every website is badly made, and it's unpleasant to use them [example from an earlier comment: if I want to open a link in a new tab, I'll do it myself. You don't have to force it (of course I know that exactly this problem is the fault of marketers and attempts to falsify statistics)].
I've pretty much given up. I do contracts now and just run the wheels off the contract and then move on. There is no point being invested. If quality doesn't come from the top, you might as well be King Cnut telling the tide not to rise.
Nice read. Firm supporter of Web Pi (3.1415). When it comes to building for the web today, I'm always amazed that "so much can be done with so little" and yet the default is the opposite - "so much is needed to deliver so little" - so irrational! Where did we go wrong? I wonder what Web Euler (2.71828) would have looked like?
My favourite phase of the web was Web Golden (1.61803). :) It mostly had static websites but some websites had tiny guestbooks that allowed a little user-generated content.
I remember some of the website hosting providers made it really easy to add guestbooks, even for someone with no programming experience. All one needed to do was create an HTML page that contained a <form> element with the "action" attribute set to a URL of a server-side script provided by the hosting provider. The server-side script would accept every comment submitted via the guestbook and automatically insert the new comment into a static HTML page after escaping the special characters properly.
There was Sketch before Figma, and it was great... if you were running macOS. Then Figma ate its lunch because they were able to support viewing and editing on every platform, and didn't require downloading and installing an application just to review and comment on designs.
Those advantages are only possible by either a) having a massive engineering team that can build applications for every device and a lightweight web app or b) building for the web.
Being a web app that runs everywhere and is always up to date is a big part of Figma’s success. They’ve already crushed a very strong native desktop competitor.
OP here---true dat; that's the MathJax script. To be honest, I haven't yet come around moving away from it, but this thread mentions some alternatives.
Sometimes I disable JS on my browser and then forget about it, only to be reminded when a website is totally non-functional without it. Then when I go back I realize with total horror how bad things were.
Pop-ops on every, single website, with dishonest UX to opt-out of tracking each time you visit. The text I may only need to see for two seconds to remind myself of something is obscured by this huge modal that takes so long to load.
With the exception of YouTube and a few other things I use, I greatly prefer the internet in 2022 when I forget to reenable JS. News sites and blogs are blazing fast, with no tracking dialogues to dismiss, and text gets drawn to the page immediately.
I'll add webfonts to that. For me uBlock disables them everywhere (because that's not what they're for) and it's good to see how by simply missing a font (which can always fail to load, not just by deliberate blocking) you can't use pages because the icons aren't there and the buttons aren't labeled in any other way.
Such a page immediately falls into DNS blocking - I won't bother just because they don't know the basics of web development...
At one time, even the old Opera had such options as standard. There was even a fixed CSS edition.
Then they switched to Blink and everything became difficult...
Yes, but there are a few things you should consider too:
* Avoid CSS, too. (Fortunately the program I have, has the option to disable CSS, so I use that and it looks better, then.)
* There should be a better way to display math equations (e.g. using MathML, possibly with a JavaScript code that only executes if MathML is not implemented in the client)
I usually just use plain text files myself. However, Fossil uses HTML, and I would prefer to make it a different HTML. I started to make one using libfossil, but have not completed it yet and it lacks some features.
Well, at least I prefer the default CSS (with only a few exceptions; I think "img { max-width: 100%; }" aught to be a default rule). However, they should be configurable by the end user to the settings that that user wants, instead of being different in different web pages.
The problem is not the website that uses wordpress instead of some 'artisanal' static site generator. The former is something that mom and pop can self-host, the latter is something the aspiring programmer enjoys doing. The problem is that modern browser programming, and modern javascript in particular are way more complicated than they need to be for people to build their own websites. That's why everyone moves their communities in discord instead of building a self-hosted chat. The browsers are powerful today, but the APIs can be really complex. I have webrtc in mind in particular, dealing with that is something that easily can demoralize someone who is not a professional programmer. Even in the old days of Flash, you could host a Red5 server on a VPS and have a video conferencing app going, nowadays most people go with SaaS solutions because it's too damn hard. We need to be talking about how to make the browser an accessible platform wher everyone can build (including moms and pops, remember Frontpage?). NOT to keep over-complicating even the smallest tasks in order to please the BigCorps (looking at you, CSS complexity). Instead of another framework let's bring in more <tags> (Hello, <marquee>)
Well, not really. They are pretty much direct opposites. Do you mean "sometimes boring can be good"? I can get on board that. But it can't be exciting, because then it isn't boring.
> I am using Hugo,2 a static website generator, to generate, well, static HTML files.
Many people think it's a binary option of handwriting HTML vs using WordPress, but with a static site generator you get the advantage of both. I think static site generator are still exiting technology. Also companies are still sending Word-files to each other, while you are using git, and the web to publish, so you are still 30 years ahead of the rest - who are trying to get ahead by taking short-cuts like jumping on the latest hype train.
> Many people think it's a binary option of handwriting HTML vs using WordPress…
It's worth noting that one can handwrite HTML for WordPress themes and emit static sites from WordPress. This is a great option for those who like SSGs but want rich content management.
> Also companies are still sending Word-files to each other, while you are using git, and the web to publish, so you are still 30 years ahead of the rest...
Word + track changes is way more sophisticated and powerful than sending around text files with Git.
The reason companies use Word is not just because they don't understand how to use Git, it's because Word is actually very powerful in its own right and contains a powerful version control system which allows you to add annotations and make reviews. It's kind of like having Git + GitHub built into one program.
Using Hugo isn't exactly "boring"... that's a pretty sophisticated system.
But what is "boring" really? Unsexy? Why is Javascript not boring, but Hugo gets a pass?
I use SvelteKit bc that's super easy for me to understand and helps me get to the content faster than say, Middleman or Hugo, so for me SvelteKit / Vercel is the most "boring" thing I can do.
I'm not sure I would frame it as "boring" ... the issue is that CONTENT (which should be interesting, and is what people are there for) is obscured by TECH.
So the tech should get out of the way of the content, instead of asserting itself front and center. That is "exciting" to me.
> I am not using JavaScript, except for a minimal installation of MathJax to be able to render equations
This is the part I don't get. I know, many commenters on this site don't like Javascript, but a little Javascript isn't going to slow your site down. Conversely, you can completely avoid Javascript by doing a bunch of work on the server, yet slow your site just as badly as with Javascript (or even worse). It would be more productive to talk about the type of content rather than the arbitrary choice of technology used to create the page.
> I am not using JavaScript, except for a minimal installation of MathJax to be able to render equations in blog posts (and I know of no other simple way to accomplish this goal).
The author mentions using server logs for understanding traffic:
> I am not using any cookies or additional ways of user tracking. Instead, I am using GoAccess to generate static reports based on the webserver logs—no user-facing parts are involved, and IP addresses are anonymised.
I've considered doing this as well, but I'd prefer not to have to run and maintain my own server, if possible.
Is anyone aware of a cheap hosting service for static sites that provides HTTP logs (even if only in aggregate)?
I believe OVH offers what you are looking for (website hosting with HTTP logs and aggregated statistics, I leave it to you to look at pricing and decide whether it is cheap in your reference frame).
JavaScript is not the problem. That people forgot how to use the simplest tool to get the job done, and to not use more than needed, that's the problem.
I agree with the article's points that many of today's websites are bloated and user-hostile. A 'spartan' website like that is a refreshing change. I'd add one more virtue to the list: it doesn't deliberately break Reader Mode.
The ideas listed are similar to those of the sadly overlooked IndieWeb community, [0][1] and they complement them. Ideally, the web should be both indie and boring.
If the purpose of the web is to be informative than it can to be boring. Maybe the visual presentation will not be up to todays expectations but that is another thing.
Markdown is great but sometimes it can be tricky to get the exact look and feel that you need.
>I am not using JavaScript, except for a minimal installation of MathJax to be able to render equations in blog posts (and I know of no other simple way to accomplish this goal).
I remember MathML support used to be bad. Is it still the case?
Not only is browser MathML support lacking, authoring MathML kind of sucks. Anyone familiar with the basics of LaTeX for mathematical equations (human-readable LaTeX) will prefer to write that and let someone else's code render it (as MathML, as SVG, as a raster image).
There’s a very faint, tiny “favorite” in the line of faint, tiny links right below the title of comment pages for bookmarking. It took me about three years on HN to notice it, but now I have a wonderful, shareable collection of the cleverer things posted here.
The original web as envisioned by Tim Berners-Lee is basically a collection of internetworked and interconnected documents, which a blog is definitely a part of it. Blame Google's ChromeOS ambitions (especially pre-Android integration) for opening the Pandora's Box of WebApps.
>Blame Google's ChromeOS ambitions (especially pre-Android integration) for opening the Pandora's Box of WebApps.
Chrome OS is 2011 (first announced 2009). But before that, lots of people wanted the power of so-called "web apps" in the 1990s as we can see from various technologies getting introduced. And some even before Google incorporated in 1998:
- ~1995 Sun Java plugin for browsers
- ~1995 Netscape Navigator added Javascript
- ~1996 Macromedia Flash plugin
- ~1999 Microsoft IE XMLHttpRequest() function to fetch dynamic data
- ... many others I forgot
In 1998, I was able to order airline tickets on the internet for the first time on US Air and Southwest Airlines websites. In 1996, Mapquest had online maps to calculate driving directions. At this early stage, we're already past the "world wide web is only static documents" idea.
I built a "Google Docs" in 1997 using Java applets (couldn't raise funds, too early). And HoTMaiL had launched the previous year, bringing email to the web, which is certainly one of the closest things I can think of to the first "web app".
WikiWikiWeb launched in early 1995. I'm trying to think what could classify as the first "web app"? I was on the Web in 1993 and there wasn't much of any use on there. Writing web apps was hard because there were no tools for it. I ended up writing most of my back end code in C. Which sounds crazy until I realize I'm writing it all in C# now.
We could have built everything we have without cookies. Start a session and pass the session id back to all the links for that user and go fom there. So, instead of the Cookie header, you'd have the same information in the GET/POST parameters.
- No JavaScript except for loading MathJax only on those pages that contain mathematical equations.
- No cookies, no banners, no account creation, no ads, no affiliate links.
- All content and code is stored in a Git repository.
- The HTML files are served using Nginx.
- The website is hosted on a Debian system.
- No load balancer, no database, no cache server, etc.
However, there are some differences too. Here are the differences between my stack and that of the author of this post:
- All my content is written in plain HTML. Some of the content in my website goes back to 2001 when the obvious way to write content was in plain HTML. I know that Markdown can be easier to write and read and I do use Markdown for GitHub READMEs. However, for my website, I just stayed back with HTML.
- I have my own small Common Lisp program to generate the static HTML files. It picks all the content HTML files, puts them within a common HTML template to ensure headers and footers are consistent across pages, generates a blog post list page, generates RSS feeds, etc.
By the way, I use Emacs for editing HTML. Its HTML+ mode has a pretty good collection of key sequences for editing HTML. For example, the key sequence C-c 2 inserts "<h2></h2>" and places the cursor in between the tags so that I can start typing the heading immediately, C-C C-o enters an arbitrary tag along with its closing pair (if applicable) and places the cursor in between the tags, C-c C-e automatically closes any open tag, etc. These key sequences along with automatic indentation of nested HTML elements by Emacs does a really good job at making editing plain HTML very convenient.