My feeling is that the differences between Camping and Sinatra are not very significant and that you could safely choose either one and be ok. But I want to ask the Ruby experts if this is true. Are there in fact any important differences between the Sinatra and Camping microframeworks? And how would you go about deciding which one to use?
The only significant difference that I'm aware of is that Camping is based around the MVC pattern like rails, and is coupled to ActiveRecord. Sinatra is more agnostic.
Camping also is no longer maintained, while Sinatra is under active development. That alone is probably reason enough to look at Sinatra first.
edit: Thank you for the correction Philippe, and great to hear that Camping development is ongoing. Apologies for indicating otherwise.
One thing to consider is that Camping is somewhat of a golf exercise. It was 4k but judofyr has gotten it down to 3k. Try reading the source, I dare you. Now, there's also the unabridged version which gives you decent comments, but the code itself is still painfully obfuscated.
With Sinatra you can pretty comfortably dig into the internals and find idiomatic ruby. That's pretty darn important, IMHO, especially if you ever need to patch something.
(Keep in mind that Camping is eccentric by design, I'm not aiming to pass judgment.)
Camping is being maintained. Since _why was concentrating on Hackety-Hack/Shoes until he kind-of-vanished, and (as semanticart writes above) Magnus Holm (judofyr) has been working on Camping. The unabridged version has some useful documentation. It works fine for me and, although I've yet to really stretch it, some Camping apps out there (like Cheat) run fine.
You might also like to check What are the main differences between Sinatra and Ramaze? which has some useful links to Sinatra and other lightweight Ruby frameworks.
Related
Forgive me if this is a noob question with an obvious answer, but what's the point of using rack-flash in Sinatra?
It feels like rack-flash functionality could easily be written yourself and a gem is a little overkill. Is there something Rack provides that I'm missing?
The README addresses this:
flash[:notice] = "You can stop rolling your own now."
It feels like rack-flash functionality could easily be written yourself and a gem is a little overkill. Is there something Rack provides that I'm missing?
Yes:
It's distributed as a gem, so you don't have to copy your flash implementation across projects. This reusability is key.
The interface is consistent with Rails, so future maintainers of your code won't have to study your idiosyncratic implementation.
It's well tested and developed in a community.
You're not wasting your time reinventing a small cog.
Unless your app's core functionality is flashing messages, this little ~100 SLOC gem that provides the above benefits is hardly overkill.
I just add a message to my session data and flash it if it's there. That's what rack-flash does too. I looked at it once and the time I need to look up its API is the time I need to write it myself over and over again. Maybe I'm missing something here but iirc one of the flash gems broke over some Sinatra update and that's where the pain starts if you depend on a gem.
Is Ruby primarily only used in ruby on rails? Is it used on the server side for general work like php is? Also, I haven't seen a lot of hype about rails anymore. Is Ruby and/or RoR dead or fading away?
I ask because I was interested in RhoMobile for building mobile apps, but I didn't want to get into using an antiquated language.
Thanks.
edit: Can i use Ruby for web pages if I don't want to use rails? (I do not mean another framework. I mean like php.)
Regarding your question about Ruby and/or RoR dead or fading away, look at the job trends
There are many web-frameworks for Ruby, not just Rails, Sinatra being one of them.
You shouldn't be deciding to use a language or technology, because there is or there is not a hype around it.
If a product is able to solve your problems, then you should use it. I know people building stuff in Smalltalk nowadays (who would have thought, right?), because it's great and it works.
Take a look at Sinatra, for example.
Also there is a lot of tools written entirely in ruby.
I'm looking for a simple Ruby framework for a non-web project. I'm very familiar with Rails, so when I write pure Ruby I miss:
The different environments (development, test, production)
The console rails c
And many other utilities provided by rake or rails
I know I can require ActiveSupport and friends, but it's not what I need. It's mostly the development framework that I miss.
One thing I investigated is to do my project as a gem (even if I don't need a gem at the end). Using jeweler for instance provides versioning. I'm sure there are better ways but I can't find any. What would you use ?
Alright, that is somewhat of a three-part question. A threstion, or triesti... actually that doesn't work. Threstion it is then.
One thing to understand about Rails is that it isn't magical. It's code, written by mortal humans who have faults (such as oversized-egos) but who are also incredibly damn smart. Therefore, we can understand it after perhaps a little bit of studying their work.
1. Rails environments are lovely
The code behind the Rails environment management is actually quite simple. You have a default environment which is set to development by this line in railties/lib/rails/commands/server.rb. You could do much the same thing in your application. Run a bit of initialization code that defines YourAwesomeThing.environment = ENV["AWESOME_ENV"] || "development". Then it's a matter of requiring config/environments/#{YourAwesomeThing.environment}.rb where you need it. Then it's a matter of having configuration in those files that modify how your library works depending on the environment.
I couldn't find the line that does that in 3-1-stable (it's gone walkies), so here's one that I think does it in the 3-0-stable branch..
As for the lovely methods such as Rails.env.production?, they are provided by the ActiveSupport::StringInquirer class.
2. Rails console is the Second Coming
I think rails console is amazing. I don't want to create a new file just to manually test some code like I would have done back in the Black Days of PHP. I can jump into the console and try it out there and then type exit when I'm done. Amazing. I think Rails developers don't appreciate the console nearly enough.
Anyway, this is just an irb session that has the Rails environment loaded before it! I'll restate it again: Rails is not magical. If you typed irb and then inside that irb session typed require 'config/environment' you would get (at least as far as I am aware...) an identical thing to the Rails console!
This is due to the magic that goes on in the initialization part of Rails which is almost magic, but not and I've explained it in the Initialization Guide Which Will Be Finished And Updated For Rails 3.1 Real Soon I Promise Cross My Heart And Hope to Die If Only I Had The Time!
You could probably learn a lot by reading that text seemingly of a similar length to a book written by George R. R. Martin or Robert Jordan. I definitely learned a lot writing it!
3. The Others
This is where I falter. What other utilities do you need from Rake / Rails? It's all there, you just need to pick out the parts you need which is actually quite simple... but I can't tell you how to do that unless you go ahead and paint those targets.
Anyway, this is the kind of question that is exciting for me to answer. Thanks for giving me that bit of entertainment :)
Edit
I just noticed the BONUS fourth question at the end of your question. What would be the point of versioning your project? Why not use a version control system such as Git to do this and just git tag versions as you see fit? I think that would make the most sense.
First of all, Rails goal as a web framework is to let you mostly forget about the low-level details of a web based application (interacting with a web server, a database, etc.) and provide you with high-level abstractions which allow you to concentrate yourself on the actual job: Getting your application done.
There is such a huge diversity of non-web applications, that it is simply impossible to have a framework that "makes them all".
It is useful to understand what a framework is, and why and when you should use it.
Let's say you would have to build a dog house. You would buy some wood, nails and a hammer to build it the way you want from scratch, or you could go to Walmart and buy a DIY doghouse kit.
You will get a manual with detailed instructions on how to build your dog's "dream doghouse", and you will get it faster done than when making it from scratch, but you will be limited to the wood that comes with it and may be forced to use their nails or screws, and in some cases you would also need to buy a special screw driver.
The DIY kit is your framework. Some smart guys already provided you with the basic tools of making your doghouse, you only had to figure out (or not, if you had a manual) how to do it given their "framework".
Now, let's say you would build a skyscraper. The materials, tools and conventions (the framework) used would probably not be the same as they would when building a doghouse, and it would be over-kill to use a "skyscraper framework" to build a doghouse.
You wouldn't write Twitter client with the same set of tools and conventions as you would when writing a banking application with a billion concurrent users.
Rails is just one framework which provides you with a set of many, many good (and useful) conventions to write a web application, but that doesn't necessarily mean that it's the ultimate way to go. You can choose another framework, and maybe you will like the conventions for writing your application even more than the ones provided by Rails; or you could write all from scratch which would not limit you to what is provided by a specific framework and maybe make it even better.
To answer your question: Think of what you want to write and don't let yourself be narrowed down by the set of tools and conventions provided by a framework, as they will surely be if you choose this path.
Buy yourself some books about Design Patterns and read some great software, and then you may understand why the authors did not choose an application framework. Indeed, they've developed their own conventions and defined the behavior of what it should do; and once again, the "Rails way" isn't the only way, which doesn't make it the bad way. :)
I would appreciate constructive criticism as I really tried to provide a good answer.
Have you looked at Monkeybars? It's a Rails-inspired MVC framework that runs on top of JRuby and Swing to build desktop applications. I like it a lot.
I have once again fleshed out Ruby, after two years of not touching it, and am considering programming for the web with Ruby. However, I have found that the Ruby on Rails framework is just too large and bloated for my taste. It is usually a matter of preference, but in my case, I just want to be able to program on the web without having to worry about structuring my code with a framework similar to RoR.
When programming for the web with Ruby, should I be using a framework? Is it recommended? If you could recommend a simple one, which would it be?
Thanks.
The simple and minimal framework for ruby is sinatra
IMO, using a framework is good idea (don't reinvent the wheel etc). Just find one that suits your needs.
Apart from Rails, I've heard about Merb, Camping, Sinatra and Ramaze. For a quick comparison, you might want to read this post. For some other ideas, check 10 Alternative Ruby Web Frameworks.
EDIT: As pointed out in a comment, Merb and Rails are merging and according to Merb creator Ezra Zygmuntowicz (see this blog post), "Merb is Rails and Rails is Merb" so I guess Merb isn't that light.
EDIT2: As pointed out in another comment, the goal of this merge is to make Rails malleable so that you don't need to use all of Rails if you don't want to.
Sinatra is a very good choice
Even if you use no framework or a very light weight one, you will notice that when your application grows, you'll try to replicate existing features of Rails or other MVC frameworks to solve your challenges. By the end of the day, you'll still end up with a heavy weight framework whichever path you take.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Have you used Sinatra successfully? What kind of a project was it? In what situations would you recommend using Sinatra instead of Rails or Merb?
I've dabbled with Sinatra, but haven't really written anything serious with it.
As you said above, there's a list at http://www.sinatrarb.com/wild.html, although a lot of the applications listed there seem to link to GitHub pages, which I assume are often people experimenting with Sinatra and publishing their results online. Then, there's also the Sinatra mailing list, where you might find links to some interesting projects.[*]
As for your question on when to use Sinatra, I personally would answer "for smaller projects." When you want something up and running very quickly, it seems like Sinatra is an excellent choice. It's also great for people who like Ruby. With that I mean, when you're doing something in Rails, you have to do it "The Rails Way". Rails is the framework upon which you're building your application, and you have to adhere to its customs and conventions. Sinatra, on the other hand, feels like a library. You feel like you're writing Ruby, if you want to connect to a database, you use the library you like/think is appropriate for the job, if you want to output HTML you choose the templating library you like, and if you want a simple web framework, you choose Sinatra. Sinatra is not something upon which you build your whole application, it's something you use beside the rest of your application.
So, as you may have gathered, I'm quite fond of Sinatra, and I would use it for personal (or small-scale) projects. It's easy to set up and easy to use, as long as you know what you're doing. Looking through http://www.sinatrarb.com/wild.html, it seems like that's what most people are using it for, see for example Is Lost on yet? and Calendar About Nothing.
[*] Edit: I found a thread here, with people linking to their projects. There seem both larger and smaller projects. Very interesting stuff.
There is a list at http://www.sinatrarb.com/wild.html.
Still, I'd like to hear a bit more about them. I also suspect that there are lots of successful Sinatra projects outside that list.
I just released TweepDiff (http://tweepdiff.com) written in Sinatra. Anything else would have been overkill but I would use Sinatra for bigger projects too.
I think sinatra is best suited for micro-applications development (no big surprise, it's a micro-framework)
Sinatra provides you with a sufficient level of abstraction to build almost everything you want quickly. And what I like about sinatra is that the framework gives you tight control over what your app is actually doing, you can really "feel" what you are writing. So, I would say Sinatra is a subtly balanced framework.
I also think Sinatra is attractive for "people who likes writing Ruby" as said before. You start writing ruby class before implementing a sinatra interface. (good exemple of this kind of workflow here : http://dev-logger.blogspot.com/2009/01/ric-rac-roe-in-soup-of-technologies.html)
I wanted to be able to run succinct self-contained Ruby scripts from my web server. As far as functionality goes, it would be similar to a CGI library. Sinatra was perfect. One sinatra app later and I have a collection of scripts accessed through simple sinatra style routes.
Whenever I need to write a web application that doesn't depend on a database, I suspect sinatra will be my first port of call.
I'd have to echo most of the above comments. We're in the process of implementing a Sinatra/HAML stack for browsing and basic reporting on data.
I really like the combination of simplicity and direct connection to Ruby. If something isn't working in the browser, it's pretty easy to port it out to a straight Ruby program for debugging.
There's definitely a feeling of building a dog house with Sinatra versus the Taj Mahal with Rails. It's easy to comprehend (it's also helping me understand the need for MVC and Rails).
Altogether very cool stuff and very fast. I haven't stressed it yet, so I can't say how well it'll behave in the real world.
I made http://istay.com using sinatra, all I can say is that it is a fantastic little framework for any site that doesn't directly use or doesn't have a database.
Though I do feel sinatra has reach it's limit with the current site, and any extensions will be written using Rails or other framework.
I use Sinatra for small 'one function' kinds of apps (My current blogging engine might be a good example). I think the simplicity of Sinatra works best for little utilities and basic API front-ends (Twitter apps, etc).
For larger scale apps there is even the Sinatra-based Padrino Framework with some of the niceties that you would usually reach for Rails to provide.