[emiller829]

This is a promising start. I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

It still feels a bit DSL-centric from the examples I've seen thus far, and haven't dug into things to see what the generated Ruby looks like -- but if it's anything close to simple, this is something that has a chance to become an important part of the Ruby ecosystem.

If nothing else, it's great to see things like this because they provide concrete example code for discussions that (IMHO) need to happen.

[jrochkind1]

For a while, I thought Sinatra was taking that role? It might be interesting to think about what people are looking for that's neither Sinatra nor Rails, or why Sinatra didn't live up to what people were hoping (if people think that).

Sometimes I think some of this is just utopian grass-is-greener thinking. While there are _many_ things I'd do differently in Rails if I had the choice (some but certainly not all of which the Rails core team probably agrees with, if they had the chance to start over)...

...I think some of the "the thing we need is something _lighter weight_ than Rails" thinking is basically wishful thinking. When you start with something lighter weight, you (being me) generally find you need more than it offers, and then you've got to go finding your own things to do those things, and when these extra third party things end up not as high quality as you'd like, or end up abandoned by their developers, or you end up spending many hours re-inventing a wheel you're sure someone else has already invented.... either the 'lighter thing' ends up gaining weight, or you end up wishing it had.

Doesn't mean I agree with all of Rails choices about what to include, or how to architect it. But I think people under-estimate how challenging it is to hit the sweet spots, as if Rails core team just lacked the will or intelligence or proper understanding or something, none of which I think they lack. Still, certainly alternatives are great, testing grounds for other possible ways of doing things are great, the more different things we see, the better all of our architecting and coding gets, that's the only way to learn.

[pmontra]

For any project worth talking about Sinatra is too skinny. Basically you have to hack your routing in about the same way you do with Node's Express, enumerating the bindings between routes and methods. Obviously there are clever ways to do it but you end up reimplementing the resourceful routes of Rails.

Another problem is that you really want to use ActiveRecord to access the database. Anything else it too painful. So you end up creating AR models and you have to manually include them.

Finally there are views. I won't even enter into that.

Soon you end up with a worse engineered Rails. I've been using Sinatra only for serving API requests for small projects. I won't touch it for anything else.

[auxbuss]

I've built large projects with Sinatra. I've done the same with Rails, many times. The idea that you can't build something substantial with Sinatra is hogwash.

It is not a given that Active Record -- I presume you mean the pattern -- is necessary, but AR is available in Sequel, which is the usual choice of ORM when build with Sinatra. (In addition, Sequel has myriad additional benefits over Rails' ActiveRecord, particularly if you want to use raw SQL.)

Views in Sinatra are not much different to Rails, so whatever issue you have, I'm unclear what they are.

If you end up engineering a worse Rails then, as they say, you are doing it wrong.

As I mentioned, I use both, and you can achieve the same results with either. They are both, in effect, rack stacks these days; they simply have different conventions, one more opinionated than the other.

[jchook]

Sinatra is the perfect REST API server language for a client application. Given the way apps are going these days, I'm not sure why everyone isn't building single-page web apps that put 90% of the responsibility on the client and use only simple JSON communications with the server for persistence or authentication.

[ulisesrmzroche]

One of the problems with always doing things the 'Rails Way' is that people start thinking there are no other ways. Plenty of people build significant apps with rich and engaging interfaces with much lighter frameworks than Sinatra even.

[regularfry]

Rails is a pile of conventions. What I want isn't something more lightweight, it's something heavyweight with different conventions.

[1gor]

Try Padrino http://padrinorb.com

[pandatigox]

Sinatra, in my opinion, gets pretty hacked together after the initial `def get '/'; puts "Hello World"; end`

Personally, I think Camping is the perfect fit for Ruby frameworks

[nitrogen]

It is very possible to organize a Sinatra project elegantly. It generally involves a combination of require_relative and Dir.glob().

[jrochkind1]

That's interesting; I tend to agree with the crowd that wishes Rails didn't do any kind of auto-loading.

But are you suggesting that you need to add a kind of basic auto-loading to Sinatra to keep things sane?

[vidarh]

Rails autoloading "just happens". If you're doing explicitly require/require_relative, even on the results of Dir.glob(), the application explicitly specifies what will be loaded, and when. For my part I find that much cleaner.

[auxbuss]

Another way is to add a file, say init.rb, to a directory and require_relative that. It achieves the same thing, of course.

[Argorak]

Only if you treat it as a framework. Sinatra is a great library.

[jamesbritt]

I've felt for a while now that we need some strong alternatives to Rails for the folks who feel like the Rails Way and the Ruby Way don't always get along.

This is why I prefer to use Ramaze. It feels more natural if you're already used to coding in Ruby. It also supports the evolution of development from lightweight to complex sites without having to switch frameworks.

http://ramaze.net