top | item 34997070

(no title)

y3k | 3 years ago

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).

discuss

Loic|3 years ago

SSI: Server Side Include[0], my first not so simple website was created with SSI, with all the pages as `.shtml`. These are memories.

[0]: https://en.wikipedia.org/wiki/Server_Side_Includes

y3k|3 years ago

I never released a production website with SSI before, but I found it when I was searching for a more bare-metal approach to make websites; then I found Caddy's template engine and it's been more than enough for what I need.

superkuh|3 years ago

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.

y3k|3 years ago

SSI is supported by "old battle tested" servers like Apache or Nginx, there's a "new guy on the block" that I find quite promissing: Caddy[0] however it doesn't support SSI, instead they have some built-in template engine that is a bit more powerful than old SSI but can achieve the same result.

[0]: caddyserver.com

tannhaeuser|3 years ago

> 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 <script> 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.