I've worked through some of the Sinatra and Rails samples, but I'm having a hard time figuring out which features belong to which technology.
What specifically do I gain by using Sinatra/Rails? Is it just ActionPack/ActionView? Correct me if I'm wrong, but I COULD just use Webrick/Mongrel and serve up my .erb files right? And I could use ActiveRecord technology in those files and still access post variables, session state and querystring variables right?
So, what I'm asking you guys is, if I start with the PHP-like scenario above; Webrick + ERB + ActiveRecord, what do I gain by using Sinatra? And what do I further gain by using Rails?
For Sinatra, it's really almost like a wrapper around Rack. So you first need to ask what the point of Rack is. Rack is basically a specification for how a framework should return a result, it can use what's returned with any web server that Rack supports. So it's really a compatibility layer that allows you to choose your framework/server combination at will, without worrying about whether they'll work together. If your framework is Rack-compliant, you should be able to deploy on practically any server via Rack.
Now, the thing is Rack is very low level. Frameworks such as Sinatra give you things like nice routing, helpers, before/after filters, and a lot more. You just need to look to the docs to see what you can get. Rails is much more featureful, and in many ways "magical". That is, you might write a single line in Rails that ends up doing quite a lot, which for some is a good thing, and for some too magical. I personally prefer Sinatra for this reason, at least before getting a decent understanding of Rails internals.
The gain by Rails is ActionView/ActionPack. But you can just replace by Mongrel/Erb. It's something different.
It's all herlper you have in your view like name_route or error management in your form. It's all resources management and all plugin like InheritedResources. The advantage of Rails.
There are some tool like the Padrino environment to help you to have all of this helper. But It's really speeder after all plugin activate ? I don't think so.
With Rails 3, Rails is a complete Rack application with a lot of RackMiddleware. You can just drop off some middleware to increase your response.
This question is still relevant until today. And with rails' features are increasing over the time, I want to add a new answer.
There are so many gems right now, so what you can achieve in Rails, most likely you can achieve it too in Sinatra. If we want to compare between Rails and Sinatra (or any other frameworks), we just need to compare the performance and the ease of use.
One of Rails doctrine is convention over configuration. When you create a project in Rails, automatically you get many gems included in your Gemfile. Not only gems, when you look at config directory, you'll see many things included. This doctrine is the reason why the magic can happen in the first place. Once you break the convention, you have to modify -or even create- your configuration.
When we want to have more flexibility but still not reinvent the wheel, we can use framework like Sinatra, where only not so many features is enabled when we first create the project. Even so, I've created mini rails from Sinatra: I just adopting rails' way, with libs/gems that I really need. Because I need to develop my own configuration, the development time was longer than using rails.
If you see this web frameworks benchmark, you'll see that Rails is so slow while other ruby framework, like Sinatra, can be found much higher than Rails.
So, when the best to use Rails?
You need fast development time. Just follow the convention;
The future features of your apps are still unknown.
When the best to use Sinatra?
You don't need fast development time;
Sinatra can be fast if you only work in mini project;
You know that you won't add many features in the future.
What do you gain from Rails? Development speed.
What do you gain from Sinatra? Flexibility.
Related
I'm curious about alternatives to the components of RoR or RoR itself.
Some research brought up the ORM alternatives to ActiveRecord here on SO.
So remaining is the question about alternatives for...
... the controllers (ActiveController)
... the views (ActiveView)
... RoR itself
... any other component I'm missing here :D
Really, I'm very happy with all of them, but I'm asking out of pure curiosity.
In place of ActiveRecord, there are a few to choose from. The biggest competitor (and my favorite) seems to be DataMapper, then there's Sequel, Mongoid, MongoMapper. There are plenty of others too, but these are relatively big players.
In place of ActionView (not Active... Action... confusing, I know), I haven't come across anything. I've seen plenty of additions to it, but no complete replacements. I guess that means people are mostly happy with ActionView. Now, there are other template-engines available though. The big player here is HAML. Using HAML doesn't mean you're not using ActionView though. You're still using ActionView, just with a different template pre-processor.
Alternatives to RoR itself. Again, there are a few. The big players are Sinatra, Merb (which started in the early Rails days by some people who disagreed with a thing or two in Rails, and then Rails learnt a thing or two and took some bits and pieces back again... confusing!). There's also Ramaze, but I don't know much about it.
The thing is, Rails is more or less unrivaled in what it does. If you get your hands on a web app written in Ruby, it's probably going to either be a Rails app or a Sinatra app. Sinatra meets a different need to Rails. Rails wants to provide you with a whole array of tools to get things done quickly, while Sinatra's main goal is to be lightweight and keep out of your way. Rails is huge, while Sinatra basically boils down a glorified route map/dispatcher (I mean this in a good way), leaving you to build your web app however you see fit. Sinatra makes it easy to package a small web admin tool inside a gem, for example. You probably wouldn't want to include a Rails app inside a gem. That would be pretty overkill.
In terms of "other components", the big thing (though it's not a Rails thing) that comes to mind is Test::Unit. While Rails just ships with Test::Unit, and doesn't constrain you from using something else, it's worth mentioning that there are other testing frameworks available. RSpec is the other big player here, and there's also ZenTest. You may also look at Shoulda, which is an add-on, more than an alternative.
I am writing a simple ruby controller that just needs to respond as a webservice to a bunch of mobile clients.
Someone told me I should look into Sinatra. What is the point of using Sinatra for something this simple? He mentioned that it would be "faster" but how can a wrapper on top of something make it faster?
I don't want to overcomplicate things; a simple controller is so easy to write and there are less gems to maintain. Am I missing something that Sinatra offers that makes it worth the extra trouble?
Thanks
The simplest useful Ruby web application you could build would be a Rack application. Sinatra is a lightweight DSL which sits on top of Rack to make coding the controllers and views more convenient. You can build more sophisticated applications by including more add-ons like ActiveRecord or Rack::Oauth, etc
Rails 2 is a more feature rich framework which includes a plethora of additional features already in the framework. Some applications don't need all that so some developers prefer things like Sinatra which is minimal.
However the distinction between Rails and Sinatra has blurred quite a bit since Rails 3. The new version allows everything from just Rack to full Rails in the stack to you can tailor it to suit your needs. The raison d'etre for some of the intermediate frameworks such as Sinatra is weaker than it used to be.
So take a look at Rails 3, start minimally and grow to suit your needs.
Sinatra is a very slim web framework. It needs way less memory at runtime than Rails. Also, request processing is probably faster since there's less code involved. So it can be very appropriate for a webservice "this simple".
Especially if you need to run many instances (e.g. high traffic or many long running requests), this can be an important factor to the number of machines you need to run your webservice.
I am (quite) an experienced programmer but totally new to Ruby and Ruby on Rails.
RoR looks great to get working quickly, specially the automatic screen generation for CRUD operations.
It really it gets you productive quickly.
The questions is with the last 20% of the work, when I must finish my application. Won't RoR conventions stand in my way? Because not every database table must be available for all users, and not all users can edit all columns and/or all rows, and the views must be adapted to my site's look and feel, etc.
I understand RoR has been used successfully in live sites, but how exactly do you gain enough speed in RoR to escape gravity after the first phase has been burned out.
I don't think scaffolding gets you 80% there. Scaffolding is nice in that it shows you how the pieces of Rails fit together, but I wouldn't build my application off of scaffolding code. Now that you've been impressed by scaffolding it's best that you forget all about it. :)
Where Rails really shines in my mind is database migrations, the awesomeness of how dynamic ActiveRecord is, and the plugin ecosystem.
There's a lot to learn when deciding to go with Rails. You have a new language, new framework, and new plugins - but if you take the time to learn those things you can be very productive with Rails.
I've been doing ruby on rails for quite sometime. The 80/20 problem is not unique for rails. It applies generally to the entire world. I'm also not aware of any framework that can just do business logic for you.
To answer your specific questions. Conventions will not stand in your way while doing the 20%. Instead, conventions will help you to get through that 20% quicker.
Personally, for user authentication, I use Authlogic. For user authorization, I use Lockdown or Authorization plugin depending on customer need.
I also use inherited_resource in most of my projects to simplify controller code. This is another power of convention.
To increase speed of development, you will not only need to know Rails, but rails gems/plugins that does the right things for you, so you don't have to reinvent the wheels again. Also, knowing Ruby language is a must for quickly develop beyond the 80%.
Ruby Toolbox provides some of the most popular gems and plugins used in typical rails projects targeted at specific domains. You can look through the relevant categories and know what most people use. (And it's probably a good idea to use popular, well maintained gems)
TDD/BDD style development will also help you to speed up in the long run.
Lastly, a warning: If you stray away from rails convention, you will have a painful time in general.
P.S. I used Merb before. My feeling is that conventions helps you in merb, but you won't get too much penalty for not following them in merb. However, my experience with Rails is that if you decide not to follow rails convention while developing rails app, it will come back to bite you in one way or another! So think twice when you really attempted to stray away from rails conventions... (This is from my own experience, and of course subjective, but you can think of it as a warning...)
Won't RoR conventions stand in my way?
Because not every database table must
be available for all users, and not
all users can edit all columns and/or
all rows, and the views must be
adapted to my site's look and feel,
etc.
This is a bit of a non-sequitur. Rails is a framework that has been lifted from real world applications. Those applications had to deal with all those issues also, as well as others you may not have thought of yet. Generally, the conventions make life easier once you learn them.
Another point is that the conventions are merely conventions. You don't have to follow them. You do not even have to use RoR for everything, though I've yet to find a case where I didn't/couldn't, I do generally try to push as much into the DB or cache layers as possible.
I don't believe that you'll ever have a serious problem with Rails conventions. Just stick with the conventions and trust the RoR system. The people behind Rails put a lot of effort into these conventions to support 99% of the common usage scenarios.
If you really need to do something outside the conventions it will eventually get complicated quite fast. However, you are not alone. There are a lots of excellent resources on the net to get help (for example the StackOverflow community).
To sum it up:
Stick with the conventions whenever possible (excellent resource to get started: Rails Guides.
Don't reinvent the wheel. Look for Rails plugins and Ruby Gems instead (don't forget GitHub).
Consult the StackOverflow community if you need something out of the ordinary.
Test all the f***ing time (just for fun).
I am experimenting with Ruby and Rails. I like Ruby, but not Rails. I have Java/PHP background, I have used some frameworks, but never totally liked any of them.
Anybody using Ruby to build web apps, but not any of the frameworks? (rails, merb etc). If yes, can you point me to some resources to learn it?
It might be wise to at least leverage Rack, and maybe Sinatra gets enough out of your way for you to feel comfortable. Sinatra isn't much more than a very small, simple wrapper around the rack handler afaik.
Doing Web apps in Ruby without using a framework is like cooking without heat. I question the sense of trying this.
That said, you could probably hook up Apache to call a Ruby program as a CGI. I suspect it would be dog slow, though.
Edit: Apparently you're not the only one crazy enough to attempt this, though: I found a tutorial on Simple Ruby CGI. The author claims as his rationale that "he has nothing better to do."
Your question looks quite similar to Ruby off the rails, so you probably should read the answers of that one.
I'm using ruby instead of bash and python on my ubuntu server for sysadmin tasks.
I've found Ruby a particularly clean and powerful replacement for the places I'd have previously used bash and python in sysadmin.
I personally found one thing for myself. When I prepare some interview or I am gonna build something from scratch, in most cases I need some basic features included in Rails. That usually happens when you build something not complex, but still non trivial. In 99% of cases I need ActiveRecord, ActiveSupport etc. It is easy to get those things in your Gemfile and play with them. One thing you will always repeat is basic application structure, easy console access with preloaded libs, rakes... I created minimal gem for myself to organise this process though.. :) If you read sources you'll see what I constantly do to start something new. It is not a big deal not to use any framework at all.
https://github.com/einzige/framework
I would like to use a lighter framework than Rails (Sinatra/Ramaze/Camping) but am concerned that by doing so I will not be able to use a lot of shared libraries that have been tailored to Rails in the form of plugins. Is this a major concern or are most of these plugins usable across different Ruby frameworks?
Are there any other potential disadvantages in using a Ruby framework other than Rails?
You can still use gems in all of the frameworks you mentioned, so a ton of stuff is reusable. Want to swap in a new ORM, no problems. Want a fancy shmacy syntax highlighting, no problems. Rails has been making a huge push to move away from the old plugin model to use gems exclusively.
If one of the other frameworks fits your needs better use it. Keep in mind that when it comes to documentation and samples rails has more.
If I was learning Ruby and wanted to try out a web framework I would probably go with Rails not because its better, but because its got much better tooling and documentation.
Most Ruby modules used by Rails (even ActiveRecord) can be used without Rails. But then you lose the extra benefit of integration provided by Rails. You may have to work extra hard to glue Ruby modules to the framework of your choice. Please also note that most of the documentation about Ruby modules used by Rails tells you only how to use that module with Rails.
Network effects play a bit of a role.
One issue that comes up when you use other frameworks like sinatra, camping, etc is that rails gives you a proven structure for your files in the your application. Smaller frameworks are quite open and free.
This can be a downside when you are working with multiple developers as you need to have conversations about creating conventions rather then simply following them.
If you've been using Ruby for less than a year, stick to Rails, unless you have a very clear need that is better handled by one of the other frameworks.
The lighter frameworks, most notably Sinatra, tend to be popular with people who know exactly what they will need and can't afford to have any additional overhead from unused code. Essentially, you pick your toolchain, instead of generally being stuck with what Rails gives you. (Yes, in Rails, you can replace ActiveRecord, et al. with other libraries, but it's not exactly easy.) So the lighter frameworks give you significantly more freedom, but you also have quite a bit more work to do in many cases.
I think no rails plugin is going to work out of the box with any of the alternative frameworks, except for ActiveRecord plugins (such as acts_as_nested_set etc.) which are still going to need some plumbing work (setting $LOAD_PATH and requiring right files). I'd recommend DataMapper for ORM, not only it's way faster than ActiveRecord, but it's also very modularly built and plugins are actual gems that you can easily install. In difference, ActiveRecord plugins are mostly monkey-patches that tend to break with every new version.
Sinatra doesn't come with any "goodies", no Rakefiles, no skeletons, no script/generate, but actually that's what it's been written for. You can gradually "plumb in" all the extra stuff. There are also skeletons for sinatra apps that come with some basic layout and defaults, you may find these useful.