2013 Rails Rumble Gem Teardown | Hacker News Reader

2013 Rails Rumble Gem Teardown

dwellable.com

22 pointsgurgeous10 comments

I am the author - this is a detailed analysis of the gems used in the 2013 Rails Rumble. It ends up being a snapshot of gem popularity and trends. A lot of surprises in here, at least for me.

The biggest surprise for me is that only 4 of 221 didn't use Rails. I pretty much go to Sinatra by default nowadays and I'd assumed that was more common now than it clearly is.

I think something like a Rumble favors having the kitchen sink. You wanna be 'go go go, install a gem for that don't mess around' and work on your domain code exclusively.

Some people would argue the same for 'real' apps but, I don't like dealing with 140+ gems 2 years later. I think it's the old upfront-productivity-optimization vs. long term maintainability issue many people run into these days.

I find that surprising. After building a few Sinatra apps, I went back to Rails and decided there were not many reasons to use Sinatra anymore. Small, non-public, services are ok. Anything that has users, handles user input or most "web apps" and it's nice to leverage all of the work that has gone into building Rails.

The thing that bothers me about Rails is how much stuff is "on" by default. I like to have enabled every single accessible endpoint in my apps by hand to avoid security issues.

I'd love for there to be a variant of Rails or even just an add-on that made a Rails app totally "mute" and then you had to enable every tiny thing by hand or in a config file so you knew every single vector into the app and what dependencies there were. Rails has had enough security issues for me to be that paranoid, and at least with Sinatra, I have a bit more work to do but I know I've tested every single hole I opened up.

I was surprised to learn that was even allowed! The Rails Rumble allows any Rack-based app, though.

Interesting to see the turbolinks. I have yet to use them, currently migrating a mid-size app to 4 and will try them out. But, that was my experience with jQuery mobile's similar ajax link by default strategy. Their great, until you have any kind of form and then you're soon disabling the ajax part and appreciating a fresh, clean dom being loaded.

Did you just look at the Gemfiles?

Especially things like CoffeeScript get put in the Gemfile by the default generator and there's still a big chance, that no line of CoffeeScript is in the project after all ...

I only had access to the Gemfiles. There's a disclaimer line near the top of the post that tries to caveat the Coffeescript/SASS numbers appropriately.

dominant ERB use surprised me, I would have guessed it much lower. Have people been moving back?

Reply on news.ycombinator.com