Live data from Hacker News

All you may need is HTML

fabiensanglard.net

221–230 of 328 posts

Re: All you may need is HTML

#221
For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time.

This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode.

To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata for searches that are processed on the client.

As icing on the cake, once the user has settled in, I use a service worker to pre-download/cache the all the posts in the blog site and allow for offline viewing. I have some tricks to avoid the annoyances of stuck sw caches.

Leads to a great user experience and maintainers don't need to have a backend portal - just write markdown and commit it straight to GitHub. Easy enough to teach people to use Typora and SourceTree

Re: All you may need is HTML

#222
post #2

HTML + CSS for whitespacing & viewport width + SSI | Caddy's template That combo is more than enough for almost all the websites out there, I've 3 different sites like that and they are blazingly fast, everything served from a $4 VPS (serving about 20k views per week).

This is the way. It's great for templating with .html fragments, extremely easy to maintain and has almost no attack surface. I don't know what "Caddy's template" is but HTML/CSS + SSI for gluing the fragments together is what peak personal website performance looks like.

> Almost no attack surface

I guess you mean because SSI is just a very limited mechanism as opposed to full blown Turing complete PHP or similar. But actually if the fragments/partials you include via SSI are user-posted content (comments) or syndicated content then of course SSI can't fence against or other injections. In that case, you could use more sophisticated SGML mechanisms (other than SGML processing instructions as used by PHP or magic SGML comments as used by SSI) such as entity reference expansion that come with full type checking and context-dependent validity assessment for filtering all kind of injections (script elements, event handler attributes, image or link href injections or whatever). But you should at least use content-security-policy headers to block inline script.

Re: All you may need is HTML

#223

I sympathise with the main thrust of the post but, to nitpick, this is just plain wrong: > But mostly css appeals to our vanity and ego. Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.

In my personal, obviously anecdotal, experience it's always the "technical" guys who think things like this. This is why we have UI/UX teams and we don't let programmers create visual interfaces.

I like it because it means they will never be my competition for anything but incredibly niche/domain-specific boomer software people have no choice but to begrudgingly use.

Re: All you may need is HTML

#224

I sympathise with the main thrust of the post but, to nitpick, this is just plain wrong: > But mostly css appeals to our vanity and ego. Design isn't just about aesthetics. Good information design, clear visual hierarchy, accessibility, etc. all help with communication. The author's effective use of spacing, bold, and code tags show us that they know this intuitively, despite what they write.

> Design isn't just about aesthetics. Why dismiss aesthetics out of hand like this, equating it with vanity and ego? Aesthetics are very important to people, possibly even more so than the information on the page.

FWIW, I agree with you (and I don't see where I dismissed it), but the point is that even a certain type of utilitarian-inclined programmer is wrong on their own terms.

Re: All you may need is HTML

#225

> THE PROBLEMS A GENERATOR SOLVES One problem not listed is source code syntax highlighting. If you provide source code listings in articles, then highlighting is a big help to readers. Generating it in HTML is not fun.

Alternatively, you could specify the type of the source code so the user agent could handle the syntax highlighting—just like every other source code viewer ever written aside from those with idiosyncrasies related to the fact that they that belong to a special class called "Web browsers".

Re: All you may need is HTML

#226
post #185

Earlier quoted context omitted.

Because reading words requires substantial styling enhancements over what the browser is already capable of? Has anyone picked up a book lately? You need a UI team to create a page of readable text? That sounds like an expensive waste. But it sounds like those 'UI' people think they know better and don't need suggestions from programmers about reading words, even though its what they do all day.

It's very funny that you seem to think reading code and reading a website are the exact same type of activities, and the same type of reading. They are not. And I don't know where you've been for the last 30 some years, but the web is not a text only format, and the reason HTML was invented was specifically to be able to create a designed space where text can actually make sense and is not a gigantic wall of impossib…

[deleted]

Re: All you may need is HTML

#227

For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time. This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode. To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata…

nice setup. I'm going to have to look into the service worker approach. typora and github are my version of what you're talking about - which I love

Re: All you may need is HTML

#228
post #3

You may not even need HTML. HTML is subject to different renderings on different browsers, confusing features that may not be supported on different browses, and may tempt you to use JavaScript (which can throw "errors" if written incorrectly). If you stick to text files, you'll never have to go to caniuse.com ever. Need styles? Just make a PDF and throw that online. During the "XML HTML" phase the web went through,…

for all the responses going into practical implications... I think @tolmasky is joking

Re: All you may need is HTML

#229

For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time. This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode. To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata…

Sounds very nice. Is this available for others to use?
Post reply on HN