I'd learn rails over sinatra. Sinatra is like being thrown into the deep end of the pool when you haven't learned to swim yet. You have to do it all yourself, where as in rails they've done all foundational stuff for you. Learning rails will teach you some good practices for how to structure a project, sinatra assumes you already know how to do this stuff yourself.

Yes, Sinatra is a Ruby web framework.

Sinatra is more of a "micro-framework" and puts you closer to the http method.

Basically, the api mimics http more closely, you literally use get, put, post, and delete methods to define your routes and actions.

In Sinatra, you define your routes in the same place where you program your Resource's functionality, so less mapping is required. In Rails, you have a separate controller and route files.

The model layers between Sinatra and Rails are very similar. For example, you can use ActiveRecord in Sinatra.

Say I take the Rails class. What's the learning curve from there to Sinatra? Better / worse than the other way?

The learning curve to Sinatra will be light. Sinatra is pretty easy to learn, especially if you already know Rails.

Also, if you want rapid prototyping, you should look into a document store such as Mongo.

Not having to write migrations (as you would with ActiveRecord + Mysql) is huge.

Also, your models can be more flexible. You can add keys to your document as needed. With Mysql, you need to have a migration to add the column.

No offense, but this is absolutely bad advice to a newbie programmer. First, mongo_mapper is virtually undocumented, whereas ActiveRecord has oodles of documentation and examples. You'll spend a order of magnitude more time trying to learn to use both MongoDB and mongo_mapper effectively than you will writing a proper set of migrations.

Second, I'm tired of all the NoSQL hype. I've worked on a project with MongoDB and MongoMapper, and the combination caused more problems than it solved. If you want cutting edge and all that comes with that, go with Mongo. Otherwise, if you'd prefer to focus on problems in the domain you're trying to solve and not the technology you're trying to solve it with, go with something relational and tried and true (PostgreSQL, if I were deciding).

I'm sick of all of the hype (for the past 20+ years) that relational databases is the only data storage technology you need.

When all you have is a hammer...

That's true and all, but Rails and Django were built to run on SQL dbs right out of the box. Getting them to work with MongoDB takes some work, and I don't think it's a diversion that someone just starting learning frameworks should try to deal with.

As for migrations, I don't think he's gonna be dealing with anything too complicated schema-wise. Django South will write your migrations for you. Maybe Rails has something like that? But honestly, I'd recommend using SQLite and just starting a new file whenever he really felt the need to alter the schema.

@grasshopper - That makes sense. Mongo is certainly new tech, so it would be more work right now with Rails.

With Sinatra, I'm finding it to be less work.

I would probably stick with relational tech if starting off with Rails, but keep your eye open toward alternative store, such as document databases and key/value stores.

@refugee - My experiences have been quite the opposite. Mongo allows me to focus on the domain. AR forces me to think about fitting the relational model into my problem, which causes a huge impedance mismatch, and causes lots of extra work and performance issues.

Of course it depends on the problem, but working with hashes and arrays is simpler than the relational model, no?

I do concede the vast swaths of docs for AR, however AR is pretty complicated and issues arise that aren't well documented.