8 ms·

Writing HTML in HTML (2019)

53 points by blakewatson 3y ago

proc0 3y ago
Sure, when your site looks like it's from 1995. Client apps today have hundreds of custom features running simultaneously.
- superkuh 3y ago
  Of course you wouldn't use this if you're being paid to make an application for profit. You use less good technologies that make it easier to collaborate with other employees, or more importantly: whatever buzzword tech of the year gets you hired. But for personal sites where you get to choose? HTML. The commercial app you write will last a few years before breaking. But the HTML site will last forever.
- ben_w 3y ago
  > Sure, when your site looks like it's from 1995 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?
- MathMonkeyMan 3y ago
  A blog is a blog. There's always CSS and the "class" attribute to make things look however you want. Reading text and images doesn't require interactivity or scripting.
- akie 3y ago
  The site could benefit enormously from these 10 lines of CSS: https://news.ycombinator.com/item?id=32972004 https://news.ycombinator.com/item?id=32972004 It makes the site look modern instantaneously.
- al_borland 3y ago
  Most sites don’t need 98% of the trash running on the site. If the goal of a site is to display information, all the modals, advanced analytics, parallax effects, video ads, etc distract from main goal, rather than enhance it.
gerikson 3y ago
Updated post from 2020: https://ankarstrom.se/~john/articles/html2/ https://ankarstrom.se/~john/articles/html2/ 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.
- omoikane 3y ago
  I think what the author is arguing for is not so much about writing in pure HTML, but the fact the levels of indirections added by most existing site-generating frameworks restricts them from doing something that would have been possible with just pure HTML. This second article seem to argue for owning your own site generator that is a thin wrapper around HTML, to deal with more dynamic content while maintaining flexibility. 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.
Semiapies 3y ago
On the one hand, I think everyone should try to put together a simple website with a few pages in raw HTML, just to get an idea of how it works. And actual, semantic HTML is not terrible in this day and age, much better than it used to be. You don't have to learn a static generator to put up a website, because you're the static generator. 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.
jdthedisciple 3y ago
Here is a better solution: You write your blog post md directly into the body and deploy a builtin minimal md engine. <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> (replace js with script, which i cant write here on hn apparently) 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?
- ravenstine 3y ago
  Actually, yes. You can eliminate the body and HTML tags.
  - deleted 3y ago
    [deleted]
  - codetrotter 3y ago
    Here is an example of the kind of pretty minimal but valid HTML5 that I usually write when I write html by hand: <!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> Check it :) > Document checking completed. No errors or warnings to show. https://validator.w3.org/nu/#textarea https://validator.w3.org/nu/#textarea
    - mikae1 3y ago
      Don't forget Server Side Includes :)  The Page Title  The Article Title  <p>The article content</p>
hiAndrewQuinn 3y ago
When I remember to update https://build-100-websites.fun/ https://build-100-websites.fun/ with my recent antics (whew it's been a while), I like to write it in raw HTML just so I remember why I never ever do that anywhere else. 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/ 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.
jrm4 3y ago
It is so hard not to feel REALLY SMUG reading stuff like this, as someone who has run my own website as the working primary source for my college instruction for the past 15 years or so using https://zim-wiki.org https://zim-wiki.org. (before Markdown was much of a thing!) 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.
- account-5 3y ago
  Do you use the built in "theme" or style of the output html? Much as I love zim-wiki for my notes I really dislike the green on white coloring.
  - jrm4 3y ago
    Funny you should mention! 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. https://github.com/jaap-karssenberg/zim-wiki/wiki/Templates https://github.com/jaap-karssenberg/zim-wiki/wiki/Templates
- FourthProtocol 3y ago
  My website started as html in 1995, vanilla html, not even css or Javascript. It has evolved to accommodate stats, and at some point (whenever it was that it was first released) I created an ASP template to manage headers, footers, contacts. 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.
ulrischa 3y ago
Dreamweaver was perfect for this. It has templates and libraries and you wrote in a split editor with html and wysiwyg. Why was it abandoned by many web developers?
- JodieBenitez 3y ago
  We abandoned this because it produced markup that was horrible to maintain.
  - ulrischa 3y ago
    Not true. Dreamweaver produces very clean HTML
    - JodieBenitez 3y ago
      In 2024, maybe. We stopped using Dreaweaver 20 years ago, totally different story then.
      - ulrischa 3y ago
        Yes in 2024 it is a perfect static site generator but nobody uses it because it was a mess in the past
- foul 3y ago
  Complexity comes gradually. 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.
  - ulrischa 3y ago
    Dreamweaver produced clean html what a lie
CM30 3y ago
I'm not sure I agree that HTML is unpleasant to write. Honestly, even when I'm writing blog posts or articles, I often fall back to writing the HTML myself. It feels about as simple/complex as writing markdown, or using a WYSIWYG editor. Maybe I just don't like being limited by abstractions.
- jwells89 3y ago
  The main thing that bugs me about HTML is how it’s so easy to goof up closing tags and attributes. Yeah browsers can deal with malformations to some extent and modern editors help prevent them but it still feels not-great. 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.
  - mikae1 3y ago
    Remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
  - bentley 3y ago
    Funny, that’s a complaint I have about Markdown. Anytime I use superscript or subscript, or try to nest markup within a list or table or something, I always get the formatting wrong. Whereas in HTML it’s always easy to nest things properly, even when dropping implicit end tags (which I always do), because the rules are both self‐consistent and standardized across implementations.
    - naasking 3y ago
      I agree nesting is easier with HTML. Most of the content I write is not really nested though, particularly when writing notes, to-do lists, etc. the low ceremony of markdown is a huge win over HTML for simple content.
      - bentley 3y ago
malkosta 3y ago
I stopped looking at SSGs after this: for file in .md; do pandoc --quiet --template template.html $file -o "${file%.}.html" done
- Tomte 3y ago
  So no index or other listing of articles. No RSS. I‘ve been tempted a few times, as well, but it‘s a little bit too sparse for me.
- hnisoss 3y ago
  reminds me of tundra.sh https://frainfreeze.github.io/tundra/ https://frainfreeze.github.io/tundra/ (https://github.com/frainfreeze/tundra/blob/master/tundra.sh#L80 https://github.com/frainfreeze/tundra/blob/master/tundra.sh#...) just does a lil bit more ig
JonChesterfield 3y ago
I'm really liking writing HTML in markdown. Write the markdown, feed it to commonmark's parser, splice the text together in ad hoc sorts of ways. Robust, trivial. 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.
- ahmedfromtunis 3y ago
  For years, I had the same experience you're describing. Writing CSS felt more like guessing than anything else. 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.
  - ogab 3y ago
    What was the course you took?
foul 3y ago
You guys trying to revive the FrontPage/Dreamweaver era?
yladiz 3y ago
I did this for a time and had attempted to commit to staying “no build tools” but after writing a few blog posts and needing to move content of the post around as I was writing it, I gave up the masochism. I do think that it’s important to know HTML as a web developer, and to get your feet wet sometimes, but unless you’re really able to deal with the genuine annoyance of writing only HTML and are doing it for puritanical reasons I don’t think there’s any real reason not to use a tool, especially if you plan to add things to your website.

53 points by blakewatson 3y ago

Sure, when your site looks like it's from 1995. Client apps today have hundreds of custom features running simultaneously.

superkuh 3y ago
Of course you wouldn't use this if you're being paid to make an application for profit. You use less good technologies that make it easier to collaborate with other employees, or more importantly: whatever buzzword tech of the year gets you hired. But for personal sites where you get to choose? HTML. The commercial app you write will last a few years before breaking. But the HTML site will last forever.
ben_w 3y ago
> Sure, when your site looks like it's from 1995 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?
MathMonkeyMan 3y ago
A blog is a blog. There's always CSS and the "class" attribute to make things look however you want. Reading text and images doesn't require interactivity or scripting.
akie 3y ago
The site could benefit enormously from these 10 lines of CSS: https://news.ycombinator.com/item?id=32972004 https://news.ycombinator.com/item?id=32972004 It makes the site look modern instantaneously.
al_borland 3y ago
Most sites don’t need 98% of the trash running on the site. If the goal of a site is to display information, all the modals, advanced analytics, parallax effects, video ads, etc distract from main goal, rather than enhance it.

gerikson 3y ago

Updated post from 2020: https://ankarstrom.se/~john/articles/html2/ https://ankarstrom.se/~john/articles/html2/ 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.

omoikane 3y ago
I think what the author is arguing for is not so much about writing in pure HTML, but the fact the levels of indirections added by most existing site-generating frameworks restricts them from doing something that would have been possible with just pure HTML. This second article seem to argue for owning your own site generator that is a thin wrapper around HTML, to deal with more dynamic content while maintaining flexibility. 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.

Semiapies 3y ago

On the one hand, I think everyone should try to put together a simple website with a few pages in raw HTML, just to get an idea of how it works. And actual, semantic HTML is not terrible in this day and age, much better than it used to be. You don't have to learn a static generator to put up a website, because you're the static generator. 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.

jdthedisciple 3y ago

Here is a better solution: You write your blog post md directly into the body and deploy a builtin minimal md engine. <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> (replace js with script, which i cant write here on hn apparently) 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?

ravenstine 3y ago
Actually, yes. You can eliminate the body and HTML tags.
- deleted 3y ago
  [deleted]
- codetrotter 3y ago
  Here is an example of the kind of pretty minimal but valid HTML5 that I usually write when I write html by hand: <!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> Check it :) > Document checking completed. No errors or warnings to show. https://validator.w3.org/nu/#textarea https://validator.w3.org/nu/#textarea
  - mikae1 3y ago
    Don't forget Server Side Includes :)  The Page Title  The Article Title  <p>The article content</p>

hiAndrewQuinn 3y ago

When I remember to update https://build-100-websites.fun/ https://build-100-websites.fun/ with my recent antics (whew it's been a while), I like to write it in raw HTML just so I remember why I never ever do that anywhere else. 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/ 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.

jrm4 3y ago

It is so hard not to feel REALLY SMUG reading stuff like this, as someone who has run my own website as the working primary source for my college instruction for the past 15 years or so using https://zim-wiki.org https://zim-wiki.org. (before Markdown was much of a thing!) 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.

account-5 3y ago
Do you use the built in "theme" or style of the output html? Much as I love zim-wiki for my notes I really dislike the green on white coloring.
- jrm4 3y ago
  Funny you should mention! 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. https://github.com/jaap-karssenberg/zim-wiki/wiki/Templates https://github.com/jaap-karssenberg/zim-wiki/wiki/Templates
FourthProtocol 3y ago
My website started as html in 1995, vanilla html, not even css or Javascript. It has evolved to accommodate stats, and at some point (whenever it was that it was first released) I created an ASP template to manage headers, footers, contacts. 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.

ulrischa 3y ago

Dreamweaver was perfect for this. It has templates and libraries and you wrote in a split editor with html and wysiwyg. Why was it abandoned by many web developers?

JodieBenitez 3y ago
We abandoned this because it produced markup that was horrible to maintain.
- ulrischa 3y ago
  Not true. Dreamweaver produces very clean HTML
  - JodieBenitez 3y ago
    In 2024, maybe. We stopped using Dreaweaver 20 years ago, totally different story then.
    - ulrischa 3y ago
      Yes in 2024 it is a perfect static site generator but nobody uses it because it was a mess in the past
foul 3y ago
Complexity comes gradually. 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.
- ulrischa 3y ago
  Dreamweaver produced clean html what a lie

CM30 3y ago

I'm not sure I agree that HTML is unpleasant to write. Honestly, even when I'm writing blog posts or articles, I often fall back to writing the HTML myself. It feels about as simple/complex as writing markdown, or using a WYSIWYG editor. Maybe I just don't like being limited by abstractions.

jwells89 3y ago
The main thing that bugs me about HTML is how it’s so easy to goof up closing tags and attributes. Yeah browsers can deal with malformations to some extent and modern editors help prevent them but it still feels not-great. 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.
- mikae1 3y ago
  Remember that there are a few common elements, like <p> and <li>, that you usually don't need to close.
- bentley 3y ago
  Funny, that’s a complaint I have about Markdown. Anytime I use superscript or subscript, or try to nest markup within a list or table or something, I always get the formatting wrong. Whereas in HTML it’s always easy to nest things properly, even when dropping implicit end tags (which I always do), because the rules are both self‐consistent and standardized across implementations.
  - naasking 3y ago
    I agree nesting is easier with HTML. Most of the content I write is not really nested though, particularly when writing notes, to-do lists, etc. the low ceremony of markdown is a huge win over HTML for simple content.
    - bentley 3y ago

malkosta 3y ago

I stopped looking at SSGs after this: for file in .md; do pandoc --quiet --template template.html $file -o "${file%.}.html" done

Tomte 3y ago
So no index or other listing of articles. No RSS. I‘ve been tempted a few times, as well, but it‘s a little bit too sparse for me.
hnisoss 3y ago
reminds me of tundra.sh https://frainfreeze.github.io/tundra/ https://frainfreeze.github.io/tundra/ (https://github.com/frainfreeze/tundra/blob/master/tundra.sh#L80 https://github.com/frainfreeze/tundra/blob/master/tundra.sh#...) just does a lil bit more ig

JonChesterfield 3y ago

I'm really liking writing HTML in markdown. Write the markdown, feed it to commonmark's parser, splice the text together in ad hoc sorts of ways. Robust, trivial. 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.

ahmedfromtunis 3y ago
For years, I had the same experience you're describing. Writing CSS felt more like guessing than anything else. 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.
- ogab 3y ago
  What was the course you took?

foul 3y ago

You guys trying to revive the FrontPage/Dreamweaver era?

yladiz 3y ago

I did this for a time and had attempted to commit to staying “no build tools” but after writing a few blog posts and needing to move content of the post around as I was writing it, I gave up the masochism. I do think that it’s important to know HTML as a web developer, and to get your feet wet sometimes, but unless you’re really able to deal with the genuine annoyance of writing only HTML and are doing it for puritanical reasons I don’t think there’s any real reason not to use a tool, especially if you plan to add things to your website.