Hacker News Reader

Comment by petepete | Hacker News Reader

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

View on HN

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.

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.

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

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.

It does in some cases, just not for the reasons stated (imho of course).

(didn't downvote you - I actually appreciate your sharing of your point of view)

I wish this functionality was part of standard HTML.

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.

You mostly just described XSL. There's a ton of templating XSL can do "for free" in the browser with no JavaScript.

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.

XSD (XML Schema Definition) is pretty good though, and it makes autocomplete and spotting errors when hand-writing XML files very easy.

I’ve messed around with generating SVG classes in python and C++ using the XSD schema and while it is pretty good it falls flat on its face for anything complicated like SVG.

Resorted to using the DTD schema as it can support complex things (and that’s what they use for the probably never to be released updated version) through some python hackery to generate a hundred or more classes that takes forever to compile and, strangely enough, actually does what its supposed to do which is represent SVG as a bunch of classes with reading/writing to xml.

I was going through a phase and tried that with rss but it was more hassle than it was worth.

—edit—

Should add the DTD makes things like enums for tags or whatever simple so you can have typed values and property formed xml documents — can’t remember if I ever managed to get that working with the XSD.

Yes, I was a big fan of XSL. Too bad it didn't catch on.

Frames are the closest thing HTML has to this

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

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.

transclusion

Or you could use a frameset

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.

Golang Templates also offer the ability to do this. I have an entire enterprise site built this way with separate header, footer, toolbar, search box, etc. And it’s silly fast too. We use AlpineJS for client side interactive bits. (edit: typos)

Reply on news.ycombinator.com