logoalt Hacker News

dimal05/03/202511 repliesview on HN

This was the rabbit hole that I started down in the late 90s and still haven’t come out of. I was the webmaster of the Analog Science Fiction website and I was building tons of static pages, each with the same header and side bar. It drove me nuts. So I did some research and found out about Apache server side includes. Woo hoo! Keeping it DRY (before I knew DRY was a thing).

Yeah, we’ve been solving this over and over in different ways. For those saying that iframes are good enough, they’re not. Iframes don’t expand to fit content. And server side solutions require a server. Why not have a simple client side method for this? I think it’s a valid question. Now that we’re fixing a lot of the irritation in web development, it seems worth considering.


Replies

EvanAnderson05/04/2025

Server-side includes FTW! When a buddy and I started making "web stuff" back in the mid-90s the idea of DRY also just made sense to us.

My dialup ISP back then didn't disable using .htaccess files in the web space they provided to end users. That meant I could turn on server-side includes! Later I figured out how to enable CGI. (I even went so far as to code rudimentary webshells in Perl just so I could explore the webserver box...)

matchagaucho05/03/2025

I've become a fan of https://htmx.org for this reason.

A small 10KB lib that augments HTML with the essential good stuff (like dynamic imports of static HTML)

show 2 replies
unilynx05/03/2025

> Iframes don’t expand to fit content

Actually, that was part of the original plan - https://caniuse.com/iframe-seamless

show 1 reply
atoav05/03/2025

I mean in 1996s netscape you could do this (I run the server for a website that still uses this):

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
    <html>
      <frameset cols="1000, *">
        <frame src="FRAMESET_navigation.html" name="navigation">
        <frame src="FRAMESET_home.html" name="in">
      </frameset>
    </html>
  
The thing that always bugged me about frames is that they are too clever. I don't want to reload only the frame html when I rightclick and reload. Sure the idea was to cache those separately, but come on — frames and caching are meant to solve two different problems and by munching them together they somewhat sucked at solving either.

To me includes for HTML should work in the dumbest way possible. And that means: Take the text from the include and paste it where the include was and give the browser the resulting text.

If you want to cache a nav section separately because it appears the same on every page lets add a cache attribute that solves the problem independently:

  <nav cache-id="deadbeefnav666">
    <some-content></etc>
  </nav>
  
To tell the browser it should load the inner html or the src of that element from cache if it has it.

Now you could convince me thst the include should allow for more, but it being dumb is a feature not a bug.

show 1 reply
codr705/03/2025

The optimal solution would be using a template engine to generate static documents.

show 2 replies
econ05/03/2025

You can message the page dimensions to the parent. To do it x domain you can load the same url into the parent with the height in the #location hash. It won't refresh that way.

show 1 reply
rbanffy05/04/2025

> Woo hoo! Keeping it DRY (before I knew DRY was a thing)

I still remember the script I wrote to replace thousands (literally) slightly different headers and footers in some large websites of the 90s. How liberating to finally have that.

RenThraysk05/04/2025

Don't Service Workers API provide this now, essentially act like a in-browser proxy to the server.

https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

show 1 reply
fooker05/03/2025

> Why not have a simple client side method for this?

Like writing a line of js?

show 3 replies
api05/03/2025

The web seems like it was deliberately designed to make any form of composability impossible. It’s one of the worst things about it as a platform.

I’m sure some purist argument has driven this somewhere.

show 2 replies
luotuoshangdui05/03/2025

HTML is a markup language, not a programming language. It's like asking why Markdown can't handle includes. Some Markdown editors support them (just like some server-side tools do for HTML), but not all.

show 6 replies