[HN Gopher] In defence of the boring web
       ___________________________________________________________________
        
       In defence of the boring web
        
       Author : Topolomancer
       Score  : 140 points
       Date   : 2022-01-30 14:52 UTC (8 hours ago)
        
 (HTM) web link (bastian.rieck.me)
 (TXT) w3m dump (bastian.rieck.me)
        
       | christophilus wrote:
       | Good read. Loaded fast. Looked great on my old iPhone. Very nice
       | use of font size and line height. A+
        
       | cblconfederate wrote:
       | That's a blog, not 'the web'
        
         | zinekeller wrote:
         | > That's a blog, not 'the web'
         | 
         | 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.
        
           | jasode wrote:
           | _> 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.
        
             | kingcharles wrote:
             | 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.
             | 
             | https://en.wikipedia.org/wiki/WikiWikiWeb
        
           | chasd00 wrote:
           | To me, it was cookies that opened the pandora's box of
           | webapps. Cookies are what made user sessions, shopping carts,
           | and everything else possible.
        
       | z3t4 wrote:
       | > 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).
       | 
       | You can pre-render svg images
        
         | ectopod wrote:
         | You can use pandoc to get html+mathml, which renders in Firefox
         | with no JS.
         | 
         | Chrome users can get an extension to render the mathml. Or you
         | can add mathjax to your page, but I don't bother.
        
       | cageface wrote:
       | It's good advice to use the simplest tool that gets the job done.
       | I like sites like this too.
       | 
       | But let's not jump from this to the conclusion that everything on
       | the web should be built this way. There's a place for things like
       | Figma too.
        
         | nesarkvechnep wrote:
         | Maybe Figma should've been a desktop app.
        
           | cageface wrote:
           | 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.
        
       | [deleted]
        
       | cblconfederate wrote:
       | 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>)
        
       | zzo38computer wrote:
       | 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.
        
         | ngrilly wrote:
         | Why should we totally avoid CSS? The default CSS is most web
         | browsers is not great for reading (no maximum width, mo margin,
         | etc.).
        
           | zzo38computer wrote:
           | 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.
        
       | MaxBarraclough wrote:
       | 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.
       | 
       | [0] https://indieweb.org/
       | 
       | [1] https://en.wikipedia.org/wiki/IndieWeb
        
       | schemescape wrote:
       | 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)?
        
         | whiplash451 wrote:
         | 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).
        
         | jbboehr wrote:
         | Only answering with what I'm familiar with, but AWS S3 provides
         | access logs:
         | https://docs.aws.amazon.com/AmazonS3/latest/userguide/Server...
        
       | bachmeier wrote:
       | > 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.
        
       | ozim wrote:
       | 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.
        
         | austincheney wrote:
         | > 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.
        
           | thaumasiotes wrote:
           | > 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.
           | 
           | Yes, we have that now. I made a tiny webpage for playing with
           | substitution ciphers, all in client-side JS (and CSS):
           | https://thaumasiotes.github.io/cryptogram/
           | 
           | Try putting text in the textarea on the left and see how long
           | it takes for the page to update.
        
           | pid-1 wrote:
           | IMO most of the complexity of the web comes from 2
           | shortcomings:
           | 
           | 1 - It's hard to reuse HTML. Consequently, even static sites
           | need some sort of build step.
           | 
           | 2 - HTML needed something like htmx, so every component could
           | be updated dynamically without writing JS code.
           | 
           | According to my estimations, if (1) and (2) were native to
           | HTML, 93% of all websites wouldn't need JS.
        
           | [deleted]
        
           | mdoms wrote:
           | > 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?
        
             | JadeNB wrote:
             | > 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.)
        
             | echelon wrote:
             | I spend 90+% of my time on the web reading and writing.
             | Only 5 - 10% using web "apps".
             | 
             | The web stack leaned too heavily into application
             | development, but its primary use is still in delivering
             | rich text.
        
               | austincheney wrote:
               | 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?
        
       | mrkentutbabi wrote:
       | Wow just the right moment, I am thinking to setup my own blog.
       | Commenting for bookMark.
        
         | MandieD wrote:
         | 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.
        
           | mrkentutbabi wrote:
           | Oh I didn't know this. Thank you.
        
           | kingcharles wrote:
           | Been using this site for well over a decade (under my old
           | handle) and never once noticed that. How is that possible o_O
        
       | susam wrote:
       | 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.
        
         | cutler wrote:
         | I worked with Perl's Template::Toolkit for many years and would
         | still recommend it for static site generation. TT3 is the
         | current version.
        
         | klodolph wrote:
         | 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.
        
           | Topolomancer wrote:
           | Very much in the spirit of Jeff Huang:
           | https://jeffhuang.com/designed_to_last/
           | 
           | 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).
        
           | masswerk wrote:
           | 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.
        
           | softwarebeware wrote:
           | You should be able to write HTML into any Markdown document
           | therefore having the best of both worlds
        
             | klodolph wrote:
             | 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.)
        
         | umvi wrote:
         | 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.
         | 
         | [0] For the curious -
         | https://gist.github.com/RPGillespie6/b133854b8ebf5a983cf32c2...
        
           | Shared404 wrote:
           | I'll jump on this bandwagon too.
           | 
           | I did it in Rust, because I wanted to learn Rust.
           | 
           | 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.
           | 
           | Oh, and my stack is nginx on Alpine currently.
           | 
           | Edit:
           | 
           | Code is here: https://git.sr.ht/~evan-hoose/SSSSS
           | 
           | 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.
        
             | qchris wrote:
             | 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.
             | 
             | [0] https://github.com/quietlychris/site
             | 
             | [1] https://github.com/kivikakk/comrak
        
               | Shared404 wrote:
               | Looks interesting, thanks!
               | 
               | 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.
        
       | z3t4 wrote:
       | > 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.
        
         | CharlesW wrote:
         | > _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.
         | 
         | Another option for this is to use WordPress as the CMS for your
         | SSG. For example, this post describes how to use Gatsby with
         | WordPress: https://liftoffllc.medium.com/gatsby-wordpress-
         | bringing-toge...
        
       | d12bb wrote:
       | 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.
        
       | TacticalCoder wrote:
       | > I am not using a load balancer, a database, or a cache server.
       | 
       | But it's serving some static assets from CloudFlare... (nothing
       | wrong with that: I'm just pointing it out)
        
         | Topolomancer wrote:
         | 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.
        
       | chrischapman wrote:
       | 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?
        
         | susam wrote:
         | 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.
        
         | Topolomancer wrote:
         | A fellow supporter! Maybe you like my manifesto from the 'olden
         | days:' http://web3.14159.annwfn.net/
         | 
         | I was full of vim and vigour then, now I'm only full of `vim`.
        
         | NikolaNovak wrote:
         | I'm not in that part of IT; what is WebPi in this context? My
         | mind went to some RaspberryPi stack, but perhaps it is this
         | instead? https://en.wikipedia.org/wiki/Web_Platform_Installer
        
           | david_van_loon wrote:
           | In this context it is a play on the Web 2.0 and Web3
           | terminology.
        
             | thfuran wrote:
             | One that means what?
        
               | luxpir wrote:
               | A number greater than 2 and less than 3, or slightly
               | beyond 3. Come on guys, grab a coffee.
        
               | ShamelessC wrote:
               | The grifters were just making sure they didn't miss out
               | on a recent rebranding effort.
        
       | chubot wrote:
       | 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.
       | 
       | https://hiccupfx.telnet.asia/ -- Get that "Client Side Render"
       | Look
       | 
       | https://lobste.rs/s/oybdsa/get_client_side_render_look
        
       | aaaaaaaaaaab wrote:
       | >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?
        
         | runarberg wrote:
         | I think support is being actively work on for Chrome and is
         | behind a feature flag.
         | 
         | https://caniuse.com/mathml
        
           | jraph wrote:
           | MathML support in Chromium is pushed by Igalia:
           | https://mathml.igalia.com/
        
         | extra88 wrote:
         | 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).
        
       | klodolph wrote:
       | "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.
        
         | eddieh wrote:
         | Yes, please use https://katex.org instead of MathJax.
        
           | susam wrote:
           | 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.
        
           | Topolomancer wrote:
           | Looks awesome, definitely giving it a try. Thanks!
        
           | MaxBarraclough wrote:
           | Looks great, hadn't heard of KaTeX before.
           | 
           | 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?
        
             | klodolph wrote:
             | 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.
        
         | throwawayboise wrote:
         | 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.
        
           | klodolph wrote:
           | 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.
        
           | Syonyk wrote:
           | 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.
        
             | tannhaeuser wrote:
             | 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].
             | 
             | [1]: http://sgmjs.net (my site)
        
           | robertlagrant wrote:
           | Hugo and others help with things like autogeneratings tags
           | and sidebars, that sort of thing.
        
         | marton_s wrote:
         | Jekyll. That's the _boring_ static site generator.
        
           | schemescape wrote:
           | 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.
        
           | bitexploder wrote:
           | 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
        
           | Topolomancer wrote:
           | 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)
        
           | klodolph wrote:
           | I might give Jekyll another shot, then.
        
             | lazyweb wrote:
             | Do it! I'm also currently migrating my old Wordpress blog
             | to markdown in Jekyll using a minimalist theme [1]. I'm
             | liking it so far.
             | 
             | [1] https://github.com/riggraz/no-style-please
        
             | Lio wrote:
             | I'm a big Jekyll fan too.
             | 
             | If that's not to your liking I guess you could try pandoc
             | and make.
             | 
             | I'm also a fan of vimwiki, but I guess you have to like vim
             | for that.
        
         | hoppyhoppy2 wrote:
         | 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)
        
         | swiftcoder wrote:
         | 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.
        
         | brabel wrote:
         | Hugo is just one of an incredibly large number of options to
         | help you generate your static website.
         | 
         | This list should have something for everyone:
         | https://jamstack.org/generators/
         | 
         | 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.
        
         | FireInsight wrote:
         | 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
        
       ___________________________________________________________________
       (page generated 2022-01-30 23:00 UTC)