This is going to come across as a rant, so I'll do my best to refrain from blaming any one project or source and just make a generalized statement.
The ecosystem of Ruby frameworks is almost unbelievably unusable. Yes, even now in the year 2021.
From the restrictive structure of Rails to the inane syntax, ridiculous operator overloads, and hundreds of gems—it's a miracle anyone can actually understand what they're writing!
Some weeks I spend literally hours debugging and researching all kinds of weird, arcane bugs or conceptual hurdles related to performance, memory usage, unmaintained gems, full-stack architectural gotchas, and the list goes on and on and on. And it's not just me. I'm on a team that is in a constant mode of struggle and churn due to dealing with largely obvious issues related to the most popular tools for Ruby, and as a result we're constantly forced to switch just about everything besides Rails.
Now the reason this really grinds my gears isn't just related to my particular project. In a purely cynical sense, what do I care? I'm getting paid the same whether I'm writing code or trying to read it.
The thing that bothers me is how awful of an experience this is for people with far less experience than me. I've been in this industry for over 20 years. However, other people are attempting to get into Ruby this year. And they're being told in order to do so they have to learn Rails, then X, Y, and Z tools…all Ruby of course. The problem is if they run into major issues—and they do, believe me, they do—they don't know enough to grasp just how buggy and redundant the tooling is. Instead, they think they must have just made a mistake, or simply haven't learned enough yet. The cognitive load required is staggering.
Or perhaps they haven't run into too many issues yet. (Lucky!) That's possible, because the vast majority of tutorials and examples out there for the top Ruby frameworks are laughably simplistic. If I see yet another example of how to serve a JSON API with data from a MySQL database to dynamically render a login page using a development stack with a crutch on You-Know-What.rb, I'm going to rip my hair out of my skull. This isn't where any real-world applications of any reasonable size get tripped up. The devil is always in the details. The problems typically arise well beyond the scope of clickbait-y "Build THIS in 10 minutes" articles.
The path to correcting any sort of systemic problem is to first acknowledge it and then to define its scope with honest and sober reflection.
We all need to start being forthcoming about just how shockingly buggy and redundant most of the Ruby tooling is across the board. Compared to what, you might ask? Maybe this is just an artifact of backend development, period. It's the nature of the beast.
So how do we fix this? Here's one suggestion:
Get off the off-the-charts hype machine, stat. Enough with hyperbolic statements like "this is the tried-and-true way to build scalable architecture" or "this gives you the best developer experience with all the features you need for production" or "write high quality, tightly coupled, scalable, maintainable applications the most productive way". (These are all real quotes, BTW.) The constant marketing is not only exhausting, it also feeds newbies a bunch of malarkey.
Start by being honest about what doesn't work as much as what does work. Warn people about building battle-hardened, production-level code on top of your buggy and incomplete foundations. Steer people towards other, better solutions—even other languages and frameworks—if you know your tool-du-jour isn't quite up to snuff yet. Slow down your progress on shiny new features and fix the features you've already shipped.
Label releases and techniques properly. It's perfectly serviceable to add new features to an existing library, or to say a particular technique is probably only suitable for the stout-hearted with time to kill. Also, stop with the "novice-style code" shaming. The world isn't going to end if you write something in a manner that's cutting edge, rather than the "tried-and-true" according to some old-school blog. We snicker at one person's Express stack or another person's MongoDB to fix the fire extinguisher and meanwhile the house is on fire.
This all mainly boils down to something we learn in the world of UX (User Experience) design—you have to feel the pain your users go through when they use your software. In the case of developer tools, developers are the users! That's why the term DX (Developer Experience) gets thrown around a lot now. The thing is, good DX isn't just some whiz-bang ooo, that's cool reaction to a new blog post. It's "how well will this work for me and my team over the next several years??!" In that sense, the DX of the Ruby ecosystem has a lot to answer for. Sometimes you even see it in GitHub issue and PR comments: fake enthusiasm and dismissal of genuine problems people are having in the real world. "Use something else" is never the correct response to DX issues.
Again, I come from the world of JS—not perfect by any means. But we have a community that tends to be nice and loves to help out our fellow developers, particularly the newbies. That doesn't just mean in terms of sharing ideas or providing education. It means the tools we build should themselves be pretty nice! Crappy code smell and lousy DX often gets called out in the JS community because we've been handed a high bar. Name your variables well. Reduce boilerplate. Use a small surface area for your API whenever possible. Cultivate well-organized codebases. Convention over configuration. Maximize programmer happiness. And so on and so forth.
The result of all this is I sometimes look at the bugs or issues with I deal with when using Ruby tooling and my initial reaction is: this would never fly in JS. Developers would simply laugh and quickly move on to a better tool. I'm not saying this to prop up JS. I'm saying this to convince you that you need to demand more of your Ruby tools.
Demand more stability.
Demand more clarity.
Demand more honesty and less marketing fluff.
Demand higher standards. (Heck, demand standards at all! The ecosystem churn around minimizing the number of dependencies is driving even the most prolific library authors absolutely nuts!)
Stop putting up with the nonsense. The excuses have run out. How long have we had Rails? How long have PostgreSQL and Mongo been with us? How long have we had other, more stable ecosystems to be inspired by?
You might conclude, after such a rant, that I hate Ruby and just want to leave. Actually, I don't! 😅 There are Ruby projects I love which offer great APIs in my opinion. Rubocop for example is one of the best developer tools I've ever used in any language. Parallelized tests and better database integration in Rails 6 are wildly exciting. I've actually written a Ruby gem and found the experience enjoyable. In fact, unlike some fellow JS devs I know, I rather like having an opinionated framework for developing a backend. (Now who's the crazy one?!) i18n_tasks is a nifty internationalization project I benefit from every day. The
jwt gem is the bees' knees.
So I don't hate Ruby. I don't hate backend engineering, and I don't hate Rails. What I hate is developer tools with awful DX due to hacks upon hacks upon endless modules of widely-varying quality as a result of constant churn in "reliability" and what's compatible with what, where, when. I simply no longer have the patience to deal.
Thus I'm begging you—imploring you—if you build or maintain any tool in the Ruby ecosystem, pause for a moment and consider how you can reorient yourself around upping the long-term quality level of the tools you produce. And if you are a newbie, DEMAND your tools give you the quality you deserve. And if you do work on a tool that's actually pretty maintained, fun to work with, and hasn't tried to take over the world with ridiculous claims—kudos to you! You're breathing rarified air. 😜
Welcome to the experience of JS developers, ridiculed on a daily basis for no reason. Most of the people complaining about JS don't use it. Most simply parrot what they've heard from devs who used the language during pre-ES6 times but quit before ES6 was stable. Some new or novice developers spend a few days reading tutorials from old blogs and ancient bootcamps, then believe that you simply must deal with the thousands of mindbending issues with ES3 (e.g. the function scoping of
Let's all try to bash languages we don't like less. It might be nice to stop calling hardworking developers gaslighters with Stockholm syndrome, suckers who are stuck with "bad" frameworks and tools. Then maybe we should stop intentionally misinterpreting their arguments and give healthy discourse a chance. I hope that JS will someday be given the respect that so many other languages receive, that the elitism within programming circles (with regards to language, framework, experience, etc.) be eliminated, and that programmers for every language can come to a happy resolution.