
Ruby Web Applications Without Rails - anoble
http://codenoble.com/blog/ruby-web-applications-without-rails/
======
matthewmacleod
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.

------
geebee
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.

------
aczerepinski
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).

------
mark_l_watson
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.

------
fortytw2
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.

~~~
gregmolnar
That's for a cold start. Once the application is initialized, it becomes way
faster.

~~~
dakull
>That's for a cold start. Once the application is initialized, it becomes way
faster.

If one uses Unicorn in production there's no such thing as a `cold start` Ruby
is not the JVM lest you run JRuby or Rubinius ofc :-)

~~~
matthewmacleod
I'm not sure that's accurate - most of Rails is lazily loaded now I believe,
specifically to reduce start-up time. You can use a different strategy in
production of course.

~~~
epochwolf
By default, Rails only does lazy loading in development mode.

------
mwpmaybe
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...](https://github.com/mwpastore/FrameworkBenchmarks/blob/sinatra-
sequel-rbx/frameworks/Ruby/sinatra-sequel/hello_world.rb)

2\.
[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

3\. [https://github.com/migrs/rack-server-
pages](https://github.com/migrs/rack-server-pages)

4\. [http://sequel.jeremyevans.net](http://sequel.jeremyevans.net)

