
Sinatra 1.0 Released: Major Milestone for Ruby’s Best Webapp DSL - jackowayed
http://www.rubyinside.com/sinatra-1-0-released-3162.html
======
adriand
If you haven't tried Sinatra, you really ought to. It's a joy to work with. If
you're accustomed to using Rails, using Sinatra brings back the enjoyable
feeling of being closer to the code, closer to the HTTP protocol itself, and
free of the many conventions and the complex file structure that comes with
Rails.

I especially recommend it for when you want to hack up something small, useful
and lightning quick. Rails is great, but sometimes it starts to feel like a
very large hammer, when many web app ideas start out as small nails. Sinatra
is a nailgun.

~~~
jackowayed
I really wish Sinatra were more practical for big projects. It's so much more
pleasant to work with, but between the speed advantage that Rails gives for
doing a lot of the normal big-app tasks and all the plugins, it seems like
Rails is too good for most big apps to make Sinatra a reasonable choice.

I guess if you were doing something very weird, where Rails would really get
in the way, it might make sense. And I've seen it end up being a piece of big
apps, just not the main web interface.

~~~
cschneid
May I suggest Monk, which is built on top of Sinatra, and provides a nice
basis to organize your code.

~~~
jackowayed
That's pretty cool. I could see using the dm skeleton for something pretty
big.

Here's the link for the lazy: <http://monkrb.com/>

------
bonaldi
Sinatra has that "secret weapon" feeling about it. While everyone else is
bogged down trying to steer their massive lumbering frameworks around, you're
whizzing past in a sporty two-seater that goes exactly where you want.

To me, it feels exactly like web programming should -- and it does so in a way
that makes a lot of sense; it builds on the whole Ruby thing of "how do I do
this? I wonder if _this_ will work? Ho! It did!"

If you haven't looked at it yet, it is _well_ worth your time.

------
n8agrin
A few people have already commented that Sinatra is great for quick small
projects. One person has mentioned that they prefer it for larger projects. My
knee-jerk reaction to Sinatra for the last year has been that it would be fun
for building small apps as well, which got me thinking:

Why wouldn't it be good for large projects?

After reading the current docs, I really don't have a good answer to this
question. Anyone have any opinions or thoughts? I know Rails gives you a ton
out of the box (for example, 304 etag caching) but how hard could it be to
implement that stuff as necessary? More and more I find myself focusing on
HTTP as the actionable interface to my model and less as simply an HTML
delivery protocol.

~~~
petercooper
_Why wouldn't it be good for large projects?_

It is for some, but it doesn't provide enough structure and opinion for some
people. With Sinatra, you either need to come up with and fully grok your own
structure (always a good thing, IMHO) or a myriad of plugins and middlewares.

Sinatra vs Rails is like a house with one big empty space vs a house with
predefined rooms ready to decorate. With Sinatra, you need to be much more of
an "architect" than you need to be with Rails. I'd much rather define my own
walls and internal structures and Sinatra lets me do that more easily than
Rails does.

~~~
adriand
> With Sinatra, you either need to come up with and fully grok your own
> structure (always a good thing, IMHO) or a myriad of plugins and
> middlewares.

This is a good assessment. If it's a big project with a lot of CRUD on a large
variety of models in a complex database, by the time you'd added all the stuff
to Sinatra that would be useful, you'd have recreated Rails.

You could still very much use Sinatra for a large project, but it would be
best for a large project that is not a standard CRUD- and form-heavy web app.
For example, if you wanted to build, say, an online video encoding service.

------
wheels
Why do Rubyists insist on overusing the phrase "DSL" so much? Sinatra isn't a
domain specific language, it's just a quirky usage of Ruby syntax to make it
more natural to set up routes for a web app. Haml is a DSL; Sinatra is not.

~~~
AndrewO
Haml is an external DSL. Sinatra is an internal DSL. Rubyists insist on using
the term so much because Ruby's linguistic flexibility makes it easy to define
them, so they're constantly doing it.

Martin Fowler is often credited with coming up with the distinction between
the two. The concept is similar to a "fluent interface" from a different point
of view.

[http://martinfowler.com/articles/languageWorkbench.html#Inte...](http://martinfowler.com/articles/languageWorkbench.html#InternalDsl)

<http://martinfowler.com/dslwip/InternalOverview.html>

~~~
wheels
Ok, so the answer is, "because Rubyists have redefined that phrase"? ;-)

The sweetening of the syntax in Sinatra seems to be rather straightforward. I
assume it's something like:

    
    
      # internal route stuff
    
      @routes = {}
    
      def get(method, &block)
        @routes[method] = block
      end
    
      # user provided code
    
      get 'foo' do
        puts 'foo'
      end
    
      # something hooked up to execute at the end of the file
    
      while input = gets.chomp
        @routes[input].call if @routes.include? input
      end
    

I find it really hard to call that a _language_ – it's just a clever use of
_normal_ Ruby syntax.

~~~
AndrewO

      Ok, so the answer is, "because Rubyists have redefined that phrase"? ;-)
    

Well, by name dropping I was hoping to avoid the appearance of that. :-)
Fowler certainly writes about Ruby a lot, but I'd hope he's perceived as
general enough to not just be a "Rubyist" (I don't know what he primarily
uses). But he also points out that Lisp is a perfectly good host environment
for internal DSLs (he calls it the "doyen of internal DSL thinking").

And I also brought up the "fluent interface" thing to suggest that you could
call it that if it made you happier. For my tastes, I'm fine with the idea
that a "language" reuses a more general purpose language's interpreter and
libraries. YMMV.

    
    
      I assume it's something like:...
    

[http://github.com/bmizerany/sinatra/blob/work/lib/sinatra/ba...](http://github.com/bmizerany/sinatra/blob/work/lib/sinatra/base.rb#L836)

Sure looks similar, but as you can see from all the code above the method
there's a lot more going on. But hey, at least they didn't need to write a
parser. ;-)

------
cpg
Congrats!

We have been using Sinatra for our installer at Amahi (<http://www.amahi.org>)
and it has performed well with a couple of caveats.

1) Things can get messy quickly if one is not careful to impose and keep on
having structure. It's hard to read what's going on very easily.

2) They released 0.9.5 which produced crashes in ruby (!) and this bit us
hard. This is really a bit of a ding on how gems are packaged and distributed.
We tried to package is as an RPM (Amahi is Fedora-based) and it was harder
than other (bigger) gems due to some things we could not figure out quick
enough. I really like it, however, the community did not really help much in
getting to the bottom of this, probably because it's still a bit small, I
guess. No question that it will grow. :)

3) (ok more than a couple, though this one may not be a Sinatra issue). We
rely on periodic http calls to get our installer progress shown on the browser
(via jQuery). Some times one http call breaks (to localhost no network
involved!) and we have not been able to figure out why. We believe we have
mostly eliminated jQuery, leaving Sinatra as the main suspect. Maybe we have
another bug in there we're hitting? It's not too repeatable, sadly.

Congrats on the 1.0 release!!

------
ctrager
I use Sinatra running at Heroku for my Hacker News Android app, for the screen
scraping part, the part that scrapes pages just like this one. Both are easy
and fun.

------
tibbon
I've been using Sinatra for a while and loving it. So much easier to
understand your code than Rails imho.

However I have one question- is there much to making it scale? Not in a
Twitter-like way, but I know there are a ton of books and documentation on
making Rails work for larger sites. Does Sinatra hold up ok?

~~~
jackowayed
I think it would be pretty simple and basically the same principle as for
Rails. You could just have several machines with Passenger (or whatever)
running your app on each and stick a load balancer in front of them.
(Disclaimer: I've never actually scaled things, but it sounds like that's
more-or-less how it's done.)

Really, the hard part almost always ends up being scaling your database. And
since Sinatra isn't super-glued to ActiveRecord (though Rails3 fixes that), it
would be easier to use whatever NoSQL-type thing you wanted if you got to the
point of needing to operate on a huge scale.

------
mark_l_watson
Great news! I usually use Rails for medium and medium-large projects but I
like to use Sinatra for small web apps and web services. Sinatra seems like a
better fit also if you want to use JRuby on AppEngine (at least for now).

~~~
grandalf
don't forget python on app engine. the google webapp framework is very much
like a verbose version of sinatra.

~~~
simonw
I'm really not a fan of the webapp framework. Like you said, it's quite
verbose - but more importantly, it runs out of steam very quickly - the moment
you need to do anything useful with cookies, for example.

~~~
grandalf
hmm, like what? I've used cookies extensively with it.

~~~
simonw
How did you do it? Did you have to construct your Set-Cookie header by hand,
or is there an API for that now?

~~~
grandalf
check out the appengine_utilities code on google code... it has some useful
stuff in it.

------
nileshtrivedi
Congrats to the Sinatra team!

I have used sinatra in a bunch of projects ( <http://brandpeek.com> is one
example) and it's a delightful little framework.

------
frankus
I'm using it as the back-end for an iPhone app on top of Amazon SimpleDB. It's
perfect for building little REST APIs.

