I view Devise, CanCan and SimpleForm as unnecessary gems these days. Rails has better facilities for all the things those three gems provide. If you take a little time to create your own login or auth system you'll be much better off than inheriting the bloat that gems like CanCan and Devise add to your code base.
I could flip a coin on whether SimpleForm is still useful or not. I tend to find myself fighting with its method signatures so I don't really like it.
All in all, Rails has grown since these gems were created. Use the new facilities that Rails provides as well as some OO design to solve problems. It's much better than including fat gems like the three I mention above into your code base.
So you're better off rolling your own auth gem vs utilizing a popular gem that's been baked in thousands of production environments?
I agree that Devise is heavy and hard to extend but when we're considering such a fundamental like auth, you have to have a pretty good reason to deviate from the time tested popular choices.
Maybe you can write a lighter auth class, but can you write a more secure auth class? If devise has a vulnerability, there are tons of other sites out there "watching your back" and could report the vulnerability. If you roll your own, how are you going to aggressively audit its security?
About 10 years ago, I remember a guy that interviewed that bragged that he wrote his own linked list class instead of using the one the STL used.
I was amazed and impressed at the time. Now that same statement would totally set off red flags and he'd be a non-hire (unless I could personally audit the code).
Maybe he provided more syntactic sugar so his implementation was easier to work with? And if that's the case, why not just build on top of the standard implementation? But if he claimed a performance increase, is that for the general case or for some specific case he was coding for?
Deviating from the standard library is a bold claim that has to be backed up by a code audit.
I think you're overstating the security value that Devise gives you. It's hardly more than Rails gives you out of the box. After all, Devise is for Rails and written in Ruby.
I guess I view Rails as a tool with which to get things done, and usually rolling my own login or auth system is not within scope of the work I want to get done. I'd rather just use something off the shelf and proceed with the itch I want to scratch. You also get the benefit of lots of eyes on that part of your code base, which means bugs get found and fixed more quickly.
My experience: it's incredibly easier to NOT use devise. I've wasted so much time reading and hacking devise source code, while the result is slower and more vulnerable than rolling my own. It does a simple job, but there are too much code to make it compatible with many rubies and operating systems and older versions of rails that I will never use.
Rather than completely rolling my own, I like to use Sorcery[1] for authorization now. It concentrates on providing the bare minimum that every app absolutely needs, making it much easier to build on top of than Devise, where you're constantly searching around their codebase trying to figure out what they provide and how to override it.
I still don't get why people use these form helper gems. In every single project I've worked on that used them, we've spent more time fighting them in complex cases than we saved in potentially repetitive simple cases.
I still don't get why people use these form helper gems.
We recently rewrote the views for one of our Rails apps and we used SimpleForm with its Bootstrap wrappers. We compared some of the new form views to the old views, and the new views had around 80% less code.
we've spent more time fighting them in complex cases
A form builder need not be used for every form. Most of our forms use SimpleForm, but not all of them do.
Anyone interested in learning more about Devise [1], Breakman [2], Simple Form [3], or Sidekiq [4], should check out RailsCasts [5]. Ryan Bates, who runs RailsCasts, has screencast episodes on all of these. With 400+ episodes, if you have an idea, he has most likely done a tutorial that will walk you through the implementation, this is invaluable for everyone from newbie to experienced, in that it will likely save you lots of time.
ps. Using Michael Hartl's Ruby on Rails Tutorial [6], and Ryan Bates's RailsCasts, I was able to go from zero knowledge about rails, to implementing CRUD apps [7] in a couple weeks. As a side note, I things these two resources show the power of internet/distance learning.
I echo some of the sentiment that some of these gems provide, but they are quite helpful in getting a quick project up and running in a few minutes to start playing around.
Some of my favorites:
figaro[1]
Alternative to dotenv, awesome mascot.
rack-mini-profiler[2]
Often folks will say to save performance tuning until the end. I find having this around from the get go makes it much easier to do as you move along.
I love sidekiq though. Probably the best on the list. Background queues are essential to most, if not all Rails applications. The goworker post from today looks interesting too.
I was looking for a dotenv alternative for the shell (fish preferably) but I couldn't find any so I wrote my own [1]. Does anyone know any alternatives?
I've grown to like Authority more than Cancan. It does 'less' magic but it's way more declarative and allows you to be really explicit on what you want to check.
Interesting to see backup mentioned. I've used it in the past, but kind of forgot about it. It's super useful. The documentation tells you to not put it into Gemfile, but it seems like you really should. Do you?
I really liked Pete's book - to the point, and let me get going quickly.
I think it can be hard to accurately judge the value of something as focused as a book that is so specifically targeted.
In particular, I feel like the book gets you to a complete end to end Rails+Stripe.js system much much faster than I could have cobbling everything together myself.
If you'd like, you can email me any specific problems you had with it and I'll see what I can do about making future versions better. pete@bugsplat.info
I could flip a coin on whether SimpleForm is still useful or not. I tend to find myself fighting with its method signatures so I don't really like it.
All in all, Rails has grown since these gems were created. Use the new facilities that Rails provides as well as some OO design to solve problems. It's much better than including fat gems like the three I mention above into your code base.