Ruby on Rails: The Documentary [video]
youtube.com
youtube.com
The latest developments in Rails are making the solid foundation even more solid. There is stuff happening to make infrastructure easier: Kamal sure, but also Solid Cache and Solid Queue and there is a lot happening in the front-end with Turbo (Morphing) and mobile apps with Turbo Native and Strada.
We have upgrade to 7.1 already and have a mobile app in production that is built with Turbo Native. I am also excited to start replacing our Redis cache with Solid Cache to make everything simpler and cached longer.
Great to see the Rails community so alive and see the deep connection the (ex) core team members have to the framework!
I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's more frontend-y.
Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks.
P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s
Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features).
I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.
Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.
Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).
I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.
Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.
Django is to Rails as Flask is to Sinatra, imo.
Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.
There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.
Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.
I would like to introduce you to Adonis. https://adonisjs.com
But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.
https://packages.adonisjs.com/?category=Rendering
And the fact that these aren't official is kind of the point I've been making. In the JS world there isn't a holistic fullstack framework. You have to stitch it all up yourself. In Adonis, Express, Fastify, Next, SvelteKit, etc.
Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.
> In the JS world there isn't a holistic fullstack framework.
This is true for all monolithic frameworks in every other language. Even Rails you have to use 3rd party addons for stuff. It's not feasible to build everything in for every possible use case, so they make it easy to add on stuff.
I think now you're just starting to move the goalposts.
I'm not talking about adding client-side interactivity though. Read my comments again.
> I think now you're just starting to move the goalposts.
I think you're not really reading my comments.
Obviously no solution will solve everything 100%. That's not even an argument.
I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates.
Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas.
Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code to the client at zero mental cost since it's mostly the same APIs
Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).
I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.
why?
Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.
EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).
https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.
By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:
https://insights.stackoverflow.com/trends?tags=next.js%2Crub...
Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.
Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.
This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.
This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).
Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.
The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.
I've learnt a bit of Django's app-centric model (which is similar to rail's "engines")
I work for a company that enforced the data/domain/interface with a plug-in approach to custom code.. and I liked it.
But for my own projects, I get stuck choosing between the two, I see more benefits in the layered approach, but I feel like I'm fighting the tide with every project I start
The downside is if you want to do something that cuts "across the grain" so to speak, things can get messy. Combine that with Ruby's high dynamism and someone trying to be too clever can make a mess fast (alias_method_chain anyone?).
Yeah, node has been incredibly successful but I think it's a fair criticism to say it's also a victim of that success in that it just feels like so much arbitrary complexity. And the flavor of the month changes so fast that projects end up this weird mishmash.
Ruby 3.3 YJIT is 2x faster than Ruby 2.5 in RailsBench.
Work on brining more Ruby Gem from C to Ruby ( easier JIT )
Lots of dev tooling around Ruby and Rails coming.
Hopefully there are more good things to come in Rails 8.0 and Ruby 3.4
Which specific documentary is it? Google seems to return a few different options.
Do I have to deal with JavaScript in any way?
Sure can. However I won't pretend it's the only framework you can do this with and be productive. I love Rails and Ruby but it has great competitors these days.
> Do I have to deal with JavaScript in any way?
Really depends on what you're doing but probably.
You can use Hotwire (look at turbo frames and turbo streams) and you will write less Javascript code while achieving some very nice interactive UI.
I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective.
I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster.
What you're saying here is true in theory, but what you're not telling people is how the community is about as close to the attitude of npm as you can get on the server side. hundreds of gems on your typical application, many of which are used in 1 or 2 places, helping avoid a grand total of less than 5 lines of code.
Then there's the ratwheel you opt into with rails. Every single damned time I find myself having to manually patch libraries to get it working properly. I even once had to track down an old Ubuntu image of a version that had EoL'd 5 years prior and THEN had to manually patch a few C dependencies just to get it to build and run.
Don't even get me started on wkhtmltopdf, fuck that dependency. If you use that in your RoR project, fuck you.
^ that's only partially meant to be humourous.
My experience is that developers suggest RoR then run off into the sunset on their new project, leaving companies not understanding that they're now on a ratwheel of maintenance and upgrades until it's so bad only someone such as myself even has the skillset necessary to pick up the pieces.
Contrast this with asp.net core. Each LTS version is supported for 2 years (which is too short imo), but more importantly, you can install the EOL versions just fine. I would never recommend RoR over asp.net core (asp.net 6+ ... LTS only) because developer productivity isn't worth the maintenance cost.
Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?
non-LTS is 2 years, LTS is 3 years
https://dotnet.microsoft.com/en-us/platform/support/policy/d...
imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity.
I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.
The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...
I've repeatedly seen the same things over a 15+ year timespan.
Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.
It may be that slow tests are just easy to complain about, and there isn't much business value in doing that. Totally fine. But, other things come to mind: weird cottage industry of gems that did dubious things to speed up tests (and were prone to breaking), the skepticism around interactors, the hegemony of active record (the pattern). None of those are bad things, but they reinforced the fact that the technical values of the Rails community do not work for me.
it looks basically the same in structure whether it is the
biggest Rails app there is or a new one
In addition to easier onboarding, it greatly reduces bikeshedding.
MVC maybe isn't the best paradigm for everything, but it's good enough for most things.
I agree! I think maybe because the consistency only shows its value:
* over years
* in its absence (on other projects which aren't using rails)
Which means it is easy to miss.
I see the same thing with spring. Having constraints helps free you up to solve different kinds of problems. I lived through the "let's define everything from the ground up, picking all our libraries, etc" phase of Java (in the early 2000s; I remember Tapestry and Wicket and Struts and Expresso and XMLC). Would prefer to not do that again.
But coalescing on a particular framework is something that a community has to arrive at together. While I think that JavaScript, for example, would benefit from this, I don't know how to encourage it (other than by leaving comments on HN, maybe :) ).
And don't think that coalescing means there are no other frameworks. Java has a number, and Ruby does too (trailblazer is a rails++ , Hanami is a rethinking of MVC, Sinatra is like flask). But having one big player makes it easier to focus on higher order solutions.
Which is funny because uncle bob cites this as a major downside to architecting code.
Three days ago I started using rails and I just flew through the weekend to get a MVP setup to show a coworker. Rails just made it easy to focus on what my app needs to do, not how my app needs to be implemented. I can finally see why people love it so much.
For the longest time, my primary complaint has been a lack of documentation/conflicting information when you break from convention. It can be extremely challenging to find/understand the "blessed" way of doing things. Thankfully, ChatGPT is extremely good at providing a starting point for this stuff.
Same thing with some of the more advanced Model relationships. I just don't write _that_ many relationships, so I tend to forget how Rails wants certain things defined. Since a lot of things rely on config, rather than "normal" runtime code, it can be frustrating to debug. ChatGPT just gets me to the right answer.
---
It's also pretty useful at gut checking DB design. There's been a few times where it's suggested a different approach than what I expected and I've preferred it's suggestions.
I’d recommend to those interested in seeing how a real Rails app is structured to look at the Jumpstart codebase as it’s a great resource on how to structure things
As an alternative Bullet Train is pretty good, even though it adds a lot of bespoke libraries that aren’t the “Rails way”
I wouldn't mind it being longer but it's great they were able to put it together
I kind of feel bad mentioning Struts and Rails in the same sentence, though, as Rails did much more than Struts.
As someone who’s taken multiple projects to production in Rails and generally loves Ruby, these days I prefer to start new projects in full-stack TypeScript. RedwoodJS has been quite good.
It was so heartwarming to remember my Rails story, its been 20 years ago since I started using it! https://twitter.com/buger/status/1723040883325460818
The Rails Console has to be one of the greatest productivity enhancers I've ever come across.
I used to love this, untill I started to hate it. I am convinced this is a major contributor to why so many Rails apps turn into an unmaintainable mess over years.
Who measures onboarding in hours? It's fine if it takes a day or two to understand the domain. And the framework. And how they tie together.
Talking about the domain: Rails puts "the plumbing" up front. Its how it achieves this consistency. My app is never about "models" or "http" or "databases". My app is about medicine-journals. Or loan-request-management. Or CRM. Rails makes itself important, at the cost of my domain.
Rails' opinionatedness makes it so that this is hewn in stone. Its MVC is a given - and that's fine - major architectures should probably be dictated by the framework. But it's ORM - ActiveRecord also is a given. And that's not fine because AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications. It's virtually impossible to swap AR out for anything else. Same with templates/views, JS, Caching, and many more: you can -in theory- replace them with a drop-in alternative. But you cannot -not even in theory- replace them with something that has an entirely different architecture or concept. This makes Rails not Omakase, but actually McDonalds: wherever in the world you come, you know exeactly what to expect, but it also makes boring and bland: no-one eats 7days/week McD.
This makes all Rails apps look alike. Despite the fact that not one of the apps that "we" are building is alike another. Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck. Regardless if you build the next fintech platform with a team of 120 senior devs over 6 years, or you hack your "marketplace for coffeelovers" over the weekends alone: you get The Rails Way. One of those might be a perfect fit. But it's impossible they all are. Each team gets the same "menu". And in many cases it simply won't fit.
If you want to give an honest apples to apples comparison then, okay fine, what framework that does everything that rails does is considerably faster?
Is a Ferarri faster than a dump truck? Sure, but they have different uses. Try hauling gravel with a Ferrari. For the class that Rails is in, there isn't anything as feature compatible that is also an order of magnitude faster.
That being said, you missed my original point, which is that there are problems where you don't really want Rails implemented in a different language because Rails is not a good tool to solve that problem. Think hammer vs saw. You are asking for a different brand of hammer that can cut wood better. Wrong question.
That said, there are areas where Phoenix can't match rails, such as having access to a large developer community and a large existing base of libraries.
https://www.techempower.com/benchmarks/#section=data-r21&hw=...
https://medium.com/@elviovicosa/phoenix-vs-rails-benchmark-2...
The big difference is the blog post you linked performs a very basic GET request to an endpoint. It mentions it doesn't hit the database or deal with caching. It's basically a non-realistic hello world that is good at isolating performance of a specific library but doesn't show how it fits into the grand scheme of things.
The other link performs multiple database queries as part of the request which goes back to the old saying that for a huge portion of web apps you're I/O bound (AKA waiting for something else such as the database).
Stateless API gateway making HTTP calls to other services, which have response times in seconds for various reasons. Rails throughput ~20 requests per second. Golang rewrite throughput: 200k requests per second. Same hardware.
This reads like someone who doesn't understand how to use a tool so they think it is broken. I've worked on Rails apps that outperformed Spring/Java apps routinely and node apps routinely at very large scale. You're very rarely bottlenecked on CPU in a modern CRUD app, much more often, it is the database.
It sounds naive to call the framework that runs github, that almost everyone in the world pushes their code to "veeeeery slow" and I don't know what you mean by "bad at io" in any context where that is a problem for Rails.
But Ruby is one of the slowest languages around. And Rails adds a lot of runtime overhead to that. It really is very slow out of the box.
And that matters for virtually no-one¹, because almost no-one is running their rails app at that scale.
That something would outperform Spring is really due to technical choices, the stack, suboptimal use or libraries. Because Java is undeniably multitudes faster than Rails; in everything.
¹ This used to be my strongly held opinion. But I'm shifting around since we're in a the middle of an unprecedented energy/climate crisis and a slow rails app is gobbling up electricity much more than a highly tuned one. Or the same service rewritten in Go or Rust or Java will.
Rails/DHH took already established design patterns and made strong opinions into a convention on the folder hierarchy of where you store your code. You can change that hierarchy, its not set in stone. It will require a lot of change. I've been on teams and it isn't just on-boarding time, its countless hours trying to find code written by someone no longer there that had their own layout of where files should go. Without conventions, people will run amok with a file structure. Multiply that by the number of developers on the team with attrition and different view points on organizing files and it can be a giant mess after a number of years. Its all a waste of time and has nothing to do with the quality of the code, what domain the application is in or anything really.
If you love Ruby there are other libraries out there like Sinatra [1] that don't have the conventions of Rails.
One had this what you describe: everything in /lib, and the MVC merely delegating to that. MVC downgraded to what it should be: plumbing that binds together your domain stuff.
The other did something similar but had it in gems (bound as Railties/engines). IT was a bit more cumbersome, as one had to release a new gem before being able to integrate it in the rails app. It forced a very solid separation of concerns.
i interpret fat model as: what can be move to the model, sits better in the model (directory). things that cannot be moved to the model: the request, the response, the session. not set in stone, but usually this works.
what i regret about older Rails code i wrote was the gluing of all biz logic to ActiveRecord ORM models (akin to, yuck, Hibernate entities), that also contain DOAs, form validation and all business logic. now i tend to split these out: form dtos that do validation, repos with queries, simple record classes, etc.
fat signals homogenous big thing, but is actually where most of the application lives. i coudl call it lib as well.
In the book "Growing Rails Applications"¹ has the -IMO- best practical patterns to solve this, but it goes right against the "you open a rails app and know what's happening": neat patterns, well manageable, and well documented, but very non-railsy.
https://rubyandrails.info/books/growing-rails-applications-i...
She is big on separating the business logic from the framework.
This level of bike-shedding is what makes conventions necessary especially when dealing with the typical hyper-pedantic software developer. Just the thought of having to debate where to put every file in a project or having to invent a new folder structure for every app we build fills me with a bizarre mixture of boredom and rage.
As with everything in life the people that whine about the medicine the most are the ones that make it necessary.
No. "we" are not.
hmm, sounds like this rails app that one might have not heard bout. You should check it out. Think it's called Basecamp
BaseCamp is DHH's company's product. DHH is the creator of Ruby on Rails. He literally create RoR to build BaseCamp, which is exactly the type of software the other poster is claiming is problematic for RoR.
DHH is on record as having said RoR was evolved organically from the early code of BaseCamp.
I wasn't. I specifically did not mention any concrete examples. I presume parent misread it as "for project management rails is unsuited" which, indeed it's not: specifically because PM is very much CRUD and has relatively little and/or relatively simple business logic (It's not for nothing that the hello-world of nearly all frameworks around CRUD are "TODO lists", the simplest form of PM).
What I tried to say, is that your domain, your team, your timing, your specific planning and your kind of project and any combination thereof has different needs. A setup, architecture, framework, fits one or a few of these perfect. But never all of the combinations of them. Nor over time (today you are a one-man-shop, tomorrow a team of 6. Today you build a full-stack web, tomorrow you need APIs for integration. Today you build a CRUD app for some medication journal, tomorrow it pivots into a complex tool for medical research.)
> Domain. Team. Project Planning. Combine any of them and the projects demand different things, but with Rails you are out of luck
There's no reasonable interpretation of that in which BaseCamp doesn't fall into the list of things that you feel RoR is poor at.
Sounds good to me. Most companies never reach that scale and if they do, I think investing into some extras will be well worth it.
Tobi looks pretty chill about it in the documentary.
the maintainable codebase from day 1 to day 5000 is (mostly) a myth. yeah maybe some other stack could have faced different tradeoffs.
I'm also curious about YOUR choice of stack at this point.
In my day job I use mostly Rails. My team is starting to rewrite some of the services we own in Golang because Rails is no longer a good fit for the problems and scale we use it for. Rails was great to get started fast.
Nothing wrong with using a press instead of a hammer at some point, they are just tools.
What sort of web app do you have that is CPU bound?
It wasn't a problem other than that a better initial design (nothing to do with rails) could have made passing all that data not needed, which was better for mobile. We had about 600,000 customers.
But yes, Spring and the various Java equivalents probably also fit the bill.
Rails is the "goto:" label of web frameworks. It's unbelievable how much it encourages spaghetti code and misdirection directly via its conventions.
Rails provides a way to approach CRUD via MVC. Controllers are your API. Models are the connection to the Database. Views are what the controllers render.
If your app doesn't do these 3 things - API, Database, and representation of your API - you don't need rails (I bet you do those three things). Other than that, you're free to layer on whatever architecture via ruby that you want on top of these basic rails constructs. If you don't like it, again don't use rails. It's opinionated for a reason
Business = program
Company = class (business can be a conglomerate)
Department = method
frameworks = implementation details
> It's virtually impossible to swap AR out for anything else.
I've used Mongo and a number of other ORM's, why can you not use other ORM's exactly?
This just sounds like you don't like frameworks and want to build things from the ground up, because most of the complaints you make are just not true. Maybe you are just inexperienced with Rails because you can swap out almost anything.
I can't reasonably swap out an array with a linked list even if the official contracts are the same.
this is why things like DAL's are created, they give you an opportunity to deal with the differences in behavior.
The issue with frameworks like RoR that use AR throughout is that the queries are sprinkled throughout the codebase, giving no opportunity to fix such behavioral differences.
What happens is every ORM then attempts some sort of "query reuse" and they do so badly because it's not possible to do it well with the contracts they expose. It creates code where you can't ever reason about the query that's actually being generated.
Sure, if you are going to swap out AR for another ORM in the middle of an established project you are going to have a bad time, but if one is doing that I have larger questions.
What is it that's not making sense to you?
How is that different from any other framework ever? You have to query the DB somewhere. Rails makes it incredibly easy to swap out databases. Much more so than any other platform I can think of.
Nothing is making you use AR at all. This is a non issue.
If it needs to be explained you've never seen anything but a gocart.
there's MongoID and it's OK-ish, -a brilliant piece of work though!- but not particularly good inside Rails yet the best alternative example there is. Yet with this (naturally) many gems won't work either. Everything in the community simply presumes Rails' AR is always there. Because it practically always is.
ROM-rb, and Sequal all attempted to be "plugin replacements" but the author of the first rage-quitted at some point exacly because Rails (the dev team) refused some compromises or even abstractions that would allow swapping AR out for something that fits SomeProject better, at the start.
I maintained both kinds of framework-heavy and "organic home grown just libraries" apps, and you know what? I totally prefer framework heavy stuff; at least it has battle tested facilities for everything, and I can expect consistency instead of fomo-driven/resume-driven development.
my last homegrown framework was a nasty 60k LoC api that did like 10 operations. total business logic was 3000 lines, including fn declarations and docs. just transaction scripts. the remaining 57k were a gargantuan amount of boilerplate that gave absolutely nothing to the project, and all in "typed python" which is like 0.9x java verbosity. a massive piece of shit.
Me neither. Which is why I want it tucked away and out of sight and out of thought.
My app is about Medicine, or Projects, or Coffee, or Orders. Not about Controllers, Models, HTTP and DatabaseLayers. Hence I don't want to work day in day out in this plumbing but rather in my domain¹.
Also, there's this false dichotomy, where "no framework === diy mess" That's nonsense. It's perfectly possible to create a well architectured, clean, maintainable and scalable system without the constraints of a framework. You don't need to write your own HTTP handling or database layers if you forego a frameworks: it's what libraries are for. Or microframeworks. Or both.
¹ Here Uncle Bob Martin explains that much better than I ever could: https://youtu.be/sn0aFEMVTpA?si=mY8S1r6qqp8LWEVF&t=4517
If the team is VERY skilled, VERY small and VERY able to keep the culture going forward indefinitely I'm all in for the homegrown framework; if not, I'd rather have a set of well done facilities that accrued many years of manhours i.e. cli commands out of the box, testing framework already well configured with decent standars like tx-wrapped tests, and so on, decent security, admin panels...
it's not a technical matter, it's a social matter. social matters are more important than technical ones.
My biggest issue with trying to do this is ActiveRecord. I'd much prefer the repository pattern.
I am convinced this is a major contributor
to why so many Rails apps turn into an
unmaintainable mess over years.
1. Any non-trivial app in any non-trivial language/framework usually becomes a mess eventually, given enough commits and developers
2. Rails (specifically, ActiveRecord) won't stop you from creating circular dependencies between models. This is easy to avoid, but it doesn't warn you about this or try to prevent it. So 99% of Rails apps have like, a User model that depends on (and is depended on by) most of the other models. This is far from a Rails- or ActiveRecord-specific issue though.
Who measures onboarding in hours?
However I think the standardization on MVC pays off here as well. For apps with multiple developer teams you may constantly be "onboarding" as you move between different areas of the app. And you can move forward with less bikeshedding.
And that's not fine because AR (as an architecture
and as how Rails implements it) is very unfit for a
large category of applications
So IMO/IME it works well for scenarios where some of your data is AR/ORM friendly and some isn't.
Same with templates/views, JS, Caching, and many
more: you can -in theory- replace them with a
drop-in alternative
Rails' caching backend has been seamless to swap between DB, Redis, in-process, and Memcached backends. As far as the caching "frontend", it's entirely optional, so I can't really imagine there is an obstacle to swapping it for something else? Like, you never have to use `Rails.cache`.
As for the JS side of things, I don't think I totally agree. There aren't drop-in alternatives, but you don't have to use Stimulus, and you can certainly use your own.
This makes all Rails apps look alike.
I disagree. This presumes that there's some initial "onboarding" process, and that once that's done you just now will know the structure of the app for all future, never spending more effort on it.
That's only true for trivial apps. What actually happens in bigger codebases is after you stop working in some section of the code for a few weeks, it falls back out of your head and you have to figure it out again. Additionally, without conventions other members of your team are constantly inventing new structures and connections between things.
So really this lack of consistent organization is a continuous drag, not a one time cost.
I need to be more concise.
Does this happen more often for Rails than for other frameworks?
There are many ways in which a Rails project can get derailed. But they seem not different from regular tech debt and I could imagine equivalent problems in other environments.
> AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications
If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?
I wouldn't claim that Rails is a good fit for all problems. Still, I'd say the structure and defaults of Rails are one of its strong benefits.
Or do you mean "application" as in "usage" - i.e. that over time you might notice a problem that's hard to solve with AR? Could you give an example? I'd guess you could use a different approach for a single task, or even move from Rails to a different tool if that becomes a big issue.
Yes. But there are many frameworks where this is even worse. Rails, however, is highly opinioated, and does not allow you to pick and choose your parts (this is a design decision). That has lot's of benefits, but the major downside is that it will never fit perfectly (or as close as one may get). Most often an "off the rack suite" is fine, but we all know that a tailor-made suit is just that much better/prettier/comfortable/durable. Same here: Rails will probably fit your project OK, but that's not good enough for many projects.
AR is a another big contributor, as is the way Rails has its MVC set up. Tight coupling, no separation of concerns, etc. etc.
As you say:
> If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?
Which is my entire point. Yet it happens. Far too often. (I'm a freelance consultant who deals with these failing Rails projects on a monthly base. And occasionally a very pretty one)
I mean you could have at least picked some better example. Considering Rails was precisely extracted out from Basecamp which is "Domain. Team and Project Planning".
It's that your domain, your team, your planning, and any combination thereof put demands on the architecture and framework.
That was until I learned that in Ruby:
`someObj.some_var = 'hello'`
Is syntactic sugar for:
`someObj.some_var=('hello')`
That made me smile. I have never smiled like that about a programming language. It literally gave me joy.
I’ll be honest I have some trepidation devoting my time now to something “old”, but on the flip side my career is in PHP so what the hell am I talking about “old” for.
I even remember at around that time there was a fundraiser specifically to hire someone to write better docs. I think it was some third party response to all the forums where people had been lamenting the desire for better docs. This was before go fund me and kickstarter so itself was a little unusual at the time.
Did anyone else feel the same way? I kind of want to give it another chance bc I have some side projects that I want to try out, but I find django/python and next/react easier to grok. Maybe I should try harder?
FWIW, I also want to pick up good practices when it comes to engineering a back end, and the good ex-rails engineers I know tend to be really good in general.
Today it’s something I repeatedly try to tell everybody about. It’s just so productive.
I think one thing is true -- Ruby gives you lots of different ways to do things. And it can be really terse sometimes, if you want it to be. Some Ruby devs IMO should learn to favor readability over terseness.
Overall though, Ruby is my favorite language and IMO can be very beautiful. I don't think anybody would call Python beautiful. (Lots of great things about it though, nice language and ecosystem... no hate)
I like ruby quite a lot, too.
rails made me very fast.
Love Rails, but found it very difficult to learn Ruby. It's very hard for me to read, but that may be because I come from a C# background.
If you're looking for something like Rails, I'd recommend trying out Laravel.
It's on par with Rails as far as features, ease of use, etc. And PHP was a lot easier to learn for me versus Ruby.
For example, ending an if statement with semicolon and then having the if block indented below is just not the normal way to do things. I’m not knocking Python, I use it all the time and it’s great, but it’s not a language you can carry over to learning other languages. It’s like if you know English, it’s pretty easy to learn Spanish. But if you only know Chinese, it’s going to be tougher to learn an “English-ish” language. Hope that makes sense.
Its not the minor syntax differences that I have trouble with, its that ruby does not "fit my brain like a glove."
Two great examples that everyone comes into right away are "Why are parenthesis optional? Why do you not have to `return`? Why do you allow such chaos to run abound willy nilly?!".
It isn't because "We just like being different!" or "We are allergic to parenthesis!". It turns out that one of the fundamental designs of the language makes it such that they don't really _mean_ anything.
I think being able to understand some of that context is really valuable to "ruby making sense" vs not. You often see people proclaim "In Ruby, everything is an object!" And it doesn't make much sense why that's a big deal. But the ramifications are actually amazing: Everything (basically) is an object -- even stuff that feels deep in the guts of the core of the language (defining a class for example). It turns out, this creates an amazing amount of _consistency_ where every single thing in Ruby from my app code, down to the low level parts of the language follow the same rules. This then makes it easy to anticipate how something works, or find out more about it.
I don't expect to single handedly fit your Ruby gloves to your brain, but here are some notes that define Ruby that I find enlightening:
- (Pretty much) Everything is an object. A `thing` is an object. A literal `1` is an object. A `class Mom; ... ; end` is an object. They all follow the same rules. If you want to learn what you can do with an object, you just need to learn what kind of object it is, and then you can find out what it knows. There aren't top-level functions to act on your objects. Ruby is all about "passing messages to objects". Your object knows how to handle itself.
- Things that look like operators are just methods on those objects. `thing > other` is calling the `.>(other)` method on `thing`. Accessing data from an object always happens via a method. There's no such thing as "accessing a property vs calling a method". It's all calling a method, always. This adds to the consistency.
- (Pretty much) Everything is an expression. A value is already created and stored in memory somewhere; might as well make it available to the next fellow. This enhances the ability to ... _express_ (sorry) things. You can expect to be able to chain things together, or leverage values as they are created.
- The whole motif surrounds having a conversation with your objects. It's less about making statements to your computer, and more about having a conversation with the context you are working in.
Honestly, these are all common bullet points that people bring up, but to me they didn't make much sense until I really held a strong grasp of the language as a whole. At some point, those bullet points became my "woah" moment of _why_ Ruby is how it is. This understanding in how Ruby was different from other languages I've used helped me understand why Ruby fits my brain like a glove. This style of creating makes a lot of sense to me.
Well anyway, thanks for staying for dinner.
I know this is a possibly unpopular opinion but I don't think one should glorify a sophomoric book as a key Ruby book-- there are others that deserve that title, PickAxe is close, but I'd have liked a book like Whittaker's "C#, Player Guide" for Ruby.
Matz's intent was and has been to bring joy and delight to developers, with the odd combination of PERL, LISP, and Smalltalk as his inspirations. Joy and delight don't necessarily equate with "most practical". But joy and delight are wonderful and healthful qualities to cultivate for a good life!
_why embodied much of the spirit of the (at least earlier) Ruby community. We were software developer immigrants, many coming from prescriptive verbose technologies (I'm looking at you, Java!). We were eager for novel ways of expressing our ideas. Ruby's metaprogramming capabilities are, as far as I know, still all but unmatched beyond perhaps Smalltalk itself (and IO, which AFAIK no one uses seriously). _why's playfulness captured all of this in elegant and sometimes bizarre but often artistic expressions in his projects and code.
I will never regret or apologize for the Ruby community's appreciation for the Poignant Guide.
And, _why, wherever you are and whoever you are, thanks.
I just didn’t know how much faster building web apps could be.
Also worth mentioning Michael Hart’s intro course, which is a really shockingly well done way to ramp up from absolute zero, even for someone with very little code experience.
* Which, in fairness, it mostly is. But also meh.
In under two weeks of opening Michael Hartl’s Rails Tutorial, I was already more productive with RoR than with the stack I'd been using professionally for 3+ years.
This isn’t even a criticism of Django; the things that Django does, it does very well. But there are a lot of things that it doesn’t do that a mature web app will eventually need to handle.
Otherwise great docu with DHH "f*uk you" slide which does give an insight into successful open source projects.
Unfortunately iirc Ryan suffered a burnout and had a lengthy break. I hope all that is better now.
Unfortunately having folks around me that had burnout helped me to avoid one myself.
The Ruby on Rails community struck me as different back in the day in how fun it was.
It's hard to explain but coming from a Java background the community seemed to be full of interesting and engaging characters. Some people don't really appreciate that and prefer things to be very dry but I loved it.
I'd like to shout out to Ryan Bates, Geoffrey Grosenbach, Zed Shaw, _why, Jason Seifer, Gregg Pollack, Sandi Metz, Ezra Zygmuntowicz, Yehuda Katz, Dr Nic, Tenderlove and a whole heap more.
Thanks everyone, you've made it a very entertaining journey.
You played a big part in it. Thank you!