1. 27

  2. 14

    This stack will also make supporting the following features difficult:

    • Paging
    • Site Navigation
      • By category
      • By tag
    • Common Elements
    1. 12

      It’s so annoying that (from our current perspective) this could have been so easily done in the <head> tag, by adding a few <meta ...> pointers to the next/previous page or something <neighbours>, but instead the only people who use anything like this are search engines.

      1. 4

        Why do you need paging? You’d need thousands of pages before your site exceeds the size of e.g. NYTimes which amounts to tens of megabytes.

        1. 4

          Maybe you don’t. But you don’t need to scale to thousands of pages before paging is useful.

          • 5 most recent stories? Needs paging.
          • List of articles about topic X? Needs paging.
          • Blog posts in the month of June? Needs paging.

          Not everyone needs those but for the ones that do? Plain HTML/CSS is going to suck and be really error prone.

          1. 1

            wait what even is paging in this context

            1. 2

              I suppose a more fitting word for that concept is ‘pagination’.

              1. 1

                well the things in /u/zaphar’s comment don’t seem to be about that… why do you need pagination to list the 5 most recent stories?

                1. 2

                  Because that list would otherwise need to be updated manually.

                  1. 1

                    how would pagination help with that? a list of 5 stories probably fits on a single page anyway.

                    1. 1

                      It’s the same process. The top-five-most-recent stories is just a page with 5 stories on it.

                      1. 1

                        pagination is the process of dividing a document into pages.

                        maybe /u/zaphar was using “paging” to refer to any dynamic content; I am not familiar with that usage.

                        1. 1

                          The “document” is the entire list of stories. The page is the first five.

                          1. 1

                            this is extremely dumb

        2. [Comment removed by author]

          1. 5

            The article explicitly contrasted his approach with static site generators.

            1. 3

              My blogging solution (that I’ve used for multiple things, not just my main one) is Blosxom running in static mode, reading markdown files from a bunch of directories.

              This means I can just create a new file, add some (markdown) text, and it’s published after a cron job is run.

              I’ve been running my blog like this since 2007, and I’ve never had to worry about keeping my editor templates up to date, or to have to run sed on a bunch of files to update a common element (or point to an updated CSS file) or have to edit raw HTML, which sucks.

              Is this a solution for the ages? I don’t know, but my blog has been online for almost 17 years, so it’s good enough for me. </endrant>

              Edit this came off as both rant-y and a bit of a DSW, so I’d like to add that I’m not shaming anyone for putting content out there in whatever form they want, however often they want. Heck, my input to this site probably exceeds my blog by an order of magnitude, similar with comments on Reddit, and Tweets.

              But at least for me, the less friction there is between brain and screen, the better. And keeping track of tags and the god-awful link syntax for HTML adds a lot of friction… a good SSG removes a lot of that friction.

              1. 1

                have to edit raw HTML, which sucks.

                Why ? It ‘s HTML for god’s sake…

                1. 4

                  Compare and contrast

                  This [website](https://example.com) makes a __bold__ claim, & I approve.
                  <p>This <a href="https://example.com">website</a> makes a <strong>bold</strong> claim, and &amp; I approve.<br /></p>

                  Not even gonna count how many shifts and commands I had to type to get the HTML dreck written (worse in non-US keyboards, too).

                  Markdown allows me to separate the URLs into “footnotes”, which makes it even better for flowing text.

                  This [website][url] makes a __bold__ claim, & I approve.
                  [url]: https://example.com

                  Lists add even more useless HTML boilerplate.

                  1. 1

                    Have you ever seen LaTeX rendered to HTML + CSS? It’s not very pretty ;)

            2. 1

              Yes, but he also doesn’t need to maintain things that he doesn’t support, and that works in his favor.

            3. 5

              Aren’t SEO and Lighthouse scores things that change all the time? So, that requires maintenance.

              I wonder if we’ll ever go through another transition like ‘mobile-first’ that’d also break your CSS on new devices.

              OP also compares Wordpress.com and GitHub Pages, two hosted services, while implying his page on GitHub will never have security vulnerabilities. Sure, if your host is outside of your security scope, then your ‘Wordpress.com stack’ will also never have security vulnerabilities.

              Ok, that last one was probably super nitpicky. And I do agree and appreciate simple fast pages. :-)

              1. 3

                To be fair, “a transition that breaks your CSS” is a lot easier to handle when you only have one CSS file :-) I think this is probably a point in favor of the OP’s approach and against something like WordPress, where I imagine that many popular themes would be updated quickly but that a long tail of other themes would be updated much more slowly.

                1. 0

                  SEO and Lighthouse scores are to be ignored as a matter of principle.

                2. 3

                  I personally add a small touch of PHP. It will probably be supported by Apache forever, so it’s almost as sustainable.

                  1. 2

                    If you’re sticking with Apache, you can accomplish most of that in a much simpler way without PHP: https://httpd.apache.org/docs/current/howto/ssi.html

                  2. 3

                    Hard to argue with the actual point being made but IMO calling HTML+CSS a “stack” is a bit disingenuous.

                    “My sharp stick will always be more reliable than your steam shovel!”

                    Why yes, yes it will!

                    1. 2

                      I don’t understand the author’s issue with static site generators. By that logic, you should only write assembly and not C, because having a compiler adds another dependency.

                      1. 6

                        I’m not the OP, but I think the category of static site generators—like the category of front-end frameworks*—has a bit of a reputation for moving fast and breaking compatibility. Maybe their objection is not to having a dependency, but to the idea of relying on a tool that forces them to either rework their configuration every six months (or else make an extra effort to stay on an old version).

                        * And unlike the category of endofunctors. (Sorry, couldn’t help myself.)

                        1. 2

                          Maybe, but you don’t need to use an immature or fast-changing tool, or if you do use one, you probably don’t need to ever update it.

                          And in the worst case, a static site generator is a very easy thing to write yourself.

                          1. 1

                            I was gonna say then you’re using the wrong static site generator :)

                            I favor choosing one that’s written in a programming language you understand, with a design that’s simple enough to fully wrap your head around.

                            That’s why I use and love Pelican.

                          2. 1

                            Also not op, but I went from a static site generator to HTML+CSS a few years ago; and for me it was mostly that I kept forgetting how the particular static site generator that I was using worked. So every half a year or so when I wanted to write a blog post, I then had to relearn the tool as well.

                          3. 2

                            A long-lasting stack is something very appealing to me as well, however I think the lack of templates would end up costing more than it saves. I ended up substituting SSGs for a small Python script that does templating and a couple other functions I wanted (like feeds and pagination). If someone is interested, I can recommend forking makesite.py, which is what I did and worked very well, and your only dependency is Python (and its standard library).

                            1. 7

                              Yep! You can apply templating with GNU Make and m4, both of which haven’t introduced any breaking changes in several decades, so the idea that templating inherently introduces churn and maintenance headache is rather silly.

                              1. 3

                                both of which haven’t introduced any breaking changes in several decades

                                GNU make occasionally introduces minor incompatibilities (see the first two notes).

                                But, yes, aside from that the core features have been the same for decades.

                                1. 2

                                  Interesting, thanks!

                                  While it’s unlikely those changes would affect HTML generation for such a site, I guess my original statement was over-broad. =)

                                2. 2

                                  Google and thee shall recieve: https://github.com/brandoninvergo/m4-bakery

                              2. [Comment removed by author]

                                1. 5

                                  What’s the point of writing it here? Just shoot him an email.