Hacker News Reader

Comment by robertoandred | Hacker News Reader

Using JS to insert headers and footers already makes them non-plain HTML pages. This is just trading one set of issues for another.

View on HN

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

I wish this functionality was part of standard HTML.

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.

Or you could use a frameset

transclusion

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.

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

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.

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.

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.

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)

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)

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

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!

(Thanks) And yeah, I know -- that was an accident. :)

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.

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.

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.

There is a modern fervor over tech minimalism/purism where using even a little bit of Javascript, for example, is just a reminder that perhaps the answer all along was to just to use the trade-offs that work for you.

Note, the people in the article were burned by wiki software that went unmaintained during its rewrite from Python 2.7 to Python 3 (afaict). Now they are editing HTML files on a production server. I'm sure getting let down like they did gave them a specific distaste for certain trade-offs that work for the rest of us, but you can also imagine the babies being thrown out with the bathwater like scaling out an article database without revision history.

That said, it tends to be a good thing when you realize a vastly simple solution works for you.

Not just JavaScript, but AJAX using jQuery. Come on now.

What are the issues with javascript?

The specific issue here is it's not plain HTML.

Reply on news.ycombinator.com