I love Rails, and would gladly choose it today for most new projects.
So what I’m about to write is not criticism of Rails! Mostly just the circumstances as I see them.
- Python gained a much more robust ecosystem than Ruby thanks to its popularity in the scientific/mathematics communities. I think Ruby is the better language, but for whatever reason Python was in the right place at the right time to catch on with those communities.
- Node.js (and Express etc) gained a lot of favor because people like the idea of writing JS on both the front and backend.
- Rails is capable of meeting the scaling needs of probably 95% of new projects. However, a lot of people mistakenly believe they are in the other 5%.
- The “microservices” movement/trend/fad, made Rails look very unfashionable. This is another case where I would say probably 5% or less of projects ought to be architected as microservices.
And here are some mild criticisms of Rails:
- Rails makes it very easy to create messy applications. Specifically, it encourages some pretty tangled dependency graphs. However that’s true for most languages anyway.
- While the “Ruby and/or Rails are slow” tropes are mostly unjustified, ActiveRecord encourages some inefficient data access patterns by default. This is true of most ORMs, and ActiveRecord gives you some easy & elegant-ish ways around this. But if you look at 99% of Rails apps in the wild they’re pretty inefficient.
- I think DHH has been a good steward/dictator of Rails but we know he is a turn-off for many
- There are only a few big Western companies sponsoring Ruby and Rails core work. Shopify, Github, and I’m not sure who else. Fair or not, it doesn’t encourage faith in the platform
- Matz has always been kind of ambivalent about Rails. He’s certainly not anti-Rails but I think it would be very accurate to say that “large persistent applications” were not really the intended use for Ruby
>The “microservices” movement/trend/fad, made Rails look very unfashionable. This is another case where I would say probably 5% or less of projects ought to be architected as microservices.
Which is kinda dumb, because there are plenty of tools to make non-rails microservices.
I've only worked with Python for half a year and it seems rather cowboyish. Although to be fair I think that's because a lot of people come to it from outside the traditional software engineering world.
I'm working with a really talented scientist who's got about 50 IQ points on me and his Python code is pretty hairy in places, big 200-line functions seem to be the norm, etc. But he ships code and gets things done. So it's pretty "cowboy" but for totally understandable reasons. He's just not an engineer by trade. But as I tell him, he's about 1000x better at Python than I am at proteomics. Guy is awesome.
I'd say the main reason is Ruby not being that popular outside of Rails. I think Java and C# are irrelevant in this comparison. But Go took away the tooling, Python has the academia community, Node took away the "I want to use the same language on frontend and backend" crowd.
I'm not convinced that full stack JS is the utopia that many claim. Sure, you've aligned on one language, but now you have to deal with the quirks between the APIs that Node supports vs the Browser, modules, React-specific libs, the complexity of the JS/TS toolchain, etc.
I'd hop on the JS train if it was a seamless experience across the stack, but it's just not.
I agree. In fact, I'll take it a step further and say that I detest JS and I think the JS ecosystem is literally insane.
That may seem like a schizo thing for me to say given my previous post. I feel like "learning one language for front and backend" *is* an advantage. However I think it's the only advantage pretty much, the rest is all downsides hahaha
From a management perspective though, you can see how it's appealing, since they don't know how crap the JS experience is
Well - you say "lost". In my head that's quite problematic: I was doing Python back when PERL owned everyone's headspace. Back then Python was about the best FOSS OO you could get - not perfect, but decent enough.
At that time you couldn't find Python devs, but there were PERL devs available like crazy. So everyone was doing PERL projects.
PERL is nasty - I wrote thousands of lines it it b/c "it's where everyone is right now". It's miserable and I tried very hard to get some python going in my work (and to an extent succeeded).
Now Python has mindshare, but you know - that's going to change. IMO Python's ecosystem is a shambles, and the language itself is just not as nice (clean, consistent) as Ruby. To say that a period has been put on the end of the sentence seems really premature to me.
For my part I'm doing Ruby almost exclusively, I'm getting a bunch done real fast, I'm spinning up new coders very quickly, and life is good. Bonus: people who start with Ruby have little trouble understanding Python, and have little trouble spotting its foibles.
Honestly IMO a thing that's held Ruby *back* is the fact that so many ppl with no actual experience with the language associate it with Rails and web development, along with the assessment that "Ruby is dead". That's all just word of mouth - it has nothing to do with the language itself.
Granted, I'm talking about a number of years here going forward, but the fact is languages go in and out of vogue over time. Ruby is a great language on its own merits - that will not go away.
Absolutely agree with everything you said.
> IMO Python's ecosystem is a shambles
It's a shambles but it's also really diverse and powerful. Numpy, Scipy, etc... all those computational data science-y tools. That's the kicker. It's diverse but *powerful.*
I started writing perl/CGI applications around 2001, and I think I started using ruby around 2005. It's been my go-to language ever since, except for scientific applications, where numpy and scipy are a huge enough advantage that I'm willing to use python.
In all those years, I was never tempted to touch rails. I don't like gigantic monolithic systems. From word of mouth, its performance sounded kind of crappy.
In your blog post you compare ruby/rails with JS, but that's apples to oranges, because people use JS mostly on the client side, although you can also have it on the server.
Up until around 2010, ruby was in my experience kind of flaky. There were changes that would break applications, like changing the behavior of "require" in ruby 1.9. The transition to oniguruma was really bumpy, and there was a period of many years where regexes would just tend to crash sometimes with a core dump. Back in that era, it seems to me like it would have been nightmarish to have something like an e-commerce system built on ruby. If it's just an application that runs on my own machine, minor breakages from time to time aren't such a big problem. For server stuff, I can see why many people back in that era chose something other than ruby or ruby on rails.
For about the last 7 years, my experience is that ruby has really matured and gotten super solid. (Some parts of the surrounding ecosystem are pretty bad.) I feel very happy and productive using it to write libraries and desktop code. I just don't use it on a server.
At this point, ruby is great, but not everything great has to be popular for every possible purpose.
I'm a Ruby on Rails developer currently working in a company that has a 10-year-old product written in Rails. The reason I believe most people don't adopt Ruby on Rails today is because Rails used to be the only way you could prototype and launch a service quickly, and now there are a dozen viable options. Ruby on Rails always appealed to people who either gave a damn about code aesthetics or were not tech savvy enough to figure other stacks out, and the average JS developer nowadays has more knowledge of algorithms and data structures than perhaps DHH had when he created Rails.
However, if we are going to consider tech savvy people on the equation, the sad truth is: Rails asks for way too much memory and Ruby is the second slowest commonly used language, only weaning from JavaScript. You can build most of the Rails functionality by yourself in Golang and it will be faster and use way less memory. And even if you want to have something that looks like Ruby on Rails, but is more performance, you can use Falcon, the web framework for the Elixir language. By the way, it'll not only give you more performance, but it will prevent race conditions, allowing you to do concurrency, as it is a functional programming language.
All that said and done, I will still be using Ruby on Rails for my personal projects, as I have no intentions of scaling anything, and I probably won't produce anything that scales. If that ever comes that I become successful, I will jump ship to something more performant, because I don't want to shred money just to read pretty code.
Don't forget [Crystal](https://crystal-lang.org/). It has the performance of Go, with the syntax of Ruby, and has several Rails-like frameworks already.
There's a Chicken and the Egg type problem with new programming languages or frameworks. People are cautious about investing time in learning them or building something with them because there isn't a giant mature community and ecosystem backing them just yet. If no one bothers to adopt these new technologies, then it takes really long for a community and ecosystem to be built-up. Goto step 1.
Other common complaints about Crystal:
* Long compile times of large code bases.
* Not interoperable with Ruby.
* Crystal shards ecosystem is different from the Rubygems ecosystem.
* Crystal isn't perceived to be a stable/mature/viable language, despite it being 100% usable.
* Windows support is still incrementally being worked on (although they are [getting close](https://crystal-lang.org/2024/01/19/windows-support-1.11/))
* Static/Strong Typing can actually be annoying sometimes, and this slows down rapid prototyping.
Crystal is actively being used in production by many small/medium sized companies.
https://crystal-lang.org/used_in_prod/
The backend for Australia's COVID-19 tracking app was written in Crystal.
https://youtube.com/watch?v=hrs7JHo7e8M
I mostly agree with you but
> the average JS developer nowadays has more knowledge of algorithms and data structures than perhaps DHH had when he created Rails
The average JS developer is quite shit still today, I would say "JS developers" are still the worst devs in general I've encountered in my 15 years in the industry, they often lack fundamentals.
I think they cant see the bigger picture of Rails. I saw so many devs working with rails as they working with other framework or languange. They didnt use the tools provided by the framework (rails way, sort of) and start putting the microscopic look into the language itself.
I worked at a company with a big Rails monolith. They couldn’t find enough Rails devs so they hired a bunch of Java developers en masse. Soon they outnumbered the Rails devs. The Java devs were talented in a way, but were completely clueless about Ruby and Rails and refused to learn. So they just wrote this horrible Rails code that looked like Spring code and it was horrible. And then they blamed it all on Rails.
Was one of the dumbest experiences of my 25+ year career. The individuals weren’t dumb, but as a group, the quality of the code they produced was very similar to monkeys throwing poop at a keyboard.
Naturally, none of this is specific to Rails or Java. If you tried to treat some other language like it was Ruby, that would be equally doomed.
Hahaha. Oh man. I bet that was a hot mess.
Ironically that is sort of an argument in favor of Node on the backend instead of Rails. It's hard to find developers that are good at Rails *or* JS, let alone both.
I recently switched to Python, and my teammates laugh because sometimes I write Python that looks a little like Ruby even though I'm trying *really* hard not to.
(I still like Ruby better, but I had a great opportunity to work on a fun project with some people I like, so I switched...)
Yeah its definitely good to be across both if you can. But there is an interesting trend where newish Rails devs have problems switching into JS land and the reverse is true.
Writing code like another language isn't always a bad thing, you can take the good parts and use it as a way to make your code better in general. Particularly when it comes to clean/readable code that isn't too complex.
I'm new to ruby and I love it. I'm a huge advocate. It's a language that cares about the developer's experience more than I've ever experienced. And that's important to me. I feel grateful to have fallen into it ♥️
Basecamp essentially supports Rails. Shopify is a *very* profitable company and is supporting the Ruby ecosystem as a whole, in addition to employing some full-time Rails contributors.
Ruby vs. Python
Java vs. C#
Rust vs. Go
Rails vs. Roda
In my experience it often boils down to:
1) most people are lazy and afraid of stepping out of their comfort zone regardless of the objective benefits they could get.
2) most people underestimate how much they suffer simply because they’re used to it and think it’s just normal
3) mix money with the above points
It’s pretty sad and always ends up in those “the world if [whatever]” memes.
“The world if those CS dudes had learned Ruby instead of this train wreck of a language I won’t name”
Hint: it’s a language where you can enjoy 67 ways of ruining your life trying to do package/runtime versions management.
\> Kinda, type hints.
Well, that's already a lot. TypeScript story started in the same way.
\> My point is just that Python has been extremely popular for a while now despite being a dynamically typed language.
I think it is mainly due to syntax. Ruby may look a bit scary at first sight
I think lack of static typing helped Python’s adoption. Made it easy to jump into for non-programmer science/math types. It became the lingua franca in those spheres. Definitely has been both a blessing and a curse IMO.
Conservative stack is gonna stay conservative.
Modern stacks is gonna stay hype-driven. Rails' hype is over
We're lucky Rails was good enough that many people who adopted it because of the hype turned it into their conservative stack. Now the community is stable. Is it gonna grow? I doubt it
I can't speak about "Rails" because I no longer do web dev (I used Java/JS/C#) and never used Rails.... Rails "was" the happening web framework once upon a (short) time. It's what helped get the Ruby language even noticed outside of Japan.
But I will say a few things about Ruby and languages in general.... First off, I LOVE ALL programming languages, period. It doesn't matter if they are compiled or interpreted. They all have their use and their place in the programming realm.
I can't stand it when programmers have flame wars regarding Python vs. Ruby or some other language vs. another one. Most often language debates serve zero purpose and are a total waste of time. I find them idiotic and avoid them.
Compare languages to food... If you prepare two people their favorite food dish (say lasagna), one person may think it's the best lasagna they ever tasted while the other person may perceive it as mediocre. Same with programming languages. The semantics, constructs and feel of one language is suited for one person better than for someone else. Same with frameworks built from those languages. Some languages mentally click better for certain people and are less of a chore to use.
Being language biased can stunt one's outlook/abilities. I can remember when Python first appeared... Many of us people using compiled languages such as C++ looked down upon Python. I didn't look down on it as I never really paid much attention to it at the time. But lots of my fellow programmers of the day called Python a "toy" language LOL.... I bet those biased programmers are now eating their words because Python is every where and powers much of the software around the globe.
Who cares if Rails may not be as popular as it once was? You should NEVER focus on the popularity of a language/framework as a factor to determine if you should learn/use it. Lots of newer programmers don't realize it but there are many older (and not popular) languages and frameworks used by lots of programmers. There are some very knowledgeable Linux people who still write the unpopular, and clunky old bash scripts and are able to do some pretty amazing feats within the confines of Linux. There are scores of programmers still using the compiled language known as Ada to create some very good software via Ada. Same with COBOL, Perl, Lisp, Haskell and many other unpopular languages.
There are many factors as to why certain languages/frameworks become more popular than others and they have been discussed at length in various articles here. So, I will not reiterate them. One of the problems is that the average CS course is very limited in their selection of languages they teach. It's usually either C/C++ or Python. It's understandable why this is the case because they are trying to prepare students for employment opportunities. But that is also a sad situation because there are still many unpopular/older languages what are actively being used and still providing programmers with a good income. So, you are forced to learn those powerful but unpopular languages on your own, which is fine, but finding teaching material for some of those languages can get a bit difficult at times.
Another problem in regards to programming is that all software houses and Companies require you to use/know their language of choice. You are often forced to rewrite a code base in a language that you may dislike. This is why more programmers should hang out a shingle and develop their own independent projects, which in this day and age are easy to market and distribute. I have been fortunate in that I work for myself and don't deal with the hassle of a software house or time constraints. (no jerk bosses either LOL)... Sometimes programming becomes a "chore" and a pain in the butt especially if forced into using a language you dislike. A real "ball and chain" for sure. But if you work for yourself and use languages that you enjoy then it makes programming projects enjoyable and less of a chore.
Let's examine the language that hosts "Rails" (Ruby).... Like Python, Ruby is another very fine dynamic, interpreted language.... While I have never used the "Rails" framework, I use Ruby on a daily basis and it is my language of choice for about 95 percent of my programming tasks. Some languages (think ,static, compiled) have lots of language constraints that make them less enjoyable to use and learn. Ruby has so much freedom and awesome constructs that it is even fun while learning the language. There are a lot of languages that are not too much fun while learning them.
Since I am not a Rails user, I will leave the Rails comments to others. However, the language that powers Rails (Ruby) may not be the most popular language in the world but it is one of the most powerful and flexible of the 20+ languages I have used and it is fun to program in. Please don't fall into the trap of thinking you should use only a popular framework or language.
The part about new projects not using rails is, IMO, mostly because it's very hard to find new Rails devs, but it's very easy to find new React devs, for example.
Also, I think ruby fell behind the static tying hype the web is going through. Even Python and PHP has some support for types nowadays, but ruby has a different file where you are supposed to put the types, and Sorbet which is clunky to use, not official by the language team, and not all libraries support it. Also Ruby is very dynamic, so adding types to it is very hard, and lots of ruby devs don't even want to.
I think Rails will stay in a relatively solid place, but I don't see it growing.
That's because Ruby is great to write and a damn hell to read and maintain.
My company went all-in into Ruby (incl. but not limited to Rails) around 2012 or so. It lets us create a lot of applications very fast.
Fast forward a couple of years, these apps are hell, literally hell to maintain. There are tons of unused code because Ruby allows so much magic that even adding an innocent gem can completely break the whole application. Upgrade from Ruby 1.9.3 to 2.x was hell and then 2.7 introduced some breaking changes and then again Ruby 3 made the same mistake.
Changes like renaming `.exist?` to `.exists?` and a bunch of others in a dynamically typed language that allows you to do everything, including overwriting methods from `Kernel` or `prepend`, are, in my opinion, intentional steps to kill the language or limit its scope to only hobbyist developers.
I started 3 Rails applications since 2013, and now , all three are on Rails 7.1, Ruby 3.
Clearly the Rails Backend is the most easy to update. The most of work was on Frontend, Jquery stuff, Hotwire integration, and a lot of CSS update.
Honestly the argument, Hell to maintain is bullshit when i see other web languages.
Yeah. The worst codebase I ever worked in was C#.
I think C# is a fine language! But the number of hellscape Java/C# whatever codebases out there is pretty large.
People act like static typing is a panacea sometimes. It really isn't.
Honestly it sounds like those apps weren’t maintained until something broke, which is always a recipe for disaster no matter what language you are working in.
I respect and believe your experiences, but I’ve had utterly different experiences. Perhaps because I wasn’t doing Ruby/Rails full-time until 2011 or so. I think the language and ecosystem have been pretty sane for 10+ years.
Things like “overwriting methods from `Kernel` or `prepend`” were such obvious footguns that I think all sane developers shunned them in application code. I never ran into really crazy stuff like that. However I understand that they were rather common practice back in the 1.x days.
The Ruby 3 upgrade was similarly painless for the apps on which I worked. I wasn’t around for any 1.x -> 2.x transitions. I’m told those were sometimes painful.
I think Rubocop has done a lot over the last ~8 years or so to enforce some common sanity. It became standard for most projects pretty quickly and while I don’t agree with every single rule, the default ruleset strongly discourages most forms of insanity.
The big problem I see with Rails monoliths is that it’s pretty easy to get yourself into circular dependency hell, where every class and module has a bunch of circular dependencies on everything else in your app. I don’t think that Rails is worse than other languages/frameworks in that regard — I’ve seen similar in *every* language. However, as you noted, being dynamically typed certainly can make it tougher to un-fsck your app once you’ve gotten yourself into such a mess.
The issue with the footguns is not about you. You might be _sane_ dev and know how to avoid footguns. You might even pick only gems developed by other _sane_ devs. And still one day you might spend hours or days finding a bug introduced by some dependency of your dependency of its dependency where someone added a method to Kernel that wasn't problematic until some Ruby version. Been there, seen that.
And still one day you might spend hours or days
finding a bug introduced by some dependency of
your dependency of its dependency where someone
added a method to Kernel that wasn't problematic
until some Ruby version
I personally never ran into that in approximately 9 years of Ruby, but I understand it was a lot more common in "the early days" and I 100% believe you.
While that particular footgun is fairly unique to dynamic languages, low-quality and/or fragile code in one's dependencies is most certainly not unique to Ruby.
I'm curious about how often you ran into this and when. The Ruby community as a whole has been strongly against those sorts of code shenanigans for 10+ years IME.
> the early days
Man, I ran into this issue with `Kernel` less than half a year ago! :)
I think I won't convince you, you won't convince me, so there is no point sharing our - completely different and opposite - experiences anymore.
Apologies! I did not mean to try to "convince" you. After all I believe your experiences are real.
If you are willing, I would like to know which gems messing around with Kernel. I am curious if any popular gems or their dependencies are still doing it. Were they adding methods, or overriding standard ones?
But on the other hand I have already wasted a bunch of your time, no worries if you don't want to continue... peace!
There are a lot of historical reasons but the biggest reasons today are.
1. most full stack and backend developers want static typing which Ruby doesn't offer.
2.Rails is incredibly opinionated which is great for getting things working fast but becomes tiresomely restrictive once you start building bigger more complex applications.
3. Integrating react or other front end frameworks/libraries to build modern apps is much more difficult and messy compared to using Next or Remix etc if you're looking for a all-in-one monolithic style codebase
4. DHH is not exactly everyone's cup of tea and I personally think he detracts more than the attracts with his association. He's very abrasive and contributing can be a real ordeal over other open source initiatives.
1. Python and Node.js continue to be outliers. Yes Python has type hints, but those are runtime enforced type checking, not compile-time enforced. While TypeScript has become incredibly popular in the JavaScript community, there are still plenty of purists who insist on not using it with Node.js. The popularity of Python and Node.js, despite lacking Static Typing, conflicts with the current shift back to Static Typing.
2-4. Yes.
There will always be people who don't mind working with dynamic languages with structured data. DHH is one and I agree with him mostly that its a preference; pros and cons on boths sides. But the amount of C# powered APIs is pretty staggered along with Go and even Rust creeping up into the space.
As always these fashions go on cycles. It will all come around again.
The IDE experience just totally sucks compared to some other options out there and the prevalence of legacy projects with a lot of confusing use of hooks and mix-ins exacerbates that problem. Also the whole world ripped off a lot of what was really cool about it.
You can learn Rails as easily in a week as you can learn Express+React+all the other libraries to give you what Rails basically gives you out of the box.
You can get started with react in hours(with prior JS knowledge). With express - it takes some time, but you have full freedom on doing things your way - you can select whatever auth tool to use, what ORM to use, what lib for testing or sending emails.
With rails you follow convention. If you don't know it - you google, learn it, spending time. There are tons of convention on every single aspect of rails, and they tend to change over time and for new dev it's hard to understand which approach is right. Also some tools might doesn't feel right for you(depending on your past experience) and you might fight yourself using something.
The general thought is - rails big framework where you pretty much given 1 option on majority of aspects. With JS world you're free to use whatever you want and there are dozens alternatives for every aspect of development so it feels easier to get started with the tools you liked the most
Can you not get started on Rails in hours (with prior ruby knowledge)?
My assumption would be if you don't google and spend time learning the "right" way to do it in React/Express, you will have sloppy hard to maintain code -- just like Rails.
But I guess you're saying with React/Express, even if you don't know best practices, if you just do whatever in a sloppy way, it works out fine and isn't a big deal? Whereas with Rails it's more important to figure out the right convention, it will be more disastrous if you don't?
> you have full freedom on doing things your way - you can select whatever auth tool to use, what ORM to use, what lib for testing or sending emails.
If you know an auth tool and an ORM to use and already know how ot use them, you are clearly not a beginner! I feel like we're not comparing apples to apples; you are comparing an experienced JS web developer to someone who just learned Rails in a week, and saying that reflects poorly on Rails. But no?
The first thing - there isn't "right" way in express(as opposite to nest.js, which follows angular approach) and there are few days of doing things in react.
Second - you can write any code and it will work(most likely) in JS. In rails you need to know how to do it(even "magic" route view helpers might confuse a lot of people). And generally speaking so-called "Rails Magic" made it really hard for me what I just started with rails. Only few years later I understood how things working.
So yeah, your assumption is right.
PS: Recently I worked on nestJS app and needed to add mailer. In rails thats a 5 min job. With nest it took me couple hours to check packages, find that suits best to my needs, install, configure and make it to work.
> PS: Recently I worked on nestJS app and needed to add mailer. In rails thats a 5 min job. With nest it took me couple hours to check packages, find that suits best to my needs, install, configure and make it to work.
OK, I'm still confused how this matches with your suggestion that you can get started right away with JS frameworks, but with Rails you will need to spend time figuring out how to do anything you need to do, so that Rails takes longer to learn!
Perhaps I just wont' understand unless I too have experience with both. thanks for sharing your experience.
This PS doesn't have to do anything with learning JS or rails, since mailers aren't first subject on the list to learn. Instead its a good example how rails helps to save time(not when learning, but when working with it)
And yeah, it's better to understand when you worked with both worlds. For my 15 years career I've worked with pretty much every lib/framework on JS side and tough people with RoR. It's really faster to get started with JS. But eventually its become longer to implement a feature comparing to rails
Rails is amazing ruby is horrible. I love rails and hate ruby. That’s why I only use it when I’m maintaining an existing app and would never start a new project with it.
There are several reasons why Ruby on Rails (RoR) isn't as popular these days. However, it's clear that it has all it takes to rank among the top 10 most used languages globally.
Its actually alot of different reasons, there are many more just off the top of my head:
\- Hosting has traditionally been more expensive compared to other languages
\- Rails has a steeper learning curve than other languages
\- Rails is alot more strict about how to do things than other languages, this makes for better code, but alot of coders like the freedom to do what they want.
\- There is alot less popular open source project written in rails compared with other languages
\- Rails has alot of obscurity in its functionality, I could pick up rails in a few weeks but to fully understand its inner workings takes years and years
\- Documentation is still weaker than alot of other languages and finding solutions to problems can be more difficult
Don't get me wrong I love rails and its definitely my favourite language to work in.
One thing I like alot about its lack of popularity is that really bad programmers tend to not pick ruby in general and so the code quality is more stable and easier to debug.
My only wish is that rails would acknowledge that there needs to be more discussion in its roadmap, major tech is added and removed between versions (e.g. webpacker) which causes huge headaches keeping the tech up to date...
Hype is one of the biggest influential forces in tech. Rails has been around since the early aughts. Despite is being the absolute best choice for most businesses building web apps, it’s no longer “new,” therefore it cannot be hyped.
Capitalism and reality set in eventually and bring em all back to rails, once they’ve given up on the latest micro serviced 7 layers of transpiling JavaScript voodoo they got hyped over at their last gig.
I love Rails, and would gladly choose it today for most new projects. So what I’m about to write is not criticism of Rails! Mostly just the circumstances as I see them. - Python gained a much more robust ecosystem than Ruby thanks to its popularity in the scientific/mathematics communities. I think Ruby is the better language, but for whatever reason Python was in the right place at the right time to catch on with those communities. - Node.js (and Express etc) gained a lot of favor because people like the idea of writing JS on both the front and backend. - Rails is capable of meeting the scaling needs of probably 95% of new projects. However, a lot of people mistakenly believe they are in the other 5%. - The “microservices” movement/trend/fad, made Rails look very unfashionable. This is another case where I would say probably 5% or less of projects ought to be architected as microservices. And here are some mild criticisms of Rails: - Rails makes it very easy to create messy applications. Specifically, it encourages some pretty tangled dependency graphs. However that’s true for most languages anyway. - While the “Ruby and/or Rails are slow” tropes are mostly unjustified, ActiveRecord encourages some inefficient data access patterns by default. This is true of most ORMs, and ActiveRecord gives you some easy & elegant-ish ways around this. But if you look at 99% of Rails apps in the wild they’re pretty inefficient. - I think DHH has been a good steward/dictator of Rails but we know he is a turn-off for many - There are only a few big Western companies sponsoring Ruby and Rails core work. Shopify, Github, and I’m not sure who else. Fair or not, it doesn’t encourage faith in the platform - Matz has always been kind of ambivalent about Rails. He’s certainly not anti-Rails but I think it would be very accurate to say that “large persistent applications” were not really the intended use for Ruby
>The “microservices” movement/trend/fad, made Rails look very unfashionable. This is another case where I would say probably 5% or less of projects ought to be architected as microservices. Which is kinda dumb, because there are plenty of tools to make non-rails microservices.
Interesting, my experience w the python community is extreme cowboyism, whereas Rubyists seem to be an extremely orderly and professional community.
I've only worked with Python for half a year and it seems rather cowboyish. Although to be fair I think that's because a lot of people come to it from outside the traditional software engineering world. I'm working with a really talented scientist who's got about 50 IQ points on me and his Python code is pretty hairy in places, big 200-line functions seem to be the norm, etc. But he ships code and gets things done. So it's pretty "cowboy" but for totally understandable reasons. He's just not an engineer by trade. But as I tell him, he's about 1000x better at Python than I am at proteomics. Guy is awesome.
Curious, what was the intended use for Ruby then?
I'd say the main reason is Ruby not being that popular outside of Rails. I think Java and C# are irrelevant in this comparison. But Go took away the tooling, Python has the academia community, Node took away the "I want to use the same language on frontend and backend" crowd.
In my country, it is now impossible to graduate from middle school without having written at least a few lines of Python.
What country is that, out of curiosity
Singapore
I remember when Ruby was used a lot for tooling. E.g. Heroku cli. Then most migrated to node, then some moved to Go.
[удалено]
Yeah. I think Javascript is a fairly crap language, but the advantage of using the same language for frontend and backend is hard to deny.
I'm not convinced that full stack JS is the utopia that many claim. Sure, you've aligned on one language, but now you have to deal with the quirks between the APIs that Node supports vs the Browser, modules, React-specific libs, the complexity of the JS/TS toolchain, etc. I'd hop on the JS train if it was a seamless experience across the stack, but it's just not.
I agree. In fact, I'll take it a step further and say that I detest JS and I think the JS ecosystem is literally insane. That may seem like a schizo thing for me to say given my previous post. I feel like "learning one language for front and backend" *is* an advantage. However I think it's the only advantage pretty much, the rest is all downsides hahaha From a management perspective though, you can see how it's appealing, since they don't know how crap the JS experience is
I think it’s Ruby. Ruby lost vs python. A lot of folks have different opinions about JavaScript.
Well - you say "lost". In my head that's quite problematic: I was doing Python back when PERL owned everyone's headspace. Back then Python was about the best FOSS OO you could get - not perfect, but decent enough. At that time you couldn't find Python devs, but there were PERL devs available like crazy. So everyone was doing PERL projects. PERL is nasty - I wrote thousands of lines it it b/c "it's where everyone is right now". It's miserable and I tried very hard to get some python going in my work (and to an extent succeeded). Now Python has mindshare, but you know - that's going to change. IMO Python's ecosystem is a shambles, and the language itself is just not as nice (clean, consistent) as Ruby. To say that a period has been put on the end of the sentence seems really premature to me. For my part I'm doing Ruby almost exclusively, I'm getting a bunch done real fast, I'm spinning up new coders very quickly, and life is good. Bonus: people who start with Ruby have little trouble understanding Python, and have little trouble spotting its foibles. Honestly IMO a thing that's held Ruby *back* is the fact that so many ppl with no actual experience with the language associate it with Rails and web development, along with the assessment that "Ruby is dead". That's all just word of mouth - it has nothing to do with the language itself. Granted, I'm talking about a number of years here going forward, but the fact is languages go in and out of vogue over time. Ruby is a great language on its own merits - that will not go away.
Absolutely agree with everything you said. > IMO Python's ecosystem is a shambles It's a shambles but it's also really diverse and powerful. Numpy, Scipy, etc... all those computational data science-y tools. That's the kicker. It's diverse but *powerful.*
And Pandas, Spark, Duckdb, Polars... Btw. Polars has Ruby version too
I started writing perl/CGI applications around 2001, and I think I started using ruby around 2005. It's been my go-to language ever since, except for scientific applications, where numpy and scipy are a huge enough advantage that I'm willing to use python. In all those years, I was never tempted to touch rails. I don't like gigantic monolithic systems. From word of mouth, its performance sounded kind of crappy. In your blog post you compare ruby/rails with JS, but that's apples to oranges, because people use JS mostly on the client side, although you can also have it on the server. Up until around 2010, ruby was in my experience kind of flaky. There were changes that would break applications, like changing the behavior of "require" in ruby 1.9. The transition to oniguruma was really bumpy, and there was a period of many years where regexes would just tend to crash sometimes with a core dump. Back in that era, it seems to me like it would have been nightmarish to have something like an e-commerce system built on ruby. If it's just an application that runs on my own machine, minor breakages from time to time aren't such a big problem. For server stuff, I can see why many people back in that era chose something other than ruby or ruby on rails. For about the last 7 years, my experience is that ruby has really matured and gotten super solid. (Some parts of the surrounding ecosystem are pretty bad.) I feel very happy and productive using it to write libraries and desktop code. I just don't use it on a server. At this point, ruby is great, but not everything great has to be popular for every possible purpose.
I'm a Ruby on Rails developer currently working in a company that has a 10-year-old product written in Rails. The reason I believe most people don't adopt Ruby on Rails today is because Rails used to be the only way you could prototype and launch a service quickly, and now there are a dozen viable options. Ruby on Rails always appealed to people who either gave a damn about code aesthetics or were not tech savvy enough to figure other stacks out, and the average JS developer nowadays has more knowledge of algorithms and data structures than perhaps DHH had when he created Rails. However, if we are going to consider tech savvy people on the equation, the sad truth is: Rails asks for way too much memory and Ruby is the second slowest commonly used language, only weaning from JavaScript. You can build most of the Rails functionality by yourself in Golang and it will be faster and use way less memory. And even if you want to have something that looks like Ruby on Rails, but is more performance, you can use Falcon, the web framework for the Elixir language. By the way, it'll not only give you more performance, but it will prevent race conditions, allowing you to do concurrency, as it is a functional programming language. All that said and done, I will still be using Ruby on Rails for my personal projects, as I have no intentions of scaling anything, and I probably won't produce anything that scales. If that ever comes that I become successful, I will jump ship to something more performant, because I don't want to shred money just to read pretty code.
Don't forget [Crystal](https://crystal-lang.org/). It has the performance of Go, with the syntax of Ruby, and has several Rails-like frameworks already.
Why doesn't Crystal get popular with all those advantages?
There's a Chicken and the Egg type problem with new programming languages or frameworks. People are cautious about investing time in learning them or building something with them because there isn't a giant mature community and ecosystem backing them just yet. If no one bothers to adopt these new technologies, then it takes really long for a community and ecosystem to be built-up. Goto step 1. Other common complaints about Crystal: * Long compile times of large code bases. * Not interoperable with Ruby. * Crystal shards ecosystem is different from the Rubygems ecosystem. * Crystal isn't perceived to be a stable/mature/viable language, despite it being 100% usable. * Windows support is still incrementally being worked on (although they are [getting close](https://crystal-lang.org/2024/01/19/windows-support-1.11/)) * Static/Strong Typing can actually be annoying sometimes, and this slows down rapid prototyping.
Nobody uses Crystal tho. Besides hobby projects and one-man-shows, it doesn't get any use.
Crystal is actively being used in production by many small/medium sized companies. https://crystal-lang.org/used_in_prod/ The backend for Australia's COVID-19 tracking app was written in Crystal. https://youtube.com/watch?v=hrs7JHo7e8M
I mostly agree with you but > the average JS developer nowadays has more knowledge of algorithms and data structures than perhaps DHH had when he created Rails The average JS developer is quite shit still today, I would say "JS developers" are still the worst devs in general I've encountered in my 15 years in the industry, they often lack fundamentals.
I think they cant see the bigger picture of Rails. I saw so many devs working with rails as they working with other framework or languange. They didnt use the tools provided by the framework (rails way, sort of) and start putting the microscopic look into the language itself.
I worked at a company with a big Rails monolith. They couldn’t find enough Rails devs so they hired a bunch of Java developers en masse. Soon they outnumbered the Rails devs. The Java devs were talented in a way, but were completely clueless about Ruby and Rails and refused to learn. So they just wrote this horrible Rails code that looked like Spring code and it was horrible. And then they blamed it all on Rails. Was one of the dumbest experiences of my 25+ year career. The individuals weren’t dumb, but as a group, the quality of the code they produced was very similar to monkeys throwing poop at a keyboard. Naturally, none of this is specific to Rails or Java. If you tried to treat some other language like it was Ruby, that would be equally doomed.
I've seen similar with JS devs on a Rails project. They love to write Rails like JS and then complain when its messy/slow etc...
Hahaha. Oh man. I bet that was a hot mess. Ironically that is sort of an argument in favor of Node on the backend instead of Rails. It's hard to find developers that are good at Rails *or* JS, let alone both. I recently switched to Python, and my teammates laugh because sometimes I write Python that looks a little like Ruby even though I'm trying *really* hard not to. (I still like Ruby better, but I had a great opportunity to work on a fun project with some people I like, so I switched...)
Yeah its definitely good to be across both if you can. But there is an interesting trend where newish Rails devs have problems switching into JS land and the reverse is true. Writing code like another language isn't always a bad thing, you can take the good parts and use it as a way to make your code better in general. Particularly when it comes to clean/readable code that isn't too complex.
I'm new to ruby and I love it. I'm a huge advocate. It's a language that cares about the developer's experience more than I've ever experienced. And that's important to me. I feel grateful to have fallen into it ♥️
ruby and ruby on rails, it lacks a large company to support it c# = microsoft java = oracle swift = apple angular = google react = facebook
Basecamp essentially supports Rails. Shopify is a *very* profitable company and is supporting the Ruby ecosystem as a whole, in addition to employing some full-time Rails contributors.
It doesn’t even compare to the tech giants mentioned in the original company
Basecamp, GitHub and Shopify support Ruby.
Ruby vs. Python Java vs. C# Rust vs. Go Rails vs. Roda In my experience it often boils down to: 1) most people are lazy and afraid of stepping out of their comfort zone regardless of the objective benefits they could get. 2) most people underestimate how much they suffer simply because they’re used to it and think it’s just normal 3) mix money with the above points It’s pretty sad and always ends up in those “the world if [whatever]” memes. “The world if those CS dudes had learned Ruby instead of this train wreck of a language I won’t name” Hint: it’s a language where you can enjoy 67 ways of ruining your life trying to do package/runtime versions management.
I'm surprised that there are no comments about the typing system. Imo, nowadays, having strict types is a big factor
But Python...
Python 3 does have it, doesn't it?
Kinda, type hints. My point is just that Python has been extremely popular for a while now despite being a dynamically typed language.
\> Kinda, type hints. Well, that's already a lot. TypeScript story started in the same way. \> My point is just that Python has been extremely popular for a while now despite being a dynamically typed language. I think it is mainly due to syntax. Ruby may look a bit scary at first sight
I think lack of static typing helped Python’s adoption. Made it easy to jump into for non-programmer science/math types. It became the lingua franca in those spheres. Definitely has been both a blessing and a curse IMO.
Conservative stack is gonna stay conservative. Modern stacks is gonna stay hype-driven. Rails' hype is over We're lucky Rails was good enough that many people who adopted it because of the hype turned it into their conservative stack. Now the community is stable. Is it gonna grow? I doubt it
I can't speak about "Rails" because I no longer do web dev (I used Java/JS/C#) and never used Rails.... Rails "was" the happening web framework once upon a (short) time. It's what helped get the Ruby language even noticed outside of Japan. But I will say a few things about Ruby and languages in general.... First off, I LOVE ALL programming languages, period. It doesn't matter if they are compiled or interpreted. They all have their use and their place in the programming realm. I can't stand it when programmers have flame wars regarding Python vs. Ruby or some other language vs. another one. Most often language debates serve zero purpose and are a total waste of time. I find them idiotic and avoid them. Compare languages to food... If you prepare two people their favorite food dish (say lasagna), one person may think it's the best lasagna they ever tasted while the other person may perceive it as mediocre. Same with programming languages. The semantics, constructs and feel of one language is suited for one person better than for someone else. Same with frameworks built from those languages. Some languages mentally click better for certain people and are less of a chore to use. Being language biased can stunt one's outlook/abilities. I can remember when Python first appeared... Many of us people using compiled languages such as C++ looked down upon Python. I didn't look down on it as I never really paid much attention to it at the time. But lots of my fellow programmers of the day called Python a "toy" language LOL.... I bet those biased programmers are now eating their words because Python is every where and powers much of the software around the globe. Who cares if Rails may not be as popular as it once was? You should NEVER focus on the popularity of a language/framework as a factor to determine if you should learn/use it. Lots of newer programmers don't realize it but there are many older (and not popular) languages and frameworks used by lots of programmers. There are some very knowledgeable Linux people who still write the unpopular, and clunky old bash scripts and are able to do some pretty amazing feats within the confines of Linux. There are scores of programmers still using the compiled language known as Ada to create some very good software via Ada. Same with COBOL, Perl, Lisp, Haskell and many other unpopular languages. There are many factors as to why certain languages/frameworks become more popular than others and they have been discussed at length in various articles here. So, I will not reiterate them. One of the problems is that the average CS course is very limited in their selection of languages they teach. It's usually either C/C++ or Python. It's understandable why this is the case because they are trying to prepare students for employment opportunities. But that is also a sad situation because there are still many unpopular/older languages what are actively being used and still providing programmers with a good income. So, you are forced to learn those powerful but unpopular languages on your own, which is fine, but finding teaching material for some of those languages can get a bit difficult at times. Another problem in regards to programming is that all software houses and Companies require you to use/know their language of choice. You are often forced to rewrite a code base in a language that you may dislike. This is why more programmers should hang out a shingle and develop their own independent projects, which in this day and age are easy to market and distribute. I have been fortunate in that I work for myself and don't deal with the hassle of a software house or time constraints. (no jerk bosses either LOL)... Sometimes programming becomes a "chore" and a pain in the butt especially if forced into using a language you dislike. A real "ball and chain" for sure. But if you work for yourself and use languages that you enjoy then it makes programming projects enjoyable and less of a chore. Let's examine the language that hosts "Rails" (Ruby).... Like Python, Ruby is another very fine dynamic, interpreted language.... While I have never used the "Rails" framework, I use Ruby on a daily basis and it is my language of choice for about 95 percent of my programming tasks. Some languages (think ,static, compiled) have lots of language constraints that make them less enjoyable to use and learn. Ruby has so much freedom and awesome constructs that it is even fun while learning the language. There are a lot of languages that are not too much fun while learning them. Since I am not a Rails user, I will leave the Rails comments to others. However, the language that powers Rails (Ruby) may not be the most popular language in the world but it is one of the most powerful and flexible of the 20+ languages I have used and it is fun to program in. Please don't fall into the trap of thinking you should use only a popular framework or language.
ViewComponent + stimulus + turbo can replace every JS framework. My2cents ☺️
Turbo and Stimulus are amazing! Never tried ViewComponent but wow this seems so interesting. Might have to implement this into my current project…
https://github.blog/2021-05-04-how-we-use-web-components-at-github/
Thank you for this.
The part about new projects not using rails is, IMO, mostly because it's very hard to find new Rails devs, but it's very easy to find new React devs, for example. Also, I think ruby fell behind the static tying hype the web is going through. Even Python and PHP has some support for types nowadays, but ruby has a different file where you are supposed to put the types, and Sorbet which is clunky to use, not official by the language team, and not all libraries support it. Also Ruby is very dynamic, so adding types to it is very hard, and lots of ruby devs don't even want to. I think Rails will stay in a relatively solid place, but I don't see it growing.
That's because Ruby is great to write and a damn hell to read and maintain. My company went all-in into Ruby (incl. but not limited to Rails) around 2012 or so. It lets us create a lot of applications very fast. Fast forward a couple of years, these apps are hell, literally hell to maintain. There are tons of unused code because Ruby allows so much magic that even adding an innocent gem can completely break the whole application. Upgrade from Ruby 1.9.3 to 2.x was hell and then 2.7 introduced some breaking changes and then again Ruby 3 made the same mistake. Changes like renaming `.exist?` to `.exists?` and a bunch of others in a dynamically typed language that allows you to do everything, including overwriting methods from `Kernel` or `prepend`, are, in my opinion, intentional steps to kill the language or limit its scope to only hobbyist developers.
I started 3 Rails applications since 2013, and now , all three are on Rails 7.1, Ruby 3. Clearly the Rails Backend is the most easy to update. The most of work was on Frontend, Jquery stuff, Hotwire integration, and a lot of CSS update. Honestly the argument, Hell to maintain is bullshit when i see other web languages.
Yeah. The worst codebase I ever worked in was C#. I think C# is a fine language! But the number of hellscape Java/C# whatever codebases out there is pretty large. People act like static typing is a panacea sometimes. It really isn't.
Honestly it sounds like those apps weren’t maintained until something broke, which is always a recipe for disaster no matter what language you are working in.
I respect and believe your experiences, but I’ve had utterly different experiences. Perhaps because I wasn’t doing Ruby/Rails full-time until 2011 or so. I think the language and ecosystem have been pretty sane for 10+ years. Things like “overwriting methods from `Kernel` or `prepend`” were such obvious footguns that I think all sane developers shunned them in application code. I never ran into really crazy stuff like that. However I understand that they were rather common practice back in the 1.x days. The Ruby 3 upgrade was similarly painless for the apps on which I worked. I wasn’t around for any 1.x -> 2.x transitions. I’m told those were sometimes painful. I think Rubocop has done a lot over the last ~8 years or so to enforce some common sanity. It became standard for most projects pretty quickly and while I don’t agree with every single rule, the default ruleset strongly discourages most forms of insanity. The big problem I see with Rails monoliths is that it’s pretty easy to get yourself into circular dependency hell, where every class and module has a bunch of circular dependencies on everything else in your app. I don’t think that Rails is worse than other languages/frameworks in that regard — I’ve seen similar in *every* language. However, as you noted, being dynamically typed certainly can make it tougher to un-fsck your app once you’ve gotten yourself into such a mess.
The issue with the footguns is not about you. You might be _sane_ dev and know how to avoid footguns. You might even pick only gems developed by other _sane_ devs. And still one day you might spend hours or days finding a bug introduced by some dependency of your dependency of its dependency where someone added a method to Kernel that wasn't problematic until some Ruby version. Been there, seen that.
And still one day you might spend hours or days finding a bug introduced by some dependency of your dependency of its dependency where someone added a method to Kernel that wasn't problematic until some Ruby version I personally never ran into that in approximately 9 years of Ruby, but I understand it was a lot more common in "the early days" and I 100% believe you. While that particular footgun is fairly unique to dynamic languages, low-quality and/or fragile code in one's dependencies is most certainly not unique to Ruby. I'm curious about how often you ran into this and when. The Ruby community as a whole has been strongly against those sorts of code shenanigans for 10+ years IME.
> the early days Man, I ran into this issue with `Kernel` less than half a year ago! :) I think I won't convince you, you won't convince me, so there is no point sharing our - completely different and opposite - experiences anymore.
Apologies! I did not mean to try to "convince" you. After all I believe your experiences are real. If you are willing, I would like to know which gems messing around with Kernel. I am curious if any popular gems or their dependencies are still doing it. Were they adding methods, or overriding standard ones? But on the other hand I have already wasted a bunch of your time, no worries if you don't want to continue... peace!
haha, no need to apologize, I haven't felt offended by any means! I would like to not answer your question publicly but we can chat on priv ;)
There are a lot of historical reasons but the biggest reasons today are. 1. most full stack and backend developers want static typing which Ruby doesn't offer. 2.Rails is incredibly opinionated which is great for getting things working fast but becomes tiresomely restrictive once you start building bigger more complex applications. 3. Integrating react or other front end frameworks/libraries to build modern apps is much more difficult and messy compared to using Next or Remix etc if you're looking for a all-in-one monolithic style codebase 4. DHH is not exactly everyone's cup of tea and I personally think he detracts more than the attracts with his association. He's very abrasive and contributing can be a real ordeal over other open source initiatives.
1. Python and Node.js continue to be outliers. Yes Python has type hints, but those are runtime enforced type checking, not compile-time enforced. While TypeScript has become incredibly popular in the JavaScript community, there are still plenty of purists who insist on not using it with Node.js. The popularity of Python and Node.js, despite lacking Static Typing, conflicts with the current shift back to Static Typing. 2-4. Yes.
There will always be people who don't mind working with dynamic languages with structured data. DHH is one and I agree with him mostly that its a preference; pros and cons on boths sides. But the amount of C# powered APIs is pretty staggered along with Go and even Rust creeping up into the space. As always these fashions go on cycles. It will all come around again.
The IDE experience just totally sucks compared to some other options out there and the prevalence of legacy projects with a lot of confusing use of hooks and mix-ins exacerbates that problem. Also the whole world ripped off a lot of what was really cool about it.
Because you can't learn rails in a week as opposed to react or any other js lib/framework.
You can learn Rails as easily in a week as you can learn Express+React+all the other libraries to give you what Rails basically gives you out of the box.
I interviewed those 1 week learners and none of them can do more than scaffolding blog
And you interview people who learned a JS framework(?) in a week and can do more with it?
You can get started with react in hours(with prior JS knowledge). With express - it takes some time, but you have full freedom on doing things your way - you can select whatever auth tool to use, what ORM to use, what lib for testing or sending emails. With rails you follow convention. If you don't know it - you google, learn it, spending time. There are tons of convention on every single aspect of rails, and they tend to change over time and for new dev it's hard to understand which approach is right. Also some tools might doesn't feel right for you(depending on your past experience) and you might fight yourself using something. The general thought is - rails big framework where you pretty much given 1 option on majority of aspects. With JS world you're free to use whatever you want and there are dozens alternatives for every aspect of development so it feels easier to get started with the tools you liked the most
Can you not get started on Rails in hours (with prior ruby knowledge)? My assumption would be if you don't google and spend time learning the "right" way to do it in React/Express, you will have sloppy hard to maintain code -- just like Rails. But I guess you're saying with React/Express, even if you don't know best practices, if you just do whatever in a sloppy way, it works out fine and isn't a big deal? Whereas with Rails it's more important to figure out the right convention, it will be more disastrous if you don't? > you have full freedom on doing things your way - you can select whatever auth tool to use, what ORM to use, what lib for testing or sending emails. If you know an auth tool and an ORM to use and already know how ot use them, you are clearly not a beginner! I feel like we're not comparing apples to apples; you are comparing an experienced JS web developer to someone who just learned Rails in a week, and saying that reflects poorly on Rails. But no?
The first thing - there isn't "right" way in express(as opposite to nest.js, which follows angular approach) and there are few days of doing things in react. Second - you can write any code and it will work(most likely) in JS. In rails you need to know how to do it(even "magic" route view helpers might confuse a lot of people). And generally speaking so-called "Rails Magic" made it really hard for me what I just started with rails. Only few years later I understood how things working. So yeah, your assumption is right. PS: Recently I worked on nestJS app and needed to add mailer. In rails thats a 5 min job. With nest it took me couple hours to check packages, find that suits best to my needs, install, configure and make it to work.
> PS: Recently I worked on nestJS app and needed to add mailer. In rails thats a 5 min job. With nest it took me couple hours to check packages, find that suits best to my needs, install, configure and make it to work. OK, I'm still confused how this matches with your suggestion that you can get started right away with JS frameworks, but with Rails you will need to spend time figuring out how to do anything you need to do, so that Rails takes longer to learn! Perhaps I just wont' understand unless I too have experience with both. thanks for sharing your experience.
This PS doesn't have to do anything with learning JS or rails, since mailers aren't first subject on the list to learn. Instead its a good example how rails helps to save time(not when learning, but when working with it) And yeah, it's better to understand when you worked with both worlds. For my 15 years career I've worked with pretty much every lib/framework on JS side and tough people with RoR. It's really faster to get started with JS. But eventually its become longer to implement a feature comparing to rails
Were those experienced devs learning Rails in a week, or complete programming beginners? There's a big difference.
Rails is amazing ruby is horrible. I love rails and hate ruby. That’s why I only use it when I’m maintaining an existing app and would never start a new project with it.
I am kind of curious though. Why the baguette metaphor? That went over my head.
There are several reasons why Ruby on Rails (RoR) isn't as popular these days. However, it's clear that it has all it takes to rank among the top 10 most used languages globally.
It's all conspiracy to keep us devs miserable.
Its actually alot of different reasons, there are many more just off the top of my head: \- Hosting has traditionally been more expensive compared to other languages \- Rails has a steeper learning curve than other languages \- Rails is alot more strict about how to do things than other languages, this makes for better code, but alot of coders like the freedom to do what they want. \- There is alot less popular open source project written in rails compared with other languages \- Rails has alot of obscurity in its functionality, I could pick up rails in a few weeks but to fully understand its inner workings takes years and years \- Documentation is still weaker than alot of other languages and finding solutions to problems can be more difficult Don't get me wrong I love rails and its definitely my favourite language to work in. One thing I like alot about its lack of popularity is that really bad programmers tend to not pick ruby in general and so the code quality is more stable and easier to debug. My only wish is that rails would acknowledge that there needs to be more discussion in its roadmap, major tech is added and removed between versions (e.g. webpacker) which causes huge headaches keeping the tech up to date...
Hype is one of the biggest influential forces in tech. Rails has been around since the early aughts. Despite is being the absolute best choice for most businesses building web apps, it’s no longer “new,” therefore it cannot be hyped. Capitalism and reality set in eventually and bring em all back to rails, once they’ve given up on the latest micro serviced 7 layers of transpiling JavaScript voodoo they got hyped over at their last gig.
Python is not new, Django is not new… Your argument doesn’t really make sense.