Geekly Articles each Day
📜 ⬆️ ⬇️

It's time to say goodbye to Rails.

Last year, I decided that I would no longer use Rails, and would not support Rails in my gems. In addition, I will do everything possible so that I never have to face Rails again at work.


Since I’m involved in many Ruby projects, people often ask me why I don’t like Rails, what problems I have with it and so on. Therefore, I decided to write this long post to summarize and explain everything.


The article is partly technical, partly personal and, unfortunately, partly angry. I am not writing this to attract attention, get visitors, etc., I have no interest in this. I am writing this because I want to end my discussions on Rails and that there is a place to give links every time I hear the same questions.


I would also like to tell you a couple of stories that "novice Rails developers" have probably never heard of, and highlight some of the questions that are important enough to at least think about them.


Good part


I will not pretend that everything in Rails is bad, wrong, and the framework is the embodiment of evil. It would not be fair, and just stupid. There are a lot of good things to say about Rails. And I will mention a couple of (obvious?) Things to maintain balance.


So, Rails made Ruby popular. It is a fact. I became a Ruby developer, which in turn changed my career and gave me a lot of amazing features thanks to Rails. Many rubists of those days went the same way. We are all here thanks to Rails. In many cases, Rails actually had a huge impact on people, and literally improved their lives. People got better jobs, better opportunities and good money. This was a radical change in the conditions of the "game" for many of us.


Over the years, Rails & DHH has inspired many people, including people from other communities, to rethink what they are doing. For example, I’m sure that Rails helped improve the PHP community (you can try to prove that I’m wrong, but I have pretty vivid memories of how Symfony got a lot of Rails inspiration). The same thing happened in Java, the Play framework is an example.


There are other fantastic aspects. Rails has always been focused on ease of use and the ability to quickly create web applications, which have allowed initiatives such as Rails Girls to succeed. Rails proved to people that they were able to create something on their own, without any programming experience, in a relatively short amount of time. This is surprising, as it can easily become a gateway to the world of programming for people who otherwise did not even consider becoming a programmer.


My trip


Let me tell you a little about my background and how I came to Rails.


I started working with Ruby at the end of 2006, because my thesis was about Rails. I studied the language while I was writing my diploma. It was fun, it was interesting, it was something new for me. Then I still worked as a PHP developer. And as a typical PHP programmer in ~ 2005-6, I did all these typical things: I wrote SQL queries in presentation templates, wrote in a procedural style, and then developed my own framework and my own ORM, I was disappointed and burned out. Despite some knowledge of C, C ++, Java and Python, I decided to switch to Ruby, because of Rails. I chose them for my diploma and quite by chance I came across a job offer from a local Rails store. I answered and they hired me. This was in March 2007.


So, since March 2007, I started working with Ruby professionally, and somewhere in 2009 I started to contribute to OpenSource projects in Ruby. Since then I have been working in a consulting company for 3.5 years, mainly with large and complex projects. Then he worked as a freelancer for several years, worked with a bunch of clients, opened his own company, and then returned to full-time work, and then back to freelancing, and now I'm a full-time employee again. I created Rails applications from scratch and participated in the development of relatively large Rails applications.


Let me tell you a story. Once I joined an existing project. It was an awesome app that managed the online shopping community website. Complex sales models, complex promotions, intricate configurations of goods, coupons, user groups, messages - it had all this. I joined them to help add some new features. One of my first tasks was ... add a link to something on some page. It took me a few days to add this stupid link. Why? The application was a big ball of complex domain logic, rolled out on several layers and with such complex views that it was not easy to even find the desired template in which to add a link. Since I needed some data from the order in order to create this link, it was not obvious how I should get it. The lack of internal application APIs and reliance solely on ActiveRecord made this task extremely difficult. I am not kidding.


My first frustrations with Rails started quite early. I experienced discontent from ActiveRecord after about 6 months of using it. I also never liked how Rails approached JavaScript and AJAX. In case you don’t remember, or didn’t catch the version before Rails adopted the UJS approach (which was the hit of the discussions in 2007-2008), Rails used inline JavaScript in templates generated by a bunch of nasty helpers. Like everything with Rails, it was "easy and pleasant in the beginning" and then turned into unsupported crap. In the end, Rails adopted UJS in version 3.0 and the community seems to have agreed that this is the best approach. That was when Merb was killed by poured into rails. Oh, you do not know what is Merb? Ok, let's talk about this.


Why I was delighted with Merb & DataMapper


Merb is a project created by Ezra Zygmuntowicz. It began as a hack to make file uploads faster and thread-safe. And he walked an interesting path from this hack to a modular, thread-safe, fast full-stack framework for developing web applications. I remember how people started talking about Merb in 2008 and it was an amazing feeling that something new was happening, and it would be great!


You may have been delighted when the API mode appeared in Rails, right? Hmm, and Merb had 3 modes: full stack mode, API mode and micro mode, in which it was trimmed to a minimum, and I still remember that this was the fastest thing that ever existed in the Ruby world. That was over 7 years ago. Think about it.


At the same time, another project attracted the attention of the community - DataMapper. He became part of the Merb stack, being his choice for ORM. I was very excited about how he solved many of the problems that were in ActiveRecord. DataMapper already in ~ 2008-9 had attribute definitions in models, custom types, lazy queries, more powerful DSL queries, and so on. In 2008, Yehuda Katz was one of the core developers of the project, he actively promoted him and there was a big stir in this regard. DataMapper was ultimately a better ORM than ActiveRecord in 2008-9. It would be unfair not to mention that Sequel appeared at about the same time and it is still used far less than ActiveRecord, even though it is a better solution.


I was delighted with Merb and DataMapper as they brought hope that we can do something better and create healthy competition for Rails. I was excited because both projects encouraged a modular approach and thread safety, not to mention such things as simply better standards for writing code.


Both projects were eventually killed by Rails, since Merb was "flush" with Rails, which resulted in a huge Rails refactoring for version 3.0. DataMapper lost the attention of the community and without much support the project could not develop, as it could be if Merb would not be "infused" in Rails.


With this solution, the Ruby ecosystem lost a bunch of important projects and only Rails benefited from it. Whether the decision to kill a Merb is good or not is a matter of personal opinion, we can only assume what could have happened if the decision had not been made. However, there is a simple truth about competition - that's great. Lack of competition means monopoly, and the simple truth about monopoly is not great. Competition promotes progress and innovation, competition creates a healthy ecosystem, it allows people to work together more to share what is common to create a better foundation. This is not what happens in the Ruby community.


After Merb & DataMapper were virtually destroyed (in the long run), it was extremely difficult to create something new in the Ruby ecosystem. Because people focused on Rails, new projects were heavily influenced by it. Breaking through with new ideas was difficult, to say the least ... because every time you demonstrate something, people just want it to be like Rails and work well with Rails. Making projects that work with Rails is hard, but I will come back to this issue later.


After all these years, we eventually came to one framework subordinating our entire ecosystem, affecting thousands of developers and creating standards that ... are very controversial. We lost the diversity of the ecosystem, which began to grow in 2008 and was suppressed by Rails.


Hey, I know how it sounds almost like conspiracy theories, but don’t treat it that way. What I have said here are facts with a mixture of my personal feelings. I started participating in DataMapper at the end of 2009 and, seeing how it collapses was very sad.


Complexity!


Difficulty is our biggest enemy. People began to show less enthusiasm for Rails, as it quickly turned out that in dealing with growing complexity, it leaves us with a lot of unanswered questions. What DHH & co offer. never was enough to solve many problems that thousands of developers began to fight back in 2007-2008. Some people had hoped that maybe Merb / DataMapper would bring improvements, but now you know what happened, so we all went back to Rails in 2010 when Rails 3.0 was released.


A couple of days ago, someone posted on / r / ruby ​​a link to an article about organizing code using "Service objects". This is one of many similar articles. If you think this is a kind of recent trend, take a look at the James Golick article from March 2010 - "Crazy, Heretical, and Awesome: The Way I Write Rails Apps . "


We’re talking about ways to improve the architecture of our Rails applications for about 6 years. I tried to contribute to this discussion as much as I could - articles, speeches at conferences and work on many open source projects that seek to solve various complex problems.


However, such arguments and ideas are always ridiculed by members of the Rails Core Team, and especially DHH. This was scary and discouraging for me, and this is the reason why I never tried to contribute to Rails. I’m pretty damn sure that my suggestions will end up in the end. Monkey-patches? C'mon, no problem, we love our 10.years.ago! New abstractions? Who needs it, Rails is easy! TDD? Not a problem, she is dead , do not worry! ActiveRecord is bloated - so what, it's so convenient, let's add more features !


The Rails ecosystem, especially around its Core Team, has never made a good impression on me, and it’s not a problem for me to admit that I’m just afraid to suggest any changes. This is especially true since the first thing I would suggest is "Please remove ActiveSupport" (haha ... imagine it!).


Okay, let's get to some technical details.


Convenience-Based Rails Design


As I said, Rails was built with usability in mind. Do not confuse this with simplicity. Just yesterday, I stumbled upon this tweet, which says it all:


Simple vs easy


This is how Rails works, a classic example:


User.create(params[:user])

, ( , User ActiveRecord), . , . / , ?


, , , " " , :



, . (coupling) .


Rails . Rails SRP ( SOLID ) ", , ". , , , Rails YAGNI. , , , Rails, tenderlove, “use ActiveSupport::Concerns”.


Rails- , , - ActiveRecord, , .


— , . Rails, , , , , . , . ActiveRecord , Rails , Rails .


, ActiveRecord , Attributes API ( , ). , ActiveRecord 200 concerns, ORM, .


Rails? . , - , Rails . — ActiveRecord.suppress, DHH. , Ruby , : ", , CreateCommentWithNotificationsFactory". -!


ActiveCoupling


Rails ? , , - . , , Rails . Rails, . , , DHH :


Rails is your app


, ? ", ". , ? !


Rails , , , , .


:



, , Rails — . , , . Rails , , "" Java . Rails - .


. .



, Rails — ActiveSupport. , , . .


, , - ActiveSupport Rails Ruby. Rails . , , , , API, - . !


Rails , . - Rails, , ActiveSupport, , , , , Rails , .


, Rails, , . , , Rails ( , , Rails), . , , Rails? , , ActiveRecord, , — ActiveModel, ActiveRecord Rails 3.0.


, Rails .


, . Rails , . , , Spring. , , Rails. , , . , Ruby , . , , Rails. Rails, , , , , . - , . , , , , , , F5. .


, , , ! Rails . , .


ActiveSupport, ActiveRecord , ORM, , , - Rails.


Rails


Rails OpenSource Ruby, . , Rails. , . , , - Rails. ! ! Rails , , - , , -. -, Rails ! .


. , dry-rb, hanami and trailblazer rom-rb. , , , , Merb DataMapper.


, , , . , , .


Ruby


, Rails — — Ruby . . , Ruby. Elixir . Clojure, " ". , . , Haskell, . Scala. , , , TypeError . — , , - .


, Rails, . Monkey-patching, , ORM — .


, " Ruby - , , , , ". . , Ruby - (, ..). -, , , Ruby-. , , — .


, Ruby. . , . rom-rb, dry-rb, hanami trailblazer. , , .



, , .


. Rails .

, . , , . , , . , , "" -, , , , , . Rails, , .


, , , Rails ,

. , GitHub, 2435 OSS . . , Rails - , . , , . , OpenSource , GitHub.


OSS, Rails

. , , . Rails . Rails, , ActiveSupport ActiveRecord .. - , (. Hanami).


')

Source: https://habr.com/ru/post/301532/

More articles:


All Articles