9 ms·

The theory versus the practice of “static websites”

291 points by ingve 3y ago

jasmer 3y ago
[dead]
floren 3y ago
My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc. It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope you have Cloudflare set up". I don't, but the load average on my 2 core, 1GB memory VPS never exceeded 0.15.
- eyelidlessness 3y ago
  That is an odd mix (without additional detail at least). I’m curious about the rationale for dynamically rendering the Markdown. I can think of a few reasons (dynamic content templated in, reduced build time/complexity come to mind), but maybe it’s something(s) I haven’t considered.
  - floren 3y ago
    It was basically a pragmatic choice. I figured the following: - For most of the site, hand-jamming HTML works fine, because I have a small number of pages outside the blog. - For the blog, I wanted easy authoring, thus Markdown. I figured if I rendered it on each request, I wouldn't need to make a separate tool to regen stuff, I could just build it all into the server; any changes I made to the markdown would be instantly reflected on the site. I wrote this in Go at a conference in 2011. Hugo didn't exist yet or I probably would have just used that. edit: I initially wrote this on Plan 9, and it's so old that there's still a mkfile invoking go/8g and go/8l individually to build it. It's 265 lines of code, which does the static content, generates the blog stuff (including creating the blog "archive" page on-demand), and manages multiple domains so I don't have to invoke e.g. apache to use the same host for multiple sites.
- derefr 3y ago
  Odd today, but you're essentially describing the idiomatic, pre-framework use-case that drove the design of PHP. "It's mostly HTML, but when you get to this line in this one file, run it as code [to e.g. parse some other file from some other format] and embed the result in the output." Made perfect sense in 2001 for building a static website where you happened to want to have e.g. a comments section on each blog post. And this kind of PHP was cheap enough that even your ISP was usually willing to let you slap some of it up on your /~userdir/ and point the public Internet at it.
  - Andrex 3y ago
    I went from hacking up the source HTML files I designed on Geocities and uploading them to Freewebs (so I could remove the linkback/ads) and it worked really well for a while. Then I wanted dynamic stuff and PHP was perfect. Eventually I accepted the stigma it had even while I never really bumped into the ugly parts, or even treated it as a normal programming language. I think after bouncing around with Node and the flavor-of-the-week static site generators, I might be going back to PHP for my personal sites. Which is insane. If you told me I'd be heading in this direction anywhere between 2 and 15 years ago, I'd think you were lying. All I really need are template files. I could use iframes but that stinky technology actually deserves its stink.
- earthboundkid 3y ago
  I think people underestimate how fast computers are now. You can easily withstand Hacker News with a small VPS as long as you have a sane architecture that isn’t too database heavy. Yeah, if you launch Threads you need whatever it is Facebook does to scale. But for a regular read only site? You don’t need to spend very much at all.
rubicks 3y ago
Shoutout to Gitlab Pages for making this easy. https://docs.gitlab.com/ee/user/project/pages/ https://docs.gitlab.com/ee/user/project/pages/
henriqueleng 3y ago
If you guys are looking for some very simple shell script that generates nice and easily extensible static pages you can check my script: https://github.com/henriqueleng/shite https://github.com/henriqueleng/shite
koromak 3y ago
I think the worst part of dynamic (JS) websites is the air gap between client and server. Its so painfully obvious compared to a static site. The Data flow feels like client->transform->api->transform->server->db->server->transform->api->transform->client, the song and dance just gets old after a while. I stupidly started my API interface as just a million unstructured JSON endpoints, each one with its own requirements / json structure / cache strategy / etc. The amount of work that essentially feels like boilerplate is mind-numbing. I haven't looked around for better alternatives very much, but I would be greatly interested in technology that makes the client/server boundary feel nonexistent, without needing to totally upend your current stack with a brand new framework like Next or something. Just a drop-in library that makes the server feel like another clientside API. I have no idea how that would be done without excessive coupling of the client/server though.
- 8n4vidtmkvmk 3y ago
  There have been lots of attempts to blur client and server. The latest Next is one, Meteor is several years old now and does something similar iirc, and a few other less popular ones. I don't think a drop in lib is possible by its nature tho, client and server have to cooperate. I've found random endpoints works reasonably well tho. You can change the server response and it only affects one client page. Easy to maintain. If you want more structure, you can also try GraphQL.
dasil003 3y ago
I agree with the author, and I think it mostly comes down to the original article author being young and not really having much perspective on the reliability, stability and backwards-compatibility of HTML/CSS/HTTP and traditional file servers over time. The fact that you can pick up an HTML file from 1993, trivially drop it on any type of web host, and have it be accessible on any browser on any platform more or less exactly as it looked then is not to be underestimated. Compiling and running any source code from 1993 that hasn't seen maintenance since then is going to range from slightly annoying to a monumental effort requiring essentially a full rewrite. This is exemplified by this comment: > There have now been a significant number of attempts to "platformitize" dynamic computation — "serverless" programming like AWS Lambda, WASM runtimes like those provided by CloudFlare and Fastly, full container deployment via Fly.io and cloud providers. None of these have an API nearly as stable as the filesystem API used to host static files, but it's a matter of time before APIs end up well-established. Containers and WASM are certainly interesting vectors of standardization, but even if everything goes fully to plan by the most bullish proponents, you still have a much more complex environment where incentives to break backwards compatibility make it exceedingly unlikely that you'll be able to just grab a container and WASM binary and drop them into any commodity host 30 years from now. Of course HTML/CSS rendering could break too, but incentives are skewed more in favor backwards compatibility. Also, because it's just a simple, human-readable file format, slight breakage doesn't render the archive useless. Heck, even the destruction of the internet and all servers doesn't render the file useless—you just need to be able to decode ASCII/UTF-8 to extract value. I think a better thesis for the original author would have been that static site generators are not necessarily simpler than dynamic sites generated at request time. I agree with that wholeheartedly, but the beauty of the SSG is that if at any time I want to stop maintaining the code, I have a ready-made servable version of the site that is trivially archivable in perpetuity. Standardized data formats expressed in simple files will always be more durable than code.
alxmng 3y ago
I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.
- jrochkind1 3y ago
  If after 20 years of CMS/blogs (WordPress is 20), there isn't yet one...
- rcarmo 3y ago
  Hugo users would disagree with you.
- jstanley 3y ago
  Write your own. You know what subset of features you care about, only implement what you need how you need it, and don't worry about making it extensible for others. You'll never need to read any documentation or worry about breaking changes when you update it, and you'll know exactly what it is doing. I wrote my blog's static site generator 10 years ago and I'm still using it. If I want something it doesn't do, I change it. It's still a single-file perl script and it's easier (for me) than any other option.
- Santosh83 3y ago
  Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of this), Joe wanting to publish his thoughts or photos still either has to sell his soul to FB/Insta/whatever or fork over significant cash for the likes of Wordpress/Squarespace, OR spend days to teach himself the nitty-gritty of buying a domain, fiddling with your DNS, setting up dynDNS, connecting all this to GitHub pages or whatever, fronting the whole thing with Cloudflare.
  - 3y ago
nicbou 3y ago
I run a content website for a living. This year I switched from Craft CMS to my own static site generator. I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance. The best part for me is that I can work offline. It's just me and my text editor, so even my tiny Macbook 12" feels blazing fast. Version control is also incredibly valuable. I can review my changes or roll them back. I can also find/replace across the entire content with regex. Text files are easy to work with. I wrote about how it feels and why it works here: https://nicolasbouliane.com/projects/ursus https://nicolasbouliane.com/projects/ursus
- hinkley 3y ago
  I keep thinking one of the things we should look for in a nextgen version control system is a useful API. Many apps need VCS, not a database, and CMS is one of the clearest.
- Takennickname 3y ago
  What do you think would benefit other than content systems?
- ishanmahapatra 3y ago
  Did you name your SSG Ursus after the bear on Berlin’s flag?
- glogla 3y ago
  Wow, that website loads so fast.
  - nicbou 3y ago
    It's very small, the CSS is inlined before the content, everything loads in a single request, and I use fonts and images sparsely. CloudFlare makes it fast everywhere.
  - steve76 3y ago
flohofwoe 3y ago
As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.
- stavros 3y ago
  Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.
  - flohofwoe 3y ago
    What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)
    - jamil7 3y ago
      Careful, they might steal your for loops.
    - stavros 3y ago
      Yes, but that's enough for a billion valuation nowadays, so...
  - BrandoElFollito 3y ago
    With modern frameworks it is not even that. What you get is a compiled, minimized page where all of the technical interesting things are lost after the build step. The only thing you can make use of is the design and the actual content.
- suprjami 3y ago
  I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.
movpasd 3y ago
From the perspective of a developer, I think the distinction is pretty clean and lies in the abstraction provides by the web (by which I mean hypermedia served over HTTP/S). The semantics of that abstraction are that requests come in to a specific path with headers and a body, and then responses are sent back out with headers and a body. The intermediate networking details like TLS are hidden. In fact, more and more things are being hidden from the developer, with most modern frameworks automatically managing authorization sessions and request headers. Within that abstraction, the standard "static doesn't depend on request/state, dynamic does" is pretty clean, but it does rely on the semantics provided by the abstraction. It's a little bit like TCP being a connection-oriented protocol over a fundamentally packet-based underlying infrastructure. I can use TCP for applications that require stream-like or packet-like data transfer. Then you could argue that "in reality, the distinction doesn't exist because it's built on IP which is packet-like". Sure — but you'd be on the wrong layer of abstraction. That's not to say the article doesn't make a good point. As developers, we should certainly always keep in mind the underlying statefulness of "stateless websites". It's always good to know your abstractions a few layers deeper than you think you need.
littlecranky67 3y ago
Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interface any REST API you like, and be as dynamic as you want. Plus, MDX plugin makes it easy to creates competely static areas/content focus sites within the same project. Unfortunately, I get the feel that with the release of v13 app router, they don't give the static export feature enought love. Features from the pages router were dropped for static export (shallow routing, static rewrites/redirects). I fear they are dropping static export all together in the future, as you don't need their comercial vercel offering at all when using static export.
- toastal 3y ago
  This is incredibly complex for many static site use cases (i.e. blogs, documentation, marketing pages). Most don’t need JavaScript let alone React/JSX/Middleware/SSR/et al. I can’t imagine the long-term maintenance of something with so many moving parts and npm dependencies. Not saying there’s not a use case, but we should KISS before jumping to projects with a 1.8 GiB Git checkout & 828,128 LoC just to make a landing page.
  - littlecranky67 3y ago
    It is definetely only geared if you create a webapp, not a website. You can have static content (with MDX) for certain parts of your app, and restrict i.e. dynamic javascript stuff to your user's account/login section. But everything is within a single codebase. I personally don't care for the size of my node_modules folder, storage is cheap. Plus, with a yarn.lock or package.lock you don't have to care about npm dependencies, if you don't upgrade any, your simple `yarn install && next build && next export` will always produce the same result for years to come. The actual export output of NextJS is amongst the smallest you can get - you also get a nice summary of how big the initial load is for every route. Everything is chunked per route, all js chunks and assets contain their hash in the filename. That is why you can serve all of /_next/static with the `Cache-control: immutable`. This means if you don't update a section of your app, there is not even a need for the client to send GET requests with the `If-modified-since`, means: No additional roundtrip for any chunks. Preloading can be configured, by default its on-link-hover - that is, if your user hovers over a hyperlink/route, nextjs will already fetch the required chunks for that route before the click happens. Yes, NextJS is not competing with Hugo or other static site generators. It is aimed at tech-savvy people, and only for webapps that will require programming JS.
bradley13 3y ago
Seems obvious enough: a static website runs no server-side code to generate content, because the content is already complete. Perhaps more debatable, but I would also say no client-side code should be used. Just HTML, CSS, and static media files. FWIW for my personal site, I run my own web server, which is incapable of running server-side code. It just copies files to sockets, nothing else.
- MrJohz 3y ago
  I think the key point that the original article was making was that there is server side generation going on - some server still needs load the file and turn it into an HTTP response, with all the correct headers, metadata, etc, and with the correct failures when the file can't be found. This server-side code needs to be implemented (and configured, etc) somewhere. That said, as the second article points out, static vs dynamic can still be a useful abstraction layer, as static servers like nginx and Apache are so solid that you can usually just treat them as part of the basic HTTP infrastructure.
  - BrandoElFollito 3y ago
    Static content can be hosted at the edge so the client calls never reach your server. There is obviously something that must serve the content but it is not necessarily you.
account-5 3y ago
I'm thinking of taking what should be a simple fast business website where the only dynamic bit is a contact form from Squarespace due the ridiculous need to the current site to run about 40 JavaScript scripts to load it. I can definitely hand generate the small amount of content in it and could work out the contact form easy enough, but having no experience with websites don't know where to start with things like hosting, etc. Hopefully can learn something here.
- sourcecodeplz 3y ago
  Just use a Google Form and embed it in the contact page.
jacquesm 3y ago
In practice most static websites aren't static because they include a bunch of stuff from elsewhere. But if you stay away from that pitfall and focus for a bit it is perfectly possible to have a really static website, my blog has been based on that for a couple of years now and I've never looked back after making that decision. It doesn't even have an analytics tracker, no outside fonts or anything that could slow it down. The end result is lightning fast performance, minimal memory footprint for the pages and rock solid because serving files over the web is a 'solved problem'. As an extra bonus by not including a bunch of eye candy and other unnecessary items I don't waste resources on the side of the viewer(s), and there is next to no chance of this setup developing a security hole in a framework. Highly recommended if you want a low maintenance rock solid transmit only website. Besides my blog, Pianojacq.com is set up much along the same lines, but there is a major difference, it interacts heavily with peripherals (MIDI) and needs a database (locally, not remotely), the end result is a highly interactive but still 100% static website.
seanwilson 3y ago
I think one big missing part still with static sites is how you host the CMS to edit it. Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies requests for you but now you're tied to Netlify and their pricing plan changes. GitLab and BitBucket will have the same issue I think: https://github.com/isomorphic-git/isomorphic-git#cors-support https://github.com/isomorphic-git/isomorphic-git#cors-suppor... Is there a simple solution here with minimal configuration? I guess you could use a browser extension to selectively relax CORS but that's not ideal. It feels like a Git-based static site generator with a CMS that has Markdown editing and live previews that runs in the browser with minimal hosting/server restrictions would work for a huge number of small websites and blogs.
- oceanstone 3y ago
  This local backend feature seems pretty powerful for free/offline editing: https://decapcms.org/docs/beta-features/#working-with-a-local-git-repository https://decapcms.org/docs/beta-features/#working-with-a-loca...
- james-bcn 3y ago
  What I would like is a good way to create structured data admin systems that can include HTML content, and then have my static generator access that to build the pages via a JSON feed or whatever. For example, having records for individual products including a body description which can be in HTML format. This means that other people can update the products, but we still have a static website. I thought Airtable would be suitable but surprisingly it doesn't support HTML fields very well.
  - seanwilson 3y ago
    Not sure if this helps but Decap-CMS lets you define your own records with fields, like a shopping product record with a price field and Markdown/HTML description, where the content is saved to Git in simple JSON/YAML data files. You can then edit the records via the browser web interface, which commits changes to Git and your static site generator would build the site from the data files. Decap-CMS demo here: https://cms-demo.netlify.com/#/collections/posts https://cms-demo.netlify.com/#/collections/posts
forrestthewoods 3y ago
My blog is static and doesn’t even use a static generator. For the mildly capable programmer I’m fully convinced this is the way. https://www.forrestthewoods.com/blog/ https://www.forrestthewoods.com/blog/
- jamiedumont 3y ago
  This is my approach too for my photography portfolio. It’s undoubtedly more work for a single edit/update/addition but over time the simplicity means that I’m not doing maintenance or migrating content between different tools that it’s less work in the long run.
- dpritchett 3y ago
  Can you describe your process? Do you just hand type import-free HTML and rsync it up to a web server? I’d make so many syntax errors without at least some sort of lint/build step.
  - forrestthewoods 3y ago
    My blog is hosted on Netlify and lives in a GitHub repo. Updating the public blog is as simple as git push. I write and iterate my blog posts in a raw text file. When I’m happy I make a copy/paste an existing post and then modify the title and body. There’s no server or build step. I just open the local .html file in my local browser. My build process is change HTML and press F5 in browser. I have experimented with markdown-to-html converters. They’re ok but not a game changer. Most of my posts have no JavaScript. But a few with custom visualizations do.
otar 3y ago
Web was invented to be static, we made it dynamic.
quickthrower2 3y ago
For convenience I prefer wordpress. I am more likely to remember how to use a site in 5 years if maintaining for someone else if it is wordpress than some static site generating script. That is just me though. For a personal blog the idea of going real old school and editing the files (maybe a simple bash script to bulk update menus etc.) is appealing though. Since my metric is “can I come back in a few years and figure out what I did”
- arkitaip 3y ago
  I love WordPress but wish it had pods built-in and a visual bilder more like Elementor where you can design everything including templates and content types.
draw_down 3y ago
[dead]
drewrbaker 3y ago
At my agency we probably build two custom sites a month. We used to do this with PHP WordPress templates, then we moved to Nuxt server side rendered on Node (Heroku), but now we are all static site Nuxt on Netlify and it’s SO MUCH better. Headless WordPress as backend. As long as you/client can deal with the build times it’s fantastic from a speed, SEO and uptime POV. Also just way cheaper to host it. Incremental Static Generation seems like the ideal solution, looking forward to that with Nuxt 3.
- snowwrestler 3y ago
  You are actually running a Wordpress site with a reverse proxy cache with forever TTLs. The fact that the cache is implemented as HTML on a file system is incidental. You could deliver the same speed, SEO, and uptime with any such technology, such as putting a regular Wordpress site behind Cloudflare or Fastly with forever TTLs and running a cache warming script.
zzzeek 3y ago
the very important thing about static sites are that you can much more easily "fire and forget" a static site - put it up on an S3 bucket site or whatever and you are pretty much in the clear about worrying about it. put up a "fire and forget" site using any kind of PHP or (perish the thought) wordpress (assuming self hosting), and if you dont check that site a few times a year, it will be all Russian porn ads before you know it.
- victorbjorklund 3y ago
  And if you dont get hacked you risk that your site is just offline due to something breaking down (maybe the db needs to be restarted, maybe the webhost changed php version etc). I got a couple of static sites and it so nice to know they are always up and never need to be fixed. My dynamic sites on the other hand needs to have alerts to check if they go down.
  - ytjohn 3y ago
    Outdated PHP is a big thing. So many times I've pulled a php file from an old server and it fails to run on the new because some methods were deprecated twenty-dickety-two. Which isn't a criticism of the language, just how things go. You either have to rewrite it to modern or run an unsupported version of PHP.
thomashabets2 3y ago
I used m4 some time in the 90s to generate my site, before I'd heard the term "static site generator". Then I switched to PHP, and then Python, and now back to static using Jekyll. It's just so much better, when possible to use. Aside from SSL certs everything can be fixed on your timeline. Compare PHP breaking something on upgrade, where you need to fix it immediately, and the site is down until you're done. Static site, even if the generator breaks, fails... well... static. If you don't need to post anything new, then you don't have a problem. And if the server explodes, you can just ask a friend to host some files. Not "hey, you run PHP version X with settings Y, right? And postgres?". (Some friends maybe even say "no, I don't want PHP on my machine")
- PhilipRoman 3y ago
  I still use m4 for such tasks. I feel like it's only 1 step up from having a sed "s/VERSION/1.2.3/g" in terms of complexity and as long as everything can be done with external shell commands, you can avoid installing python, etc.
AndrewKemendo 3y ago
The vast majority of the internet is files of text and images that don’t need to be updated that often. Further, rendering of text and images is handled by client configured applications that change - with the content fitting into client specified configurations Given that, if you want your content to be fast to access and simple to maintain over the longest period then: 1. Provide the smallest possible amount of bytes to the client that completes the communication task 2. Format the data in a way that will remain supported by the most clients over the longest term It’s fun to play with different setups for a variety of use cases and server side rendering, but history shows that the most reliable design pattern prioritizes clients being able to consume and render data as quickly and clearly as possible. I’ve never found a simpler way to do that than a file server hosting static .html files with text, svgs and pngs.
brillout 3y ago
I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can. I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic. I've wrote more about it over here[2] (SSG = static, SSR = dynamic). [1] https://vite-plugin-ssr.com https://vite-plugin-ssr.com [2] https://vite-plugin-ssr.com/pre-rendering https://vite-plugin-ssr.com/pre-rendering
jameshart 3y ago
The biggest difference between a static site versus a dynamic one is security surface area. A static site web server can only ever, worst case, be induced to serve the wrong files. And you can mitigate that by making sure the only files you put on the server in the first place are ones you want to serve. A dynamic site can be induced to run code. It can be induced to return the wrong data from the database it has access to (passwords for example). It can be induced to modify data. Wordpress breaches happen all the time. Nginx breaches don’t.
- berkle4455 3y ago
  > Nginx breaches don’t Except when someone forgets to append a trailing slash on a location block with an alias directive.
- 3cats-in-a-coat 3y ago
  I just want to straighten the perspective on things a bit. Technically there's no web site that doesn't "run code". There's always code involved. It's code all the way down, from the web server to the file system drivers, the operating system and so on. While it's true that static files reduce attack surface, we need to think deeply why is that, and design intelligent dynamic systems that have the security of static ones. And ultimately it's about input, and how input is treated. It doesn't matter how complex code you run, if you accept no input, you can't attack that system. Of course with no input you can't even figure out which page to show. So there's always input, even for static sites. But I'm trying to point our attention to what's the major distinction here.
  - interroboink 3y ago
    Perhaps we could describe a dynamic website as being a static website + extra (i.e. the dynamic stuff). As mentioned in the article, every dynamic website will also need some static assets (the .js files, images, etc.) So, it seems like a dynamic website will always have greater attack surface area than a static one, by definition. It will have all of the static site surface area, plus some more. ---- I wonder if there is room for a language that is not as general as JS, but can still be used to add dynamism to a website. So, you don't have to be stuck in the "it's Turing complete, so we can't be sure it's well-behaved before running it" situation. Perhaps CSS is kinda turning into that, these days. Though maybe CSS will become Turing complete too, at this rate (:
simonw 3y ago
I've been exploring an architectural pattern for a few years now which I think gives you the best of both worlds: it lets you run dynamic server-side code, but in a way that's both extremely inexpensive to scale up and that is self-healing if anything breaks. I call it the Baked Data pattern: https://simonwillison.net/2021/Jul/28/baked-data/ https://simonwillison.net/2021/Jul/28/baked-data/ The key idea is that you deploy a full read-only copy of your site's data as an asset bundled into your application. This only works for sites that don't constantly have updates, since you need to re-deploy the entire site when anything changes (just like a fully static site). Benefits are you can deploy to inexpensive dynamic scale-to-zero hosting (like Vercel), you can handle any amount of traffic by running multiple copies of your app and if the app crashes your host can just restart the application automatically.
- snowwrestler 3y ago
  Back in the day, Drupal had a module called “Boost” that sort of did this. Once you activated it, it baked out every page of the site to HTML in a directory, and altered .htaccess to send all traffic there. When you updated content, it rebaked everything. https://www.drupal.org/project/boost https://www.drupal.org/project/boost
- mattlondon 3y ago
  I am not sure how this differs from a static site generator that also has some backend functionality? E.g. I've seen static sites with server-side search etc, comments systems etc which submit each post/comment as a separate flat file and then regenerate static pages automatically from those etc. Is it more that your approach stores stuff in sqlite and builds from that, rather than markdown files? That seems to be the only meaningful difference I can see compared to normal static sites with backend/server-side functionality?
  - simonw 3y ago
    It's a variant on that pattern. The key idea here is that your server-side stuff is completely read-only - so comment systems aren't supported - because the server-side data is treated as a deployment asset. Have you used platforms like Vercel? Their one big limitation is that you can't use persistent storage with them - if you want to talk to a database of some sort you need to add an extra database vendor. The baked data pattern works around that by bundling read-only data (usually a SQLite file) with your deployment.
mlhpdx 3y ago
Before CloudFront I had a setup that used custom HTTP server code to capture requests directly as S3 objects, then wait on an SQS queue for the response which would indicate the location of an S3 object containing the entire response verbatim. (Yes, each server could handle exactly one request at a time, call it a learning experience.) This was the closest I ever felt I got to a “static” website. The goal was to eliminate redundant computation, and it did that, but there are much better approaches these days. What I ended up with was just bespoke, persistent caching.
ericls 3y ago
A website is static when I control where write happens. A website is dynamic when other people can control where write happens.
AtNightWeCode 3y ago
I worked a lot with both SSR and SSG. I think SSG is the correct choice for most sites. There may be reasons to use SSR like if it is the only alternative to problematic client side rendering or in some cases security.
muhammadusman 3y ago
Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very similar to her website and also includes instructions on how to host it on Github Pages for $0/year versus what she is currently paying Wix at around $100/year. The template is here: https://github.com/usmanity/rose https://github.com/usmanity/rose
- mdrzn 3y ago
  "Prerequisites -Github account -Familiarity with markdown (learn more here) -Ability to run node.js and npm on your computer -Optional: a domain name." Definitely not the same as using Wix, and definitely not usable for non-technical people.
- TZubiri 3y ago
  Just let her use the tool designed for her demographic and you use the tool designed for yours.
  - eyelidlessness 3y ago
    There’s no harm at all in putting effort into building a tool which might suit the former, on top of the latter. That’s more or less how all software for non-technical people is built: simplifying a more complex technical solution to make it accessible for the intended audience.
- rollcat 3y ago
  My partner (who is very non-technical) went through registering a domain, making a Github account, installing VS Code, slapping some HTML together by hand, and putting most of these things together before she even mentioned to me that she wants a website. Of course it took us a bit more work to polish it, but 90% of the work was hers (I helped with things like setting up Hugo, Netlify, writing some template code, fixing the CSS on mobile, etc). The biggest pain point of making a static website is just wrangling the generator. We wanted an image gallery with a couple selected works showcased on the front page, and the combination of various Hugo features to achieve that exact effect turned out to be non-obvious. There was probably a way to make it simpler, but we haven't found the time to find it. I think most non-technical people can easily get the first 90% of the work done by themselves with the currently available tools, it's just the other 90% where you find yourself struggling ;) (https://alida.gallery/ https://alida.gallery/)

291 points by ingve 3y ago

[dead]

My personal website is an odd mix of static and dynamic; that is, it's mostly static, but the blog portion is dynamic. When you hit a blog URL, it fetches a Markdown file from the disk, converts to HTML, and then jams that HTML into a template which provides the rest of the page, brings in CSS, etc. It's still fast and efficient; when one of my blog posts was #1 on HN last week, my friend texted me "good luck, hope you have Cloudflare set up". I don't, but the load average on my 2 core, 1GB memory VPS never exceeded 0.15.

eyelidlessness 3y ago
That is an odd mix (without additional detail at least). I’m curious about the rationale for dynamically rendering the Markdown. I can think of a few reasons (dynamic content templated in, reduced build time/complexity come to mind), but maybe it’s something(s) I haven’t considered.
- floren 3y ago
  It was basically a pragmatic choice. I figured the following: - For most of the site, hand-jamming HTML works fine, because I have a small number of pages outside the blog. - For the blog, I wanted easy authoring, thus Markdown. I figured if I rendered it on each request, I wouldn't need to make a separate tool to regen stuff, I could just build it all into the server; any changes I made to the markdown would be instantly reflected on the site. I wrote this in Go at a conference in 2011. Hugo didn't exist yet or I probably would have just used that. edit: I initially wrote this on Plan 9, and it's so old that there's still a mkfile invoking go/8g and go/8l individually to build it. It's 265 lines of code, which does the static content, generates the blog stuff (including creating the blog "archive" page on-demand), and manages multiple domains so I don't have to invoke e.g. apache to use the same host for multiple sites.
derefr 3y ago
Odd today, but you're essentially describing the idiomatic, pre-framework use-case that drove the design of PHP. "It's mostly HTML, but when you get to this line in this one file, run it as code [to e.g. parse some other file from some other format] and embed the result in the output." Made perfect sense in 2001 for building a static website where you happened to want to have e.g. a comments section on each blog post. And this kind of PHP was cheap enough that even your ISP was usually willing to let you slap some of it up on your /~userdir/ and point the public Internet at it.
- Andrex 3y ago
  I went from hacking up the source HTML files I designed on Geocities and uploading them to Freewebs (so I could remove the linkback/ads) and it worked really well for a while. Then I wanted dynamic stuff and PHP was perfect. Eventually I accepted the stigma it had even while I never really bumped into the ugly parts, or even treated it as a normal programming language. I think after bouncing around with Node and the flavor-of-the-week static site generators, I might be going back to PHP for my personal sites. Which is insane. If you told me I'd be heading in this direction anywhere between 2 and 15 years ago, I'd think you were lying. All I really need are template files. I could use iframes but that stinky technology actually deserves its stink.
earthboundkid 3y ago
I think people underestimate how fast computers are now. You can easily withstand Hacker News with a small VPS as long as you have a sane architecture that isn’t too database heavy. Yeah, if you launch Threads you need whatever it is Facebook does to scale. But for a regular read only site? You don’t need to spend very much at all.

rubicks 3y ago

Shoutout to Gitlab Pages for making this easy. https://docs.gitlab.com/ee/user/project/pages/ https://docs.gitlab.com/ee/user/project/pages/

henriqueleng 3y ago

If you guys are looking for some very simple shell script that generates nice and easily extensible static pages you can check my script: https://github.com/henriqueleng/shite https://github.com/henriqueleng/shite

koromak 3y ago

I think the worst part of dynamic (JS) websites is the air gap between client and server. Its so painfully obvious compared to a static site. The Data flow feels like client->transform->api->transform->server->db->server->transform->api->transform->client, the song and dance just gets old after a while. I stupidly started my API interface as just a million unstructured JSON endpoints, each one with its own requirements / json structure / cache strategy / etc. The amount of work that essentially feels like boilerplate is mind-numbing. I haven't looked around for better alternatives very much, but I would be greatly interested in technology that makes the client/server boundary feel nonexistent, without needing to totally upend your current stack with a brand new framework like Next or something. Just a drop-in library that makes the server feel like another clientside API. I have no idea how that would be done without excessive coupling of the client/server though.

8n4vidtmkvmk 3y ago
There have been lots of attempts to blur client and server. The latest Next is one, Meteor is several years old now and does something similar iirc, and a few other less popular ones. I don't think a drop in lib is possible by its nature tho, client and server have to cooperate. I've found random endpoints works reasonably well tho. You can change the server response and it only affects one client page. Easy to maintain. If you want more structure, you can also try GraphQL.

dasil003 3y ago

I agree with the author, and I think it mostly comes down to the original article author being young and not really having much perspective on the reliability, stability and backwards-compatibility of HTML/CSS/HTTP and traditional file servers over time. The fact that you can pick up an HTML file from 1993, trivially drop it on any type of web host, and have it be accessible on any browser on any platform more or less exactly as it looked then is not to be underestimated. Compiling and running any source code from 1993 that hasn't seen maintenance since then is going to range from slightly annoying to a monumental effort requiring essentially a full rewrite. This is exemplified by this comment: > There have now been a significant number of attempts to "platformitize" dynamic computation — "serverless" programming like AWS Lambda, WASM runtimes like those provided by CloudFlare and Fastly, full container deployment via Fly.io and cloud providers. None of these have an API nearly as stable as the filesystem API used to host static files, but it's a matter of time before APIs end up well-established. Containers and WASM are certainly interesting vectors of standardization, but even if everything goes fully to plan by the most bullish proponents, you still have a much more complex environment where incentives to break backwards compatibility make it exceedingly unlikely that you'll be able to just grab a container and WASM binary and drop them into any commodity host 30 years from now. Of course HTML/CSS rendering could break too, but incentives are skewed more in favor backwards compatibility. Also, because it's just a simple, human-readable file format, slight breakage doesn't render the archive useless. Heck, even the destruction of the internet and all servers doesn't render the file useless—you just need to be able to decode ASCII/UTF-8 to extract value. I think a better thesis for the original author would have been that static site generators are not necessarily simpler than dynamic sites generated at request time. I agree with that wholeheartedly, but the beauty of the SSG is that if at any time I want to stop maintaining the code, I have a ready-made servable version of the site that is trivially archivable in perpetuity. Standardized data formats expressed in simple files will always be more durable than code.

alxmng 3y ago

I’m skeptical cheap and easy is something inherent with static sites. I think a dynamic setup can have both those qualities, but there isn’t yet CMS/blog software that hits the sweet spot: self-contained, simple to setup, manage, and host.

jrochkind1 3y ago
If after 20 years of CMS/blogs (WordPress is 20), there isn't yet one...
rcarmo 3y ago
Hugo users would disagree with you.
jstanley 3y ago
Write your own. You know what subset of features you care about, only implement what you need how you need it, and don't worry about making it extensible for others. You'll never need to read any documentation or worry about breaking changes when you update it, and you'll know exactly what it is doing. I wrote my blog's static site generator 10 years ago and I'm still using it. If I want something it doesn't do, I change it. It's still a single-file perl script and it's easier (for me) than any other option.
Santosh83 3y ago
Indeed. These days we have 24x7 net connections on both our mobiles as well as home LAN/desktop whatever, but you still can't get a single, 1-click, drop-dead simple program that you can use to both author as well as serve web-pages and images right from your own device. Thanks largely to dynamic IPs, NAT, firewalls, ISP upstream throttling and developer apathy (since their livelihood may depend on the complexity of this), Joe wanting to publish his thoughts or photos still either has to sell his soul to FB/Insta/whatever or fork over significant cash for the likes of Wordpress/Squarespace, OR spend days to teach himself the nitty-gritty of buying a domain, fiddling with your DNS, setting up dynDNS, connecting all this to GitHub pages or whatever, fronting the whole thing with Cloudflare.
- 3y ago

nicbou 3y ago

I run a content website for a living. This year I switched from Craft CMS to my own static site generator. I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance. The best part for me is that I can work offline. It's just me and my text editor, so even my tiny Macbook 12" feels blazing fast. Version control is also incredibly valuable. I can review my changes or roll them back. I can also find/replace across the entire content with regex. Text files are easy to work with. I wrote about how it feels and why it works here: https://nicolasbouliane.com/projects/ursus https://nicolasbouliane.com/projects/ursus

hinkley 3y ago
I keep thinking one of the things we should look for in a nextgen version control system is a useful API. Many apps need VCS, not a database, and CMS is one of the clearest.
Takennickname 3y ago
What do you think would benefit other than content systems?
ishanmahapatra 3y ago
Did you name your SSG Ursus after the bear on Berlin’s flag?
glogla 3y ago
Wow, that website loads so fast.
- nicbou 3y ago
  It's very small, the CSS is inlined before the content, everything loads in a single request, and I use fonts and images sparsely. CloudFlare makes it fast everywhere.
- steve76 3y ago

flohofwoe 3y ago

As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.

stavros 3y ago
Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.
- flohofwoe 3y ago
  What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)
  - jamil7 3y ago
    Careful, they might steal your for loops.
  - stavros 3y ago
    Yes, but that's enough for a billion valuation nowadays, so...
- BrandoElFollito 3y ago
  With modern frameworks it is not even that. What you get is a compiled, minimized page where all of the technical interesting things are lost after the build step. The only thing you can make use of is the design and the actual content.
suprjami 3y ago
I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.

movpasd 3y ago

From the perspective of a developer, I think the distinction is pretty clean and lies in the abstraction provides by the web (by which I mean hypermedia served over HTTP/S). The semantics of that abstraction are that requests come in to a specific path with headers and a body, and then responses are sent back out with headers and a body. The intermediate networking details like TLS are hidden. In fact, more and more things are being hidden from the developer, with most modern frameworks automatically managing authorization sessions and request headers. Within that abstraction, the standard "static doesn't depend on request/state, dynamic does" is pretty clean, but it does rely on the semantics provided by the abstraction. It's a little bit like TCP being a connection-oriented protocol over a fundamentally packet-based underlying infrastructure. I can use TCP for applications that require stream-like or packet-like data transfer. Then you could argue that "in reality, the distinction doesn't exist because it's built on IP which is packet-like". Sure — but you'd be on the wrong layer of abstraction. That's not to say the article doesn't make a good point. As developers, we should certainly always keep in mind the underlying statefulness of "stateless websites". It's always good to know your abstractions a few layers deeper than you think you need.

littlecranky67 3y ago

Big fan of NextJS and its static page export for that reason. I build and deploy just static .html/.js/.css to whatever CDN or static webserver of my choice. Since all indivudual pages/routes are pre-rendered during build, the first load is blazing fast and indexable by search engines. Also the way NextJS chunks the .js code and pre-loads contributes to the fast-load experience. For rich functionality you can interface any REST API you like, and be as dynamic as you want. Plus, MDX plugin makes it easy to creates competely static areas/content focus sites within the same project. Unfortunately, I get the feel that with the release of v13 app router, they don't give the static export feature enought love. Features from the pages router were dropped for static export (shallow routing, static rewrites/redirects). I fear they are dropping static export all together in the future, as you don't need their comercial vercel offering at all when using static export.

toastal 3y ago
This is incredibly complex for many static site use cases (i.e. blogs, documentation, marketing pages). Most don’t need JavaScript let alone React/JSX/Middleware/SSR/et al. I can’t imagine the long-term maintenance of something with so many moving parts and npm dependencies. Not saying there’s not a use case, but we should KISS before jumping to projects with a 1.8 GiB Git checkout & 828,128 LoC just to make a landing page.
- littlecranky67 3y ago
  It is definetely only geared if you create a webapp, not a website. You can have static content (with MDX) for certain parts of your app, and restrict i.e. dynamic javascript stuff to your user's account/login section. But everything is within a single codebase. I personally don't care for the size of my node_modules folder, storage is cheap. Plus, with a yarn.lock or package.lock you don't have to care about npm dependencies, if you don't upgrade any, your simple `yarn install && next build && next export` will always produce the same result for years to come. The actual export output of NextJS is amongst the smallest you can get - you also get a nice summary of how big the initial load is for every route. Everything is chunked per route, all js chunks and assets contain their hash in the filename. That is why you can serve all of /_next/static with the `Cache-control: immutable`. This means if you don't update a section of your app, there is not even a need for the client to send GET requests with the `If-modified-since`, means: No additional roundtrip for any chunks. Preloading can be configured, by default its on-link-hover - that is, if your user hovers over a hyperlink/route, nextjs will already fetch the required chunks for that route before the click happens. Yes, NextJS is not competing with Hugo or other static site generators. It is aimed at tech-savvy people, and only for webapps that will require programming JS.

bradley13 3y ago

Seems obvious enough: a static website runs no server-side code to generate content, because the content is already complete. Perhaps more debatable, but I would also say no client-side code should be used. Just HTML, CSS, and static media files. FWIW for my personal site, I run my own web server, which is incapable of running server-side code. It just copies files to sockets, nothing else.

MrJohz 3y ago
I think the key point that the original article was making was that there is server side generation going on - some server still needs load the file and turn it into an HTTP response, with all the correct headers, metadata, etc, and with the correct failures when the file can't be found. This server-side code needs to be implemented (and configured, etc) somewhere. That said, as the second article points out, static vs dynamic can still be a useful abstraction layer, as static servers like nginx and Apache are so solid that you can usually just treat them as part of the basic HTTP infrastructure.
- BrandoElFollito 3y ago
  Static content can be hosted at the edge so the client calls never reach your server. There is obviously something that must serve the content but it is not necessarily you.

account-5 3y ago

I'm thinking of taking what should be a simple fast business website where the only dynamic bit is a contact form from Squarespace due the ridiculous need to the current site to run about 40 JavaScript scripts to load it. I can definitely hand generate the small amount of content in it and could work out the contact form easy enough, but having no experience with websites don't know where to start with things like hosting, etc. Hopefully can learn something here.

sourcecodeplz 3y ago
Just use a Google Form and embed it in the contact page.

jacquesm 3y ago

In practice most static websites aren't static because they include a bunch of stuff from elsewhere. But if you stay away from that pitfall and focus for a bit it is perfectly possible to have a really static website, my blog has been based on that for a couple of years now and I've never looked back after making that decision. It doesn't even have an analytics tracker, no outside fonts or anything that could slow it down. The end result is lightning fast performance, minimal memory footprint for the pages and rock solid because serving files over the web is a 'solved problem'. As an extra bonus by not including a bunch of eye candy and other unnecessary items I don't waste resources on the side of the viewer(s), and there is next to no chance of this setup developing a security hole in a framework. Highly recommended if you want a low maintenance rock solid transmit only website. Besides my blog, Pianojacq.com is set up much along the same lines, but there is a major difference, it interacts heavily with peripherals (MIDI) and needs a database (locally, not remotely), the end result is a highly interactive but still 100% static website.

seanwilson 3y ago

I think one big missing part still with static sites is how you host the CMS to edit it. Correct me if I'm wrong but Decap CMS (previously Netlify CMS) runs in the browser and makes reads/edits via GitHub which can then trigger rebuilds and deploys, but it still needs a small server/proxy I think because CORS stops your browser communicating directly with the GitHub API. Netlify hosts a GitHub backend that proxies requests for you but now you're tied to Netlify and their pricing plan changes. GitLab and BitBucket will have the same issue I think: https://github.com/isomorphic-git/isomorphic-git#cors-support https://github.com/isomorphic-git/isomorphic-git#cors-suppor... Is there a simple solution here with minimal configuration? I guess you could use a browser extension to selectively relax CORS but that's not ideal. It feels like a Git-based static site generator with a CMS that has Markdown editing and live previews that runs in the browser with minimal hosting/server restrictions would work for a huge number of small websites and blogs.

oceanstone 3y ago
This local backend feature seems pretty powerful for free/offline editing: https://decapcms.org/docs/beta-features/#working-with-a-local-git-repository https://decapcms.org/docs/beta-features/#working-with-a-loca...
james-bcn 3y ago
What I would like is a good way to create structured data admin systems that can include HTML content, and then have my static generator access that to build the pages via a JSON feed or whatever. For example, having records for individual products including a body description which can be in HTML format. This means that other people can update the products, but we still have a static website. I thought Airtable would be suitable but surprisingly it doesn't support HTML fields very well.
- seanwilson 3y ago
  Not sure if this helps but Decap-CMS lets you define your own records with fields, like a shopping product record with a price field and Markdown/HTML description, where the content is saved to Git in simple JSON/YAML data files. You can then edit the records via the browser web interface, which commits changes to Git and your static site generator would build the site from the data files. Decap-CMS demo here: https://cms-demo.netlify.com/#/collections/posts https://cms-demo.netlify.com/#/collections/posts

forrestthewoods 3y ago

My blog is static and doesn’t even use a static generator. For the mildly capable programmer I’m fully convinced this is the way. https://www.forrestthewoods.com/blog/ https://www.forrestthewoods.com/blog/

jamiedumont 3y ago
This is my approach too for my photography portfolio. It’s undoubtedly more work for a single edit/update/addition but over time the simplicity means that I’m not doing maintenance or migrating content between different tools that it’s less work in the long run.
dpritchett 3y ago
Can you describe your process? Do you just hand type import-free HTML and rsync it up to a web server? I’d make so many syntax errors without at least some sort of lint/build step.
- forrestthewoods 3y ago
  My blog is hosted on Netlify and lives in a GitHub repo. Updating the public blog is as simple as git push. I write and iterate my blog posts in a raw text file. When I’m happy I make a copy/paste an existing post and then modify the title and body. There’s no server or build step. I just open the local .html file in my local browser. My build process is change HTML and press F5 in browser. I have experimented with markdown-to-html converters. They’re ok but not a game changer. Most of my posts have no JavaScript. But a few with custom visualizations do.

otar 3y ago

Web was invented to be static, we made it dynamic.

quickthrower2 3y ago

For convenience I prefer wordpress. I am more likely to remember how to use a site in 5 years if maintaining for someone else if it is wordpress than some static site generating script. That is just me though. For a personal blog the idea of going real old school and editing the files (maybe a simple bash script to bulk update menus etc.) is appealing though. Since my metric is “can I come back in a few years and figure out what I did”

arkitaip 3y ago
I love WordPress but wish it had pods built-in and a visual bilder more like Elementor where you can design everything including templates and content types.

draw_down 3y ago

[dead]

drewrbaker 3y ago

At my agency we probably build two custom sites a month. We used to do this with PHP WordPress templates, then we moved to Nuxt server side rendered on Node (Heroku), but now we are all static site Nuxt on Netlify and it’s SO MUCH better. Headless WordPress as backend. As long as you/client can deal with the build times it’s fantastic from a speed, SEO and uptime POV. Also just way cheaper to host it. Incremental Static Generation seems like the ideal solution, looking forward to that with Nuxt 3.

snowwrestler 3y ago
You are actually running a Wordpress site with a reverse proxy cache with forever TTLs. The fact that the cache is implemented as HTML on a file system is incidental. You could deliver the same speed, SEO, and uptime with any such technology, such as putting a regular Wordpress site behind Cloudflare or Fastly with forever TTLs and running a cache warming script.

zzzeek 3y ago

the very important thing about static sites are that you can much more easily "fire and forget" a static site - put it up on an S3 bucket site or whatever and you are pretty much in the clear about worrying about it. put up a "fire and forget" site using any kind of PHP or (perish the thought) wordpress (assuming self hosting), and if you dont check that site a few times a year, it will be all Russian porn ads before you know it.

victorbjorklund 3y ago
And if you dont get hacked you risk that your site is just offline due to something breaking down (maybe the db needs to be restarted, maybe the webhost changed php version etc). I got a couple of static sites and it so nice to know they are always up and never need to be fixed. My dynamic sites on the other hand needs to have alerts to check if they go down.
- ytjohn 3y ago
  Outdated PHP is a big thing. So many times I've pulled a php file from an old server and it fails to run on the new because some methods were deprecated twenty-dickety-two. Which isn't a criticism of the language, just how things go. You either have to rewrite it to modern or run an unsupported version of PHP.

thomashabets2 3y ago

I used m4 some time in the 90s to generate my site, before I'd heard the term "static site generator". Then I switched to PHP, and then Python, and now back to static using Jekyll. It's just so much better, when possible to use. Aside from SSL certs everything can be fixed on your timeline. Compare PHP breaking something on upgrade, where you need to fix it immediately, and the site is down until you're done. Static site, even if the generator breaks, fails... well... static. If you don't need to post anything new, then you don't have a problem. And if the server explodes, you can just ask a friend to host some files. Not "hey, you run PHP version X with settings Y, right? And postgres?". (Some friends maybe even say "no, I don't want PHP on my machine")

PhilipRoman 3y ago
I still use m4 for such tasks. I feel like it's only 1 step up from having a sed "s/VERSION/1.2.3/g" in terms of complexity and as long as everything can be done with external shell commands, you can avoid installing python, etc.

AndrewKemendo 3y ago

The vast majority of the internet is files of text and images that don’t need to be updated that often. Further, rendering of text and images is handled by client configured applications that change - with the content fitting into client specified configurations Given that, if you want your content to be fast to access and simple to maintain over the longest period then: 1. Provide the smallest possible amount of bytes to the client that completes the communication task 2. Format the data in a way that will remain supported by the most clients over the longest term It’s fun to play with different setups for a variety of use cases and server side rendering, but history shows that the most reliable design pattern prioritizes clients being able to consume and render data as quickly and clearly as possible. I’ve never found a simpler way to do that than a file server hosting static .html files with text, svgs and pngs.

brillout 3y ago

I agree and, as the author of vite-plugin-ssr[1], that's what I recommend to my users: go for static whenever you can. I think it's something every web developer should be aware of. Static is indeed a lot simpler than dynamic. I've wrote more about it over here[2] (SSG = static, SSR = dynamic). [1] https://vite-plugin-ssr.com https://vite-plugin-ssr.com [2] https://vite-plugin-ssr.com/pre-rendering https://vite-plugin-ssr.com/pre-rendering

jameshart 3y ago

The biggest difference between a static site versus a dynamic one is security surface area. A static site web server can only ever, worst case, be induced to serve the wrong files. And you can mitigate that by making sure the only files you put on the server in the first place are ones you want to serve. A dynamic site can be induced to run code. It can be induced to return the wrong data from the database it has access to (passwords for example). It can be induced to modify data. Wordpress breaches happen all the time. Nginx breaches don’t.

berkle4455 3y ago
> Nginx breaches don’t Except when someone forgets to append a trailing slash on a location block with an alias directive.
3cats-in-a-coat 3y ago
I just want to straighten the perspective on things a bit. Technically there's no web site that doesn't "run code". There's always code involved. It's code all the way down, from the web server to the file system drivers, the operating system and so on. While it's true that static files reduce attack surface, we need to think deeply why is that, and design intelligent dynamic systems that have the security of static ones. And ultimately it's about input, and how input is treated. It doesn't matter how complex code you run, if you accept no input, you can't attack that system. Of course with no input you can't even figure out which page to show. So there's always input, even for static sites. But I'm trying to point our attention to what's the major distinction here.
- interroboink 3y ago
  Perhaps we could describe a dynamic website as being a static website + extra (i.e. the dynamic stuff). As mentioned in the article, every dynamic website will also need some static assets (the .js files, images, etc.) So, it seems like a dynamic website will always have greater attack surface area than a static one, by definition. It will have all of the static site surface area, plus some more. ---- I wonder if there is room for a language that is not as general as JS, but can still be used to add dynamism to a website. So, you don't have to be stuck in the "it's Turing complete, so we can't be sure it's well-behaved before running it" situation. Perhaps CSS is kinda turning into that, these days. Though maybe CSS will become Turing complete too, at this rate (:

simonw 3y ago

I've been exploring an architectural pattern for a few years now which I think gives you the best of both worlds: it lets you run dynamic server-side code, but in a way that's both extremely inexpensive to scale up and that is self-healing if anything breaks. I call it the Baked Data pattern: https://simonwillison.net/2021/Jul/28/baked-data/ https://simonwillison.net/2021/Jul/28/baked-data/ The key idea is that you deploy a full read-only copy of your site's data as an asset bundled into your application. This only works for sites that don't constantly have updates, since you need to re-deploy the entire site when anything changes (just like a fully static site). Benefits are you can deploy to inexpensive dynamic scale-to-zero hosting (like Vercel), you can handle any amount of traffic by running multiple copies of your app and if the app crashes your host can just restart the application automatically.

snowwrestler 3y ago
Back in the day, Drupal had a module called “Boost” that sort of did this. Once you activated it, it baked out every page of the site to HTML in a directory, and altered .htaccess to send all traffic there. When you updated content, it rebaked everything. https://www.drupal.org/project/boost https://www.drupal.org/project/boost
mattlondon 3y ago
I am not sure how this differs from a static site generator that also has some backend functionality? E.g. I've seen static sites with server-side search etc, comments systems etc which submit each post/comment as a separate flat file and then regenerate static pages automatically from those etc. Is it more that your approach stores stuff in sqlite and builds from that, rather than markdown files? That seems to be the only meaningful difference I can see compared to normal static sites with backend/server-side functionality?
- simonw 3y ago
  It's a variant on that pattern. The key idea here is that your server-side stuff is completely read-only - so comment systems aren't supported - because the server-side data is treated as a deployment asset. Have you used platforms like Vercel? Their one big limitation is that you can't use persistent storage with them - if you want to talk to a database of some sort you need to add an extra database vendor. The baked data pattern works around that by bundling read-only data (usually a SQLite file) with your deployment.

mlhpdx 3y ago

Before CloudFront I had a setup that used custom HTTP server code to capture requests directly as S3 objects, then wait on an SQS queue for the response which would indicate the location of an S3 object containing the entire response verbatim. (Yes, each server could handle exactly one request at a time, call it a learning experience.) This was the closest I ever felt I got to a “static” website. The goal was to eliminate redundant computation, and it did that, but there are much better approaches these days. What I ended up with was just bespoke, persistent caching.

ericls 3y ago

A website is static when I control where write happens. A website is dynamic when other people can control where write happens.

AtNightWeCode 3y ago

I worked a lot with both SSR and SSG. I think SSG is the correct choice for most sites. There may be reasons to use SSR like if it is the only alternative to problematic client side rendering or in some cases security.

muhammadusman 3y ago

Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very similar to her website and also includes instructions on how to host it on Github Pages for $0/year versus what she is currently paying Wix at around $100/year. The template is here: https://github.com/usmanity/rose https://github.com/usmanity/rose

mdrzn 3y ago
"Prerequisites -Github account -Familiarity with markdown (learn more here) -Ability to run node.js and npm on your computer -Optional: a domain name." Definitely not the same as using Wix, and definitely not usable for non-technical people.
TZubiri 3y ago
Just let her use the tool designed for her demographic and you use the tool designed for yours.
- eyelidlessness 3y ago
  There’s no harm at all in putting effort into building a tool which might suit the former, on top of the latter. That’s more or less how all software for non-technical people is built: simplifying a more complex technical solution to make it accessible for the intended audience.
rollcat 3y ago
My partner (who is very non-technical) went through registering a domain, making a Github account, installing VS Code, slapping some HTML together by hand, and putting most of these things together before she even mentioned to me that she wants a website. Of course it took us a bit more work to polish it, but 90% of the work was hers (I helped with things like setting up Hugo, Netlify, writing some template code, fixing the CSS on mobile, etc). The biggest pain point of making a static website is just wrangling the generator. We wanted an image gallery with a couple selected works showcased on the front page, and the combination of various Hugo features to achieve that exact effect turned out to be non-obvious. There was probably a way to make it simpler, but we haven't found the time to find it. I think most non-technical people can easily get the first 90% of the work done by themselves with the currently available tools, it's just the other 90% where you find yourself struggling ;) (https://alida.gallery/ https://alida.gallery/)