If you haven't read "The Shocking Immaturity of JavaScript", please scroll to the bottom first.
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.
How Do We Fix This?
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.
Wrong. You can hop the fence over to other programming languages, frameworks, and ecosystems, and discover that the tooling there is far more stable and usable over the long haul. I don't wish to turn this into a pitch for JavaScript, but let's just say in my many years of extensive engagement with the MERN stack and related projects, I've never encountered the sheer volume of bugs, incompatibility, redundancy, and limitations which I encounter on a regular basis in Ruby land. And it's not just me…I'm in chat rooms and Twitter threads all the time where other folks are losing their minds over the constant craziness. All we can do is shake our heads and go take a walk or something to relieve the pressure.
So how do we fix this? Here's one suggestion:
Start Telling the Truth
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.
Feel the Users' Pain
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?
Conclusion
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. 😜
What the **** did I just read?
This is a parody of this ridiculous article. I'm assuming any Ruby devs reading will think this article made no sense at all, that it was simply bashing the language with falsifications, that it was totally incoherent and made a ridiculous attempt to demonize Ruby projects. My point? None of the issues presented by the OP reveal any depth of knowledge regarding JavaScript. I have never used Ruby for a full-fledged project, just as the author of the original article clearly hasn't used JavaScript for more than a few months. Most of the build tools he mentioned are trivially easy to get set up with, and he refused to provide examples of bugs that made his life difficult. From personal experience, I was able to set up a mid-size project from scratch (without any boilerplate, taking a bootcamp course, etc.) after around 3 months using the language. So in the same way that the OP made no concrete argument, this article is 90% complaining and 10% explaining why it's complaining, and 0% giving examples of where the complaints are justified.
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 var). Still others, as in the case of this author, actually have used modern JavaScript, but they haven't invested effort into learning the design decisions behind their dependencies and instead blame their failures on bugs (of their own creation), bad standards (that don't exist), and an uncaring community (that is actually quite supportive).
I don't mean to start a war between JS and Ruby developers. I think both languages have separate use cases. For instance, from the little experience I have with Rails, it seems to offer much more structure than any Node.js project would have while remaining mostly configurable and extensible, so those who prefer batteries-included frameworks would probably use RoR over any backend JS library. The use of Ruby as both the runtime and the installables in Homebrew is a great example of one of its most powerful use cases: modular scripting. On the other hand, the inability to use anything but JavaScript in the frontend isn't terrible, since a language that abstracts away differences in processor architecture is absolutely necessary (though admittedly, a universal bytecode such as compiled Java or WebAssembly would have worked fine as well). Modern JS tools aren't awful; in fact, they can be a joy to work with. The monthly craze for a new framework has subsided, so it's possible to learn a single UI framework (React, Angular, or Vue are the most popular) along with a bit of ES6 to be a full-fledged frontend engineer.
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.
Top comments (0)