What makes you say it is hard to maintain longer lived projects? (I used to be a RoR developer for a few years, so I'm curious about other people's experiences.)
As a person maintaining multiple Rails codebases approaching a decade in age: RoR just bitrots incredibly fast and its really difficult to catch or update.
With each new version of RoR gems just stop being compatible without replacement, and its a fairly significant effort to migrate everything to the new shiny being introduced. In fairly stable projects where there isn't much feature churn/replacement, you pretty much have entire sections of the codebase that never move past the version they were originally written in. You're constantly maintaining controllers/models written in RoR 3.2/4/4.2/5/5.1 styles since its incredibly difficult finding which features were used, but they still kinda sorta mostly work, until they silently don't.
The difference compared to other frameworks/languages is that Rails is very heavily powered by "magic". Every other tech explicitly configures and calls features being used, but Rails is mostly held together by "convention", but convention evolves. How do you search for things like "the filename of this must match the class name of this" or "the method name must match this database feature". Nevermind the metaprogrammed methods that aren't documented anywhere. The convention evolving as developer preferences changes is generally a good thing and keeps RoR from becoming too dated but it is an expensive maintenance burden.
I quite like Rails and it's still my first choice for personal projects/prototypes. But I'm definitely souring to it for long running professional work.
It's mostly the "magical" parts like before/after hooks. When you are tracing a bug and are trying to do step-by-step debugging, it has been hell. Quickly jumping to definitions? Even RubyMine can't do it.
Furthermore, as the project grows, you need to introduce something more/bigger than MVC and people put these files everywhere. Sure it's a management problem but it doesn't help that people don't do the right thing by default.
In general, there's a breaking poing that you will very soon hit when you try to just pile things on top.
It's mostly the "magical" parts like before/after hooks.
I dislike a lot of the "magic" in Rails, but don't find before/after hooks very "magical" at all.
I guess when you get into inheritance perhaps. When you have an inheritance chain, which hooks are firing and in which order? That gets confusing fast. But, that also doesn't feel Rails-specific at all to me.
Rails gives you some ways to shoot yourself in the foot, but what language/framework doesn't?
When you are tracing a bug and are trying to do step-by
-step debugging, it has been hell.
I don't find this too much of an issue. It may be primitive but I just rely on debug output statements.
I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)
In general that's the strategy for Rails debugging or really any dynamic language where the editor/IDE can't reason about the code like it can with a static language.... lots of debug output and then get a little creative with how you filter it in your terminal.
Helps to use an terminal app like iTerm that lets you use split panes so you can look at multiple filtered views of your log output at once if you like.
Quickly jumping to definitions? Even RubyMine can't do it.
Yeah. I used to work in C# + Visual Studio + Resharper and oohhhhh boy, I often miss being able to lean heavily on the IDE/compiler.
Still, as far as definitions go? I don't know. I just grep for "def foo" (if I don't know what file it's in) or use my editor to jump right to the file where it exists (if I know where it is, which is usually the case)
Not as slick as the editor/IDE actually being smart, but I don't really find it to be a friction point.
> I have an expansion set up in my text editor that spits out `Rails.logger.debug("[jbootz] ")` and then I just do `tail -f log/development.log | grep jbootz`. I also have iTerm set up to highlight any lines containing "jbootz", so it stands out when it's mingled in with other output. (I just picked "jbootz" as it's a unique string)
... that seems unnecessarily complicated compared to using byebug, or hell, the RubyMine debugger.
Yeah. MVC is not always the right tool for the job, but it's generally fine and IMO rarely a terrible fit.
I don't see how that's a Rails-specific problem.
Before Rails, working in the wild and wooly world of Microsoft web dev (with occasional PHP thrown in) I saw some real horrorshow web apps. People hacking together their own confusing and misthought architectures. And those horrorshows were rule and not the exception.
The standardized structure of Rails apps is such a breath of fresh air. It's so nice to step into a Rails codebase and basically know where most things are most of the time.
Admittedly it's also nice to step away from Rails for smaller, simpler apps.
Before Rails I did a lot of work where there was no framework comparable to Rails, in ASP "Classic" and then ASP.NET.
Generally each web app had its own organizational structure. Everything was still "page-based" so your site's file structure would mirror the actual URLs: the code for your product page would be "/product.asp" and your shopping cart page would be "/cart.asp" or whatever. Those files had intermingled markup and code extremely similar to ERB files in Rails.
Conscientious developers of that era would of course extract as much functionality as possible into shared include files. Even in those savage days we tried to separate logic and presentation whenever possible. Early PHP dev worked much the same way.
Needless to say this generally lead to spaghetti code. You certainly could make very maintainable ASP/PHP sites, with a lot of effort -- just like you can find some very maintainable and well-structured shell scripts. But, even so, each "well-structured" ASP/PHP site would have its own structure and it was quite a learning curve jumping into a new one, if you ever had to look at somebody else's code.
Early ASP.NET apps used an even more bizarre set of Microsoft constructs. Code-behind files, etc. Yuck.
Later came ASP.NET MVC which was quite good IMO. It borrowed liberally from Rails which was a good thing.
In Ruby land I developed with both Sinatra and Rails. Sinatra is great and a lot of fun, but you are totally on your own w.r.t. structuring your app. Once your Sinatra app grows past a certain complexity, you will generally just find yourself reimplementing large parts of Rails and encountering the same problems w.r.t. structuring your app.
Rails and MVC are not perfect -- many say other variations like MVVM/MVP/etc are better. Perhaps so. I've certainly had pain points with Rails (too much "magic", high RAM usage) but as far as structuring my applications.... no.
I think there are probably a large number of people who "learn Rails" without really learning the deeper/unique concepts of vanilla Ruby. For me at least it was like a decade in between first writing some Ruby and really feeling like I've started to understand the full scope of the language and syntax that's available to me, such that I'm only now able to start thinking about what cool actual-things I can build with these concepts.
