The Post-Jamstack Era: Just Use Rails

multiplegeorges | 36 points

This is addressing all the things I don't care about at all for a static site, and then suggesting a tool that makes very little sense.

If you're hosting a static site... life is easy. Throw your content in any s3 compatible storage and point a CDN at it. Done. It will cost literal pennies a year (The domain name will be by far the most expensive piece, and lots of places will give that to you for free if you don't care about being a subdomain).

That too complicated for you? Host it on a raspberry pi out of your bedroom. For the vast majority of traffic loads... that thing is going to be A-OK, even on a crappy consumer line (You'll probably be violating your TOS with your provider if it's a commercial site... but I've found they really don't seem to care unless you're causing them headaches, and a static site ain't gonna cause many headaches).

That too complicated for you? 10 lines of js with express will stand up a prefectly functional static site. Or you literally just install nginx and configure a single server block.

Static sites are fucking easy. It is ridiculously easy to serve static content these days. And borderline free (again - the domain name is going to DWARF the rest of your costs combined, even if you're only paying 5 bucks for the name).

How do you generate your static content? Who cares - do whatever feels best to you (I personally think rails is a bonkers solution, but if you want to use rake tasks to create your output... more power to ya?)

It really sounds like the author doesn't understand what a static site is, because JAMstack also isn't a static site solution (It has API right there in the name).

If you need to be consuming APIs with changing data... you aren't a static site (even if the html/js/css you serve happens to be static). In which case... rails is a fine choice, but if you're only serving the html/js/css and hitting 3rd party apis... I would still recommend an s3 bucket with a CDN.

horsawlarway | 3 days ago

Over two decades ago, folks did this using web server paths with index.html prioritized over e.g. index.php or index.cfml or whatever.

When you'd build the page dynamically, you'd also write a static .html before serving the html to the visitor. From then on, the .html got served.

On a new build, you'd rm the .htmls.

Back at the time, it seemed to be "the simplest thing that could possibly work" for multiplying a server's traffic capacity by 10000.

Terretta | 3 days ago

If you are going to create a static site, do not use Rails, use jekyll or something similar, they are built for this.

Alifatisk | 3 days ago

If the author truly is using nextjs just for static, then it should be a simple compile and host the output folder?

Strange to say use rails for static, but the author argues how server less is a nightmare. Though, I also think the same, use nextjs just for the react frontend and a proper backend.

langsoul-com | 4 days ago

did the author forget the age of mobile phones? You need an API anyway.

nsonha | 3 days ago

This post has successfully convinced me this company is full of retards. Great job.

Just use hugo/whatever and host on s3. This shouldn't even be a debate, let alone they've already done 3 rewrites. Bunch of clowns.

nprateem | 3 days ago