4 ms·

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 d

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.

jamesbritt 12y ago
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 http://ramaze.net
jrochkind1 12y ago
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.
- pandatigox 12y ago
  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 12y ago
    It is very possible to organize a Sinatra project elegantly. It generally involves a combination of require_relative and Dir.glob().
    - jrochkind1 12y ago
      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 12y ago
        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 12y ago
      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 12y ago
    Only if you treat it as a framework. Sinatra is a great library.
- pmontra 12y ago
  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.

jamesbritt 12y ago

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 http://ramaze.net

jrochkind1 12y ago

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.

pandatigox 12y ago
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 12y ago
  It is very possible to organize a Sinatra project elegantly. It generally involves a combination of require_relative and Dir.glob().
  - jrochkind1 12y ago
    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 12y ago
      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 12y ago
    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 12y ago
  Only if you treat it as a framework. Sinatra is a great library.
pmontra 12y ago
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.