4 ms·

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 surp

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.

petercooper 13y ago
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.
- gurgeous 13y ago
  I was surprised to learn that was even allowed! The Rails Rumble allows any Rack-based app, though.
- mountaineer 13y ago
  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.
  - petercooper 13y ago
    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.
- bemurphy 13y ago
  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 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.

petercooper 13y ago

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.

gurgeous 13y ago
I was surprised to learn that was even allowed! The Rails Rumble allows any Rack-based app, though.
mountaineer 13y ago
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.
- petercooper 13y ago
  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.
bemurphy 13y ago
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.