It's amusing to me how programmers look back with disdain at web development in the 90s and how "you just uploaded files to a FTP server" and now we've circled back to the same thing, just with a whole lot more plumbing in the middle.
For me, Netlify is the right mix (I'm not affiliated with them). It has the 90s ease of use with modern tools and performance out of the box. It's simple to upload files or sync a repo and it it's free. I'm not sure why anyone would host a static website on the AWS stack.
> I'm not sure why anyone would host a static website on the AWS stack.
Well, I do that, so I guess I'll chime in.
First and foremost is the idea of not tying your site's build process and hosting to a company that could go under. Yes, Amazon could, but if I had to bet Netlify will either cease to exist, be bought out, have its free offering discontinued/changed/etc. long before that.
Second is that sometimes your site's build process is more complicated than what Netlify provides. For example, my site is a static Hugo site, which Netlify supports, but there's one crucial step in the build process where I turn my "resume.html" page into "resume.pdf" -- I have to run a Docker image that starts headless Chrome in order to render the PDF properly. As far as I can tell, that can't be rigged up in Netlify.
Finally, I was able to learn a lot about AWS by hosting my site this way -- setting up a Lambda to listen for GitHub commits, using the AWS API to launch an EC2 instance to build my site, how to configure S3 and CloudFront to serve up content properly, etc. And at the end of the day I get a site that I have complete control over and is approximately free to run.
> First and foremost is the idea of not tying your site's build process and hosting to a company that could go under.
Sounds like you're imposing a complex build process on yourself while getting locked into a web of AWS features to be honest.
Could you not skip generating the PDF resume since you've already got the HTML version to keep life simple?
If you stick to running a basic NPM script to build your site there's little lock-in with Netlify. You could also build your site on a CI platform then push the generated pages + assets to Netlify after.
> Sounds like you're imposing a complex build process on yourself while getting locked into a web of AWS features to be honest.
I should elaborate a little. My whole site is contained within a Docker container that has NPM, Yarn, headless-chrome, Hugo, etc. I can generate everything with a single command. The AWS bits are just there for hosting and responding to a GitHub commit. So the build process is portable-ish, but from what I saw Netlify doesn’t just let you do headless-chrome on a free plan[1].
> Could you not skip generating the PDF resume
Not really, the point is to automate everything away behind a single Git push.
Why do you need a PDF resume that's built automatically though? Does it need to be in PDF? Does it change that often? Aren't resumes something you customise per job application?
For the first point, I'd say it's best to save the setup time by using a service like Netlify and keep that for if/when they shut down.
For the PDF, there's probably some service that could be used to wire that quick. But I agree that can be the cut-off point where it might be simpler for some to use docker.
I didn't vote on the comment but it came across to me as emblematic of what I feel is "wrong" with technology trends over the past decade. Where instead of solving business problems it's mostly building tools on top of tools or reinventing the wheel in the latest language/ecosystem. Programmers rarely produce anything of value anymore, but instead parade around their mastery of an increasingly complex toolchain that delivers the same end result.
It’s a page with some pretty fancy styling, a lot of it shared with the regular pages of my website. So it would be a ton of effort to port it to LaTeX.
You can install and run just about any binary: LaTeX being an example of a binary that generates PDFs. Just curious: what do you use to generate your PDFs?
The site is generated by Hugo, and the resume is one page on the site with some custom styling bits. Then a Docker container running headless Chrome plus some JS bits is used to export it to PDF.
I’ll give you my answer: I optimized for the lowest cost for a solution I could forget about. And not any suspicious free option like Github pages that might go away next year. True lowest cost hosting for a static website. AWS was the cheapest for me.
Does it matter? To people at our distance from it the process is a magical one where a git repo becomes a website. What technology stack they use, on which services, etc, is an abstraction that isn't particularly relevant to us.
If it broke it would take me all of minutes to have it hosted elsewhere. There is essentially zero lock-in with the service, even if you're using some of more complicated build steps.
And there seems to be a rash of "whoa I stumbled on my old site's url at {90's hosting provider} and it is still up and running after all these years" comments lately. (And loads instantaneously with no UI framework).
To be fair, when you dive deep into complexity, it's easy to get lost in the weeds. The trick is to remember what you're doing and why you're doing it so you don't lose sight of goals while chopping through the complexity jungle.
that is comical but doing what is described in this post in the 90s would have required load-balanced tower PCs strategically located all around the world, with another few computers acting as a load balancer, all maintaining copies of the website and cached server responses, and an expensive SSL certificate
we get all that for free now or 50 cents a month, just for static websites
there is almost no comparison, except for acknowledging that the plumbing sucks, all of which you can make better if you want.
It's amusing how quickly people forget how bad FTP was -- complex connection setup made it difficult to proxy, lack of encryption made it easy to sniff, managing FTP accounts was really hard without sophisticated auditing and management tools.
SSH/SFTP helped a lot on the security front, but even for small companies, it's way easier to use cloud buckets than FTP.
