asciiflow VS kawipiko

> 7. You can put them in the source where they are relevant.

> Got a hairy state machine? Stick a comment at the top with something like nomnoml's syntax and anyone can follow what's going on without having to trace through the code.

For that use-case a markup graph language is a poor solution. Use https://asciiflow.com instead to produce something that people can digest without needing a third-party tool that may not even exist anymore.

Many diagrams I am able to draw manually as I'm editing source code on emacs, but for more complicated ones I tend to use this: https://asciiflow.com . To each their own, so pick your favorite ASCII editor.

This isn't at all what you are asking for but I use it in code all the time for flow-charting logic. https://asciiflow.com/ And on the plus side, the output is very portable.

Combination of: - http://maaslalani.com/slides/ - for slides - figlet/toilet/cowsay/lolcat - for generating titles and ascii art - https://github.com/lewish/asciiflow - for charts and diagrams

So I used this website: https://asciiflow.com to draw out the diagrams and then pasted them into the LCDs using the monospace font! An LCD is 39x58 "ASCII tiles" FYI if you wanted to do this too!

AsciiFlow

[the author here] Indeed didn't mention anything about the shared webhosting solutions, just as I didn't mention anything about S3 + CloudFront, or Backblaze B2 + a CDN in front, or Cloudflare + WebWorkers, or AWS Lambda, or any other thousand ways to do it... (Like for example there is <https://redbean.dev/> which I find just so intriguing, and not far from my own <https://github.com/volution/kawipiko> proposal.)

Although shared webhosting is part of our web history -- and still a viable choice especially if you have something in PHP or something that requires a little-bit of dynamic content -- I don't think it's still a common choice for today.

It's somewhere in between dedicated cloud-hosting, because although you have an actual HTTP server (usually Apache or Nginx) that you can't configure it much because it's managed by the provider, thus it gives you the same features (and limitations) as an a proper cloud-hosted static site solution (such as Netlify); and between self-hosting because of the same reasons, having an actual full-blown HTTP server, but one you can't fully control, thus it gives you fewer features than a self-managed VM in a cloud provider or self-hosted machine. Thus unless you need PHP, or `htaccess`, I think the other two alternatives make a better choice.

The issue with "static sites", due to the de-facto requirements in 2022 imposed by the the internet "gatekeepers" (mainly search engines), is that they aren't "just a bunch of files on disk that we can just serve with proper `Content-Type`, `Last-Modified` or `ETag`, and perhaps compressed"; we now need (in order to meet the latest hoops the gatekeepers want us to jump through) to also do a bunch of things that aren't quite possible (or certainly not easily) with current web servers. For example:

* minification (which I've cited in my article) -- besides compression, one should also employ HTML / CSS / JS and other asset minification; none of the classical web servers support this; there is something like <https://www.modpagespeed.com/>, but it's far from straightforward to deploy (let alone on a shared web-host;)

* when it comes to headers (be it the ones for CSP and other security related ones) or even `Link` headers for preloading, these aren't easy to configure, especially if you need those `Link` headers only for some HTML pages and not all resources; in this regard I don't know how many shared webhosts actually allow you to tinker with these;

The point I was trying to make is that if you want to deploy a professional (as in performant) static web site, just throwing some files in a folder and pointing Apache or Nginx at them isn't enough. If the performance you are getting by default from such a setup is enough for you, then perfect! If not there is a lot of pain getting everything to work properly.