1. 11
  1.  

  2. 3

    This is a lot of anti-Rails FUD, I’m kinda surprised to see it upvoted here.

    I personally have stopped writing Sinatra apps for everything but one to three page applications; I always end up either re-building two thirds of Rails poorly by adding tons of gems, or just straight porting the app to Rails as it grows.

    1. 2

      I generally wouldn’t view this as anti-rails by any means, in fact we still have a large amount of rails applications that do exist at Heroku. The difference is where we formally had a rails application that handled a massive amount of things we’ve pulled it apart to have an API at the core, and multiple supporting rails applications at the edges. This allows us to move faster and have a cleaner separation between each application than before.

      1. 6

        anything that makes the development environment different than production is a disaster waiting to happen

        So you run the exact same hardware, OS, all identical versions?

        you’ll have to know what IP spoofing is, and how to address it.

        This is a pro for Rails, not anti. You don’t have to know about how it works, Rails just takes care of it for you.

        Great for those of you trying very hard not to design an API.

        Silly, silly FUD. Tools to help you parse things quickly don’t mean bad design.

        THE RAILS ROUTER

        This is just random statements of preference with nothing backing it up whatsoever.

        You also go through zero of the things in the ActionPack layer, all those are super big advantages.

        To be fair to Sinatra…

        How do I separate my views in different folders?

        This is super easy. erb :"foos/index".

        How can I protect my app against CSRF?

        Other random things:

        while also adding pretty substantial dependencies like qt.

        You don’t need to add qt to do full browser testing in Rails.

        Getting asset pipeline for designers doesn’t come without a lot of backend model adjustments from engineers.

        I don’t even understand what this means.

        making JSON the default format becomes a nightmare when you have to take browsers into account.

        You do know that Rails does a lot of stuff to detect awkward Accept headers and make them better, right?

        Code bloat: Rails doesn’t help here

        Neither does Sinatra.

        the nature of a pure API app is radically different than the one of a web app:

        Both of these statements under this heading are silly, and wildly unsubstantiated.

        Anyway, basically, I found this post to be a near-incoherent ramble of wild statements, hence ‘fud.’ Rails is CERTAINLY not perfect, but I don’t think this post does a good job of pointing out the flaws.

    2. 1

      Oddly limited comparison. I prefer to go with Ramaze, get the best of both worlds, and avoid this false dilemma.

      I often get the feeling from these kinds of posts that they are by and for people who haven’t really learned how to use Ruby, and so are more or less forced to accept what this or that framework provides them.

      1. 1

        Is Ramaze sort of like the ruby equivalent of Pyramid, where you can sort of scala it from being very heavy and opinionated, sort of Rails style, and not at all opinionated and borderline microframework, sinatra style? I think this kind of framework makes a lot of sense because it feels so pluggable, and you basically get magic only on demand. This discussion on ember.js makes a compelling argument for why you might want a lot of magic happening behind the scenes.

        1. 1

          I’m not familiar with Pyramid, but what I like about Ramaze is that I can start off with the barest, simplest program, and if starts getting more complex I don’t need to change frameworks. But since Ramaze does not impose many presumptions on if you start light you stay light.

          You add in what you need as you need it. If you want magic you can add it. If you want to Just Code It you can do that too with little fear that you’re going to break somethng because the underlying framework is assumes you are doing things The One True Way.

          It’s not for everybody. All software is opinionated, and I just prefer more of those opinions be mine.

          The real question is not whether people should be using Ramaze, but why people are always pushed towards either Rails or Sinatra when there are over a dozen Ruby Web frameworks.

          1. 1

            Yes, it sounds similar to Pyramid. I think that people like Rails because it is extremely opinionated, and Sinatra, because it is not, and that attracted people initially. Beyond that, people are unwilling to use frameworks that don’t have good community support, or aren’t well documented. Python has reached a similar situation, where there are dozens of frameworks, but the only ones that seem to have real community support now are flask and Django, although Pyramid is quickly improving. I think that community support is a really big thing for frameworks, especially when you’re learning your first framework, and if you find that rails has 17000 posts tagged on Stack Overflow, whereas Ramaze has 5, it is much easier to learn rails. Many people are unwilling to dig through source code to find documentation.

            1. 1

              “ and Sinatra, because it is not”

              Do you mean not opinionated, or just not extremely opinionated? Because Sinatra is most definitely opinionated.

              When evaluating frameworks people need to ask themselves what opinions/biases/prejudices does this software embody, and does that align with my goals? You can’t avoid it though. (Much like news outlets. All biased, but you don’t notice it when the biases align with your own.)

              “and if you find that rails has 17000 posts tagged on Stack Overflow, whereas Ramaze has 5, it is much easier to learn rails”

              Interesting interpretation. You could also take that to mean that people end up needing to ask for help much more often for Rails than for Ramaze, hence Ramaze is less trouble to learn. Number of SO questions seems to be as useful a metric as the TIOBE index of language popularity (i.e. kind of useless without assorted qualifiers).

              Community support is valuable, but so long as a community is of a minimum size and degree of helpfulness the differences taper off.

              Anecdote: I used to hang out in the ruby IRC channel on freenode, and fairly often someone would pop up with a Rails questions. Inevitably they would be directed to #rails. Just as inevitably the response would be, “I just came from there and no one will answer my question.”

              If you post a question to the Ramaze newsgroup or on #ramaze I bet the odds of getting it answered are the same for Rails or Sinatra. Maybe better.

      2. 1

        Why has this discussion expanded beyond the phrase “Build or buy?”.

        You buy with Rails, you build with Sinatra.