Sinatra - Hyper Fast Mini Webapp Development in Ruby
sinatrarb.com
sinatrarb.com
I've written a blog with lots of documentation at http://www.gittr.com.
In addition, coworkers of mine at Citrusbyte have taken Sinatra and built a minimal, yet more full featured web-stack called Monk (http://www.monkrb.com). Basically it takes the Sinatra library and wraps it up with convenient conventions, libraries for testing, settings files.
I've used Sinatra for small projects like Irclogger (http://www.irclogger.com) (http://www.github.com/cschneid/irclogger). You can take a look at the code and see how simple it is underneath. I've also used Sinatra for larger projects involving many files, user login and authentication, database access, and more.
What you'll find when you're writing Sinatra is that almost nothing is provided in the way of helpers, but also that you won't miss them. You write your own helpers where you want, and use normal rubygems to provide other functionality. It's not really a web framework's role to render JSON when there's a perfectly normal JSON gem that does it well. On the other hand, various people have recreated the small helpful stuff in reusable forms, including fairly simple things like partial rendering, up to reverse URL lookup (like Rails provides person_edit_path(), etc).
I'm not sure what the other commenter is talking about with bloated memory footprint for Sinatra, it's a fairly minimal piece of Ruby code, and any memory bloat will be the fault of your code, and not the framework itself. A hello world app in Sinatra takes about 10 megs of ram to get up and running (under Thin in my case). Rails takes about 40 last time I checked. Everything from there is related to your app (be careful with ActiveRecord, it'll chew through ram).
To sum up: Sinatra is a do it yourself framework toolkit. It doesn't provide much beyond making it easy to build your own helpers and your own application specific code. If you need help or advice, swing by #sinatra on freenode.org. People are always around to help.
be careful with ActiveRecord
Edit: http://www.engineyard.com/blog/2009/thats-not-a-memory-leak-...
Model.find(:all) is going to be problematic across the board, there will always be a risk when you start playing with things like including children (there's a great benefit as well). You need to know what you're doing with any ORM.
It's not as full-featured as ActiveRecord, but then it's also not nearly as heavy!
Considering I created the project, nursed it through it's first couple years of development, and invented patterns like Strategic Eager Loading and Lazy Loading Contexts, which no other O/RM has to this day to my knowledge, that should say something. It's an epic fail of a project at this point."
-- Sam Smoot
http://robots.thoughtbot.com/post/162764036/why-do-rubyists-...
Although I think a lot of Sam's work, his boast of inventing patterns of "Strategic Eager Loading and Lazy Loading Contexts" is hard to take. I wrote stuff like this in Samlltalk in the early 90s and again in Java in the late 90s.
From my perspective, I don't trust any of the ruby ORMs. I constantly watch the SQL they generate thinking any day I'll catch an error. This isn't to berate the developers, but to acknowledge that the approach to solving this problem domain is too "magical" for my tastes. This is one reason with my new app I'm going with mongodb. I get a less trusted DB, but my ruby code accessing it is closer to the metal.
Anyways, yes, OK, nothing new under the sun. I don't doubt better programmers than me did this awhile back. I'm just not aware of another OSS or Commercial O/RM that provides it, and I'd never seen it before.
Also, I can't take credit for actually _implementing_ the Lazy Loading Contexts... that was someone else. Really smart guy, but he dropped out of the project eventually.
DM is just crazy sometimes, but with 0.10 Dan says that's changing. I'd trust it again when someone big deploys and raves about it, I just don't have any motivation to investigate it personally. I think there's better things to spend your time on considering Sequel is around. Why fight it?
I took code from Sharon early on (connection pooling), he took code from me (block query syntax), Sequel is kinda the best of both worlds. I've never thought building an O/RM on top of a Table Data Gateway was a good idea, but that's mostly a performance concern, and Sequel's performance is right up there so does it really matter?
My only concern with Sequel is that last I looked it's not as robust as Hibernate when it comes to aliasing tables. But then what is? It's probably a rare enough issue that you can just get around it with the sproc or ad-hoc query support once or twice in a given large app.
All good programmers boast about a thing or two they "invented", me included. I wouldn't have it any other way. ;)
I just looked at your site and realized you were the guy I've been feeling sorry for all this time since you were one of the early production adopters. I'm glad to hear it's been a pretty smooth experience. I can stop carrying around that guilt. ;-)
Oh, and since this thread is about Web Frameworks, try Harbor (http://wiecklabs.com). :-D
Lesson learned about being to vocal/open too early, but Harbor and the related projects are seriously good stuff if I do say so myself. Also look for a major open-sourcing of a user-management/authorization system built on Harbor in the next day or two at http://github.com/wiecklabs.
True, he did generate a SWIG wrapper to create the first prototype of DataObjects after a conversation we had where I suggested Ruby would be a better place with an ADO.NET-like database interface... but none of that was really usable since you had to have the exact same MySQL version down to revision, on the same system. The only other major contributor to DataObjects outside of the Wieck team I recall (and apologies if I missed anyone) was Dirjan Bussink fixing my broken Connection Pool. Later contributors (and Dirjan) ended up rewriting a lot of it for Asynchronous Execution, more driver support, etc. But that's the reason the thing looks so much like ADO.NET.
Oh, and Command#set_types was me too. Which is the reason DO is the fastest (last I bothered to look) database API for Ruby.
The marketing contribution was HUGE. It always surprised me how many new people showed up after one of Yehuda's presentations. DM wouldn't be what it is today without Yehuda. But your own opinion on DM's code is about as valid as Yehuda's. Just look at the commit-history.
From a raw performance perspective, it's faster than Rails, but it has some issues with it's design that can cause extremely bloated memory footprints.
From a developer sense, it doesn't come with a lot (hardly any) of helpers, generators, or other fancy tools. So depending on your use case you could end up re-inventing some wheels.
It's biggest advantage is that it's small, lacks a lot of magic code, and doesn't force you into a specific structure. This makes it great for web services, small apps, or even small components of larger apps. But like anything else it's definitely not a silver-bullet.
By design it doesn't have a lot of helpers, generators, or other tools. Depending on your usage this could mean a lot of re-inventing the wheel.
I have tried some simple benchmarks against two apps. One with a single subclass, and another with 3 subclasses. The one with a single subclass used 22M (RSS), the one with 3 subclasses used 23M (RSS).
This was running it with thin. The code is here: http://gist.github.com/187475
There is nothing to do in Sinatra except to get to work on your application, which is a good thing.
I highly recommend Datamapper over ActiveRecord, too; between Sinatra and Datamapper, you can literally pop open a single file and have a complete working application when you exit the editor, with no external setup steps.
What does Sinatra use for layouts and views and partials by default? Last I looked it appeared to be .... nothing.
It seems then that for anything non-trivial you're either inventing a view system or tacking one on. Am I missing something about this?
Among the things I like about Ramaze is that, like Sinatra, I can do the all-in-one-file web app if I like, but if I decide to refactor to layouts and views and such there's an obvious, ready path. Ramaze lets me evolve smoothly from dead-simple to high sophistication, and I don't see that with Sinatra.
It's downright trivial to add your own rendering helper for any templating language.
And for organization purposes, it's really freeform. Act like you're writing any other ruby app, and organize how you like. If it's small, a single file makes sense, if it's medium sized, maybe a file for controller and one for models, for big, do the split into an app/{routes,models,views}. All of that is easily supported.
Check out Monk as a good example of how Sinatra can be adapted to a more complex directory structure.
(also, Hi James!).
So far I see nothing that makes Sinatra more appealing or useful than Ramaze, and some thing that make it less so.
The curious thing is that on the one hand Sinatra gets described as a "framework", and on other other hand there's a great deal of BYOC (bring your own code).
That's fine, and something I tedn to prefer, but if I really want lightweight microstuff I'd start with a plain Rack app, and if I need more I'd convert it into a Ramaze app.
I do like how Sinatra auto-maps the REST verbs, but basically it comes off more as Rack middleware with a cheering section than an actual Web framework, micro or otherwise.
(also, Hey Chris!)
Sell me on Ramaze. I love that I can whip out a 2-file application in Sinatra --- one file for the Ruby and templates, and another for the jQ js that'll run on the client. What does Ramaze do better than Sinatra for me?
Yeah, I love that about Ramaze as well. :)
"What does Ramaze do better than Sinatra for me?"
Appears to be faster (at least in some simple benchmarks I ran). Choice of templating language may be key.
Has a better-sized set of robust standard helpers, should you want to load them.
More built-in adapters for a wide variety of template engines (Haml, Ezamar, Liquid, Markaby, others)
Unbeatable community on irc (#ramaze on freenode)
Way cooler shirts and coffee cups: http://www.cafepress.com/rubystuff/4904578 ;)
Whether or not any of this works out as "better" for anyone is hard to say. I like that Sinatra doesn't dump a ton of must-load crap on you just to get started, but neither does rolling a plain Rack app. Or Ramaze, for that matter.
It's also nice to have a reliable set of built-in libs to pull from, and as best I can see there's a stronger choice in Ramaze.
But, to be honest, Sinatra just never showed enough value to me to dig into all it's possibilities, so I may be wrong in my observations.
By default, Sinatra will read views out of the views/ directory, but I try to keep things in the files, so each area of functionality in the app is self contained.
Sinatra was great however. Everything (by default, I realize you can move beyond this) was in a single file that I could glance at, find my errors and correct. The downside mainly was that when looking for help I kept finding Rails-specific stuff, which wasn't useful (trying looking up Ruby stuff without encountering Rails, or accidentally filtering every decent page out of search). The documentation for Sinatra could certainly be improved and I'd love to see a book on it.
One of the first Sinatra tutorials you used to run across on Google (was on http://www.xnot.org/ but is now removed) didn't work with current versions of Sinatra and produced very odd errors. Slightly frustrating to a noob when the documentation isn't marked with a date or the fact that it was only to the alpha versions.
Overall Sinatra is amazing for bashing out really quick and simple web interfaces in about 10 minutes. Rails is just too heavy oftentimes. I might just need to make a page that allows someone to see something that Ruby is pulling from a database- and that's it!
In other words, there's massive reuse of CPAN components with Catalyst, as the framework itself doesn't provide much for free.
The sinatra "hello world" is insanely compact, and really says something... Here is one point where Catalyst is different, to put it politely.
On a side note, I got so frustrated with Catalyst that I now use Django.
sinatrarb.com points to 208.67.217.132 which does not seem to have http running (at least not on 80).
www.sinatrarb.com points to 65.74.177.129 (which is the sinatra website)
That, and sinatra has been around for years, but I guess by the discussion nobody cares if it's not new...