undefined

points

[-]

> i have a static website with a menu. keeping the menu synchronized over the half dozen pages is a pain

You can totally do that with PHP? It can find all the pages, generate the menu, transform markdown to html for the current page, all on the fly in one go, and it feels instantaneous. If you experience some level of traffic you can put a CDN in front but usually it's not even necessary.

by em-bee5 hours ago|

parent|

[-]

that's the server side html generator i already mentioned. ok, this one is not large, but it still ties me to a limited set of server platforms that support running php. and if i have to write code i may as well write javascript and get a platform independent solution.

the point is, none of the solutions are completely satisfactory. every approach has its downsides. but most critically, all this complaining about people picking the wrong solution is just bickering that my chosen solution does not align with their preference.

my preferred solution btw is to take a build-less frontend framework, and build my site with that. i did that with aurelia, and recently built a proof of concept with react.

by ndriscoll5 hours ago|

parent|

[-]

You didn't actually indicate a downside to using xslt, and yes it would fit your use case of a static include for a shared menu, though the better way to do it is to move all of the shared pieces of your site into the template and then each page is just its content. Sort of like using a shared CSS file.

To just do the menu, if your site is xhtml, IIRC you could link to the template, use a <my-menu> in the page, and then the template just gives a rule to expand that to your menu.

by em-bee5 hours ago|

parent|

[-]

the downside to xslt is xslt itself, and lack of maintenance of xslt support in the browser. (browsers only supports xslt 1.0 and it looks like even that may be dropped in the future, making its use not futureproof without server side support)

by ndriscoll25 minutes ago|

parent|

[-]

I'm not sure how xslt itself is a downside. It's a pretty natural template language to use if you already know HTML. You don't need more than 1.0 for your simple use-case. e.g. here's a complete example (tested in Firefox and Chrome):

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
      <xsl:output method="html"/>
      <xsl:template match="nav-menu">
        <nav>
          <ul>
            <li><a href="page1.xhtml">Page 1</a></li>
            <li><a href="page2.xhtml">Page 2</a></li>
            <li><a href="contact.xhtml">Contact</a></li>
          </ul>
        </nav>
      </xsl:template>

      <xsl:template match="*">
        <xsl:copy><xsl:apply-templates/></xsl:copy>
      </xsl:template>
    </xsl:stylesheet>

Then here's a page to use it:

    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet type="text/xsl" href="templates.xsl"?>
    <html>
      <head>
        <title>Welcome to my page</title>
      </head>
      <body>
        <nav-menu/>
        <h1>Welcome to the page!</h1>
        <p>This is the content</p>
      </body>
    </html>

Anywhere you want more templates, you add another

    <xsl:template match="my-element">
      <!-- HTML for my custom element -->
    </xsl:template>

And now you can use your custom <my-element/> directly in your HTML. You can of course also have attributes and children for your custom elements and do all sorts of things with XSLT if you dip your toes in a little further.

As far as longevity goes, it's lasted 25 years now, so that's something. As far as I know, there are a bunch of government services out there that still use it (which is great! Governments should be making things cheap and simple, not chasing trends), so removing support for it is somewhat infeasible. If it were removed, you could always make a Makefile that runs `xsltproc` on all of your xhtml files to spit out html files, so worst case your back to a build step, but it's the world's easiest build step

by rsolva9 hours ago|

prev|

[-]

I recently tried building a website using Server Side Includes (SSI) with apache/nginx to make templates for the head, header and footer. Then I found myself missing the way Hugo does things, using a base template and injecting the content into the base template instead.

This was easy do achieve with PHP with a super minimal setup, so I thought, why not? Still no build steps!

PHP is quite ubiquitous and stable these days so it is practically equivalent to making a static site. Just a few sprinkles of dynamism to avoid repeting HTML all over the place.

by rossant6 hours ago|

prev|

[-]

Frames. Use frames. They're the future. Definitely.

by em-bee6 hours ago|

parent|

[-]

on stackoverflow on the question how to include html, one answer does indeed suggest frames...