Hacker News Reader

I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails.

Each person has a preference on where they thought something should be. Days were spent arguing over the location of mundane things. Each team member had a different understanding of REST, so without the rails routing we argued about what we thought an ideal API would look like. We argued about which view engine we should introduce. We argued about how to handle our JS/CS. We argued some more about routes and how to make them more discoverable. On and on. Not intentional, but something new would come up and we would need to figure out where to put it.

This, more than anything, hammered home for me the strength of rails. Rails is great at getting you up and running, but it's greatest strength is that it's idioms are well documented. That gives developers a strong impression of how things are going to be and where things go. This saves you so much time by not having to argue and reach consensus on every little thing.

My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it...

However, Rails is just too fng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing imperative programming which sucks. Programmers want to actually know and control what they are doing.

I once dealt with a legacy Rails app that had really complex Models. ("Fat models, thin controllers") Of course the original designers hadn't thought about every corner case, and of course not thought about what AR is actually able to deal with seriously. The app was just slow and not maintainable.

But to say something good about Rails: creating standard web pages with it is a peace of cake. All standard tasks are automatized.

Great when building but it sucks when debugging and maintaining.

The more abstraction you shove down the programmer's throat, the less he will understand what's really going on behind the scenes. Eventually the abstractions become more of an impediment than a panacea, e.g. when you try to do simple things. And we also end up with the creation of "leaky abstractions", since programmers who create them have developed a love for abstraction (what might contribute to that?) but little understanding of the lower levels.

There was a recent post on HN regarding /usr/local that seemed to suggest some programmers do not understand what a partition is nor should they need to become acquainted with such unimportant details. I hope I'm wrong in that interpretation. Because if true, that is just sad.

Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app? Legacy is where conventions actually shine!

I agree that the total lack of structure in Sinatra can be harmful at times, but don't blame a technology for your team problems.

That's just the bad workman blaming his tools for the faults of the toolbags he works with.

Blaming the tools is completely reasonable if your problems can be solved by better or more appropriate tools. If I need to drill a hole precisely and accurately and the team or management has standardized on hand drills, it's entirely appropriate to bemoan the use of hand drills versus a proper drill press with an appropriate jig.

Oh you guys/gals and your programmer to carpenter analogies :)

Padrino (www.padrinorb.com) is a sinatra-based 'rails without the bloat' framework.

It provides generators, basic helpers (link_to etc.) and, most importantly, it gives project a sane structure. Oh, and it does not tie you to any fixed set of components. Using Padrino and Sequel is a bliss!

But your app remains a sinatra app, small and elegant. Also, the documentation is excellent.

yeah what can be wrong about a framework imposing design & coding discipline on sheeple :P

"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs.

Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go?

You don't need all the ceremony and structure of Sinatra to write a JSON API, you just don't.

Sinatra has a lot less boilerplate than the typical Rack app.

Because it has a lot more "ceremony and structure". Sinatra is a Rack app. It hides the raw boilerplate from you just like Rails hides a lot of the boilerplate you end up putting into a Sinatra app of any significant size.

There's a continuum of "more manual work" <----> "more framework", and there's no one right answer, even for something like a JSON API.

Rails is a Rack app too. While I agree there are diminishing returns the lower in the stack you go, your original reduction is misleading.

The choice between Sinatra and Rails can reasonably be debated, but there's little reason to write a JSON API in Rack unless you need control of protocol details that neither abstraction provides. Sinatra/Rails are frameworks, Rack is middleware.

You're absolutely right, you don't need Sinatra to write a JSON API either. The more ruby devs that realize this the better. Really, just people getting out of the mindset that Rails is the be all end all of ruby is all I'm going for.

You cannot really compare Sinatra with Rails. Rails has scaffolding, DB migrations and all this ultra-highlevel stuff rendering debugging to pure guess-work. Reminds me of doing template-metaprogramming with C++. If it works it's great and the performance rocks, if not you are left alone with cryptic errors and nobody can help you.

If you want Sinatra with scaffolding there is Padrino which I personally find to have superior scaffolding compared to rails.

Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd.

One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.

And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.

So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.

Unless I vastly misunderstand your statement, it's nowhere nearly that hairy.

https://gist.github.com/3719513

Did I miss something?

Rack is "env variable goes in, array of [code, headers, body] comes out, here are some handy utils for handling grunt work". That's it. That's Rack. You can do whatever you please with it in the middle. That's all that a middleware is, and Rails itself is basically just a collection of Rack middlewares (procs) with some support libraries stapled on. That's a gross simplification, but at the end of the day, that's basically the heart and soul of the framework.

My point is that there are multiple levels of abstraction. Of course you don't have to re-write and re-implement boilerplate when you use Sinatra over Rack, just like you don't have to re-write and re-implement when you use Rails over Sinatra. "Rails bad, Sinatra good" is just silly, because it all boils down to what kind of tradeoff you're willing to make between what's done in framework versus what's done in your application.

I get what you are saying, but I feel reducto ad absurdum is unfair here. I understood the parent's point as this; using Sinatra to give yourself the convenience of the {get,post,...} methods for working with HTTP vs. Rails, which forces upon you its more opinionated structure for websites.

I agree with the parent, that I have no use for the complexity of Rails and Sinatra is convenient. Other people are free to choose as they wish, and Rails might be the more appropriate library is some cases regardless of preference (like in the sibling post about teams).

But there's a ton of utility on the spectrum from Rack to Rails and it's perfectly reasonable to choose a midpoint, and perfectly reasonable to choose it because you think Rails is too much but Rack is not enough.

I absolutely agree with you. What sticks in my craw is the oft-repeated mantra that "Rails is too heavy" or the perception that Sinatra is doing something that Rails isn't.

When you look at Rails as a collection of middlewares (which you can choose!) and support libraries (require 'rails/all' may not be needed!), instead of looking it as a monolithic black box that can't be configured to fit your needs, it's suddenly a lot less "heavy" and a lot more "wow, okay, buffet-style app composition sort of rocks". People seem to have this idea that Rails is on the far end of the "magical and heavy" spectrum, when it can be just about anywhere along the spectrum that you want it to be, based on your selection of middlewares and libraries to use.

I have production apps that range from small one-off Rack apps (my dynamic asset server, for example) to Sinatra to full-blown Rails, and they're all very similar beasts. Rails isn't some mystical black box, and Rack isn't just some RFC somewhere, and I think it does a grave disservice to both to marginalize them.

I guess I got the wrong impression from your argument. It all depends on what you are trying to accomplish, as you say.

The reducto ad absurdum was a poor choice, and likely obscured the point, so my fault. :)

FTA: https://gist.github.com/1942658

Why wouldn't you just do a 50-line Rails app instead, and slot in any other Rails niceties when you feel like you need them?

Agreed, when you want to build an API use Sinatra, and when you want to do web MVC there is Padrino which turns Sinatra into a very competent MVC framework.

I really enjoy Sinatra and am indeed using it for REST style API hosting, but the counter argument might be all the security stuff that is built into the Rails routes/controllers. this might be a great case for a stripped down rails app as opposed to a Sinatra app.

I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?

Escaping everything by default to avoid XSS attacks. that's a nice feature to have.

This can be done in Sinatra: http://www.sinatrarb.com/faq.html#auto_escape_html

I've used Padrino for a couple of projects now, but unfortunately it slips into "Uncanny Valley Rails" territory (particularly when it comes to the rake tasks you expect to have but turn out to be missing, eg. db:test:prepare).

Cheez, the reason to not use Sinatra for me is that I'd have to implement all the security measures myself. Sure for a hobby project or a really simple project it might be OK. I guess it all depends on what budget you have for spending time re-implementing all the plumbing.

https://github.com/spastorino/rails-api

Problem solved.