I agree wholeheartedly with all of the points made in the article, but this website kinda sucks as an example.
- The website is "one binary", but the deploy strategy involves compiling it instead of running a binary artifact
- Won't rely on github pages, but depends on external resource at openlibrary.org
- Writing your own stuff lets you take advantage of open standards, but the .html files in thoughts/ are structured as plaintext with a false file extension
- When people go this route, they usually try to cram everything into the initial page load. This has several static files served dynamically.
- The Golang code does not cache any responses, and does not store templates in memory.
- Several dependencies in the go.mod file, all of them seem unused?
Most importantly:
No discussion about the technical benefits of the "single-binary" ethos compared to modern infrastructure.
It's my humble opinion that it's a great idea, and this is a poor example.
- The website is "one binary", but the deploy strategy involves compiling it instead of running a binary artifact
- Won't rely on github pages, but depends on external resource at openlibrary.org
- Writing your own stuff lets you take advantage of open standards, but the .html files in thoughts/ are structured as plaintext with a false file extension
- When people go this route, they usually try to cram everything into the initial page load. This has several static files served dynamically.
- The Golang code does not cache any responses, and does not store templates in memory.
- Several dependencies in the go.mod file, all of them seem unused?
Most importantly: No discussion about the technical benefits of the "single-binary" ethos compared to modern infrastructure.
It's my humble opinion that it's a great idea, and this is a poor example.