Hacker News Reader

Comment by stevenpetryk | Hacker News Reader

I still see Rails as perhaps one of the best frameworks to start a new generic web project in. The out-of-the-box functionality is just so perfectly tuned, and the fact that they're focusing on features that appeal to larger applications just shows how Rails has helped companies grow.

View on HN

Any Reason why Rails still does not include an any decent Auth by default?

Edit: I remembering keep asking this question but obviously no answer was satisfactory enough that stick to my brain.

has_secure_password is built in, and works as long as you include the bcrypt gem in your Gemfile. I've never found Devise or any other 'off the shelf' solution to be satisfying for me because authentication seems to vary just enough between projects to make it easier to use has_secure_password and rewrite auth from scratch.

Personally, I think it would be cool if someone built an user account/authentication experience as a generator (along the lines of Rails scaffolds), so that you could see all of the generated code and modify it without having to get elbow-deep into the bowels of what I find to be an overly-abstract gem.

That's been my experience with Devise and similar libraries for other frameworks and languages. If it fulfills all needs for a project, that's great, but I tend to find that it's simpler just to build authentication around authentication "primitives" like has_secure_password. The thing I do like about Devise is that it has views for everything including password reset out of the box. The abstractions it provides end up being more of a headache than they are worth.

To be honest, I'd rather see more gems for these sorts of purposes that are just a collection of off-the-shelf views that can be easily tied in to one's authentication solution of choice. By installing Devise, you bring all of the extra non-view baggage it comes with into the application's memory space even if you don't use it. Yuck. (no offense!)

Actually, I just reread your comment and I think your scaffold/generator approach is also a nice way to go. It's just too bad that there hasn't been as much development effort towards these sorts of things recently in the Ruby community. I'd build it, but have gotten away from Ruby because the community is obsessed with applying object-orientation to every problem, over-abstracting, metaprogramming, etc.

Because every application doesn't need it and it's virtually effortless to add Devise, which is the defacto standard at this point.

I think the defacto standard is devise but they want you to be flexible enough to roll your own or whatever serves you. I would like to have it built in though.

I'm not familiar with recent versions of Rails or its authentication situation, but whenever I hear this said about some mandatory functionality of a system, it sounds to me exactly like "We haven't yet figured out how to do ___ well".

It reminds me of the old days when I'd get a library which would say "We want to be flexible, so just pass in any memory allocation function here!", or Linux distros that said "We want to be flexible, so just write any boot script here!" Then a year later, some competitor ships with a default, and everybody switches over to that because it's obviously better (and you can always customize it if you need to).

Especially so with Rails, whose entire existence seems to be picking good-enough defaults.

This sounds about right. And if you want something in between without rolling your own, Sorcery is excellent.

https://github.com/Sorcery/sorcery

Looks interesting, thanks

There are many ways to do auth. Some Rails auth gems are more prescriptive than others. All of them involve large tradeoffs in various directions. It would be weird to bless just one of them as the "right" way to do auth in Rails, imo.

Have you tried Devise? It’s not default but it’s one of the best Auth tools I’ve seen in any stack. I love it and use it in tons of apps.

> Any Reason why Rails still does not include an any decent Auth by default?

If memory serves, Rails has quite good authentication built in by default.

If that's not what you meant, could you clarify?

Yea it's really sad that at the hackathons I've been to you can hardly find one other rails developer. With rails you can build things fast and spend more time focusing on building cool unique features. But I go to hackathons and I can't collaborate with anyone using Rails or Ember.

Also google cloud has a ton of awesome integrations for ruby and rails so you can build lots of fancy features quickly as well.

The rails community needs to do more outreach to universities and students.

Ten years ago, you'd find plenty of people using Rails at hackathons—back when it was the new hotness. Maybe hackathons tend attract people who are interested in building stuff with 'cool' technologies as opposed to building cool stuff.

and possibly just 'younger' folks who've only ever known or worked with whatever came out in the last 1-3 years?

the older people get, the less time and interest they're going to have in spending a long weekend with random people trying to work on something collaboratively.

i've done a few - my team (of 3) came in second place (against a team of 16!) with around 20 teams in total. Good feeling, but nothing ever came of it - protip, learn if your team members are actually at liberty to work on the project after that weekend. Mine were both barred from pursuing the project in any meaningful way (work visa for non-citizen, and non-compete with existing employer for the other).

Did a followup hackathon later - all teams seemed to self-organize before the event, which wasn't promoted/explained beforehand (but apparently about 80% of the people 'knew' already). Left with working with random people who didn't understand the idea that '48 hours' mean 'consecutive' hours. Two hours into the project, my one partner said "hey, i gotta leave to pick up my kids - i'll be back tomorrow around noon for a few hours"... and then left.

That was also my first taste of 'sponsored' hackathon - you had to use one of 4 sponsor-supplied APIs to qualify for anything.

I've been a mentor at a hackathon a few months ago. 90% of the participants were on their twenties. The chances they know Rails are lower than for the same demographic ten years ago.

Interesting. What server side tech stacks are often used by young developers in the recent hackathon? Are there a few dominant ones or many choices?

I'll second that question. I figured Rails would still be pretty popular, and now I'm wondering to what degree that is or isn't true these days.

My guess would be React/Angular or, if it's a particularly hip group, Next.js/Nuxt.js/Serverless with as little back-end as possible.

In my experience Angular is out and React is in with some vue people around as well.

For backend, graphql is in, expressjs is still in, firebase is in, flask and django are in.

Ruby on rails is unfortunately out among my peers: https://devpost.com/software/built-with/ruby-on-rails

Not a bad idea to do a blog post analyzing devpost trends, I might do that after exams.

React, vue, firebase, express, flask and django at mine.

We've had so many generations of Web frameworks, but presumably it's still not a solved problem, because we keep moving to new ones.

Of course, sometimes the latest thing has a useful mix of properties that is worth the move. Though many hottest ones turn out to be popular only for a year or so, and then people lose interest.

I wonder how much a factor in the churn is the individual engineer desire to have the newest framework keywords on our resume, even when we can tell it's mostly a gratuitous rehash, because a lot of hiring is for keywords.

Or maybe more often we're looking for the new tools to provide additional advantage for projects (not resumes), but it's difficult to assess the holistic net payout until we've invested heavily in it for a year, whereupon we repeat with the next tools that seem to promise advantage.

I'm all about trying new tools all the time, especially as little side/toy projects, but it's odd that we are often betting important projects on less-proven new tools, when you'd think by now we'd have figured out and proven tools that would be hard to beat. (And I say this as a fan of certain tools that aren't proven enough, but which I wish a few startups would use for getting to demo/launch, so I can humbly see one way this happens.)

If the average tenure at a company is less than two years, then why not bet your project on the new, hot technology? You get to put it on your resume, excite potential future colleagues with your buzzword compliance, and never have to worry about maintaining a project long term.

Good point. The current short-timer employee conventions (as well as startups that can just be serial-entrepreneur'd if they fizzle) might remove some of the traditional incentives to use proven methods (to manage near-term risk, and to build for long-term maintainability/growth).

> We've had so many generations of Web frameworks, but presumably it's still not a solved problem, because we keep moving to new ones

I do not think that it is not a solved problem. I think, in most cases, there is a propensity to wanting to believe it is not a solved problem, because building things from nothing is a lot of fun.

The cool thing about being a software engineer is that you can go back as far as 0 and 1 with comparably reasonable effort and tools that are at your disposal, for free. You get to build anything you want, exactly as you want. Of course mostly it will not go back as far as machine code, but hey look, there is a new js front-end framework.

And sure, in parts this is all part of the learning experience. But I the amount of productivity that has been lost and will be lost due to the technology being reinvented (or shall I say: rediscovered), has to be absolutely mind boggling.

We all like to play, but engineers are pretty fucking expensive and the number of web applications that could absolutely not have been build in good old Rails or PHP by people who know their tools inside out is probably approaching the low zeros.

Agreed that more hackathon participants should know Rails. Although I will say that 50% of hackathon backends are unnecessary as nobody will check if you're actually persisting data/doing user accounts. And the other 49% would be perfectly fine with Firebase. But for those 1% cases where you need a CRUD API stat, Rails is absolutely unbeatable.

100% agree, at hackathons I start off by telling my team that the backend doesn't really matter we should just focus on a good interactive demo at the end (which is usually met with major eye-rolls).

The only thing is that with Rails you can build the backend so fast and simply that it can be better to just use Rails if your team knows Rails.

But my new thing is onboarding teammates who know React or Vue into Ember quickly then using Emberfire to build SPAs fast. Then we use cloud functions and firebase to take care of everything else.

Eh. Rails is fine, and lots of other things are fine too.

Rails is amazing on day 1, even week 1 of a new project, vs piecing together your favorite separate smaller libraries into a web framework. That can be just what you need for a side project that you want to get up and running fast. But if you’re planning to build a business around it and work on this codebase for years, it’s crazy to optimize for day 1. (Not saying rails is necessarily a bad choice in the long haul, just that you should be picking it for better reasons than being easy to get up and running).

There is an argument that you should absolutely be optimising for day 1. One of your biggest advantages as a startup is agility. Until you've hit upon product/market fit, you want to choose tools that enable you to iterate fast.

I'm talking about literally day 1, not just like the first phase of the company. If a startup is exactly a single day (or single week) ahead of the competition such that the productivity on that day is make or break, that goes way beyond agility and is probably just not a very good opportunity.

Reply on news.ycombinator.com