Ask HN: Who’s using Ruby for web development, without Ruby on Rails?

51 points by vanilla-almond ↗ HN
Ruby on Rails (RoR) dominates web development in Ruby. It's rich in features, but it's also a heavyweight framework.

Do you eschew RoR and use an alternative Ruby web development approach? (Example: different framework, or writing your own framework)

78 comments

[ 3.3 ms ] story [ 144 ms ] thread
Stripe uses Ruby without Rails
Came to post this.

I would bet that Stripe is the large non-Rails Ruby user in the world?

We have a lot of internal APIs written using Sinatra.

I first started writing my APIs using Sinatra about 10 years ago. I had started with Rails when it first came out around 2005, liked it, but then ran up against a lot of issues. Sinatra and the Sequel gem were amazing so I switched to that, since I didn’t need most of what Rails had.

Now I just use those two out of habit. Rails is a LOT better now, but i still just reach for Sinatra and Sequel usually.

I see a good bit of Sinatra out there in the wild for exactly this -- API only services. I even see it in shops that are running Rails everywhere else.

It does seem to be much more the exception than the rule. But it may be getting more common with kubernetes deployments which make lots of individual services a bit easier to manage.

I really like Sinatra but a lot of the Rails improvements kind of took away some of the benefits of using Sinatra over Rails.
I believe it. I keep reading about Rails improvements but haven’t really tried it in anger in a long time.

I started with Rails when migrations were just .sql files you wrote by hand. I switched to Sinatra mostly to use Sequel, because ActiveRecord at the time would do horrible queries unless you wrote them by hand. I know they have solved that issue, so I should try Rails again… but my Sequel muscle memory is pretty strong at this point.

It's not just Sinatra. Devise, AFAIK, has been a staple for authentication and authorization and rails (or at least in blog posts it has) and in Rails 7 it seemed like it complicated things more than helped and I can do all the secure handling pretty easily in Rails.
Sinatra + Sequel is the only way I've ever loved using Ruby for Web development. After extensive contact with Rails across several projects, I've... concluded I simply cannot enjoy using it, is a nice way to put it, I guess. Sinatra + Sequel is a delight, though.
Sinatra is my go to for barebones pages-style server side rendering.
A lot of people use Sinatra for this type of thing.
What do you mean by "heavyweight"? Also why is it a problem that something is "heavyweight"?

What problem are you trying to solve by asking these questions? What context is this question for? Are you curious how many people use a non-rails solutions for enterprise apps? Cloud apps? Personal projects? Apps you want users to pay for? A blog?

I'd suggest stating what problem you'd like to solve by asking this question so you can receive more detailed feedback. For example, if your company is spinning up a new app and you're evaluating choices, someone may respond that they used sinatra but found themselves reinventing rails so they wish they would have used rails. I'd say this is more insightful than "yea, we use sinatra". Alternatively, maybe someone used sinatra for a personal project and found the experience of reinventing rails rewarding and educational on their own time. Let us help you!

> What do you mean by "heavyweight"?

Rails latest release (7.0.4) have 386,970 lines of code in total, 310,779 of it being Ruby code. 3000 files in total. Just the `lib` directory of `activerecord` has 33,036 lines of code, across 369 files.

By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases.

Full `cloc` report in case someone is curious:

        4268 text files.
        3839 unique files.
         511 files ignored.
    
    github.com/AlDanial/cloc v 1.96  T=1.25 s (3079.1 files/s, 434339.6 lines/s)
    -------------------------------------------------------------------------------
    Language                     files          blank        comment           code
    -------------------------------------------------------------------------------
    Ruby                          3013          73152          54669         310779
    Markdown                        92          19324            388          45525
    JavaScript                      87           2974           2170          20955
    YAML                           171            406            350           3679
    CSS                             23            347            152           2409
    ERB                            386            303              9           2244
    CoffeeScript                    12             97            125            413
    JSON                            11              7              0            372
    HTML                            21             15              3            200
    Bourne Shell                     2             20             25            167
    Text                             7              0              0             51
    yacc                             1              4              0             46
    SQL                              1              6              0             43
    Dockerfile                       1              7              7             40
    SVG                              7              0              1             36
    builder                          3              1              0             10
    DTD                              1              0              0              1
    -------------------------------------------------------------------------------
    SUM:                          3839          96663          57899         386970
    -------------------------------------------------------------------------------
I don't know why something with many LOC is a problem. Why does OP care about LOC?
More code, more liability. If you can get away with achieving the same with less code, things tend to be harder to turn into big messy piles of code.
I'm not a huge fan of rails but, you can generate apps that don't include active record example of all the flags you can pass to rails when initializing a projects.

    --skip-git            Skip git init, .gitignore, and .gitattributes
    --skip-keeps          Skip source control .keep files
    --skip-action-mailer  Skip Action Mailer files
    --skip-action-mailbox Skip Action Mailbox gem
    --skip-action-text    Skip Action Text gem
    --skip-active-record  Skip Active Record files
    --skip-active-job     Skip Active Job
    --skip-active-storage Skip Active Storage files
    --skip-action-cable   Skip Action Cable files
    --skip-asset-pipeline Skip Asset Pipeline
    --skip-javascript     Skip JavaScript files
    --skip-hotwire        Skip Hotwire integration
    --skip-jbuilder       Skip jbuilder gem
    --skip-test           Skip test files
    --skip-system-test    Skip system test files
    --skip-bootsnap       Skip bootsnap gem
Yeah and Rails is modular enough that you can easily pare it down even further - you don't need to `require` everything.
What does liability mean in the context of a batteries included app framework?

If you ever plan on becoming liable for the framework code you're doing something very wrong.

Oh huh. I hadn't considered liability implications of using a framework. Thanks for the viewpoint.
This is a real inexperienced take about a codebase with a huge number of contributors and users, with a lot of test coverage, that has a history of addressing P0/P1 issues quickly.

Do you have the same concerns about your compilers? Your web servers? "More code, more liability" is a very sloganeering/cargo-cult take.

It’s true, though. Code costs money. I looked into this years ago for a former employer and at the time it was broadly estimated that for each line of code that a company owns it costs at least $30 every time a developer has to look at a given LOC. This is true whether the dev is writing it, fixing a bug in it, or just looking at it to investigate something related. And that’s for every developer on the company. So if you have code that, for whatever reason, is constantly being looked at by developers, that cost rapidly jumps, even though no one is actually touching it.

I’m currently down with the Flu B, so don’t feel like looking up citations, and for that I apologize. My recollection is that this was, unsurprisingly, a fluid estimated, with lots of caveats attached to it. Regardless, it struck me as true, and something I’ve never failed to take into consideration when writing my own code.

Compared to what? How about Django or Laravel?

And does ANYONE here want to compare Rails with the standard "enterprise" stack of Java and React, and all their implied dependencies (Spring, Lombok, etm.)?

> By most metrics, RoR is pretty heavyweight, as their literal taglines are "Ruby on Rails scales from HELLO WORLD to IPO" and "A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern", so it needs to be pretty big to support those use cases.

Not sure what do you mean by "most metrics". Framework supporting features is not same as they being used all at once in every app.

PostgreSQL has more than 1.3M lines of code and it gets used by projects of all sizes, would you call it "heavyweight" too?

yes is heavyweight, SQLite for example isn't , but is kind the point you want database to use multiple formats, have acid compliance, json support, parallelism, easy debuggability, scalability, fault tolerance. this are problems that you pay only little cost because 1 PostgreSQL database can scale to thousands or millions of users, and is more like a video editor you doesn't code directly in it, and data replication is difficult and expensive.

some people don't want have a server only for this and accept the drawbacks of not having a full database server, for example remoteok.

SQLite claims at least 180K LOC (~145K+25%, covering a substantial but incomplete part of the codebase), and the above report shows Rails at 386K LOC.

Suggesting that LOC does not support this argument, and perhaps is not a great metric in general, especially across different languages.

https://www.sqlite.org/amalgamation.html (as of Version 3.37.0 - 2021-11-27)

I’d call Postgres “heavyweight” compared to SQLite. Maintaining a SQLite db is as simple as a file, and then you can use litefs or litestream to back it up.

Maintaining a Postgres server or cluster is hard. But it offers way more functionality.

I agree that the term heavyweight can mean many things to people. I’ve take it as a generic mix of maintenance, complexity of project, ease of use for your purposes.

> PostgreSQL has more than 1.3M lines of code and it gets used by projects of all sizes, would you call it "heavyweight" too?

Yes. There’s not a definition of “lightweight” that could be applied to psql, at least without making the word useless.

If I were the person asking the question- I'd get frustrated by this answer. Nothing against you, the response is accurate, sufficient, and true, but woo I was subconsciously leaning forward and covering my mouth while reading.
Why's that? Given the original question people can simply reply "me", but I assume they're looking for more than that.
(comment deleted)
The rest of this thread reads like plenty of posters had no trouble figuring out what was intended by the question.
The question was obviously in reference to something like Sinatra or Hanami, or simply using individual gems.
> Also why is it a problem that something is "heavyweight"?

One issue I could think of when a framework dominates a language is that it could steer changes in that language that benefit itself more than the language.

There's Sinatra for more barebones things, but honestly, homegrown solutions always grow into a shittier version of Rails. You don't have to use all of the features Rails provides. As others have mentioned, for simple APIs Sinatra is fine.
> homegrown solutions always grow into a shittier version of Rails.

An old joke: any sufficiently advanced Sinatra app is indistinguishable from Rails.

> You don't have to use all of the features Rails provides.

You kind of do. First, you have to opt-out, not opt-in. And the opt-out path is less battle-tested, so there's a lot of skeletons to be found there. Use it at your own risk.

If you want the best modern example of a ruby framework which starts small (like sinatra) but allows you to opt into a wider feature-set (like rails), you should give roda a look: https://www.youtube.com/watch?v=9fukis_VHl4

Ruby is pretty good for writing scripts to run in the terminal. For things where I need to do a bunch of string manipulations, I prefer it over something like creating a shell script.
Same. I’ve moved a lot of my personal scripts from zsh/bash to Ruby, and they’re so much easier for me to reason about now — or six months in the future when I’ve forgotten what exactly they do.
It completely replaced Perl for me
There aren’t many compelling reasons to choose ruby without rails, for a greenhorn project. unless you already have a big pool of devs who know and enjoy ruby, and/or a lot of home grown gems/libraries.
I’ve done some simple CGI stuff in Ruby before. Those are normally for ephemeral tasks tho, not anything intended to be used long term.
I like Ruby but I don't like Rails. No idea if this is better now but I would get weird exceptions that would be from metaprogramming goofiness that was really difficult to debug and find documentation for, and it uniquely bothers me when I can't figure out where errors are coming from in code (same critique of async/nodejs). The general heaviness also just didn't mesh well with my programming style, I like things cleaner and more simple.

The Neocities frontend is basically something much simpler built on top of Sinatra and I haven't regretted that decision at all. It's (relatively) clean and simple, and if I need to do something weird that doesn't conform to the paradigm (this happens a lot), it quickly gets out of my way. You can generally do anything you want with Rails, but in my experience that more frequently involves digging through a bunch of documentation and google searches to try to figure out how to get the framework out of my way.

I've also found ruby to be a really solid language for doing lower level glue tasks, for an unusual example I use it to glue a redis database to powerdns, which serves a lot of query requests, it's plenty fast and very reliable. I've never had to rip out ruby from something more performance-oriented and replace it with something "faster".

At the same time if I had a team of 10 people I was working with I might appreciate Rails keeping everybody on the same design structure so I there's not an endless battle over how it should be put together, but in my past experience this kind of just happens with Rails too.

> The Neocities frontend is basically something much simpler built on top of Sinatra and I haven't regretted that decision at all.

Hey good job on Neocities btw.

I've noticed that a lot, and while it's not wrong to adhere to the "golden path", I take issue when it becomes instilled as rhetoric in a developer and precludes them from understanding or dignifying someone else's choices or questions when deviating from it.

There's always this aggression-of-curiosity in response, never a "well you'd do x, y, and z, but it's not recommended". It's always "Well why would you do that? That's wrong, you're supposed to..." and then an hour later after someone is red in the face just asking a question it comes down to "yeah I've never used 0mq before with rails, sorry maybe try Slack"

[edit: The comment I was originally replying to has gone from 1 sentence to a paragraph and is still receiving edits. Including this note for posterity just in case it looks like I'm talking to myself in a closet.]

Today I learned Neocities uses Sinatra, thanks for sharing your point of view and for the work you're doing on Neocities!
Was your Rails experience quite a while ago? Stuff like the method_missing matching a regex stuff that was common years ago has basically disappeared from common use, at least in my circle.

Rails 7 has been my favorite version since 3. Version 3 was probably the peak of metaprogramming and when basically anything you tried worked which was fun but really cowboy.

This sounds like my experience with Django... After 5 years I still haven't mastered it and it still continuous make me think why is this so complicated.
> I've also found ruby to be a really solid language for doing lower level glue tasks

This!!! I can't express this enough, Ruby is the sweet spot for gluing things togheter and rapid prototyping.

I solely use Hanami since 1.5 year, and I had never looked back!

It provides everything needed, while still allowing to fully control which features I want to disable.

Been a few years since I tried Rails (I don't do much web development), but seriously considering giving it another try. I do wonder if a "Lite" version of Rails could happen somehow - DHH was talking about JSON APIs in his latest blog post, and indeed they are more no-ops than an SQL database.

I have tried Ruby CGI but very barebones - no MVC.

I haven't tried Sinatra, but someone at a Ruby web development company told me Sinatra works for APIs but difficult for websites, but it isn't battle-tested like Rails.

yet another comment about Sinatra, I've been using it for 10 years, first on heroku now on fly.io. It's such a great and stable framework, most people probably don't even need RoR.
We have a Rails monolith with a couple internal Sinatra services if that counts. To be honest, I love working with Sinatra and Sequel (when using an ORM) vs. working with Rails and ActiveRecord. We provide public apis via. Grape, but that's mounted as an engine inside our monolith vs. deploying our own Grape application on Rack just for operational simplicity.
We[0] use Ruby without Rails - Sinatra for the most part.

I started the codebase over a decade ago now, and at the time Rails felt a little heavy (inline with your comments). That said, Rails does let you get started pretty quickly without needing much of anything else.

Rails has more magic. If you prefer less magic, then Sinatra is the way.

0: https://www.enchant.com

Made my "own" static page generator using chatgpt recently: kramdown for markdown, erb for layout, filewatcher to reprocess on file changes, rss and sitemap. docker-compose file with nginx pointed at the out directory. Deploying with git. Works great.
I see a fair amount of companies writing internal services in sinatra/hanami/etc and using Rails for user-facing routes. The smaller frameworks are great but as soon as you hook up an ORM, user session management, conditional view rendering for different clients, background jobs, caches and all the rest then you often end up with a worse Rails. If you have a service that you know upfront will need not need that then the simpler frameworks are a much better choice.
I work at a medical analytics company that uses Ruby + Sinatra. Our product is a "real" application that allows for sophisticated reporting drawing from huge data sets. No Rails is involved.
I am a solopreneur with Smart Kiosks running on Raspberry pi.

The whole service (which isn't too complex) is a file script in Ruby managed through SystemD. This script turns off/on the screen based on API calls, and is also in charge of scheduled/remote restarts, pinging the backend and stuff like that.

What I like the most is how easy and reliable is. Beeing a below average guy, ruby makes really easy to combine system calls, API calls and shell commands within the same context.

I've been on the Roda [0] and Sequel [1] framework for over 10 years now across various projects. Even after all these years, starting a project in this stack feels like a breath of fresh air even compared to the newer language/frameworks that jabe come out since.

Jeremy Evans is the creator and maintainer of both of these Ruby gems and is super helpful in resolving ask kinda of issues.

[0]: https://roda.jeremyevans.net/

[1]: https://sequel.jeremyevans.net/

I've used ruby/sinatra/passenger/nginx for a few projects -- html/preact/javascript front-end calling into the ruby backend. Sometimes python/flask instead of ruby/sinatra.
I've been working on a framework for a while. It's a server side VDOM that streams updates to a small JS runtime. Components are written in Haml. https://github.com/mayu-live/framework
That's so cool! Makes me happy seeing HTTP/2 being suppport as well.
Thank you! HTTP/2 is great. It's really convenient to have one connection per client.
Any thoughts or plans about HTTP/3 in Ruby? I've been searching around and it's dead silent within the community, only seen a presentation about implementing QUIC in Ruby using Ractors but nothing more.
Sorry, I just saw this now! I don't know anything about HTTP/3 in Ruby, or at all actually.

I'm using the async-http gem for the HTTP/2 server and it works great for my use case.