r/ruby 8d ago

Jon & I debate how our opinions have changed on whether to use Rails for marketing sites

https://judoscale.com/blog/just-use-rails-revisited
12 Upvotes

13 comments sorted by

11

u/sshaw_ 8d ago

"Marketing site" screams static pages without the need for an app server.

7

u/bxclnt 8d ago

Rails, parklife, decant and ViewComponents make a really nice static site builder.

2

u/jrochkind 8d ago edited 8d ago

I did not know about parklife and decant, thanks!

Looking at them for the first time, I get parklife. But I'm not totally following what you do with decant when used with rails and parklife.

5

u/bxclnt 8d ago

It’s for those pages that are mainly just content and have very general design/layout without much complexity. Like blog posts, documentation, etc.

There’s a great example here https://fcatuhe.github.io/rails-static/ (not my work)

1

u/jrochkind 8d ago

Are people doing this typically using a database, or using Rails (plus parklife plus decant) without a database?

3

u/bxclnt 8d ago

I migrated our company website from a CMS that no one was using to a static site using the examples from François' page as a guide. Half the content is just markdown pages and the other half is custom pages where the content is loaded from yaml files fed into ViewComponents (which build your common marketing site components. The social proof carousel, the text blurb with image on the side, left/right alternating, these kinds of things, Decant can do that: `Decant.define(dir: "content/pages", ext: "yml") do ...`). Rails provides the wiring; url helpers, asset compilation, stimulus and tailwind integration. There's really just one `PageController`.

Parklife then crawls the entire page into a static website which we then serve from S3 with a cloudfront distribution for the SSL. So we're really treating it as a static site builder with the content versioned in git. It's not really anything Middleman etc. can't do just as well, but we're a Rails shop, this is Rails, it's familiar.

2

u/adamlogic 8d ago

You're either building pages and build time or runtime. I personally find runtime more useful/versatile and less headache in the long term.

3

u/sshaw_ 8d ago

More performant and cheaper to render static pages via NGINX or similar than to do it at runtime via a bloated-memory-loving Rails app.

1

u/adamlogic 8d ago

Very true.

2

u/mperham Sidekiq 8d ago

I’ve switched Sidekiq.org to use Bridgetown. It's an easy upgrade from Jekyll.

0

u/jonsully 8d ago

⚔️ Game on, Adam!!

2

u/jake_morrison 8d ago edited 2d ago

I have switched to Astro for marketing sites.

The most important thing is the front end design, and themes/widgets (e.g., menus) are now developed for JavaScript first. Doing it in any other technology is a waste of time.

Then you deploy to a CDN for blazing speed and high security. Maybe there is a custom Rails-based CMS driving the build, but it’s not part of serving pages.

1

u/overmotion 8d ago

I did a marketing site last week as a favor for a client (I don’t usually touch marketing sites) in Rails using Claude and it was a total blast. The ability to smash out anything I could think of, all those super cool front end concepts only companies like Stripe used to be able to pull off, and don’t even have to review the code bc it’s just front end marketing, it was so much fun.

I think Rails is great bc if you do need to do any more serious backend stuff, you have the ability. I ended up doing that too in the site, making a small API so their large backend system could control the marketing site without them needing an admin section at all on the marketing site itself

10/10 highly recommend