<html>
<body>
# Blog Post Title
<br>
Welcome to this simple blog post
</body>
<js>
document.body.innerHTML = document.body.innerHTML.split('<br>').map((line) => line.trim().startsWith('# ') ? `<h1>${line}</h1>` : `<p>${line.split('# ')[1]}</p>`).join(''); // add more md features here if desired
<js/>
</html>
Obviously move the JavaScript to its own file and embed it to avoid repetition across blog entries. Plus, move it into 'DOMContentLoaded' event handler to be safe.
Could it get any more elegant and beautiful?
I use Hugo and I actually prefer writing HTML over MD.
Maybe, but why do things the hard way? Even if your editor autocompletes, typing the angle brackets is more cumbersome than Markdown.
> Also remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
Having to remember random trivia like this is exactly why writing HTML is awful.
Just thought I'd post this "novel" idea since most people do love their MD.
<p> and <li> don’t ever need to be closed, do they? Closing would only be necessary if leaving them open would introduce ambiguity, but it never does.
5-10 lines of VanillaJS maximum for some basic (and custom!) MD features is all I need.
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>Hello</title>
<style>
/* css here */
</style>
<header>
<h1>Cool beanz</h1>
</header>
<nav>
<ul>
<li>Home
<li><a href=/foo.htm>Foo</a>
<li><a href=bar.htm>Bar</a>
</ul>
</nav>
<article>
<h2>The Life and Dreams of Irish Setters</h2>
<p>Widely appreciated for their qualities, the Irish Setter is a breed of dog to behold.
<p>Lorem ipsum and so on and so forth.
</article>
<footer>
<p>Copyright © 2024, Bob Schmob
</footer>
> Document checking completed. No errors or warnings to show.
It's borderline bizarre to have watched this method of doing things kind of die out, and then also come back in the form of "static site generators" -- which, frankly, are still way clunkier than this.
Write in Zim, export to html, rsync to site. Easy.
Used to update things whenever a new ASP version was released, but haven't bothered for years.
Process is simple - copy ASP template, rename, fill in the content, FTP to hosting Co and done.
I'm not much of a programmer or designer at all, but probably my most popular thing is the "EightFiveZero" theme I made for Zim, which the author of Zim linked to from the wiki and makes me almost feel like a real programmer or something.
Also, I don't want to dump on this dude but I've authored literally hundreds of entries on my 2 blogs since 2019 using Markdown. I doubt I'd ever bother to write that many using plain HTML.
I have being doing the same for my website since ~20 years ago, where my input is mostly pure HTML, and I generate static HTML pages from those with a few scripts. My website does look rather antiquated, but I consider that a feature.
On the other hand, I've written a lot of HTML since the 90s. And there's a dirty secret behind why so many static generators exist--the effort of slapping together something that builds a site how you want it is similar to learning an existing system. Often, that's a short build script rather than some expansive framework.
Maybe I just don't like being limited by abstractions.
That’s why I like HTML for the site’s frame and markdown for the content. The amount of HTML is then finite and easy to keep correct and Markdown is harder to mess up due to its simplicity.
If I’m feeling really fancy, and the need is really there, I might add some PHP for something that needs to be done server side. It’s simple and it works.
My typical tool of choice for static sites and plain old prototyping remains Hugo, which rounds out at least half a dozen other websites I'm the sole contributor to right now, like https://hiandrewquinn.github.io/selkouutiset-archive/. Like everything you have to amortize the one time cost of learning it over the n times you use it. If you only ever make one website, raw HTML might be fine -- if you're trying to make 100, some experimentation might be worthwhile.
You will not find reasonable to reparse HTML spit out from Dreamweaver or Word to fit js/cgi parts in there but withstanding 5 years of work you may find perfectly sane to compile JSX. Plus most of the people in the field never wanted to mantain two very different stacks for work and play, it's also a good way to dogfood.
Also you can recover better in plain text when markup is messed up vs a wysiwyg editor.
Css on the other hand I hate more every day I look at it. Write some, see if it behaved as expected, it did not. Iterate until angry. There's something fundamentally wrong in my mental model for what the style text is likely to do to the appearance of the page.
A few weeks ago I decided that enough's enough. After years of writing CSS, I decided to refresh my knowledge with an intermediary level course. It turns out, a lot of stuff got mixed out, a gaps formed and grew over time.
Now, I enjoy writing CSS again as I find it more predictable and behaves as expected.
for file in .md; do pandoc --quiet --template template.html $file -o "${file%.}.html" done
just does a lil bit more ig
I‘ve been tempted a few times, as well, but it‘s a little bit too sparse for me.
The commercial app you write will last a few years before breaking. But the HTML site will last forever.
Tail end of 96 at least, even the link uses CSS. In principal you can also write JS manually within HTML.
> Client apps today have hundreds of custom features running simultaneously.
How many of those features are adverts and user-unwanted tracking that you need a GDPR compliance team for?
It makes the site look modern instantaneously.