91–100 of 218 posts
I've been maintaining my personal website as plain HTML for five years now. I must say, I quite like this method. There's no substitute for practice when it comes to maintaining your skills at editing HTML and CSS. Yes, you must copy and paste content and not having layout page is annoying at times. But the overhead of just doing it yourself is surprisingly small in terms of the time commitment. Typically, I'll draft…
Plain HTML and CSS personal site experience can be vastly improved by using server side includes. Your webserver's SSI module is likely just the right amount of templating power so you don't have to re-write the same HTML in $x spots with a minimal attack surface and maintenance burden. SSI hasn't changed in 20 years and the nginx module at least hasn't even ever had a cve. ... This type of ssi templating is extremel…
Amazing how such a simple mechanism can remain useful even decades later.
I've been maintaining my personal website as plain HTML for five years now. I must say, I quite like this method. There's no substitute for practice when it comes to maintaining your skills at editing HTML and CSS. Yes, you must copy and paste content and not having layout page is annoying at times. But the overhead of just doing it yourself is surprisingly small in terms of the time commitment. Typically, I'll draft…
HTML was envisioned as an SGML application/vocabulary, and SGML has those power features, such as type-checked shared fragments/text macros (entities, possibly with parameters), safe third-party content transclusion, markup stream processing and filtering for generating a table of content for page or site navigation, content screening for removal/rejection of undesired script in user content, expansion of custom Wiki syntax such as markdown into HTML, producing "views" for RSS or search result pages in pipelines, etc. etc. See [1] for a basic tutorial.
[1]: https://sgmljs.net/docs/producing-html-tutorial/producing-ht...
Earlier quoted context omitted.
I recently learned the object tag can do what I wished for in the 90s... work as an include tag: Turn your back for twenty-five years, and be amazed at what they've come up with! ;-) Should reduce a lot of boilerplate that would get out of sync on my next project, without need for templating.
Unfortunately that will require the client to make additional web requests to load the page, effectively doubling latency at a minimum.
- HTTP/1.1 (1997) already reuses connections, so it will not double latency. The DNS lookup and the TCP connection are a high fixed cost for the first .html request.
- HTTP/2 (2015) further reduces the cost of subsequent requests, with a bunch of techniques, like dictionary compression.
- You will likely still be 10x faster than a typical "modern" page with JavaScript, which has to load the JS first, and then execute it. The tradeoff has flipped now, where execution latency for JS / DOM reflows can be higher than network latency. So using raw HTML means you are already far ahead of the pack.
So say you have a 50 ms time for the initial .html request. Then adding some might bring you to 55 ms, 60 ms, 80 ms, 100 ms.
But you would have to do something pretty bad to get to 300 ms or 1500 ms, which you can easily see on the modern web.
So yes go ahead and add those tags, if it means you can get by with no toolchain. Personally I use Markdown and some custom Python scripts to generate the header and footer.
I write my website and blog directly and entirely in HTML using BBEdit. For me, this is just much easier than any other method. I don't have to rely on any external system.
as always: imho.
ad "duplicated (html) code" in static webpages:
back in the 1990ties when a lot of people wrote html by hand, there was a thing called "server side includes" ...
* https://en.wikipedia.org/wiki/Server_Side_Includes
or just use some "ubiquitous" script-language like php for this simple task of orchestrating/including snippets/components of code etc. :)
just my 0.02€
Did he reinvent a static-site generator? Markdown, pandoc, makefile... Sounds like a job for hugo/eleventy/jekyll/whatever.
Jekyll also has a higher ceiling than Pandoc when you need a templating language, plugins, etc.