[HN Gopher] The appeal of using plain HTML pages
___________________________________________________________________
The appeal of using plain HTML pages
Author : todsacerdoti
Score : 184 points
Date : 2022-04-30 17:07 UTC (2 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| pipeline_peak wrote:
| Years ago I had a simple blog site hosted by 1&1. Because dynamic
| layouts are so expected to keep pages modern, I found it's often
| a hassle to go static because web hosting platforms often come
| with WordPress or some templating engine.
|
| I wish I knew a way around this because my knowledge of web
| design is incredibly small and I intend to keep it that way.
| pooper wrote:
| If you use sane markup, modern browsers have "reader mode" that
| will take care of presentation for the most part.
|
| If you don't want to learn web design, you don't have to learn
| web design. Keep creating and serving sensible html pages and
| you will be alright.
| notriddle wrote:
| > I wish I knew a way around this because my knowledge of web
| design is incredibly small and I intend to keep it that way.
|
| Just copy the CSS from http://bettermotherfuckingwebsite.com/
|
| Anything else is probably overkill.
| togaen wrote:
| I love reading all the hate the author is getting here. It means
| he's right.
| jefftk wrote:
| HTML as an authoring language is underrated, but several
| commenters are confusing "writing HTML" with the aesthetic of
| nearly unstyled HTML. I think this is happening because the post
| we're discussing is not itself an example of what the author is
| describing: it's authored in DWikiText.
|
| An example (that I maintain) of what the author describes:
| https://www.bidadance.org. Each of the pages is just plain HTML
| on disk.
| cmroanirgo wrote:
| Looking at the article's source and then yours, I see no
| correlation. The author is clearly talking about authoring in
| html without any tooling, whereas yours clearly has a tooled
| event list. It's not an article taking about whether external
| files are used. In fact, the article talks how they style it to
| match their wiki, & that the article is not authored in
| DWikiText at all.
|
| Edit: you cheated by changing uri. The point still stands for
| your home page
| jefftk wrote:
| Sorry, I put the URL back to the root of the site. (I'd
| changed it to a page that I thought better illustrated this
| approach.)
|
| The events list is created with JS, yes. But that's the only
| thing on the whole site (~25 pages) that works that way.
|
| Here's another site I maintain this way where the events list
| is plain HTML: https://www.kingfisherband.com
| tedunangst wrote:
| It's not like the post is unclear that it's talking about a
| site other than itself. People just can't read good.
| thunderbong wrote:
| Why aren't any of the paragraph tags closed?
| enriquto wrote:
| Because it's unnecessary in html5, just like closing li, td,
| tr tags. When you use implicit tags (body, header, etc) and
| auto-closing tags (li, p, tr, td,...) then html becomes
| refreshingly lean and human-editable.
|
| EDIT: for a nice summary, look at google's html style guide.
| Section 3.1.7 is particularly neat [0].
|
| [0] https://google.github.io/styleguide/htmlcssguide.html#Opt
| ion...
| irrational wrote:
| I don't understand how they are optional.
|
| <p>Qed.
|
| <img src="some_image.jpg">
|
| And
|
| <p>Qed.</p>
|
| <img src="some_image.jpg">
|
| Are going to give me different results.
| jefftk wrote:
| It's are "optional" in the sense that the spec says it's
| optional and defines what that means: "A p element's end
| tag may be omitted if the p element is immediately
| followed by an address, article, aside, blockquote,
| details, div, dl, fieldset, figcaption, figure, footer,
| form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main,
| menu, nav, ol, p, pre, section, table, or ul element, or
| if there is no more content in the parent element and the
| parent element is an HTML element that is not an a,
| audio, del, ins, map, noscript, or video element, or an
| autonomous custom element."
| trey-jones wrote:
| I can't believe the committee approved this spec without
| consulting me. I can see that I'm not the only one that
| feels this degree of agency in syntax is a bridge too
| far. Clearly this part of the spec was written by a Ruby
| developer.
| jefftk wrote:
| The specification is just codifying what browsers already
| did in practice.
|
| There was a time when people thought we might be able to
| change web development practice and browsers to something
| more consistent, but (a) what they chose was XHTML and
| (b) the benefit of switching was not there.
| irrational wrote:
| LOL. So I can memorize or check that list every time I'm
| using a p tag (and, of course, I'm relying on someone not
| doing something like changing the display property of a
| block element to inline), or... I can just use a closing
| p tag. I know which one is infinitely easier for me.
| jefftk wrote:
| You can memorize the list, but it's easier than that:
| things that can go in a paragraph (which includes images)
| let the <p> continue, while things that can't (which is
| the long list there) close the <p>. In practice you get
| used to it very quickly.
| niconii wrote:
| I mentioned "block elements" in my other comment, but to
| be clear, CSS has no effect on how HTML is parsed, so the
| display property isn't relevant here.
|
| Furthermore, you need to know about this rule even if you
| do write `</p>`. If you write this: <p>
| <div>hello</div> </p>
|
| it is _invalid_ HTML. This is because the paragraph is
| auto-closed, and then your code is equivalent to this:
| <p> </p><div>hello</div> </p>
|
| resulting in an error because of the extra `</p>` after
| the `</div>`.
| legalcorrection wrote:
| Do browsers actually do that?
| jraph wrote:
| They can't produce imbalanced tags because it's
| impossible to represent in a DOM tree.
|
| They will indeed auto close the (first) paragraph, and
| also auto open a new <p> element because of the extra
| closing </p> tag.
|
| Try it out by typing this in your address bar and open
| the inspector:
| data:text/html;charset=utf-8,<!DOCTYPE
| html><p><div>hello</div></p>
|
| The generated HTML (document.body.parentNode.innerHTML):
| <head></head><body><p></p><div>hello</div><p></p></body>
|
| Browsers will go out of their way to produce a (valid)
| DOM from pretty much any string (as per the HTML5 spec).
| (Almost?) nothing is a syntax error. You won't get a
| HTML5-compliant browser to show a parse error to the user
| in HTML (of course, this is not the case in XHTML).
|
| edit: sorry niconii, I edited my comment under your feet.
| niconii wrote:
| Just to add to this, HTML parsers will attempt to make
| sense of any random line noise you give it and turn it
| into a DOM. When I say something is "invalid" HTML, what
| I mean is that it's not allowed by the spec and will
| result in an error if you run it through a validator
| (which you should do!)
|
| For example, try running the following document through
| the W3C's HTML validator[1]: <!DOCTYPE
| html> <html lang=en> <title>Test
| Document</title> <p> <div></div>
| </p>
|
| The HTML spec contains a list of all possible parse
| errors[2].
|
| [1] https://validator.w3.org/nu/#textarea
|
| [2] https://html.spec.whatwg.org/multipage/parsing.html#p
| arse-er...
| jraph wrote:
| It is allowed by the spec afaik (the spec precisely tells
| browsers how to interpret this, so everything is
| perfectly specified in the spec boundaries - and so it's
| not "out of spec").
|
| Of course, that screams "MISTAKE" that a validator should
| warn you about. Like a linter that would spot missing
| extra parentheses for an assignment in a if condition in
| C-like language. It is allowed to not put the
| parentheses, but it is recommended to put them.
|
| And of course, that makes "Valid HTML" (almost?)
| redundant (There are probably "vocabulary" errors that
| are possible, like a missing src attribute for an img or
| a missing title tag in head - don't take my words on this
| though).
|
| div in p is not invalid, it's outright impossible to
| obtain from HTML parsing.
|
| You _can_ obtain this by doing this in JavaScript:
| document.body.appendChild(document.createElement("p"));
| document.body.firstChild.appendChild(document.createEleme
| nt("div")))
|
| Or by parsing as XHTML:
| data:application/xhtml+xml;charset=utf-8,<!DOCTYPE
| html><html xmlns="http://www.w3.org/1999/xhtml"><head><ti
| tle>Hello</title></head><body><p><div></div></p></body></
| html>
|
| You get: document.body.innerHTML
| <p xmlns="http://www.w3.org/1999/xhtml"><div/></p>
|
| Which I realize is actually a bit scary, I go out of my
| way to write XHTML in the hope any error will be caught,
| but parsing as text/html actually produces a valid dom
| where parsing as XHTML won't necessarily.
| niconii wrote:
| This is not quite right. The HTML spec specifies not only
| what browsers/user agents are allowed to do, but also
| what document authors are allowed to do.
|
| While the HTML parser does _handle_ errors, to conform to
| the spec, document authors must not make these errors.
|
| Here is an excerpt from the spec[1]:
|
| > As described in the conformance requirements section
| below, this specification describes conformance criteria
| for a variety of conformance classes. In particular,
| there are conformance requirements that apply to
| _producers_ , for example authors and the documents they
| create, and there are conformance requirements that apply
| to _consumers_ , for example web browsers. They can be
| distinguished by what they are requiring: a requirement
| on a producer states what is allowed, while a requirement
| on a consumer states how software is to act.
|
| Furthermore, a user agent is not required to correct
| errors, and can simply halt at the first error[2]:
|
| > The error handling for parse errors is well-defined
| (that's the processing rules described throughout this
| specification), but user agents, while parsing an HTML
| document, may abort the parser at the first parse error
| that they encounter for which they do not wish to apply
| the rules described in this specification.
|
| [1] https://html.spec.whatwg.org/multipage/introduction.h
| tml#how...
|
| [2] https://html.spec.whatwg.org/multipage/parsing.html#p
| arse-er...
| jraph wrote:
| I stand corrected! Thank you. I should have read the spec
| before posting.
| niconii wrote:
| Yes, that is a case where it's not legal to omit `</p>`
| if you don't want the image to be inside the paragraph.
| Take a look at the spec[1], which outlines exactly when
| it is valid to omit tags.
|
| The `p` element in particular has pretty scary rules, but
| it basically boils down to "if it doesn't make sense for
| this to be inside a paragraph (usually because it's a
| block element of some kind), it ends the paragraph."
|
| [1] https://html.spec.whatwg.org/multipage/syntax.html#op
| tional-...
| jefftk wrote:
| More details: https://html.spec.whatwg.org/multipage/syntax
| .html#optional-...
| niconii wrote:
| Just to clarify, HTML5 didn't introduce this, it's been the
| case since at least 1993.
|
| https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
| jefftk wrote:
| Before HTML5 it was common to hear things like
| "technically you don't need it, but it's not to spec so
| don't do it".
| zerocrates wrote:
| Probably mostly a casualty of that window when people
| were trying to make XHTML happen, so all the SGML-isms
| like omitted close tags became verboten.
| niconii wrote:
| Well, then they were wrong, because it's always been part
| of every HTML spec.
|
| Perhaps they were thinking of XHTML, which did require
| all tags because it was based on XML.
| nicoburns wrote:
| I believe before html5 they weren't required, but what
| the parsed DOM tree looked like wasn't clearly defined if
| they weren't, and in practice different browsers did it
| differently meaning you could very easily end up with it
| rendering differently in different browsers. html5 fixed
| that.
| niconii wrote:
| Oh, for sure, actually _parsing_ HTML was awful before
| HTML5. The spec sometimes diverged from how browsers
| actually interpreted HTML, and error correction basically
| boiled down to browsers trying to reverse-engineer each
| other to figure out how they handled broken HTML. HTML5
| was a godsend for actually standardizing all of that.
| vmception wrote:
| Browsers literally would not render with one tiny syntax
| error/spec-deviation in your HTML
|
| No different than having a JSX syntax error in React
| today
| Macha wrote:
| In XHTML strict mode, which basically nobody used.
|
| In XHTML transitional, and HTML1-4, what you'd get is
| browsers with divergent understandings of your DOM tree
| structure such that content that worked fine in one would
| be a horribly mangled mess (often breaking layout in
| difficult to read ways) in another browser.
| niconii wrote:
| Okay, I've gotten a bit carried away with HTML spec minutia
| elsewhere in these comments, mainly because this stuff
| really isn't common knowledge among web developers and it's
| hard to resist talking about it.
|
| However, I also want to add to the other point here;
| namely, "why do this in the first place?"
|
| Google mentions "file size optimization" in the style guide
| linked above, and it led to criticism on HN and elsewhere
| along the lines of "sure, maybe shaving off a few bytes
| adds up for Google, but you're not Google." However, this
| really isn't why I do it, and I think maybe it's poisoned
| the discussion a bit.
|
| For me, it's mostly about reducing visual noise. It's not
| necessarily less typing if you're using an editor that
| auto-inserts closing tags, but I think it's harder to read
| with the end tags, particularly when it comes to tables.
| For instance, consider this table (which, if you're
| curious, is about Super Nintendo audio samples):
| <table> <tr><th>sample rate</th> <th>data rate</th>
| <th>max length</th></tr> <tr><td>32000 Hz</td>
| <td>18000 byte/s</td> <td> ~3.641 s</td></tr>
| <tr><td>16000 Hz</td> <td> 9000 byte/s</td> <td> ~7.282
| s</td></tr> <tr><td> 8000 Hz</td> <td> 4500
| byte/s</td> <td>~14.564 s</td></tr> </table>
|
| And now, take a look at it without the optional end tags:
| <table> <tr><th>sample rate <th>data rate
| <th>max length <tr><td>32000 Hz <td>18000 byte/s
| <td> ~3.641 s <tr><td>16000 Hz <td> 9000 byte/s
| <td> ~7.282 s <tr><td> 8000 Hz <td> 4500 byte/s
| <td>~14.564 s </table>
|
| Personally, this is much easier for me to read and
| maintain. There's also much less chance of me accidentally
| mismatching opening and closing tags, since I've eliminated
| almost all of the closing tags besides </table>.
|
| On top of that, let's be honest,
| <html><head></head><body></body></html> is just useless
| boilerplate. We all know what goes in the head and what
| goes in the body, and I think we can all figure out where
| the HTML starts and ends. The browser knows all of this
| too, which is why all of those tags are completely
| optional. Not only does getting rid of that make the code
| less noisy, it solves the age-old problem of "should I
| indent the head and body or not?" (Though, in practice, I
| still keep <html lang=en> so that I can specify the
| language for people who use screen readers. </html> is just
| silly, though.)
| litoE wrote:
| I've used htp (https://sourceforge.net/projects/htp/) to manage
| what are essentially HTML-only web sites. It provides the ability
| to use "include" files and macros, which allow me to give all the
| pages a consistent look and feel that can be easily changed. I
| usually create a simple makefile so that all the HTML files can
| be updated as necessary whenever the source files change.
| brimble wrote:
| Good old m4 can get you pretty far, as a template system for
| generating html.
| layer8 wrote:
| Reference with tutorial here: http://htp.sourceforge.net/ref/
|
| One selling point is that it only uses regular HTML syntax, so
| no need for dedicated syntax highlighting. Development seems to
| have stopped though since 2015.
| jklinger410 wrote:
| <link href="/~cks/dwiki/dwiki.css" rel="stylesheet"
| type="text/css">
| ilaksh wrote:
| https://gemini.circumlunar.space/
|
| https://github.com/runvnc/tersenet (note that Gemini is a real
| system, mine is just an idea)
| 11372 wrote:
| This is what happens when UNIX terminal users bring their anti-
| gui baggage to the web. He doesn't even use pure html he's got
| all kinds of dynamic stuff going on.
|
| Advocate for simple and easy to read UI if you want but come on
| now.
| alx__ wrote:
| Honestly I feel these sorta of posts are just trolling for
| views. Hey if you wanna make your site feel like a
| '90s/Brutalist design throwback that's cool. But don't act like
| you're a more enlightened developer.
|
| When you're just relying on browser defaults and there no basic
| styles to make the text readable. The pages are a challenge to
| understand. You can have plain html but using CSS to create
| some visual hierarchy would go a long way. Feels like there's
| two text sizes and two colors.
| PaulHoule wrote:
| I'd say the author is one of the most respected tech bloggers
| out there.
|
| With pure HTML and possibly some cleanly included JS he could
| get any visual appearance he wants, such as the common hero
| video or the effects you see where scrolling manifests
| differently as you scroll through different parts of the
| document.
| aseipp wrote:
| You can be a good writer but none of that really changes
| the thrust of the parents point which, I think, is that: if
| you want easy upvotes on a site like this, you can just
| post some variation of "javascript bad, web 1.0 html good."
| If you can stretch this idea into 3 or more paragraphs,
| even if you say fundamentally _nothing_ new that hasn 't
| already been seen 100 times, you're virtually guaranteed to
| get a bunch of upvotes and "DAE?" comments about how epic
| of an approach it is.
|
| In this case though, the author isn't submitting it, so
| it's not like they're the culprit. But even if they were
| it's also not really an indictment of any sort either;
| happens to everyone who writes online; it's the siren song
| of "engagement" with your work. (Lots of people here want
| to believe this site is somehow fundamentally different
| from Reddit or any other forum where "internet points"
| dictate the flow of content. It isn't; the tics and
| triggers are just different. Topics like this are a good
| example.)
|
| > With pure HTML and possibly some cleanly included JS he
| could get any visual appearance he wants
|
| With default browser font sizing and spacing? Yeah, sure,
| you can get any _bad_ look you want from pure HTML and some
| JS. CSS is practically mandatory for webpage readability
| these days, but it 's all a moot point since the OP doesn't
| seem to be arguing against CSS in any form anyway (and even
| literally admits he uses it.) Honestly the linked support
| site is mostly OK in this regard; though I'd blow up the
| font size a point/point-and-a-half more, add a tiny bit
| more line spacing, and make the margins bigger.
| nottorp wrote:
| > no basic styles to make the text readable
|
| You mean dark grey text on light grey background?
|
| Or a mobile stylesheet that displays one paragraph and half a
| photo on a 5k monitor and makes you scroll for the rest?
| gowld wrote:
| The very short post says:
|
| "our current support site [https://support.cs.toronto.edu/]
| is that most basic thing, a bunch of static .html files
| sitting in a filesystem (and a static file of CSS, and some
| Javascript to drop in a header on all pages)."
| TAKEMYMONEY wrote:
| That's the thing, the author here _is_ using CSS and the
| hierarchy is still very poor and difficult to parse. It 's
| the worst of both worlds.
| TAKEMYMONEY wrote:
| HTML comments to Stack Overflow pages? Display: table? Floats
| for layout?
| errantghost wrote:
| At that point they might as well have hired it out to someone
| on fiverrr (not a dig at people who work fiverrr at all.)
| jefftk wrote:
| That page is not an example of what the post is about: it's
| written with his Wiki software:
| https://utcc.utoronto.ca/~cks/space/dwiki/DWiki
| Bancakes wrote:
| It's ironic you should call anything UNIX baggage since that
| whole website is a few kilobytes and renders instantly. As
| opposed to any 5MB JS-filled flaming cistern of a site a modern
| developer would make.
| blowski wrote:
| That's a false dichotomy. There are plenty of <100KB sites
| that look good, render instantly, and work very well.
| Bancakes wrote:
| You must be from 1995 or something because I haven't seen
| one popular site like that.
| bachmeier wrote:
| These days, it's easy to type your markdown into a text area and
| then use a JS library to convert it to html. If they're already
| loading Javascript, all they'd have to do is insert the necessary
| Javascript in there. No need to write any html.
| swayvil wrote:
| Does PHP count as plain HTML?
|
| How about PHP + CSS?
| 0des wrote:
| Imagine my smug face as the pendulum finally swings back to me,
| with my hand typed, hand crafted, fair trade, organic and bespoke
| HTML. For my next trick, I will achieve the unthinkable and show
| you how I launch my blog without a dual redundant k8s cluster.
| markdown wrote:
| > how I launch my blog without a dual redundant k8s cluster.
|
| Filezilla? rsync? Please share your secret!
| TAKEMYMONEY wrote:
| > my blog
|
| ...is the usual use case for the "why not just use HTML?!"
| argument. Still, even at the enterprise level, considering
| SSR's popularity, the "pendulum" has been in favor of static
| HTML for a while.
| Closi wrote:
| You mean static HTML loaded onto serverless cloud storage
| with cloudfront, using Hugo to compile markup into HTML with
| a CI/CD pipeline created to push the content up to your S3
| bucket, then with a headless CMS visual editor which sits on
| some SaaS platform, with any server-side interactions written
| in Lambdas?
| ant6n wrote:
| Exactly, plain html!
| vmception wrote:
| Sounds tedious, I propose we make scripts for all these
| steps and bundle it alongside the frontend framework that
| _renders_ static html
| tshaddox wrote:
| > static HTML loaded onto serverless cloud storage with
| cloudfront
|
| That's just a verbose way of saying "a file hosting
| service."
|
| > using Hugo to compile markup into HTML with a CI/CD
| pipeline created to push the content up to your S3 bucket
|
| What's wrong with that though? You could describe any
| computer technology in arbitrarily high level of depth to
| mock how complicated it is. Text editors sound very
| complicated too if you describe their internal data
| structures, the window server the GUI runs on, the
| operating system's context switching system, etc.
| jameshart wrote:
| For some reason
|
| using a bash script to munge a few files together then a
| cron job running to rsync them to an Apache server
| running on a VPS
|
| is considered morally and technically superior to
|
| using a JavaScript tool to build a site then having a
| GitHub Action push the files up to an S3 bucket with a
| cloudfront distribution in front of it.
|
| There's no obvious reason for this, other than a belief
| that if something _can_ be done with 50 year old
| technology, it _should_ be.
| smm11 wrote:
| Just responding to note the use of "bespoke" in the wild.
| Macha wrote:
| It's not that rare a term, HN search has 13 pages of just
| titles using it: https://hn.algolia.com/?dateRange=all&page=8
| &prefix=false&qu...
| cxr wrote:
| bob1029 wrote:
| In my estimation, the point the parent comment is trying to
| make is regarding the unfortunate extent to which the
| developer community currently relies upon technological
| sprawl and other unnecessary complexity.
| mdp2021 wrote:
| It's not perfectly clear, but estimates do not go far away
| from "What a satisfaction it will be, when I will return in
| control with my properly crafted markup. Next, I'll prove a
| simple server suffices to serve it".
|
| About 'snarky', I never understood what it is meant to mean
| exactly (in spite of many reviews of the guidelines) but I
| took it to be a variant of bluntness for short-tempered
| expressions of contempt. I would not interpret it to cover
| criticism in general, especially of practices.
| krsdcbl wrote:
| Feel like this post confounds "plain html" for "minimal styling"
| eurasiantiger wrote:
| Simple can be powerful. For example, the humble Apache directory
| listing can be JS-enhanced to a blog, a photo gallery, an album-
| per-folder music player and so on, and without JS it gracefully
| degrades to a list of posts, images or whatever media, or to a
| folder structure -- just hide in .htaccess whatever files you
| don't want visible.
| ape4 wrote:
| KISS
| api wrote:
| This would be far more versatile as an approach if HTML could
| include other HTML. Not SSI but built into the spec and requiring
| nothing from the server and no JavaScript.
|
| Couple this with good CSS and HTML could actually be composable.
| Composability was known to be a good thing in GUIs in the 1970s
| and the web still struggles with achieving it without heaps of
| JavaScript.
|
| Of course I'm sure there is some weird reason this was never
| done, so instead you need mountains of shit to work around it.
| klodolph wrote:
| I love plain HTML. The chief problem I have with it is just
| dealing with templates--stuff like navigation. Lots of other
| people have the same problem. So they add some simple templating
| system, where they stick some text around the HTML. Ok, and then
| they want to automatically generate navigation, maybe add a few
| other features here and there. Add width/height to <img>, syntax
| highlighting for code snippets, etc.
|
| It's really easy for this kind of endeavor to get out of hand.
| The hardest part of plain HTML is _sticking with it_ and writing
| just enough automation to keep you sane.
|
| It's also far too easy to get sloppy when working on something
| that does some basic preprocessing. My personal preference is to
| keep the pages as HTML, and write a processor that does minor
| modifications to the HTML DOM, using a proper HTML5 library.
|
| If done carefully, you can keep the experience close to the
| experience of editing pure HTML. For example, rather than some
| custom "shortcodes", you can use custom HTML elements. Custom
| HTML elements are a more verbose, but come with major advantages
| over terser shortcodes (use existing tooling, you don't need a
| parser). You can do simple stuff like automatically add alt="" or
| srcset="" to your <img> based on image metadata, or automatically
| generate breadcrumbs using site structure.
|
| The general idea is to keep it as close to plain HTML as
| possible. If possible, make it so the page _is_ plain HTML.
| TheGoodBarn wrote:
| I LOVE static html sites. I fell in love with https://surge.sh/
| when I first started making sites, and now for the most part just
| host everything on GitHub or GitLab pages depending.
|
| I also love Vue and the simplicity of remote html
| resources/dependencies for simple sites. I created a single html
| file VueJS template that has a bunch of resources out of the box
| for things that I commonly want if I want to create a quick
| simple site.
|
| Check it out -> https://vue-template.spaghet.me
|
| The beauty of the site is its basically a _quine_. You can get
| started by just running: _curlhttps://vue-template.spaghet.me -o
| index.html_
| jjnoakes wrote:
| Just curious - why does your template include web3.js? Do you
| end up using that on tons of quick simple sites, and if so,
| what for?
| TheGoodBarn wrote:
| That is leftover from another template, I actually meant to
| remove it!
|
| ---
|
| I have created a few NFT / Web3 pages using that template.
| For the most part, a lot of Web3 UIs are just client side
| sites that connect to on-chain data, so another super lean
| use-case for simple HTML pages.
| SemanticStrengh wrote:
| That's lovely
| jrd259 wrote:
| Manually edited HTML requires great diligence to be well-formed,
| and this is important for accessibility.
| 1vuio0pswjnm7 wrote:
| (2019)
| robertoandred wrote:
| Using JS to insert headers and footers already makes them non-
| plain HTML pages. This is just trading one set of issues for
| another.
| mholt wrote:
| Rather than JS, one can use Caddy's built-in template engine
| [0] to include headers/footers server-side (but way more
| powerful than SSI): {{include
| "/includes/header.html"}}
|
| No JS, no external build step, still static HTML files -- just
| pieced together by the server at request-time. Works great [1].
| (Or use plain Markdown, and have Caddy's template engine render
| it as HTML on-the-fly. Your choice.)
|
| [0]:
| https://caddyserver.com/docs/modules/http.handlers.templates
|
| [1]:
| https://github.com/caddyserver/website/blob/master/src/docs/...
| <-- Try doing that with SSI
| senko wrote:
| I love the way you've just reinvented PHP 1 (see
| https://en.wikipedia.org/wiki/PHP#Early_history).
|
| That aside, Caddy is awesome, thanks for a great piece of
| software!
| Macha wrote:
| Smarty always amused me a bit, with how PHP had started as
| a templating language but had grown so far from that that
| people felt it needed a templating language of its own.
| mholt wrote:
| (Thanks) And yeah, I know -- that was an accident. :)
| slim wrote:
| What are the issues with javascript?
| [deleted]
| nkrisc wrote:
| The specific issue here is it's not plain HTML.
| petepete wrote:
| 100% this, there's no good reason to do this in JS.
|
| Apache has supported Server Side Includes forever. All you need
| to do is drop an 'include' in your HTML file and Apache will
| inject the contents in the right place.
| <!--#include virtual="/header.html" -->
|
| I don't know for certain but suspect other webservers will have
| similar functionality.
|
| https://httpd.apache.org/docs/current/howto/ssi.html
|
| Edit:
|
| IIS: https://docs.microsoft.com/en-
| us/iis/configuration/system.we...
|
| Lighttpd:
| https://redmine.lighttpd.net/projects/1/wiki/docs_modssi
|
| Nginx: https://nginx.org/en/docs/http/ngx_http_ssi_module.html
|
| Tomcat: https://tomcat.apache.org/tomcat-7.0-doc/ssi-howto.html
|
| Jigsaw: https://www.w3.org/Jigsaw/Doc/User/SSI.html
| amazing_stories wrote:
| Upvote for Apache Server Side Includes. Two years ago I was
| tasked with redesigning an important informational website
| that never got the proper attention because all devs were
| occupied with maintaining the different web application
| stacks. I wanted something future-proof that an intern could
| update, basically straight HTML and minimal CSS. I replaced
| anything that would normally use PHP (and in some cases
| JavaScript) with stuff built in to Apache. It's cool that
| Apache also supports conditionals.
| bornfreddy wrote:
| I mean, that's all cool, except now the next person needs
| to know (or learn) Apache directives. I would assume that
| intern is more likely to know PHP or JS. This solution is a
| compromise at best, and to me it doesn't sound like Apache
| is a good choice here (granted, there could be other
| circumstances I am not aware of).
|
| If I received your code I would start by rolling my eyes,
| then by wasting some time learning Yet Another Technology
| (TM) that I will likely forget before the next time it
| comes handy.
|
| In my experience, if you care about maintenance, one should
| stick to the worn path unless they have a good reason not
| to.
|
| > It's cool that Apache also supports conditionals.
|
| <...shudders...>
| petepete wrote:
| Apache was just used as an example but the most popular
| web servers all support SSI.
|
| I wouldn't suggest using it for anything complex but it's
| ideal for inserting common headers and footers into
| static HTML.
|
| Plus, it's using fewer technologies than anything you
| suggest. Less to maintain, less to go wrong. Sounds like
| a winner.
| matheusmoreira wrote:
| I wish this functionality was part of standard HTML.
| mfontani wrote:
| Frames are the closest thing HTML has to this
| throwawayboise wrote:
| Frames trigger bad memories for some older devs for how
| they were abused but this is really the best way to do
| it. Doesn't depend on server modules for includes, and
| even text-mode browsers generally support frames (but
| many do not support JavaScript).
| johannes1234321 wrote:
| Except that frames cause issues with bookmarks or linking
| to specific pages from the outside.
|
| An iframe with some CSS might however work to some
| degree.
| dsego wrote:
| transclusion
| iso1210 wrote:
| <iframe src='footer.html'>
|
| Or you could use a frameset
| akvadrako wrote:
| Indeed, xinclude would be great. Combine that with an HTML-
| based and declarative web-component solution and it would
| go a long way to reducing the need for scripting on basic
| websites.
| giantrobot wrote:
| You mostly just described XSL. There's a ton of
| templating XSL can do "for free" in the browser with no
| JavaScript.
| akvadrako wrote:
| Yes, I was a big fan of XSL. Too bad it didn't catch on.
| franga2000 wrote:
| Sure, but it's about as far from user/dev friendly as it
| gets. I recently had to make a standalone FAQ-style page
| and got the idea to use XSL to render it from an XML file
| (since you can teach any semi-literate person how to
| write XML in like 5 minutes). Firstly, XSL is so much
| weirder than any templating engine we're used to, that it
| took me stupidly long to do the most basic things. Then
| it turns out, browsers don't include default styles in
| XSL-rendered documents (no headings, no lists, nothing!),
| so I had to style it completely from scratch.
|
| Everything in the XML "ecosystem" (XSL, XPath, XDT, SOAP)
| is so unfriendly that I'm no longer surprised everyone is
| reinventing these concepts in (unfortunately) JSON these
| days.
| frosted-flakes wrote:
| XSD (XML Schema Definition) is pretty good though, and it
| makes autocomplete and spotting errors when hand-writing
| XML files very easy.
| cwillu wrote:
| The benefit of their approach is that they can drop the files
| into basically any server, and the site will work. Seems like
| a good tradeoff for the sort of concerns they have.
| giantrobot wrote:
| Pandoc will create self-contained documents with the '-s'
| switch. It's also pretty easy to use a custom template as
| well. You can go from markdown (or asciidoc or whatever) to
| plain but templates HTML with a single command. You then have
| an HTML file you can stick anywhere.
| jaywalk wrote:
| Not just JavaScript, but AJAX using jQuery. Come on now.
| mynameismon wrote:
| I looked at the JS being loaded in the first place, and it's
| just two files: the entire JQuery package, and:
| $(document).ready(function() {
| $('nav').load('/nav.html'); });
|
| That's...it.
| cestith wrote:
| I'm kind of wondering why JQuery is needed for that, but I'm
| not curious enough to dig into nav.html to see why. The
| navigation looks simple enough. An at-home static site
| generator that literally replaces a custom tag with the
| contents of a file using sed would take less maintenance it
| seems to me than keeping JQuery updated.
| hombre_fatal wrote:
| chrisco255 wrote:
| <p>I think writing in HTML is <em>very</em> frustrating. It can
| be particularly difficult to write it on a mobile device due to
| lack of easy access to special symbols.</p>
| ziddoap wrote:
| > _It can be particularly difficult to write it on a mobile
| device due to lack of easy access to special symbols._
|
| I'm assuming this excludes laptops, so we're talking
| tablets/smartphones? If so, out of curiosity, how often are you
| writing code on a smart phone/tablet? I've never written a line
| of any code on anything other than a laptop (when travelling)
| or desktop.
| number6 wrote:
| Fixed production on a terminal running in my phone. Would not
| recommend.
| _jal wrote:
| Seconded.
|
| Ssh on a phone is better than no ssh, but good lord is it
| frustrating.
|
| I would never willingly edit HTML (or anything else for
| machine consumption) on a phone, that's what real keyboards
| are for.
| number6 wrote:
| Sometimes this is a good thing. Makes you stop. Sit down.
| Activates your analytical mind.
| recursive wrote:
| I'm sure there are 3rd party keyboards that optimize for
| different use cases, such as angle braces and double quotes.
| brimble wrote:
| On the flip side, last time I wrote some in an editor with
| decent HTML-authoring autocomplete, it was so fast I wondered
| why we bother with weird compile-to-HTML templating languages
| anymore. It wasn't really any slower than writing Pug or
| whatever, and the result IMO was _more_ readable.
| merelysounds wrote:
| What's more frustrating, writing in HTML or writing in a more
| concise format and having to maintain some build pipeline?
|
| I guess the answer depends on many factors; personal
| preferences and also the project's context play a big role;
| personally I'm surprised how often I choose <em>HTML</em>.
| iso1210 wrote:
| Markdown is probably a happy medium - markdown itself looks
| pretty much like normal writing in usenet or email, just
| formatted visually, and the 'build pipeline' is something
| like "markdown foo.md > foo.html"
| LAC-Tech wrote:
| Let's face it, mobile devices are primarily for consuming, not
| producing.
| mftb wrote:
| I like plain html pages for presentation too, but this writer is
| making a fundamental mistake. He keeps making it, as he
| vacillates between solutions.
|
| He keeps mixing his data into his presentation of that data.
|
| Keep your data however you like, plain text files in a simple
| directory structure, database, whatever. The important thing is,
| as much as possible, organize the data in a presentation neutral
| way.
|
| Choose whatever programs you want to present that data, in
| whatever context. When you eventually tire of some of those
| solutions, if you've done things right, you will simply discard
| them and pick new ones to present your data in new ways.
|
| As long as he continues to mix his data with it's presentation at
| the outset, he doesn't have data, he has a website, or a wiki, or
| whatever, and he'll keep having to solve the same problem.
| olliej wrote:
| My website has remained unsullied plain html since I wrote it.
| This would be more impressive if I ever actually updated it :D
|
| (behold http://nerget.com and weep when you see the "new"
| features it refers to :D )
| throw10920 wrote:
| I'm pretty sure that this is just a lower-strength version of
| "the wiki trap" mentioned in the article - if you write all of
| your pages in HTML, then they're going to _stay_ HTML unless you
| invest the effort in writing a parser+translator that converts
| all of your content into Markdown or Wikitext or whatever else
| you might want to migrate that content into.
|
| For instance, if you decide you want to give a templating
| language like Mustache a try - have fun programmatically
| extracting your content from those HTML pages and translating it
| into Mustache. Doable? Sure. Easy? Certainly not - and it's going
| to be _very_ painful and manual if you didn 't keep the same
| format for all of those HTML pages.
| JadeNB wrote:
| > if you write all of your pages in HTML, then they're going to
| stay HTML unless you invest the effort in writing a
| parser+translator that converts all of your content into
| Markdown or Wikitext or whatever else you might want to migrate
| that content into.
|
| The designed virtue of Markdown is its ease of _authoring_ ;
| why would you want to convert _to_ it? It 's surely easier to
| convert directly from HTML to whatever other format you want
| than from Markdown to that format.
| notriddle wrote:
| Because you're migrating a living document.
| munk-a wrote:
| I adore plain HTML but their lack of any versioning seems silly
| to me. It's so easy to use (for instance) git to sync changes
| back and forth that eschewing it from the process just seems
| unnecessarily dangerous. Throw it all in source control (and
| maybe if you're using git create a public github repo) and you've
| got a free backup along with a safer way to edit the files.
| Considering it's all plain HTML local edits can be trivially
| vetted by just opening .html files in browsers or, for the more
| advanced, taking five seconds to download an appropriate
| WAMP/MAMP/LAMP binary that sets up apache and some crap you don't
| need - then just move your source dir into whatever their
| public_html is called.
|
| It is so _so_ trivial to vet local HTML changes and use a
| repository where you just directly push to master that I 'd
| suggest it to anyone building a plain HTML site just for the fact
| that you're getting free backups as a side effect.
| cellularmitosis wrote:
| Alternatively, they could just throw an rsync one-liner into a
| crontab and slurp down a backup copy of the files once per day,
| in case they make a mistake. This optimizes for the common case
| (the days where you don't make a mistake) and removes the
| requirement that everyone on the team needs to know git.
| munk-a wrote:
| In the article they mention they're generally using vi for
| editing. The learning barrier for git is so much lower than
| vi.
|
| Git, when used without branches and merges, is really dead
| simple.
| jameshart wrote:
| Just one caveat: you might need to make sure the .git directory
| isn't publicly accessible via the web server.
| munk-a wrote:
| I _guess_ though to be honest there isn 't any privileged
| information stored in there to my knowledge? It's just
| historical information which you're probably going to end up
| publicly exposing on github anyways.
| jll29 wrote:
| I'm sympathetic to your view in favor of siplicity.
|
| > I'm normally someone who's attracted to ideas like writing in a
| markup language instead of raw HTML and having some kind of
| templated, dynamic system (whether it's a wiki, a CMS, or a
| themed static site generator), as you can tell from Wandering
| Thoughts and DWiki itself.
|
| Note that HTML _is_ a markup language (an SGML application) and
| so _is_ XHTML (an XML application).
|
| If you meant by "a markup language" a user-friendly or domain-
| specific markup language, then there is good news: if you use XML
| as your markup (ideally by defining your own wiki's DTD, as
| simple or as sophisticated as you like) then you can associate an
| XLST transform "program" with it, and then a click on "view HTML"
| in the browser will display the underlying XML [sic], not as you
| would expect the generated XHTML, as the XHTML is generated from
| the XML on the fly only (not stored persistently anywhere, thus
| avoiding file clutter).
|
| For example, you may like a structure like:
| <docs> ... <doc> <title>...</title>
| <text>...</text> <keywords>...</keywords>
| </doc> ... </docs>
|
| The XSLT can insert the standard XHTML boilerplate as well as
| your logo and a header after the <doc> and before the <title>
| element, for instance, and any potential footer between </text>
| and </docs>. That gives you much in terms of separation between
| structure and content, yet no separate conversion pass is
| required to render the pages in a standard browser, and no
| special viewer plug-ins are required either.
| devnulll wrote:
| GitHub pages seem to be about the simplest way to do this today -
| bringing the goodness of basic source control, simple issue
| management, and related.
| cellularmitosis wrote:
| Another lightweight github-based approach is to just link
| together a bunch of gists:
| https://gist.github.com/cellularmitosis/fdac60efe210d1cee263...
| canadianwriter wrote:
| Yup! I use Github pages as my "CMS" for my pure HTML static
| site (https://kolemcrae.com) works beautifully!
| ExtraE wrote:
| I have a fair number of sites on Github pages but I've ended up
| migrating most of them to Netlify (which is a _very_ easy
| process) when I 've needed more features, like wildcard ssl or
| multiple domains. Still haven't paid a cent!
| uncomputation wrote:
| Yes, this one million times over. I have went from home-rolled
| React to Jekyll to Gatsby to Hugo and now seriously considering
| just doing my own HTML/CSS. Practically, I have rarely run into
| the issues other markup languages and SSGs are supposed to fix
| and more often, I find their constraints actually
| limiting/complicating my fairly simple desires. If I want to add
| movie/album reviews, rather than just making /reviews directory
| with some files and some basic CSS, I get stuck thinking about
| Hugo "archetypes" and templates and _index.md and layouts and all
| of this baggage. I wanted to add support for my site to use my
| custom "CSS as S-expressions" parser [0], but got turned off by
| the idea of integrating Hugo "pipelines" or "assets" or all of
| that. Not to mention that this grows ever more overwhelming if I
| take a months-long break and have to Google how to start my own
| blog server! Then I look at RMS' site and, ugly as it is, it has
| held up and looks way easier to update and less constrained by
| any premeditated structure/hierarchy.
|
| [0]: https://uncomputation.net/cascading-style-s-expressions/
| notriddle wrote:
| RSS.
|
| If you're writing a blog, then you probably want a way for
| people to subscribe to it instead of making them visit your
| site manually. Unless you are confident that you not only CAN
| write a feed by hand, but will never forget to hand-update it
| after updating the post itself, you're going to want to at
| least have the RSS feed be auto-generated.
|
| And once you've added the infrastructure to auto-generate the
| RSS index, there's very little point in not auto-generating the
| HTML index, too. If only because, that way, you won't forget to
| run it.
| hk__2 wrote:
| Have you tried Jekyll? I don't know Hugo; I like Jekyll because
| it's very simple with very little abstraction. My blog is just
| some hand-written HTML with liquid templating. I like how you
| can add any metadata you want to a post/page and then use it in
| your templates.
| klodolph wrote:
| I have various static sites that I maintain, I recently added
| a new site created in Jekyll and wrote a bunch of content for
| it.
|
| While I like Jekyll and I'll continue using it, I can
| definitely relate to the frustration when first using it. I
| get this feeling that I _already know_ what I want Jekyll 's
| HTML to look like, and now I need to work backwards and
| develop an understanding of Jekyll in order to figure out how
| to get Jekyll to produce the desired output.
|
| By "HTML" I don't actually mean that I have a problem with
| embedding specific markup in the page, it's stuff like
| putting the files in the right place, getting the template to
| contain the right material, etc.
|
| And to be clear, I'm going to continue using Jekyll since it
| seems more practical than e.g. Hugo given my constraints /
| available resources / etc, and I may even migrate some other
| sites I maintain _to_ Jekyll, but Jekyll, like other static
| site generators, seems to throw a lot of mess in the way of
| simple desires, as the parent comment articulates.
| seanosaur wrote:
| Jekyll was literally mentioned in the second sentence. You
| may have missed the point of the comment.
| PaulHoule wrote:
| I've found it hard to resist the conclusion that "Hugo sux".
| leetrout wrote:
| You get out of it what you put in to it, so to speak.
|
| It is very easy to over complicate things but it is also easy
| to use it for lightning fast static page generation focusing
| only on letting it manage the head and global page structure.
| CraigJPerry wrote:
| >> my custom "CSS as S-expressions" parser [0]
|
| That's a pretty neat idea, if all CSS on a site originated from
| your s-exp's then you'd make it trivial to find not just what,
| but why a particular style has been applied (because now you're
| only looking in an acyclic-graph, it's easier to search).
| uncomputation wrote:
| Thanks, yeah this is actually related to/the first step in a
| similar idea I had for a CSS SAT solver which generates a set
| of minimal CSS rules.
| notorandit wrote:
| And plain old Html works with almost any device, even old nokias,
| motorolas, nintendos.
| PaulHoule wrote:
| Something I've experimented with is web templating systems that
| are HTML 5 native, that is, you parse documents to the DOM,
| process them in the DOM, then serialize them to the disk (like
| Hugo) or the web browser.
|
| For instance the "template" of your web site might be an HTML
| document that has something like <div
| id="content"/>
|
| in the middle of it. The content is in another HTML document,
| there is some logic that merges the document <head>(s), and the
| contents of the <body> of the content goes into the above <div>.
|
| It's not that hard but I think it's never caught on for a few
| reasons.
|
| One of them is that DOM parsing and unparsing is an order of
| magnitude or two slower than text-based templating sytems. I
| guess you could parse the template once and cache it but it's
| still going to be slow.
|
| Another is that you run into "hygenic macro" problems if you want
| to merge random DOM trees into each other: for instance you could
| have multiple elements with the same id, the same classes used
| for different meanings in some other places. You need some answer
| to this if you want to make something scalable (e.g. the whole
| point of this exercise is that you should be able to transclude
| HTML + CSS from anywhere and have it "just work")
|
| Finally it would be really nice to have a reliable WYSIWYG HTML
| editor, particularly one that would help you use CSS classes in a
| disciplined way to customize the system to add whatever markup
| features you want for your site.
|
| It doesn't exist and I wonder why. Every HTML editor I've seen is
| just garbage. Latency for typing characters is several round
| trips to the moon. Navigation, selection, where characters appear
| when I type all seem to be random, like my computer is possessed
| by the devil.
|
| (It's a general problem w/ most WYSIWYG editors that look like MS
| Word, including MS Word. I'm sure there is something conceptually
| wrong with the model which is why all those editors are buggy,
| but it seems everybody else thinks it is OK for selection,
| navigation and where you type characters to be random.)
| lazide wrote:
| The problem is browsers don't render like a word processor, so
| it's hard to fit the model to reality.
| klodolph wrote:
| I use something like this for my personal website.
|
| I don't know how fast text-based template systems are, but I
| can do a clean build of my entire website in under half a
| second. That seems pretty fast to me. I've been adding content
| to it for over 20 years now... it's not a massive site since
| it's just me, but it's not exactly small either.
|
| Every page is authored as HTML, with some extra headers at the
| top. It's parsed as HTML5. The processor will apply templates
| in a fairly simple way... merge everything in <head>, merge
| everything in <body>. There's a special tag for templates that
| means "put the <body> here, instead of merging".
|
| Any given piece of HTML will be parsed / unparsed only twice,
| because the templates work on DOM manipulation. The second
| parse / unparse is there because I use an HTML minifier, and
| the HTML minifier has a bytes in/bytes out interface.
|
| > Another is that you run into "hygenic macro" problems if you
| want to merge random DOM trees into each other:...
|
| This is a beast of a problem. If I need an ID in a template
| that may get used in multiple places, then there's some piece
| of code somewhere generating the ID.
|
| My experience is that it really becomes a problem when you have
| large, large sites with tons of people working on them, and
| it's not a problem at all for one person.
|
| > Finally it would be really nice to have a reliable WYSIWYG
| HTML editor, particularly one that would help you use CSS
| classes in a disciplined way to customize the system to add
| whatever markup features you want for your site.
|
| It's called "Dreamweaver". Truly one of the most powerful web
| authoring tools ever made.
| PaulHoule wrote:
| I want to like Dreamweaver but on a desktop replacement
| laptop it takes several seconds for characters to appear when
| I type.
|
| Selection, where the cursor ends up when I click on something
| and where the cursor goes when I hit the arrow keys are all
| erratic enough to make me wonder if my computer is possessed
| by the devil.
|
| I've submitted so many tickets to Adobe about strange
| problems with Dreamweaver that it's a wonder I haven't been
| hellbanned from their issue tracker.
| klodolph wrote:
| All my experience with Dreamweaver is many years out of
| date. I don't doubt that it's become slow.
| PaulHoule wrote:
| I always thought there was more potential in HTML than gets
| realized
|
| https://ontology2.com/the-book/html5-the-official-document-l...
|
| but practically it never happens. So we get stuck with languages
| like markdown, restructured text and various sorts of wiki
| markup. Just about everybody who gets serious about extracting
| data from Wikipedia learns the hard way that parsing wikimedia
| markup is possible to get 90% right with a lot of suffering but
| if you have a DOM-intelligent HTML parser often you can get
| 99.95% right with 2 minutes of work parsing the HTML.
|
| (The reason why is that people look at HTML and fix the markup
| until the HTML looks right, they don't look to see that the
| markup is conformant to any spec.)
|
| For a long time I've wanted to like Dreamweaver and it didn't
| seem so bad in 2003 but today I type a few characters into the
| live view and then I can go on vacation and the characters might
| have appeared a week later. You'd think every HTML editor that is
| embedded in HTML was developed by a sadist except that it seems
| there is a basic conceptual problem that makes WYSIWYG HTML
| editing completely impractical.
| blowski wrote:
| I too used Dreamweaver in 2003, and let's say that I have a
| different recollection to you in terms of its performance.
| beebeepka wrote:
| Huh, I had no idea Dreamweaver was still a thing.
___________________________________________________________________
(page generated 2022-05-02 23:00 UTC)