Sr Rails devs describe Rails as being the easiest and most productive way to build web apps. Meanwhile @joemasilotti@excid3 & others discuss how we’re losing a generation of Jr Rails devs because its daunting.
Can both be true?
Here’s my story on how Rails is losing Jrs.
📖👇
But first, this is NOT a list of complaints—it’s meant to open the eyes of Sr devs to the idea that Rails has strayed from its promise of “convention over configuration” and how other frameworks have caught up to Rails over the past decade.
✌️
Let’s get do it!
🧸 Assets: a tale of a menu that got too big
Do you use importmaps? js-bunding? css-bunlding? js-bundling *and* css-bundling? What if you need to switch from importmaps to js-bundling? What’s sprockets and propshaft?
There was a time when Rails had one asset pipeline: Sprockets
Sprockets had its issues, but one great thing about those times is we only had to learn one thing and wrestle with it to get it working.
I wrote about how to navigate the complexity of assets, but it’s still not enough for people new to Rails.
You have to be “in the know” to find the docs at github.com/rails/importma…, which is something a person new to Rails won’t know.
Finally, there was a time when a Rails gem plugin could be installed and assets would Just Work™. Today that’s no longer true since a plugin might work with Sprockets, but not jsbundling or importmaps.
hotwired.dev doesn’t mention Rails. It’s trying to be framework agnostic, but could somebody please point me to a non-Rails framework that’s using Hotwired?
Its easy to see how a Jr might be confused by this and think they’re at the wrong place.
Even secondary pages like turbo.hotwired.dev don’t mention Rails. Only when I’m 3 levels deep at turbo.hotwired.dev/handbook/intro… do I see Rails, but all the examples are generic and don’t use Rails helpers.
Want to build a realtime web application in Rails? Deploying it to production is actually quite difficult. You’d have to know that Sidekiq is de facto background worker framework and AnyCable is the way to deploy WS.
There’s a point in your journey as a Rails dev where you have the epiphany that most production Rails applications use Redis for caching, WebSockets, and Background workers.
Calling it “Rails on Redis” wouldn’t be too far off, and its just as important as the DB.
I could keep going, but I think you get the idea that there’s a lot of stuff Sr devs take for granted that represents a learning curve for Jrs.
What can we do about it? 🤔
The obvious is “mentor a Jr” and I don’t like Tweeting about obvious stuff, so here’s some other ideas…
🫣 Look at other frameworks
Rails was a breath of fresh air when it was introduce, but most languages have caught up to Rails.
Look at them and steal all their good ideas, esp the docs & dev UX.
🧸 Steer Rails back towards convention over configuration
If you maintain OSS projects, do your best to steer your project and the Rails community back towards conventions.
The more we standardize on how parts of Rails works, the bigger & better plugin ecosystem we’ll enjoy.
📕 Improve documentation
There’s lots of examples above for how documentation could be improved both in the core Rails docs and Hotwire docs.
The docs are ideally direct, opinionated, & tell devs “the one way” to do a thing instead of giving them a bunch of choices to navigate.
💡 Make the Dev UX more helpful
When a Rails project is booted up, here’s what people see: a “Rails” hood ornament with no indication of what to do next.
Compare that with Phoenix, which points people towards documentation and community.
Lots of potential here!
👯♀️ Mentor a Jr
I said I wouldn’t say mentor a Jr, but it does help! If you do take on mentorship, it will be helpful for learning from them what parts of Rails are difficult to navigate both within the stack and within the docs.
To sum it up, Rails was ahead of its time when it shipped 10+ years ago.
Today we take it for granted because we know it so well and maybe haven’t closely followed other frameworks.
They’ve caught up, and its worth watching if we want to keep the Jr’s flowing into Rails.
✌️
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Here's what I've been working on—it's called Terminalwire.
It's a new way to build command-line interfaces for web apps that doesn't require an API, which dramatically reduces the complexity of shipping a CLI.
DMs are open if you're an org wanting to simplify CLI development.
Terminalwire will work with all major web frameworks, but I'm currently building it for @rails first because of the communities obsession with "compressing the complexity of modern web apps."
@rails I'm building Terminalwire differently this time—instead of kicking it off with a self-service product, I want to work with orgs that want to ship a CLI or dramatically simplify their CLI development process.
DMs or brad@terminalwire.com are open if that's you.
The form object tracks which fields you’ve used, creates a permitted params hash, signs it, and stuffs it into a hidden `permitted_params` input field.
When the form is submitted, Rails verifies the params and stuffs them into `params.permit`
Here we go... the VC world talking about “surving hard times” with advice given in lots of words that can be summed up as “be prudent with your money”
I went through YC in S08, known unofficially as “the worst YC class”. It’s when the “RIP good times” Sequoia deck went out.👇
What did we do with our company? We started to raise a small round, but half way through sent everybody their checks back because the amount of revenue we brought in from our customers that year was roughly equal. I called this Customer Capital funding.
The way we funded our work was by keeping an internal product backlog and putting a phone number on our website. If a customer called wanting something aligned with our backlog, we’d give them a quote, collect their money, and build it for them. It’s not rocket science.