Hacker News Reader

Comment by matthewmacleod | Hacker News Reader

Every time - every single time - I have started building an application using Sinatra I have regretted not building it in Rails from the start.

I totally understand the desire for a minimal and clean codebase. If I’m not going to use 80% of Rails, why would include it, right?

But in practice, I have found there is basically zero cost to using Rails instead.

View on HN

I still love Sinatra for back office and API stuff where you don't need to worry quite so much about authentication, exploits, web assets, permission hierarchies/matrices etc.

At the company I used to work for we built our invoicing system's API with it and it was fantastic, plain succinct Ruby with Sinatra, Sequel and not much else.

For public-facing apps that require signup, clever routing, image uploads and other non-trivial functionality, Rails definitely makes more sense.

Exactly.

I think the answer to 90% of these "framework A vs. framework B" discussions comes down to "use the best tool for the job".

For readers interested in a contrary anecdote, every time I've used Sinatra based frameworks, such a Express or Nancy, I've thought without a doubt it was the right choice over something MVC based.

The simplicity of these frameworks allows arbitrary changes with minimal friction, patterns, restrictions, and other people's opinions, i.e. conventions.

> Every time - every single time...

Just thought I'd provide some counter data here. I've built small services in Sinatra, which did not warrant the usage of Rails and never had to change anything, having them in fully functional operation for years.

I could have built these little apps in Rails, but I did not need it, never did, and my code/deployment/etc. is cleaner and smaller because of it.

Also these services have always been quite small (a few endpoints or functions), which is what I think Sinatra is best for.

I second this. I use sintra for all those sites that are 75% static pages and few dynamic parts here are there and could not be happier.

Non optionated means that I can really easily setup the model that I want/need without having any framework in my way. Love it. One caveat: I am a senior engineer 7+ years of experience. I would not have been comfortable having to do those design choices earlier in my career and Rails would have been better suited then.

It’s been a few years since I’ve used Rails, but when I did, it always felt like within a year or two a new version of Rails would come out and I’d basically have to rewrite the site from scratch if I wanted to update.

I don’t know if the codebase has stabilized but the transition between 2.x to 3.x to 4.x was pretty rocky from my recollection. Hopefully it’s better, since Rails is probably the best framework to get a site up and running quickly.

Since v3 I’ve had no issues upgrading apps to the latest. As soon as a new release is available, I upgrade. V2 to v3 was pretty painful though..

Specifically the change in the default to escape strings and having to specify when you want to pass it through unsafely (html_safe / raw). Broke a lot of v2 apps, but ultimately I think it was definitely the right call. Same thing again when strong_params become the default. So mostly due to security improvements.

v2 -> v3 also was the merb merging and a pretty significant rewrite, so it's pretty impressive that we didn't have even more trouble IMO.

I've been using Rails since before 1.0 and the upgrade pain has decreased significantly over time. The worst upgrade I had was 3.0 to 3.1 where there was a performance regression that caused my test suite to go from 15 mins to about 8 hours on ruby 1.8.7, so I had to simultaneously upgrade to 1.9.3 at the same time. That involved YAML parser changes which I didn't catch before corrupting some serialized data in the DB.

Since that time both ruby and rails have stabilized their upgrades significantly. The biggest issue since then was updating to strong params, and that was only an issue for apps with a large CRUD surface area.

These days I think Rails is the perfect balance of stable and flexible for a wide swath of prototypes and apps. The areas where I'd look for an alternative would be web sockets, heavy concurrency (ie. needing more than background workers), or where raw compute is the bottleneck.

If you truly had to rewrite from scratch you did something wrong, the APIs are not vastly different.

I agree, totally true even with some small trivial apps. The few places a Sinatra app have worked for me are highly specialized, single method and generally have been for performance reasons and could have been in any other framework due to them loading as SSI or AJAX call.

Reply on news.ycombinator.com