Ruby Web Applications Without Rails

Theoretically, I'm a big fan of this. Rails is huge, and for some applications you certainly don't need it.

On the other hand, my practical experience is that every single time I've tried building a Ruby web application without Rails, I end up reimplementing a buggy version of Rails. There are a surprising number of features that are required or desirable in a web application that are really easy to ignore until you realise.

YMMV of course, but don't run out looking at things like the new API-only support in Rails too, before you take this approach.

I really like ruby and rails, but my big concern isn't really about performance, its about how to deal with the rise of heavy JavaScript spa apps. I'm still working out how to deal with this.

One approach is to wait it out. Stay with the trade rails view, add JavaScript as needed, see what I can get out of turbolinks and sockets in rails 5.

Another possibility is to go rails-api and write the front end in react or ember. This of course requires going in heavily on JavaScript and (at least for now) duplicating a lot of effort in client and server code (models data routes ...)

Another is to say bye to ruby and go all in with node. I don't hate JavaScript but it felt great to go from java to ruby. Doesn't feel great going from ruby to JavaScript but that may change over time.

Another is to go rails api and try to carve out a role as a pure back end dev. I enjoy back end work more anyway, and maybe specialization is inevitable. It has certainly happened in other fields.

Lastly maybe the trend toward isomorphic development will continue and devs will have as wide a range of choices on the client as they have on the server. I do see signs of this - volt is one good example.

The last time I remember this kind of uncertainty was around 2004 when MVC and DI and ORM frameworks were proliferating wildly in javaland. I studied a lot and finally picked... Ruby ;). so let's also not rule out the possibility that something very new sweeps everything off the table with a loud crash to usher in a very new way of thinking.

I love Ruby. That being said, if you require response times faster than what Rails & Sinatra can deliver, don't the newer/faster languages make more sense than implementing a hyper-optimized Ruby solution?

I would worry that as soon as you need to add one feature you didn't originally consider, you'll slip back to normal Rails/Sinatra turnaround times. (Which of course are perfectly acceptable for most apps).

I used to be a huge Rails fan, but that was a long time ago. Now, I like simple frameworks like Sinatra and Compojure (for Clojure), with some experiments using Meteor.

Way back when, I liked keeping the source code for CRuby and Rails handy and back then the code base was interesting to explore. Sadly, I really don't know how Sinatra, Compojure, and Meteor work since I have spent very little time looking at the code.

It's been a while since I last used rails, but something about

> A "Hello World!" in Rails takes about 1.13 seconds to render

strikes me as most definitely incorrect... If not, I'm shocked.

As someone who's spent a not-insignificant amount of time optimizing the heck out of a Sinatra benchmark[1] for TechEmpower's Web Framework Benchmarks[2] (TFB), and as someone who's spent the last four months or so building a json:api compliant Sinatra back-end and Ember.js front-end (for an MVP), this subject is near and dear to my heart. I definitely thrashed on language selection for a few weeks before settling on Ruby. It was an opportunity to learn a great language, but I wanted to actually learn the language instead of relying on a huge library. Rails had a lot of overhead for what we had in mind, Rails API had only recently been merged and seemed unproven, and the more esoteric Ruby web frameworks based on Celluloid (e.g. Reel) and EventMachine (e.g. Goliath) were too daunting.

I think going all (well, almost all) the way down to Rack, as suggested in the OP, is a little too extreme. One of the commenters over there mentioned Rack Server Pages[3], which is interesting. Sinatra appealed to me because most of its features come disabled out of the box (in modular mode), and you can selectively reenable them and incorporate other bits of Rack middleware to build up your stack. Some commenters here appear to be conflating Rails and Sinatra in terms of behemoth-ness, which is strange to me because Sinatra::Base is less than 2,000 LOC. Sinatra is not much more than a thin DSL for creating Rack applications as described in the OP! Anyway, it also seemed silly to eschew Rails only to pull in ActiveRecord and ActiveSupport, so after another round of research I selected the excellent Sequel ORM[4] to handle database abstraction.

There have been times when I felt like we were going against the grain. The Ruby community is oriented around Rails, and most of my early Ruby questions received Rails-specific answers, which was frustrating. Some pieces of Rack middleware and other things like json:api serializers tend to be implemented (and documented) in a Rails-specific way; getting them to work with Sinatra (or finding viable alternatives) has been time-consuming. More than once I've thought to myself, "If we're going to use some unsupported and/or fringe-y thing, we might as well have built this in Elixir or Luminus or Sails or ChicagoBoss or..." That being said, writing Ruby is fun, the community is great (MINASWAN), and we've discovered some amazing libraries. There is a ton of work going on to improve Ruby (specifically, JRuby 9K, Ruby OMR, ConcurrentRuby, etc.) so the language has a bright future. In the meantime, our solution is fast, stable, simple, and easy to test and deploy, so it meets all of our requirements.

1. https://github.com/mwpastore/FrameworkBenchmarks/blob/sinatr...

2. https://www.techempower.com/benchmarks/

3. https://github.com/migrs/rack-server-pages

4. http://sequel.jeremyevans.net