In defence of the boring web
bastian.rieck.me
bastian.rieck.me
- 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.
[0] For the curious - https://gist.github.com/RPGillespie6/b133854b8ebf5a983cf32c2...
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.
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.
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).
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.
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.
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 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).
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.)
- 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.
https://news.ycombinator.com/item?id=30142334
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 HTML superscript and subscript tags may simply be nested:
10<sup>10<sup>10</sup></sup>
10^10^10
10^10^10^^
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.
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.
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?
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>
<div>
*foo*
</div>
<div>
*foo*
</div>
<div>
<p><em>foo</em></p>
</div>
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).
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.
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.
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.
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.
> It's hard to *reuse* HTML
And not:
> It's hard to use HTML
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.
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?
It's also not like Trello is some wonder of software engineering either (or that impressive functionality wise).
The web stack leaned too heavily into application development, but its primary use is still in delivering rich text.
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.)
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
[1]: http://sgmjs.net (my site)
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...).
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.
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 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.
I was full of vim and vigour then, now I'm only full of `vim`.
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.
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.
But it's serving some static assets from CloudFlare... (nothing wrong with that: I'm just pointing it out)
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...
* 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, 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.
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.
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...
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.
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.
So I guess "boring" is relative?
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
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.
You can pre-render svg images
Chrome users can get an extension to render the mathml. Or you can add mathjax to your page, but I don't bother.
> 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)?
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.
Markdown is great but sometimes it can be tricky to get the exact look and feel that you need.
I remember MathML support used to be bad. Is it still the case?
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.
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.
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.