Show HN: Stasis, a simple static site generator with deployment to S3/CloudFront
49 points by czep 4 years ago | 29 comments- mekkkkkk 4 years agoSo it's Jekyll, but in Python, with the added benefit of... what exactly? Deploying on a CDN is a one line shell script. Maybe I'm missing something.
There seems to be a lot of static site generators being advertised nowadays. Is it because none of the big ones are feature complete? Or is it just a fun/easy thing to do as a hobby project?
- softwaredoug 4 years agoI think the latter. And users of static site generators like Jekyll tend to like to tinker a lot within Jekyll. It’s a natural transition to try and build your own.
- ulisesrmzroche 4 years agoI think it’s the same “build your own blog” project we all share only with modern tools and architecture.
Shout-out to the ancient “Staticmatic” Ruby gem, first open-source project I even contributed to, and still got the best name
- jjjbokma 4 years agoFor me the latter. I wrote a static microblog generator [0] for my own site [1]. There is both a Perl and a Python version. I wrote the latter to learn more about Python.
[0] https://github.com/john-bokma/tumblelog [1] https://plurrrr.com/
- nerdponx 4 years agoThere has been a glut of SSGs out there for years. I think the most popular/mature Python-based one is called Pelican.
It's a case of them all being slightly opinionated, and it's relatively easy and fun to make your own that suits your own needs.
- ivanhoe 4 years agowell, it certainly doesn't hurt to have more to choose from. It's been a popular subject, so people are coming up with their own approaches. Time will filter out those worth the attention.
- softwaredoug 4 years ago
- dceddia 4 years agoThe linked blog post was a good read about why the author went down this path, goals of the project, and some technical challenges along the way: https://czep.net/20/stasis.html
As someone with a Jekyll blog who's considered changing SSG's a few times in the past, this was interesting to read. I could see myself going down a similar path.
Gatsby adds a lot of complexity that IMO isn't a big benefit for a simple blog, and when I tried migrating my site to it, a lot of existing posts were broken in weird ways.
Eleventy is "Jekyll but in JavaScript" and way closer to what I want, but its flavor of Liquid is just slightly different from Jekyll's to the point where I would have to update a bunch of posts, plus there's no incremental build yet.
So I'm still sticking with Jekyll for now. Maybe one day I'll break down and build my own SSG like the author...
- johnchristopher 4 years ago> Eleventy is "Jekyll but in JavaScript" and way closer to what I want, but its flavor of Liquid is just slightly different from Jekyll's to the point where I would have to update a bunch of posts, plus there's no incremental build yet.
So much for
> bamboleo 3 days ago [–] https://news.ycombinator.com/item?id=25561177
> You can’t be serious. Jekyll blogs are pure text files you can download and view in a thousand ways. Good luck extracting sensible data from WordPress’ database without losing metadata.
Unless SSG get a common metadata and/or post format I don't think migration is as smooth as some say it is.
In the XML days we had ATOM. I don't know if we have any JSON/MD things like that ?
- dceddia 4 years agoHeh, they are indeed pure text files, but then again so is XML :D
My Jekyll posts are mostly Markdown with some YAML frontmatter, but some have a few "include" statements here and there that use Liquid. The frontmatter stuff is easy enough to transform with some `sed` commands or whatever.
The bigger problem is the surrounding stuff that relies more on Liquid, like email signup forms, the list of posts, the list of tags, etc. All the little things that would need a small bit of work to reformat to work with another tool, it all adds up. And there were some oddities with how the two parsers handled newlines around Liquid, so sometimes Eleventy's output would be jumbled together when Jekyll's looks fine.
- johnchristopher 4 years agoThere's a quote about reinventing xml ^^. 15 years ago I wrote a very rudimentary static blog using only ATOM documents and some XSL. Maybe it's time to revisit the idea.
> The bigger problem is the surrounding stuff that relies more on Liquid, like email signup forms, the list of posts, the list of tags, etc. All the little things that would need a small bit of work to reformat to work with another tool, it all adds up.
Yeah, but then it's not really content (posts) so I think it's okay. This doesn't need to be as portable.
- johnchristopher 4 years ago
- ratww 4 years agoThe posts on those are just Markdown, and most of them use the same metadata format. For Atom/RSS you can use a plugin in Jekyll or 11ty. It's really not that complicated...
- johnchristopher 4 years agoI believe you are missing my point. I am not talking about syndication, I am talking about a reliable standard post/content format that would guarantee interoperability and plug and playability between static CMS. Without tweaking.
- johnchristopher 4 years ago
- dceddia 4 years ago
- nickjj 4 years ago> So I'm still sticking with Jekyll for now.
This is where I'm at too.
I've been using Jekyll to manage a few sites (some with 300+ posts and 100+ drafts). It's really not bad with incremental builds. It's about a 3 second turn around to see live reloads while writing.
It's definitely not perfect, but I still haven't found anything that comes close.
- dceddia 4 years agoYeah, the incremental builds are pretty good. I even turned on LiveReload and it's ok-ish. It's not super snappy but it mostly works.
If I move to something else I want the ability to include proper components on the page, whether React or Svelte or something. I'd love to find the sweet spot where I can embed interactive examples without having to "program my blog" like Gatsby. Elder.js looks interesting, but probably more complex than what I need.
And anyway, every time I start considering this path, I being to wonder whether rewriting my blog is really the best use of my time...
- dceddia 4 years ago
- hanniabu 4 years agoHave you looked into Hugo?
- dceddia 4 years agoI have! I love the speed aspect of it, but I'm less keen on the template language. I'd have to rework a lot of Liquid stuff that I've built up over time, then it looks like it'd be very hard to port out of Hugo down the road because as far as I know, that language is pretty specific to Hugo.
Hugo also seems to be more or less "take it or leave it" in terms of customizability, and I don't know Go. I've got a custom syntax highlighting setup that uses JS, which I imagine would be hard to integrate. (it was annoying to integrate into Jekyll too!)
- dceddia 4 years ago
- johnchristopher 4 years ago
- freedomben 4 years agoI built something like this for one of my sites and ended up deeply regretting it when my hosting for the month hit $100 (due to bandwidth/data fees).
I now pay $5 a month with nginx on Linode/Cloudflare. If you pay for this out of your own pocket and your site doesn't make any money, consider bandwidth/data costs first.
- thamer 4 years agoWas this with very large files? I remember a similar HN comment a while back and couldn't see how this would happen with a static site.
If you store 1 GB of data in total in us-east-1 and serve 1 request per second with an average size of 100 KB, it would cost $1.28 per month[1] for S3 and $25.38 for CF without the free tier, $20.24 total with the free tier. That's much more than most static websites ever store and ever serve. I use S3 & CloudFront for multiple static websites (all low-traffic, < 50 pages with some images) and the cost per site for hosting is less than I pay to renew its domain each year.
I used to do these by hand and finally started using Hugo a few years ago, and love the solution. Everything is simple to set up, the SSL cert is free and auto-renewed, the performance is great and the costs are negligible. For the vast majority of small static websites and even up to thousands of page views a day I find this approach ideal. (obligatory: I am not affiliated with Amazon in any way, just a happy customer).
[1] on https://calculator.s3.amazonaws.com/index.html — S3 page -> Standard, Storage: 1GB, GET: 2628000 requests, returned: 262.8 GB. CloudFront page -> Data transfer out: 262.8 GB, Average object size: 100 KB.
- freedomben 4 years agoYes, I host quite a few high-quality images and videos that can really add up. It's not shocking to see it come close to 1 TB a month.
- freedomben 4 years ago
- docuru 4 years agoFor the $100, Was it because there was too many static files, plus frequently update? (beside user visits)
- ivanhoe 4 years agoProbably, the hidden costs of running in cloud can be tricky...
- freedomben 4 years agoYep, frequent updates, lots of high quality images and some videos. That also made a huge spike in traffic painful because I wasn't expecting it. Having a page go viral can have unforeseen consequences :-)
- freedomben 4 years ago
- ivanhoe 4 years ago
- sweeneyrod 4 years ago$100/month gets you around 1TB on CloudFront doesn't it? If that's all web pages, surely you should be getting enough traffic that you can monetise somehow for the cost to be negligible.
- freedomben 4 years agoYep it was right around 1TB :-)
(high quality images and videos, combined with a viral page)
- freedomben 4 years ago
- thamer 4 years ago
- alex-wallish 4 years agoThis is pretty cool. Reminds me a bit of Cactus which hasn't been updated in 3 years. Is there any support pretty urls?
- icy 4 years agoI'm not sure how I feel about shelling out to pandoc when they could've used something like mistletoe. And pushing to a CDN needn't be a part of the tool.
I too recently (re)wrote my SSG, in Go: https://github.com/icyphox/go-vite, ditching my old Python one.
- rualca 4 years agoI don't understand the point of this project. S3 and cloudfront is already designed to deploy static sites. I mean, one of the basic S3 tutorials is to show how to deploy a pure HTML+CSS site on S3. Hell, there is even a myriad of tutorials showing how to deploy React and Angular apps to S3. All it takes is to copy the artifacts to the bucket.
- 4 years ago