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.
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.
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.
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.
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.
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.
I've decided to never quit those "bells and whistles", other frameworks just aren't good enought in competing with those...
That is why I am optimizing my rails stuff with a few trick made in crystal lang (like the websocket server and a bunch of MTTQ like jobs ;) . For me, until ruby 3x3 gets out, crystal is a good help with scaling up processing.
I do a bit of Node.js stuff at work (not a programmer by trade, just lightweight stuff) but on my side project it's Rails first and foremost. As the sole developer, I need to just get stuff done. Performance isn't a concern at the small scale I work on. I've experimented with other frameworks and besides Django I've never found anything that's end-to-end the way Rails is. I don't have to think about the framework or the technologies, I just write some code and I'm done with it. I don't have to interact with the database directly, ActiveRecord handles it for me. It's pure productivity, which as a solo developer is the most important thing for me.
For some front-end pieces where I need more flexibility, Vue nests in nicely with Rails where it's needed and gets out of the way where it's not needed. There's nothing in the JS world that even begins to compete with Rails as an end-to-end solution.
I wish Rails had a way to use less features. API mode is great, but when I'm writing a GraphQL API for instance, I don't use controllers, I don't use views, I don't really use routing. I do use the excellently integrated ORM, database migrations, auth libraries (mostly devise), config environments, deployment options and CLI interface.
I could just delete the folders, but that's not the point. Rails is sitting on an amazing foundation but there's only one possible house that you can build.
You can opt out of loading the library code for views/mailers/etc. Not sure if there's a way to skip the routing layer though. I'm sure you're aware of that already but just in case, you can skip loading the entire framework.
The only concern I have is that because AR isn't designed as a separate gem, there's no guarantees about breaking changes. But I suppose that's unlikely.
Haven't heard much from Helix since 2017, and it does appear to be inactive since. The limitation to only Strings, Integers, Floats, and Booleans made it pretty hard to use in practice given how Array/Hash/Object-centric Ruby is.
Though the latest Mozilla blog post about Rust FFI using protobufs makes me think rolling the same approach on top of Helix's groundwork with Strings should make it possible to pass around meaningful objects with a bit of overhead.
I use Rutie[0] to handle passing complex ruby objects to Rust and it works well. You can also use Rutie-Serde[1] which handles even more of the heavy lifting for parsing Ruby objects into Rust structs.
Interesting site. At first I thought my browser was somehow set to 250% zoom. So then I zoomed out to 50% but the font sizes are still as big as they were at 100%.
Weird. Apparently they decided to (ab)use CSS viewport units everywhere just to jump on the cool kids bandwagon, completely breaking browser zoom functionality. This is not what viewport units are for. The site is also nearly illegible at 610px browser width because of it.
There're a problem with Pull request in many large OSS.
Sometimes i see many mysterious PRs which says nothing in the description. It seems the author really doesn't want to expose any details of the why and what of the PR itself.
Visitors, devs REALLY want to learn more about Pull requests, they're not just users.
