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.
Related
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.
So Rails and Merb are sort of merging in Rails 3.0? Thats how its been described to me anyway. This means that a lot of what made Rails, Rails will now be moved to plug-ins so that it can be more lightweight. HOwever, what are those plug-ins going to be and as a new Rails developer, what are THE must have - and also more mature - plug-ins that a Rails developer should install? Some good examples I can think of might be will_paginate, ruby_prof or sqlite3-ruby.
My understanding is that Rails (3) will still essentially be composed of the framework components that make it up now i.e. ActiveRecord, ActiveSupport, ActionPack, even prototype.js etc. It's just that the internals have been significantly refactored and cleaned up and it will be much easier to swap out components for alternatives. For example, perhaps replacing ActiveRecord with Data Mapper.
The tag line for Rails 3 is the same as Burger King i.e. Have It Your Way (I'm not joking!)
Many releases have taken out significant components and put them in plugins, you probably haven't even noticed most of the time. The best thing to do would be to just stay upgraded and pay attention to deprecation messages in your logs and you'll be fine.
This is all thanks to posts like this which highlighted the problems to the community earlier on. Now it should be much, much smoother.
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'm planning on taking the time to actually learn Ruby on Rails in-depth (I've previously done some very minor dabbling with it) so I can hopefully reinvent myself as a Rails developer.
The issue I run into though is that there are a fair bit of related technologies that are currently used in the Rails community, and I'm not sure if I should learn the whole shebang or focus on learning Rails with the defaults first, and then branch out into the additional stuff.
For example:
Templates. I took a look at Haml and it looks really cool (shouldn't be hard to learn either).
Testing. I've wanted to learn test driven development for a while now, but the "next big thing" in Rails-land seems to be behavior driven development with RSpec
Javascript. I'm not sure if I should stick with RJS or use something like jQuery which seems to be converting people.
I've never really used version control much. Rails seems to be using Git for most of it's projects.
Basically I want to learn Rails "right", but there seems to be a lot of different ways that I could go. Should I ignore the "variants" and focus on the Core stuff until I've written an application or three (e.g. core, unmodified Rails; RJS w/Prototype and Scriptaculous for Ajax, regular Test::Unit for testing, ERB for templating, Git for version control), or should I try to pick up some of the variants along the way?
If you want to do well in the rails world you should plan on learning (and relearning) things on a regular basis. It isn't as hard as it might sound, but it is important. I'd suggest you make a list of things to learn, and just work your way down it doing by getting an hour or so of hands-on-time with something new each day. If you feel like there's more to learn (or that the subject is in flux) throw it back on the tail of the list to revisit another day.
A starter list (yours plus a few you didn't mention), in no particular order:
erb
gems
acts_as...
test driven development
git
rspec & behavior driven testing
javascript
prototype.js
jquery
sql
rail's finders
rake
the rails console
plain old ruby
duck typing
ruby's metaprogramming facilities (how the magic is done)
css
rails generators
And so on and so forth. As you're going through one and come across something interesting, throw it on the list.
The point is, if you try to take a narrow view you will probably make life harder on yourself and learn slower than if you make a commitment to perpetually, steadily expanding your horizons.
I've been a full time rails developer for over a year now and what you use really depends on what kind of team you end up on. I've barely used RJS, have never used RSpec, but I use git, jquery and rails every single day.
My Advice: stick with rails for at least a few months. There is plenty to learn in the framework alone. I would consider ignoring RJS as I feel like it's going out of "fashion" as developers trend towards jQuery.
Regular Test::Unit is great, although I like to add thoughtbot's Shoulda to provide some testing macros that save a whole lot of time (consider ignoring all the Shoulda context stuff though).
Learning git feels pretty important IMHO, mainly because it's a great and is gaining quite a bit of popularity. It also enables you to feel comfortable using github, which can be a big advantage.
I'd recommend starting out with the basics of Rails. Haml, RSpec, jQuery, and Git are all great things, but if you try to learn it all at once, you may become overwhelmed.
I would start with the defaults first, as I agree with Matt's comment that trying to learn it all at once would be overwhelming.
Plus it may turn out that depending on your applications you may or may not need jQuery, you may be happy with the default testing, and there are tons of ways to do templates so starting with ERB to get the basic understanding of how the view/templating works is a good idea.
Once you get more experience and know exactly the requirements you will have for your application(s), you can then more easily pick up and swap out some of the variants.
Git is important. Make an account on github, install git, and get used to it - you need some kind of version control, might as well make it the new cool buzzwordy one.
The other stuff, not so much. Bang out a few applications and then add them in one at a time.
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.