1. 18

  2. 18

    “Static sites, on the other hand, are impossible to hack: there is no code running, and thus no vulnerabilities to exploit!”

    That’s overstating it. We were hacking static sites all the time before the invention of web applications. We did it via their web servers or other software running on the machine. Sometimes hit the boxes of people connecting to the machine with user or admin privileges. Vulnerabilities are still found in web servers. People still use buggy software in the trusted network. So, this claim should instead say they’re either more secure or harder to hack since they just depend on a web server without extra, bug-ridden code on top. Then, maybe a recommendation of using some specific ones that have good, track record both in number of vulnerabilities and how quickly they patch them. Maybe there should be a mention of Let’s Encrypt in that section, too. Kind of a combined recommendation.

    I like your additional sections on ownership and portability. Those were either not covered or barely discussed in some prior write-ups on static sites.

    1. 4

      That’s true – thanks for calling it out. What I typically do is deploy my static sites into an S3 bucket (with restricted permissions, obviously), then throw it behind Cloudfront for speed.

      Netlify is another awesome service that makes this stuff really easy/simple and mitigates a lot of the misconfigs for web servers/etc. that many people run into.

      1. 4

        I like your additional sections on ownership and portability.

        Funny enough, I have a problem with one of those sections.

        Take a look at any outsourced products, and compare them to in-house products: with very few exceptions, in-house projects are almost always better.

        I’m currently doing a POC of a competitor of Okta for enterprise authn/authz (ha!). The only metric favoring our in-house solution was cost.

        I’ve found that outsourced products are often more reliable, secure, and maintainable than in-house solutions. Where in-house solutions typically win are around matching the solution to the very specific business problem they’re designed to solve. When that’s enough, it’s perfect; when it isn’t, though, the rough edges really start to be noticed.

        1. 4

          Heh. I think my argument there was that you shouldn’t outsource your core product code. So if you’re a web company and your website is a main driver of your business, being able to customize/control it is pretty important. Really depends on the business goals though =)

          1. 3

            I think that’s fair. FWIW: after going through the static site/CMS debate internally, I can also agree 100% with your conclusion.

            I guess after further consideration what I’m arguing with here is your definition of “outsourcing”. To me, I’d rather toss dollars at SaaS to solve something that isn’t my core competency. If I can’t do that, I’d rather come up with an extremely narrowly tailored solution that addresses my very specific business needs. The least palatable option is a very general-purpose tool (like Drupal or Wordpress) that I still have to operationalize, as it tends to come with nasty headaches elsewhere.

            It’s an odd one… I’d chose to pay someone for operational certainty around a general purpose tool over operationalizing the general purpose tool myself. I wonder what that says about me.

            1. 2

              I agree. For what it’s worth, you should totally check out Netlify. They make managing static sites so easy. I started using it recently and absolutely fell in love with it <3 I’m not at all affiliated with them but it is useful.

      2. 8

        It’s worth noting that static sites and CMSs are not mutually incompatible - I work on one, Netlify CMS, which connects to a hosted Git repo and edits the content within it, which triggers a rebuild of the site if you have a CI pipeline set up. There’s other ways to do it as well, such as using a CMS which serves content through an API API (GraphQL is typical for this kind of CMS) which your static site generator pulls from to build the site, and having the CMS ping a service which rebuilds the site when changes are made. The term for these kind of CMSs is “headless CMS” - it’s only involved in editing your content, and the actual building, deployment, and hosting of the site is totally orthogonal. There’s a list of headless CMSs at https://headlesscms.org/ (disclaimer: this site is run by Netlify, though it’s an open-source project with a repo at https://github.com/netlify/headlesscms.org/).

        1. 2

          Awesome! I didn’t know this existed. I’m a huge fan of Netlify and use it for a lot of projects. Didn’t realize y’all have a CMS that works like that – I will investigate this fully.

          Your service is fantastic. Super clean + useful.

          1. 2

            There are a couple CMS options around. I’ve also been working on one: https://github.com/usetint

            1. 2

              Hey that looks sweet, and I was quite happy to see you support indieauth for sign in!

          2. 1

            I’ve believe Gatsby also supports this via its WordPress plugin. I don’t know how well it works, but lot of people (especially non-developers) are comfortable with the WordPress UI, so it could be a nice combo.

          3. 4

            I think the comparison is flawed. Static Sites are just a frontend, and you could generate a static site from WordPress if you wanted to…

            CMS on the other hand are content management system and are basically a backend for people to manage the content.

            Many CMS propose a frontend, which is not static, but you have other CMS types called headless, or API first CMS that make wonderful backend for static websites.

            The headless work great on the web, as backend for apps, pwa, web apps, etc. And itegrate with everything, chatbot, TV, whatever.

            1. 1

              CMSs that use dynamic code in the frontend tend to rely on that functionality. Maybe not the core product but many of the plugins needed do.

              Static Sites are just a frontend, and you could generate a static site from WordPress if you wanted to…

              You don’t want to do that believe me! I had to implement exactly this a few months ago. The pain of having to manually figure out which files were missed by the export plugin to manually add them is big. Trying to teach people that most plugins won’t work because code will not be executed for each request seems to be in vain. They happily install whatever might solve their problem and then complain that stuff isn’t working as expected on the static version. Forcing me to try to implement that functionality on the webserver level should that be even possible.

              1. 1

                I would of course not use WordPress as backend for my static site… But there are many excellent headless that you can use for that. Strapi, CloudCMS, Contentfull, Kentico cloud, etc.

                I personally use Cloud CMS.

                I agree that if your users are use to WordPress, and that they have freedom to add plugins etc, that is not a viable solution. What I meant with my comment is that a static site is your frontend, a CMS is where you maintain content, or where you are supposed to maintain content.

                But CMS have grown to become monsters that supposedly do everything… Like shops etc.

                What I advocate in the company I work for is “content as a micro service” where your CMS is used only to create and manage content and not to manage the design, the shop, etc.

                This is a little outdated and does not reflect exactly where I am with this thinking, but it is nevertheless the underlying idea : https://jboye.com/2017/06/27/the-making-of-ers-2-0/

                1. 1

                  Thanks that was an interesting read!

                  1. 1

                    Thank you!