Sinatra 1.0 Released: Major Milestone for Ruby’s Best Webapp DSL
rubyinside.com
rubyinside.com
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.
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.
I have found that I can write 10-20 lines of code and replace just about any plugin, and that makes the app far less complex, particularly when you think of how messy and undisciplined many rails plugins are.
I realized that rails offers the biggest benefit if your site uses TONS of forms. It's really not that big a deal to write a few forms by hand, and it makes using client side validation easier and cleaner.
I also love datamapper.
Here's the link for the lazy: http://monkrb.com/
There just aren't that many moving parts, so there's very little that can go wrong, and there's no hidden magic, which is what has been making my life hell in the Rails 3 beta.
Also, Sinatra is fast. I just did a quick benchmark (ab -n 1000 -c 5 -k) on my laptop, and the scores were impressive. In the same rackup server, a bare Rack app did 4932 req/sec, Sinatra did 3169 req/sec, and the Rails 3 beta managed... 214 req/sec.
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.
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.
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.
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.
That's why Ramaze has hit the sweet spot for me. Hyper-fast and feature complete.
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...
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
Ok, so the answer is, "because Rubyists have redefined that phrase"? ;-)
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:...
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. ;-)
Some of the more enthusiastic new people to Ruby seem to do the same thing, only with everything -- "function", "class", "module", "library", etc. -- mapping to "DSL".
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!!
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?
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.
It's the closest thing to sinatra I've found written in python. (It might need some maturing though)
I have used sinatra in a bunch of projects ( http://brandpeek.com is one example) and it's a delightful little framework.