"Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using Rails."
This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.
To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO-FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow implementation of half of Ruby on Rails."
I still love Sinatra for back office and API stuff where you don't need to worry quite so much about authentication, exploits, web assets, permission hierarchies/matrices etc.
At the company I used to work for we built our invoicing system's API with it and it was fantastic, plain succinct Ruby with Sinatra, Sequel and not much else.
For public-facing apps that require signup, clever routing, image uploads and other non-trivial functionality, Rails definitely makes more sense.
For readers interested in a contrary anecdote, every time I've used Sinatra based frameworks, such a Express or Nancy, I've thought without a doubt it was the right choice over something MVC based.
The simplicity of these frameworks allows arbitrary changes with minimal friction, patterns, restrictions, and other people's opinions, i.e. conventions.
Just thought I'd provide some counter data here. I've built small services in Sinatra, which did not warrant the usage of Rails and never had to change anything, having them in fully functional operation for years.
I could have built these little apps in Rails, but I did not need it, never did, and my code/deployment/etc. is cleaner and smaller because of it.
Also these services have always been quite small (a few endpoints or functions), which is what I think Sinatra is best for.
I second this. I use sintra for all those sites that are 75% static pages and few dynamic parts here are there and could not be happier.
Non optionated means that I can really easily setup the model that I want/need without having any framework in my way. Love it.
One caveat: I am a senior engineer 7+ years of experience. I would not have been comfortable having to do those design choices earlier in my career and Rails would have been better suited then.
It’s been a few years since I’ve used Rails, but when I did, it always felt like within a year or two a new version of Rails would come out and I’d basically have to rewrite the site from scratch if I wanted to update.
I don’t know if the codebase has stabilized but the transition between 2.x to 3.x to 4.x was pretty rocky from my recollection. Hopefully it’s better, since Rails is probably the best framework to get a site up and running quickly.
I've been using Rails since before 1.0 and the upgrade pain has decreased significantly over time. The worst upgrade I had was 3.0 to 3.1 where there was a performance regression that caused my test suite to go from 15 mins to about 8 hours on ruby 1.8.7, so I had to simultaneously upgrade to 1.9.3 at the same time. That involved YAML parser changes which I didn't catch before corrupting some serialized data in the DB.
Since that time both ruby and rails have stabilized their upgrades significantly. The biggest issue since then was updating to strong params, and that was only an issue for apps with a large CRUD surface area.
These days I think Rails is the perfect balance of stable and flexible for a wide swath of prototypes and apps. The areas where I'd look for an alternative would be web sockets, heavy concurrency (ie. needing more than background workers), or where raw compute is the bottleneck.
Specifically the change in the default to escape strings and having to specify when you want to pass it through unsafely (html_safe / raw). Broke a lot of v2 apps, but ultimately I think it was definitely the right call. Same thing again when strong_params become the default. So mostly due to security improvements.
v2 -> v3 also was the merb merging and a pretty significant rewrite, so it's pretty impressive that we didn't have even more trouble IMO.
I agree, totally true even with some small trivial apps. The few places a Sinatra app have worked for me are highly specialized, single method and generally have been for performance reasons and could have been in any other framework due to them loading as SSI or AJAX call.
Same with flask and django. And the worst is that the flask version is often riddle with security holes (not flask's fault) that would have been prevented for free.
I actually always say that despite the apparent easiness of the micro framwork hello world, you have to actually be very skilled to use them correctly to do anything beyong a few pages. While a full feature framework will make a beginer produce a decent work by default.
There are situations where Flask is good enough and very fast to deploy, while Django is overkill and more complicated to set up.
I agree that, should a system get significantly complex, eventually you will want Django; but a lot of projects simply never get there. That's why it's good to have a choice anyway.
They didn't say there are holes in Flask, but that the Flask version of an app is more likely to contain holes (presumably because you're less pushed into safe defaults).
Maybe that it doesn't sanitize the user input, but calling that security hole is a bit of a stretch. Sure you have the freedom to use some insecure libraries with flask but the same could be said about any framework.
Have you ever written a flask app yourself? It provides identical protections against xss etc. that you mentioned, as well as an auth plugin and tutorials on doing auth right...
I think it's unfair to spread a negative opinion of Flask because you had to work on an app that used it badly.
> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.
Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...
I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose.
That’s not always perfect or suitable for every use case, but it’s not a bad thing.
Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that’s one of my most popular ever: https://words.steveklabnik.com/rails-has-two-default-stacks
This sentiment also was a major theme of my forward to The Rails Way.
I’ve been thinking about this stuff a lot in the context of Rust...
For now, what I’ll say is that I’ve seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.
I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off.
Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on.
I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.)
Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.
I really don't care for Rails' components. But I think you are right when you talk about this -- monolithic frameworks allow you to get all these decisions out of the way and simply get on with developing your project. How much benefit are you really getting out of spending the time comparison shopping a bunch of serialization libraries instead of just picking on and moving on? Unless serialization is somehow a core part of what your application does, the benefit is probably quite marginal.
The big value that Rails adds is that it eliminates valueless choices. Most of the time, which logging library, ORM, view templating language, whatever doesn't really make all that much difference in terms of effectiveness and essentially come down to aesthetics.
When working with a framework that doesn't make those decisions for you, you end up with two big downsides - you waste time and energy arguing over which of these low-value choices you want to take, and new developers take longer to come up to speed with your particular architecture, since they need to learn each of the choices and how they are integrated, whereas in Rails it's obvious where everything is and how it's configured if you're familiar with the framework.
Bloat is also over-emphasized, particularly for the backend. You'll load the gems in memory, sure, but they're a fairly small footprint on their own and it's not like Rails is calling the parts of the framework it's not using (save maybe middleware, although most of that is useful for most web applications).
A big benefit of how opinionated frameworks preempt debates about marginal issues is that it's an externally imposed decision, instead of one team member triumphing over the others.
It really helps team cohesion for DHH to tell you that you're using X instead of Y as opposed to the most domineering devs getting their way every time. In my mind this even compensates for some suboptimal choices Rails may make.
> You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library.
But I'd rather spend my time creating business value than researching ORMs, templating libraries and mailers. And since I've never not been able to accomplish something with the ones Rails includes by default, I've never seen the need to use something else.
And guess what? Let's say you have that file parser that runs faster in Go? Send that call from Rails to Lambda and bam! you don't have to worry about infrastructure either!
If you're building a CRUD app (most are), then any popular MVC (Rails/Django/Laravel/.NET MVC/etc) will likely do. If you're worried about "Twitter/Facebook/Google scale" when you're starting, then you're doing it wrong.
I'm surprised to hear that a person can efficiently create business value without knowing the ecosystem of the language they are using. Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)
> Without a knowledge of what exists outside Rails, how do you know you're not wasting time and effort? (Not to ask how you're going to get your next job.)
So now you need to factor in research time. Then, continual research time, every time a new library or version of a library comes out. And if your research turns up that, no, in fact, version X or new lib Y is not substantively better (by whatever metric you're looking at), do you count that research time as 'wasted'?
> how do you know you're not wasting time and effort?
You look at the results of what you're doing vs what expectations were, firstly. You can then, periodically, look at your efforts, and compare reports from others who are claiming to do the same thing, and ... occasionally... spend time determining if a different approach offers radically better returns on the effort/results you have now. Switching to XYZ may also involve huge amounts of refactoring, upgrade, migration, etc. How do you know all that effort won't be "wasted" if new platform XYZ is abandoned 18 months from now?
"efficiently" doesn't necessarily mean "at maximum efficiency". Also, "business value" is almost always intertwined with hitting particular date/time goals, which often trump technical metrics.
Rails ain’t exactly new. It works pretty well for most things. I think most Rails developers generally stay abreast of large developments in the ecosystem, but the days where you would see significant benefits from being aware of every little library that comes out are long gone.
Yes, I agree that knowledge of the ecosystem is important to efficiently create business value. If I don't know that Devise exists and I roll my own auth library, that's a waste of time.
That's different than if I don't know that Sequel exists and I blindly use ActiveRecord. They're both ORMs. They can both read and write data from a database. And guess what — ActiveRecord is better for the vast majority of situations and everyone in the Rails community knows it, so my research into Sequel would have been time wasted.
Rails helps you avoid wasting time on this kind of stuff and pre-packages stuff that most everyone needs and where the alternatives are not substantively different.
The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think!
You also get a uniformity of understanding of your library and a support network.
Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.
The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.
> I don't think even the biggest Rails zealot would advocate building Google Maps in Rails.
Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.
The world is filled with other people. IMO, the benefit you get from another person being able to immediately be productive in your codebase vastly outweighs any benefit you would get from hand picking an ORM, a mailer, a templating library, etc.
And, anyway, Rails is pretty modular; you can rip out and replace anything that isn’t to your taste.
Choosing is much harder than it seems, and much more resource consumming. Then you have to integrate them. And of course test, maintain, document and update said integration.
All people I worked with that had your philosophy didn't so that last part, and it had important consequences for the whole project duration.
I completely agree! I worked with Rails 2+ years and it was really comfortable that everything I needed was at hand at the moment of scaling the application with new features or requirements.
After that, I needed to make some microservices orchestration and NodeJS (using Koa as the HTTP server wrapper) was a better tool to deal with all these asynchronous tasks.
But: Routing? Parsing JSON? Storing files in S3? Dealing with databases? Serve some static assets (e.g. Swagger)? Up to you! And good luck finding the up-to-date and standard library for your needs.
Overall, using workers, doing asynchronous tasks (e.g. starting a thread after hitting an endpoint) and coding orchestration endpoints (e.g. GraphQL) was a enjoyable experience where you have almost full control of what you were doing, but I still miss those days working with Rails where the community was so helpful in finding a friendly path to dealing with some common problems. My impression is that it feels less fragmented overall.
I haven't found myself an ORM as good and expressive as ActiveRecord or Sequel. Overall I think it has to do with all the metaprogramming tools you have available on Ruby. That's something amazing to deal with cookie-cutter problems, but also a problem when you need to do more granular control or get out of the typical CRUD problems.
> If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.
I have developed very nontrivial applications with Modern, which can be thought of as Sinatra-like, without regretting the choice or without implementing a bunch of Rails things. The web application is an immutable spec and defined as such; state is offloaded to dependent services pushed into your HTTP action handlers. Done. But, then, in 2018 (or 2016 when I started its predecessor), "an application" no longer required bashing into it ERB templates or the like, so I'll grant that it's a little easier.
I think that's totally valid. As web applications grow you run more and more into the need for new features and the need for common solutions, things that Rails already give you. For example, when I wanted to try out jRuby for an application of mine, one point that made that impossible was the existing usage of the sqlite gem. Had I used activerecord I could have moved it over to the jdbc api with a simple added gem, Rails would have set me up for that solution. Or locales: The construction I added into my software basically re-implements how a Rails gem is used.
But that's also the value in it: After you constructed a big enough Sinatra application you understand why and how Rails is doing the things it does. I think that's very useful.
This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]
I can't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]
There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.
There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release.
For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expect other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.
I say the best days of Ruby Rails has yet to come.
I would say no. PHP currently has a speed advantage, and it may be easier to scale, and the Psy shell is a very comfortable REPL. However, PHP as a language is somewhat restricted in meta-expression, and the syntax is clunky by comparison. Laravel borrowed a lot of Ruby's Enumerable library, but there are still things that you will miss. Symfony and the Active* ecosystems are probably comparable? I feel like when I'm following the execution of something in Rails, I end up reading a lot of two-line methods whose purpose is not at all apparent from context, and in Laravel, I miss the ability to do absolutely anything in a single line of code. Both languages have pretty comparable web libraries. The Laravel ecosystem is newer, it's slightly less likely that a given package will exist, and it may be buggy. The Rails ecosystem is more mature, it's slightly less likely that a given package will be maintained, and it may be buggy. PHP is almost exclusively targeted at the web, and Ruby is slightly more general-purpose.
If Ruby/Rails is an option, you're sort of baking into the comparison the idea that being expressive at the cost of performance is an adequate tradeoff. Ruby is going to win over PHP on that metric every time. In general, trading performance for expresssivity tends to be good; Rails has succeeded in spite of its performance, not because of it.
In what way? What is your metric? Laravel is slower, has less support in the community and uses PHP.. It also lacks webpack and SPA capabilities which are already baked into Rails. So in my opinion Laravel is actually behind.
Just did some quick Googling and looks like there is a Laravel port of Turbolinks. It certainly does look like they’re catching up. Surpassed? Not convinced.
"catching up" = copying most of what Rails is doing, not innovating or having any original ideas of their own. That's not really a sign of a strong community, and people working in Laravel might start asking themselves why not work with the real thing instead of a clone.
The Laravel community and projects/products that are part of it are very attractive from a small business POV, everything seems to work well together, knowledge is transferable.
You have Laravel for web apps, the Statamic CMS for blogs and content heavy sites, Jigsaw for landing pages, Maizzle as email framework, all using tech and conventions that Laravel devs know. On the frontend they promote Vue and Tailwind CSS across the board.
They actually make it possible for smaller shops or freelancers to have everything under their control. It's basically like a polished Wordpress ecosystem.
It’s a great approach for hybrid web apps. I didn’t want to go with a React only frontend where routing is controlled by react-router. I’ve opted instead to leave the routing to Turbolinks. This has a number of advantages. I get the benefits of an SPA while still being able to render server generated Rails views. This frees me up to use React only where it’s advantageous; like on real-time super dynamic views. I have multiple React entry points and the data is tied together by a shared Redux store. I’ll admit this was not trivial to setup but it’s been working great.
AFAIK anyway, Webpack isn't automatically installed with every Rails app but is easily available via https://github.com/rails/webpacker. So it's not "bundled" necessarily all the time, but is quite trivially added to a Rails project.
If your question is more like "why the hell would you ever want to run Webpack and Rails simultaneously together":
You will increasingly find tools you want to use that more-or-less require Webpack (or a similar JS build tool). Because of things like e.g. the asset pipeline, it's extremely frustrating trying to get those tools to work in concert with each other as micro-services that know nothing about each other. It's much easier to use something like Webpacker so they can play nicely with each other.
I get the idea, it just seems like a very "2013" way of doing web development. Things have moved on past the monolith for an endless amount of reasons.
I used to believe the same as you and wrote quite a few web apps with dedicated backends and frontends. The overhead and amount of redundancy doesn’t seem worth it to me anymore though and I’ve turned to hybrid apps. Development time has dramatically improved and I’ve lost literally nothing.
Rails can be used without the asset pipeline and with Webpacker only. But yes, most likely you will not use API-only mode of using the asset pipeline or webpacker.
I have been thinking about this quite a bit. Just so happened one of my favourite site was redone in PHP Laravel as Backend and Vue.Js. And they did the whole thing in less than two weeks! I than checked out larval, and I have to admit PHP Laravel is the closest thing to Ruby Rails in terms of productivity.
React is an in-browser component/templating/state management framework. Apples to oranges.
Furthermore, I don't see GitHub as a great application for an in-browser state management system. Rich state frameworks are great when you're making an system with a real load of state in the frontend. For example, a spreadsheet or a rich word processor or design layout application. For an application with little mutable user state in the frontend, all you do by using a full-on UI framework is add complexity and introduce a huge state-synchronization / distributed systems problem, as well as introduce the need for complex/hacky server-side rendering workarounds for users, snapshots, and search engines which don't have full runtime capability. Using React on your blog is almost certainly a mistake and using React for GitHub feels like it's right on the edge of being one as well.
They were probable referring to the web implementations of office, it's the only interpretation that makes sense in my mind. Were you aware there was an online version of office?
Disclaimer: I've worked with but dislike ruby and rails in comparison to other choices (whether language or ruby framework).
IMO people are still using rails because a bunch of orgs moved to it from Java years ago, or started with it after some successful hackathon. It's in wide demand because a large number of orgs mindlessly (or mindfully) chose it long ago. Basically all enterprise/large company apps I've seen have been in either Java or Rails. Some places are still using COBOL. Some places are still maintaining/starting codebases in COBOL. I assume that people will be able to make this same argument about NodeJS in ~2-5 years.
Also, the the point about micro-frameworks being bad being made in the comments because you eventually re-implement rails seems to be wrong or badly articulated -- that's exactly the point of using a smaller-yet-composable tool, you don't use any parts until you need them. Sinatra has also leaned into this by allowing pieces of rails to be loaded, and providing a path to transitioning to Rails proper.
I dislike rails because there's too much magic, and too many ways to do things -- it's precisely why I like micro frameworks. Also, the (request, response, next) middleware/handler paradigm is the most composable way to write server software I've ever seen.
There's a little big detail w/r/t java comparison: every company I've personally worked with who uses rails for their backend vs java moves WAY WAY WAY faster. So in terms of the "enterprise stack" dichotomy, there is a difference in kind between rails/java.
I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.
I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.
And there are some companies where you need to move fast while at the same time need to have high performance (100.000 req/s with 30-50 ms mean latency). In that case Java is the only option between Rails amd Java.
The gap between Scala + Play and Ruby + Sinatra (or cut down Rails) is not like it was in 2008. Ruby 2.5 is ~13x faster than Ruby 1.8. Now you're lucky to squeeze 3x the web throughput out of a Java/Scala service as opposed to CRuby and JRuby closes that gap further.
Can you point to me any performance site where Ruby 2.5 + Rails that backs your point? If you use JRuby than you are on the JVM already. In that case why Rails at all?
My own experience at ChartMogul with building production services in Ruby, Go and Rust is that the overall throughput of REST API type services increases a disappointing amount.
With JRuby you get to retain all the benefits of the Rails ecosystem. Most of the Go and Scala community is driven by much larger companies who do open source libraries but they don't really build frameworks to help developers build software quickly.
People that have the skills to pull off a complex site __correctly__ with just a micro framework are rare and expensive.
But people that can do it and make it easy for the team to scale are unicorns.
I've yet to meet one that stays on this kind of missions for long because they get a better offer, leaving the custom project to people without the skill to manage it.
And if you think all that is easy, you are not that unicorn because you don't have a perspective going beyong your code files.
I’d just like to chime in that myself and the other rails developers in my company use rails because we love it (in addition to it being the right tool for the job). I personally find ruby a beautiful language and using it every day makes me happy.
I didn't mean to say that no one uses rails because they like it -- I fully understand that rails was not only caused a watershed moment for web development (particularly server side), especially when what came before was java in large part. Also, having survived perl I've never seen a "scripting" language handle flexible syntax/paradigms as beautifully as ruby has -- it is certainly a beautiful language.
I think the increased productivity, beautiful language that rails is pushed everyone in the right direction, I just personally think stopping there is a bad idea, and that while rails is great it's not necessarily the reason it's in widespread use.
I didn't see any mention in the article of comparing install rates for rails versus other platforms (since of course this info is hard to get) -- and there are tons of rails-ish software out there (django being a huge one). If django had been the thing to break through and rails came after I think the roles would simply be reversed.
This was a common complaint about Rails years ago. What are the "magic" parts in current-day Rails that you dislike?
(I disliked the dynamic finder methods, e.g. find_by_city_and_state, which you would now do using arguments to where(). I also disliked the default routing which made every public controller action routable, if I remember right. Those are now either deprecated or removed.)
These days I don't really work with rails codebases, so I don't have any recent examples in mind to call upon. There's just a bunch of stuff you need to know about how rails works before you can successfully read/understand rails code -- I just remember seeing all this stuff in code and I was just thinking "where the f did this come from", and then realizing that the version of rails we were on had this feature that tied together these two parts with some obscure method.
I haven't even looked at Rails 5 or worked in a recent Rails 4 codebase so I'm sure things are much better but the code I remember the feeling of being perplexed so often at how a worked in previously wasn't my own so I can't go back and remember what parts really made me angry.
How is that different from any new codebase you have to look at? If anything Rails reduces the confusion because it has a set of agreed to conventions. I can’t think of any decently complex codebase I’ve ever come across that didn’t have it's own weird abstractions that aren’t immediately clear.
Disliking Rails’s built in abstractions seems to come down to only liking abstractions your own devs created which sounds like not invented here syndrome.
It's more which tools are used to make abstractions -- I find that rails uses and encourages implicit (auto-created methods, stuff injected into a method's scope) abstraction creation rather than explicit (functions/higher-order functions) abstraction creation.
Interesting. I've honestly never heard the complaint about "magic" and abstractions made so concrete. I still believe many of auto-created methods are a good thing and generally done with the thinking that if you do X in 80% of cases the same developer also wants Y. Which makes perfect sense to me but I can also see how that would be surprising and/or annoying.
I’m not seeing how your complaint that there are too many ways to do things in Rails leads you to using a micro framework. Since Rails makes a bunch of choices for you ahead of time, there should be less ways to do things in Rails vs a micro framework.
I don't really have an exact example for you -- the last corporate rails codebase I touched was 2 migrating to 3/4, and the last rails guide I saw was 4 (rails is on 5 now?)...
More generally, my point was that smaller libraries have less space for multiple ways to do things/overlapping concepts. In the codebases I've worked with, I've found myself questioning whether to use one specific rails concept or the other and the resulting "right" choice seemed arbitrary -- like whether I should make a controller mixin or create a helper.
For example, if you look at a framework like sinatra, the smallest/simplest thing you use to respond to a request is just a function. How to use functions properly is pretty clear, there's not much else to debate over.
“And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."
The author has no idea what they are talking when it comes to the alternatives.
I was making simple CRUD apps in Phoenix (the types of apps I would normally use rails for) for a year before I even looked at OTP. You can become productive in elixir and Phoenix very quickly especially if you come from a ruby/rails background.
I recall a blog post by dockyard where they said they had new hires making commits within the first week.
The author isn't wrong. You need to learn OTP to know that you don't need it (at least in the very beginning).
When I was learning Phoenix, I spent a substantial amount of time learning Elixir as well and OTP is one of the first few things they put in front of you. Don't get me wrong, I loved learning about it personally, but I am not surprised that a lot of people would consider it too much effort.
> In summary, we 'still' use Rails as it works just fine.
PHP works fine. COBOL works fine.
Nobody ever said Rails doesn't work. Or doesn't work fine. That's a straw man.
It's just that Rails, and Ruby in general, is in clear decline. Not just because some new flavor of the month frameworks are coming out, but because a lot of the concepts Rails supports are antiquated, and Rails hasn't shown to be that adaptable to more modern front end trends after years of efforts from DHH.
Hell, I'm sure that even DHH himself would be very upset if people settled for something that "works just fine". He's just not happy that this time around, that characterization is being used to describe his creation.
1) "a lot of the concepts Rails supports are antiquated" ...
2) "Rails hasn't shown to be that adaptable to more modern front end trends"
Would you mind elaborating? What Rails concepts are "antiquated", and what "modern front end trends" does Rails not adapt to?
I've never done any Rails development, but understand the general idea of how it works, so I don't have any skin in the game. I'm just honestly curious about what you were referring to.
I imagine SPA trends with frameworks such as Angular are leading to the parent’s conclusion. However, you can still use SPA frameworks and just use Rails as an API, or you can take a step back and realize a large percentage of web apps still don’t need a complex SPA framework and might get enough front-end functionality out of something like Vue. In other words, many developers fall into the trap of choosing tools they prefer even when they may take more time to use and not provide enough business value. Plenty of web apps would ship faster if built with Rails and be just fine.
> It's just that Rails, and Ruby in general, is in clear decline
[Citation Needed]
In my experience the demand for rails has only gone up within the last few years and rails is only getting better.
> Rails hasn't shown to be that adaptable to more modern front end trends
You clearly haven't been keeping up with rails .. Rails now integrates seamlessly with React, Vuejs,.. and has built in support for yarn and webpacker .
In addition, with the introduction of ActionCable, you can have websocket integration as well with Pub/Sub.
All in all, Rails remains a very mature, robust framework to build your business on.
Not apples to apples but I don't see the decline in Rails. I would say that I definitely see fewer job postings for Rails work overall and more for separate backend and React work.
This is still sort of the mainstream view on this, but I think a return to monolithic Rails-style frameworks is coming. Microframeworks and especially Node got a lot of popularity, and then all the microservice stuff started to get popular and overused as well, and ultimately this is leading a lot of people to do unnecessary work and ending up with a custom solution that isn't as good as what they could've had off the shelf.
As for modern front end trends, Rails is getting better in this regard, especially since 5.0. Most people typically have a separate frontend and backend codebase anyways, so in that sense Rails API is all you need, and that's baked in now.
From conversations with an experienced PHP dev who was recently looking for remote opportunities, all of the good and high paying options were in Ruby.
PHP suffers from an abundance problem where programmer opportunities are concerned. There are a lot of “PHP” developers with skill levels that are highly variable, from Wordpress devs to really hardcore programmers.
This is very true as a php developer myself I notice that there are a lot of low pay wordpress jobs available to php developers. At the same time you can get more serious jobs with equivalent pay as other languages in php but there seems to be a lot more competition for them.
> because a lot of the concepts Rails supports are antiquated
I actually see Rails as a framework that has managed to keep up with the times better than most. Django, for instance, has aged less well than Rails imo.
What alternative exists that’s better than “fine”? All of the popular framework options have major cons/arguments against. It’s almost as if some of the choices we make when picking software development ecosystems are subjective.
As much as I like Rails, those are two examples of catching up. The approach from Active Storage has been the way uploads should have been handled for over a decade and Action Cable is good-enough-for-prototype but otherwise not scalable at all.
Over a decade? That long ago, we were storing image uploads in a BLOB column in Oracle! I used Heroku, AWS and GAE within a year of each of their debuts, and if I recall correctly, there weren't a lot of frameworks that had a handy dandy approach to generically storing uploads in <XYZ-CLOUD>. Were there any even?
And as for Action Cable, I hear anycable.io can give you a performance boost if you need it. I've used websockets in both Node.js and Java Spring and although it's awesome for some use cases, a majority of apps will never reach for it. So this is a good example of Rails focusing on things that will help most people without trying to cover every tool that everyone will ever desire.
I'm waiting for a framework that covers the whole stack and also makes it easy to make SPAs, if you wish. When that arrives I think it'll really take off.
For a while Meteor seemed to be that framework, but for a number of reasons — performance issues, lack of support for SSR - it hasn't taken off. While it's often good practice to separate the API and the frontend, for solo developers or small startups that's often overkill and adds complexity.
Or - get 90% of the benefit of SPAs but leave your business logic where it belongs (on the server). PJAX/Turbolinks/Intercooler or something similarly lightweight is probably all most people need when they reach for full-fat front-end framework.
Yes, for personal projects I've moved away from SPAs to backend frameworks and as little JS as I can get away with. I admit I don't know how easy Turbolinks or PJAX are. A while back when i played around with Intercooler in Django it wasn't seamless.
Turbolinks and PJAX are really what a lot of folks wanted before the web development community at large was introduced to client-side routing through SPAs post-Knockout.js days.
You might be interested to look at Drab in the Elixir / Phoenix ecosystem. It takes advantage of the lightning fast view layer of Phoenix as well as Phoenix Channels to manage everything.
Approaching 1.0 it’s the most unique approach to the problem I’ve seen.
Drab is a hex package, so asking if it supports hot code reloading isn't the right question. As to the second question, the answer is yes assuming your server side hot code didn't break the client session, and didn't introduce an API mismatch.
Spring Boot. It has monstrous enterprise horsepower, supports many deployment models, scales horizontally and vertically, easily configurable as REST or MVC with built-in views or both concurrently, can be bootstrapped in 30 minutes.
Meteor dropped the ball so hard, it's a net loss for the world!
If only they had come out with routing baked into the project, and react baked in. They would have survived. None of this "we support 29 different routers but zero documentation on how to integrate it with meteor."
Now it's dead, used only by legacy apps or tinkerers. No real mass use applications are being written with Meteor these days.
Imo Rails is currently the fastets most conevenient framework to develop in because of its comprehensiveness and maturity. But what I'm looking for is something more radical [copying my comment below] where the frontend and the backend is more integrated. The way it's done now data structures are duplicated. Of course this has to do with how things are done with REST over HTTP. Meteor actually implemented their own websocket protocol -- it's ideas like that I'm looking for.
Of course you risk making monoliths with this approach, but like I said I'm primarily looking for something that makes it easy for solo developers or small teams.
I built a huge SPA application that is real-time connected by web sockets (Turbolinks which is included in Rails) with Rails. I did it in 3 months, alone. Hired our first engineer and we can tackle pretty much anything that comes up. I think Rails has worked incredibly well for a small team. The addition of webpacker allowed us to use React where it makes sense and Rails views everywhere else while Turbolinks holds it all together. Rails is the framework you describe.
You don’t really duplicate that much between server and client. Yes, you have models on both. But the models do different things. Server is all about validation and querying a database to generate responses. Client side is all about user interaction.
The whole Rails ethos is about admitting that your app isn’t really special and that what you’re doing is pretty similar to what everyone else is doing. So it’s better to decide on the best way to do things as a community so you don’t have to roll your own framework.
FWIW, my experience is different. I spend almost no time in Rails doing anything other than implementing the business logic that is unique to my app. But I’m a go with the flow kind of a guy.
DRF is nice, but what I'm looking for is something more radical where the frontend and the backend is more integrated. The way it's done now data structures are duplicated. Of course this has to do with how things are done with REST over HTTP. Meteor actually implemented their own websocket protocol -- it's ideas like that I'm looking for.
Of course you risk making monoliths with this approach, but like I said I'm primarily looking for something that makes it easy for solo developers or small teams.
We still use Rails and it's a good fit for getting projects off the ground quickly and validating ideas. It's a niche but it's an important niche.
Once Rails projects get beyond a certain size though they start getting exponentially more difficult to maintain. My sense is that Node is going to surpass Rails by sheer brute force eventually. When I work in JS now I'm just amazed at how much better the tooling and performance is than Ruby and ES6/7 is overall a pretty nice language to work with. And having something like Typescript is essential once a codebase gets big enough.
By tooling I mean things like code editing, linting, type checking, debuggers and runtime quality and performance. As far as I can tell Rails is still a lot more polished than any JS web frameworks.
>>And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags.
You don't need to learn OTP to become productive in Elixir/Phoenix. It's abstracted away from you, but also gives you the ability to dive in if you want/need.
I think it's disingenuous to say you don't need to learn OTP. You need to learn the basics of it, or you will struggle, because you will be trying to solve problems in a way that doesn't fit with the underlying language and runtime. That said, learning the basics of OTP is super easy, and can be done in an afternoon (spawning processes, sending messages, supervision, understanding what applications are in Erlang/Elixir parlance).
It's like saying you can build a Rails app without understanding classes/objects - sure maybe you could throw something together because the tools are so friendly, but you would get lost pretty quick when trying to do something on your own. Learn those basics up front, and you can get a long way without having to delve into more advanced topics.
One of the biggest and often overlooked features of Rails is rspec and db:migrate. For whatever reason, I have yet to find alternatives in other frameworks that have matched the elegance of these 2 indispensable tools.
Similarly, while I'm not a huge fan of ORMs im general, ActiveRecord is pretty hard to beat pound for pound.
People take for granted that Rails provides the closest thing to Aspect Oriented Programming that exists today (that I know of).
I don’t use rails regularly anymore, but I used it long enough to appreciate what it gives you. As long as developer efficiency and time to market is more important than than micro performance optimizations, Rails and other options that emphasize developer efficiency will continue to succeed.
Unless you’re in an established enterprise environment, that is generally going to be the story.
>And then there's the Phoenix framework. Chris McCord wanted this MVC framework for Erlang, where Elixir is based on Erlang, used mostly for large scale backend systems. And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."
This is false, you do not need to know OTP to be productive.
These days if I'm forced to work with Rails, I almost always write functionaly-kinda-ish Ruby code. Elixir sold me heavily on the idea of one input in, one input out and all the other good that comes from functional programming.
I probably no longer write idiomatic Rails code (40 methods in a ruby model).
I commented elsewhere already, but you do need to know _some_ OTP to be productive. But those basics (processes, messaging, supervision) can be learned easily in an afternoon.
In my opinion, OTP is not the reason why the learning curve is steep. If anything, the learning curve is steep for those trying to switch from something like Ruby to a functional programming language for the first time. A language with immutability as the default, no concept of classes or objects (though viewed through the Alan Kay lens, processes could be seen as "true" objects). If it is your first FP language, most of one's object-oriented experience is not going to help, so there is a lot to absorb before you even get to Phoenix or OTP.
In 2007, Rails was the hot new fad like Node.js became a decade later. Now it’s the boring legacy app, like Java was in 2007 and Node.js will be around 2020. Looking back, all this effort now seems like mostly-pointless reinvention.
No one avoids Ruby/Rails because it's old, we avoid it because it locks you in to conventions that most other modern languages / frameworks considered bad practice, like magic, metaprogramming, one process per request, locked in to OO, the concept of "controllers," separating templates from view logic, and doing everything at runtime.
That, and generally ORMs are out of practice as well. Using rails without ActiveRecord is almost pointless to me.
Even when I was programming primarily in rails in it's hay-day (2010 - 2013), I was always swapping out my inefficient AR queries with just custom SQL. I am generally a "performance doesn't matter that much" kind of guy, especially when people try to micro-optimize, but one place it matters a lot is with your data. These days I just go straight for SQL and save myself a lot of trouble. There will always be impedance mismatch between your data store and models, and ORMs in their ambitious attempt to serve every use case, at times, generate some really inefficient queries. ORMs really like to stay within relational SQL databases as well, with half-baked support for a couple NoSQL stores like Mongo, but then get into Cassandra or Dynamo territory and they are useless.
I can see how some of those things could be controversial, but there are quite a few popular tools out there that do everything at runtime. Also, didn't know most frameworks consider "controllers" to be bad practice. And since when is it so terribly harmful to separate templates from view logic?
The usual amount of snarkiness I've come to expect from the Ruby community. What a smarmy tweet:
"Lol 20 something developers using new tools when they could just use this ancient slow dynamically typed OO language I allied myself with doing the exact same thing 10 years ago"
Ok I'll bite:
- Because it had it's milkshake drunk by nodejs which has better support for modern front end workflows and great languages like typescript built in top of it. And is faster and better supported.
- because it's slow and difficult to scale
- because it has years and years of baggage
- because I prefer elixir it golang or rust or Scala
- because it's not a perfect fit for every project
- because I do not like stateful object oriented languages with magic so I can trust my intern and Jr devs to write something decently maintainable
1. Node on the server does not have a comprehensive framework that compares to rails. You'll roll your own, and it will suck.
2. It's not any more difficult to scale than Node, you'll just need more servers to handle the load. Horizontal scaling works basically the same for both platforms.
3. Well understood baggage is better than baggage only a handful of people in your company know about as a result of your custom web framework.
4/5 of course nothing is a perfect fit for every project and everyone has their preferences, but this can be said for any language or platform so it's sort of a non argument.
6. Good luck finding interns and junior devs who can be productive writing in some esoteric functional language.
extend ActiveSupport::Concern
attr_accessor :foo
class << self
included do
def method_missing(name) do
define_method(:after_save) do |bar|
...
end
end
end
end
What do you mean? This stateful, first class mixin OO metaprogrammed magic, implicitly globally mixed in to your application, makes it super easy to understand the flow of your application and the capabilities of your system. It's also super easy to see where things are defined, and the structure of methods/classes/object doesn't depend on luck / the order your program _executes_ in! Fat models are the way to go, there's obviously no problem with stateful mixins to "separate" model logic and make sure your model can do absolutely everything, because what is data, really?
Perfect for junior and senior devs alike.
edit: I forgot to include `method_missing`, which definitely isn't a design flaw, and there's absolutely no fundamental community problem that Ruby developers don't see any problem with using it.
Since discovering Clojure in 2013 my biggest regret is that the Clojure community is not interested in building a Rails equivalent. I don't mean an MVC clone but a full-featured web framework supported by the wider community rather than someone's personal curated list of libraries like Luminus. I think Rails set the bar for whether a new language can transition to mainstream adoption.
I only did a short stint in web dev between undergrad and grad school for about a year. We used Rails. This was about 7 years ago. Are the reasons Rails has fallen out of favor technical or faddish? Or a little of both? I'm not intending to start a flame war of any sort. I'm just curious, having been out of the field for a while.
I have a few Rails apps. Team now wants to move to nodejs. I made a few apps in nodejs. It's such a mess, yarn vs. npm, webpack setup. I guess nodejs community is still searching for their holy grail (Rails.)
It was released in 2004. Youtube and twitter didn't even exist then. The iPhone and Android were still 3+ years away, which means mobile internet as we know it today wasn't around then either. ROR has been around the block.
Sinatra is frustratingly limited in some ways. I would describe it as easy, but not simple. It’s easy to use it to bang out any use case the authors foresaw. But now I’m going back and reading the code all the time to figure out how to accomplish certain things. And that reading is difficult, because like some other Ruby things it’s more focused on providing a pretty DSL for the user. How-to docs for basic things are easy to find, but reference docs aren’t, and often just list methods without any description of what they do.
If Rails is in decline it's because almost all languages now have some sort of MVC framework on par with Rails now. Since C# is used in the enterprise it's just natural to go with ASP.NET MVC Core instead of trying to get Rails to run on Windows. In my opinion, I feel one of the big mistakes that Rails made was not focusing on getting it to work officially on Windows.
Why rails should bother? There are plenty of other ruby gems and their developers who don't care about Windows. Even if Rails works, you can't convince community to make every single gem compatible with Windows. So it makes no sense.
As we transition to a more multicore, multi threaded environment Ruby cannot perform well. And thus by induction Rails.
An interesting way forward is functional programming, because of its composable nature can perform really well in such environments.
I dont see where Rails ideal niche exists going forward, is it in Large Apps that need really scalable apps that exist on multicore environments?
Does it lie in small SPA like apps for which it has virtually no support? or
Does it lie in the middle where you just throw more hardware at the problem before rewriting the whole app?
In the last one yr i have seen more enterprise apps being activated in Nodejs than in Rails. Why does the enterprise Like Nodejs while Rails is on its downward spiral? i suspect it has to do with Nodejs being Beginner friendly.
I left the Rails ecosystem 3 yrs back never looked back, and i dont see why i would ever go back.
Enterprise moves over to Node mainly because of hype, sometimes performance. Node is very library based, there is no framework that can compete with Rails there. In the wild Node web projects often lack a coherent structure because there is no agreed upon way to do things. Rails is perfect for e.g. inhouse websites in the enterprise.
It may not be just hype, Javascript is fashioned like C, most normal devs feel comfortable around C like languages. Infact a good testament to this is the growth of Typescript which makes both C# and Java crowd feel at home.
I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light.
Rails' biggest problem is that it isn't JavaScript, and thus code is not portable between client and server.
I have rarely seen the mystical pattern of "sharing Javascript code between client and server" actually work in a scalable and maintainable way outside of having a shared "enums" file.
Things like lodash, moment, validation logic, and http libraries are the big benefit of this. It is generally less of business focused code and more of utility type code that is easy to share. I do this on a daily basis, and have been for years.
Out of curiousity, where have you found it useful for code to be portable between client and server?
I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.
I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened.
I've also found it useful to have TypeScript on client and server to be able to share types between them.
Also, when using React, Node on your server makes server-side rendering a lot easier.
Personally not so much in model code, but in typescript interfaces/DTO which are used by both routing-controllers on the server side (additionally generating swagger api docs along the way) and by mobx on the frontend.
If that were so true why would people rewrite apps in Go or use a JVM Language? Process based parellelism is memory intensive and you a=have no control, the best one can do is hope that the scheduler of the OS will take care of everything. Also code portability is not the issue, it is about what gets you started quickly scale well for a long time and dont ask for rewrites. Rails doesnt fit the bill, you cannot get started fast, It doesnt scale well unless you throw more hardware, MVC breaks with slightly complicated apps.
Ruby IS a JVM language today via JRuby. You get JIT, thread parallelism, and all the usual compacting GC goodness etc.
The GIL in CRuby means you need one process per core but that's also true of NodeJS.
Processes and threads aren't as different as you think. Linux pthreads are "just" processes which are allowed to write into the same memory. PostgreSQL remains process based to the day, although it does give them a little pain.
Rails is optimal for the web-tier which is traditionally scaled by being stateless, so you have one process per core (or thread if you are using JRuby) and you are done. It's ironic you list Node as the path forward since it is also single-threaded. Obviously it is more efficient on the baseline with async IO, but it still requires the same number of processes to saturate multiple cores, and you can also trivially eat into the IO overhead in ruby with green threads via Puma.
Rails has a problem most are aware of, When i started rails few yrs back, they said skinny controllers fat models, but in a few months our Models became 3000 lines, so they said external loading libraries, then came concerns, then they took concern back because it doesnt work. Then another solution came in the form of gems, people thought lets make more gems we have tried so many different ways to do this. If that is not all there is a problem in rails that exist purely because of the way the framework works. The mass assignment problem, this problem literally doesnt exist in any other framework. What we do with this is a patch to restrict an action, but it really exist because of the nature of the framework. This is a code smell if your program due to its very nature creates problems that needs patching is probably not doing something right. In my opinion best is to go back to simpler ways of organising code. Rails is too much an abstraction that creates its own unique problems.
Seriously though, the only problem firebase solves is the question "what infrastructure decision can I make right now that I will regret as soon as possible?"
I'm being facetious but then I feel like this whole thing is a joke, so it's kind of fitting.
I've known a lot of people get started quickly with firebase and then proceed to have to yank it out for the nonsense they run into. I also question the real value/merit of firebase.
Heroku did this properly imho. They are a perfect example of how one can provide hosting that actually is helpful and sophisticated where it needs to be but gets out of your way when you don’t need to care (for 99% of applications that don’t need to scale beyond a certain point).
Firebase excels for real time/multiuser/shared data scenarios. It gives you things out of the box that are not trivial to implement from the ground up.
You can also use something like Firestore if your backend is primarily a place to store data. Combined with e.g. Next.js you can develop quite quickly with it.
I actually noped out of a contract when the client wanted to bet his entire infrastructure on firebase. Data, documents, authentication etc. Now I'm not familiar with Firebase, but I am familiar enough to know when to bow out. Their company in for a wild ride.
I actually don't think MVC (the way Rails implements it) is a very good fit for web development. A project shouldn't be divided by file types, but by features. Django does it a bit better. The way it's done with Pages apps in .NET Core 2 is also interesting.
I downvoted you for talking babble that has little basis in reality.
With that said, don't take downvotes on HN to heart. I get downvoted for the most innocent or earnest of comments. It's not signal. Comments are signal.
In the end, It's up to you to decide if discussion or internet points matter more to you.
This. Rails is perfect for fast development of CRUD in MVC, but if you're building anything complicated, you need something that supports more options than MVC. People can laugh at PHP all they want, but a framework like Symfony runs circles around Rails. You can do both simple and complex in it. I haven't tried Hanami yet, but while the frameworks concept seems much more promising than Rails, it's community is much smaller.
Still Rails is very populair, also here on Hackernews. Probably because the things we need to do in real life are actually not that complicated as we often make them out to be.
Probably, the ability to dump arbitrary 3000-line classes into arbitrary directories. If you happened to start out working with Zend and then moved to Symfony, you might have strange ideas about how Rails is structurally too opinionated.
How much of that do you think is a good thing? Zend was essentially an unstructured collection of arbitrary classes which were more-or-less interoperable. Class names needed to be globally unique, and namespaces didn't exist, and there were no conventions about where third-party code should go, or a very effective class registry, and dependency management often meant PEAR, which was like CPAN, but terrible. The idea of having arbitrary files in arbitrary places is something that any framework should be able to accommodate, but having some sort of well-defined folder structure is really quite necessary (in my opinion). It was not really the norm in Zend, and the tools and libraries and conventions and language are all much improved since then, but it's still possible to write ad-hoc-structured code using Symfony, and there are developers who prefer this.
Yes, ActiveRecord is not a good pattern for large-scale apps. The reason it's in Rails is because it's very good for simple cases and prototypes. But there is absolutely nothing in Rails stopping you from adding a service layer in whatever shape you see fit, I'm a fan of interactors (https://github.com/collectiveidea/interactor), but use whatever you want, it's easy to plug in new directories into the app structure and get magic loading and spec running automatically.
I agree that Rails enables a lot of messes, but I don't think the solution is to make your framework prescriptive about every single detail. I'd rather have the flexibility and enforce some standards per project than expect the framework dictate everything, because once you hit scale you have to do your own thinking and architecture anyway.
I wish Rails developers would listen and understand real flaws in the ecosystem instead of downvote. I happily admit major flaws in all languages I prefer to work in. Skinny controllers and fat models are both solving problems that never needed to exist in the first place.
I found getting into MVC stuff back in the days rather cumbersome and in 2009 many of my friends did internships as Rails devs, they went in hyped and came out disillusioned.
It always occupied a strange niche between stuff like WordPress and SPA/PWAs (sinatra+front-end fw)
Let me make sure I follow you: you think Rails, the top framework used by startups, occupies a "niche" between wordpress and SPA's; and you think sinatra + any JS frontend the bees knees?
This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.
To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO-FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow implementation of half of Ruby on Rails."