1. 14
  1.  

  2. 6

    After reading the article, it’s not clear to me why a collection of pages and posts is not enough to be a “site”.

    It’s also not clear what exactly is novel about this approach. Would wget paired with literally any web framework not have achieved the same with less ceremony?

    1. 5

      A collection of pages and posts is enough for many sites, but lacking for others.

      For example one might want to have an “event” content type, which isn’t sorted by publication date, but by the date of the event in list views. Or a “bookmarks” page which is just a collection of links and notes. Why have an extra file for each bookmark, when a simple yaml list for all of them might be enough?

      There’s nothing new about this approach, the post lists a few alternative to most tools known as “static site generators” which could often be described more accurately as “static blog generators”. https://www.getlektor.com/ isn’t listed, but should be mentioned as well in this context.

      1. 1

        one might want to have an “event” content type, which isn’t sorted by publication date, but by the date of the event in list views

        1. There isn’t any reason why you couldn’t sort on a different meta attribute in a static site
        2. It may or may not be important, but some typical nuances around a feature like this wouldn’t be available in a static site anyway, e.g., hide events that have happened in the past. For it to work, you would have to compare the event time with the system time. If that system is a machine under your control (the server, or your laptop where you run the generator) then this necessitates regular re-deploys. Otherwise that system is your reader’s machine, i.e., JavaScript, but that has it’s own drawbacks — it depends on your expectations.

        Or a “bookmarks” page which is just a collection of links and notes. Why have an extra file for each bookmark, when a simple yaml list for all of them might be enough?

        It’s not clear to me why you would need an extra file for each bookmark. If you want a page with a list of links in it, why not create one page with a list of links in it?

        1. 3

          There isn’t any reason why you couldn’t sort on a different meta attribute in a static site

          Yes, it’s not about a fundamental difference in ability. It’s mostly about convenience. I did use pelican for events a few years ago. Ported that site to lektor because that makes stuff like sorting and an ical feed much easier.

          If you want a page with a list of links in it, why not create one page with a list of links in it?

          Because you retain the ability to filter and to present each item in different ways. You could for example implement categories with something like “statik”.

          1. 1

            I think it’s less about this not being a static site, but that the popular static site generators don’t offer clear path forwards for a lot of these use cases without doing a decent amount of work.

            Conversely, if you had the magical “write a dynamic app + DB and then just spit out a cached version of the results into a folder” sort of flow, a lot of this is … trivial? As easy to build as the dynamic version.

            In theory static site generators should at least be as easy to get right as dynamic ones, but if you paired me with flask + some crawler, I could make “non-blog” static sites a lot more easily than with something like jekyll

        2. 1

          After reading the article, it’s not clear to me why a collection of pages and posts is not enough to be a “site”.

          It’s enough for a lot of sites, but not all. The pages/posts model gets you quite far, but the moment you want to integrate more data types or extend the existing ones (/u/phaer gave some nice examples) it becomes tricky to work with.

        3. 5

          Gatsby uses GraphQL to query both your files on disk and external services when doing the static site build.

          That said, this is neat and I like the FileAlchemy idea :)

          1. 4

            For Ruby fans, I think Middleman has a very similar approach and would fit this use case quite well.

            1. 4

              Hugo https://gohugo.io/ which works exactly like this… define some data types and layouts and views for them. It can even call out to external APIs (at build time) to get data.

              Coupled with a means of triggering builds (CI/CD, periodic, or even dynamic end points) and you have a pretty dynamic static site.

              1. 4

                I’ve been using Frozen-Flask to make static sites for a long time. Recently, I wired together Frozen-Flask, Flask-FlatPages, flask-webpack, all in one. You can run npm start to build a complex static site (1000’s of pages) that has full support for CSS preprocessors, JavaScript babel toolchain, and the like (all via webpack), while being simple-as-can-be in how it generates HTML (Flask routes, Jinja2 templates and Markdown content). And you can develop locally in “dynamic mode” (static builds are for deploys, not development). Then, to deploy, thanks to Frozen-Flask, we just “freeze” the site use rsync to push the HTML + assets to a web server or CDN.

                This stack has also been amazing for working with junior developers/designers. Even my marketing team has the website running locally (after spending a little time getting Node/Python installed on their Macs). They even use GitHub as a sort-of CMS. It’s really great and simple, simple, simple, especially compared to some of the static site generator “frameworks” out there.

                It’s nice to be able to “preview” a site by looking at fully rendered HTML, CSS, and JavaScript. And it’s nice not to be forced into using heavyweight SPA frameworks like React or to be stuck with arbitrary “static” limitations as often happens in something like Jekyll. (Because you still have Python and Jinja2 as a full-blown escape hatch.)

                Recently, I needed to also have a “backend” service that was just as simple as the static sites. For that, I used the Python framework Zappa. It was great. To respond to dynamic requests or access authenticated services, Zappa lets us deploy a simple HTTP server that is powered by AWS Lambda, AWS API Gateway, and the like, but is powered by a simple set of Flask routes and view functions. It took a little “AWS know-how” to get initially set up, but once it was set up, I could hand it off to my designers/developers, and it was a Heroku-like single-button-deploy experience. Feels to them just as simple as the static site – no servers to run, no scaling to worry about, etc.

                I hadn’t heard of Flask-FileAlchemy before but it looks interesting. Will check it out.

                1. 1

                  That sounds like an interesting setup. I’d love to read more about it. Is it all internal at this point?

                  1. 2

                    I was planning on turning it into a blog post and GitHub repo. It can’t exactly be a standalone project; it’s more like a Flask & npm starter project. Someone has suggested to me to use the Python tool cookiecutter for this.

                    1. 1

                      A blog post would be nice!