191–200 of 288 posts
I think there is a much-better-than-merely-non-zero chance that the rise of coding agents will also mean a rails renaissance. All of the complexity identified in the article really gets in the way of LLMs.
Am I the only one who still thinks any kind of build process does not belong in web development? If I'm making a typical website, all I'm using is a few PHP files, a single CSS file and maybe some JavaScript. There are no build steps. No minification. No compilation. No frameworks. I just can't understand even using Rails for web dev.
Earlier quoted context omitted.
> Good luck doing that with React Data is sent to React by inertia/graphql/whatever and React renders it. It’s pretty straightforward. Edit: I do love LiveView/HotWire/HTMX etc but honestly everything is a trade off and there are times just rendering a react component is less complex.
“Just rendering a component” takes thousands of nested function calls, covering a million lines of code; it’s not possible for a person to read or understand the whole process unless they dedicate months to it.
Earlier quoted context omitted.
> rsyncing or dropping a tarball into a fleet of instances Could you elaborate? Doesn't sound like a big deal.
It is very funny to me that the sibling comment calls this "a very broken setup" and for you "it doesn't sound like a big deal". It's all about perspectives, or you really just never had to deal with it. The happy path ain't a big deal. But think of the unhappy ones: * What if a server gets rebooted (maybe it crashed) for any reason anywhere in the process. Maybe you lost internet while doing the update. Were you sti…
You push the image again.
> What about a broken build. All your servers are on it, or only one?
The ones you pushed the image are on the new image, the ones you didn't push the image are on the old image.
> How do you revert (push an older tarball)
Yes, exactly, you push the older version.
The command pushes a version into the servers. It does exactly what that says. There's nothing complicated to invent about it.
All the interpreted frameworks use the same semantics, because it works extremely well. It tends to work much better than container orchestration, that's for sure.
> A lot more manual processes.
It's only manual if it's not automated... exactly like creating a container, by the way.
Any project that doesn't need 30 or more devs with various specialties working on it all at the same time doesn't need the complexity that frontend/backend separation introduces. I learned this the hard way through years of over-architecting 1-2 person projects as a freelancer. Nowadays, it's just Django with a little bit of Tailwind on top.
What if you're building a highly interactive front end?
When you are building a data browser, you should use web tools.
This article has been re-written for over a decade. The so-called "complexity" is just a list of tools that each solve a specific problem. Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well. If you're using Rails as an API backend with React handling the frontend, it's almost a comple…
Yes!
> and they're all necessary for a modern web application
No! Just as important as understanding the purpose of a tool, is also understanding when a certain tool is a bad fit for a certain project. There are no silver bullets.
Earlier quoted context omitted.
“Just rendering a component” takes thousands of nested function calls, covering a million lines of code; it’s not possible for a person to read or understand the whole process unless they dedicate months to it.
Sure it adds complexity, but isn't that what abstractions are for? We are talking about grokking how data flows in _a web app in Rails_. I wouldn't think usual workflow requires going into actual inner workings of React :p
The more stuff you add on the harder everything is to understand, and the less stable your app becomes until suddenly you need specialists for every piece just to keep things chugging forward. Everything needs greasing and maintenance over time..
..and then in 4 years the React team decides "oh you know what the way Svelte is doing things is actually way better.. we'll need a re-write to integrate their ideas". Now what?
"that wouldn't happen! so many businesses depend on React!".. uh they have no obligation to make things compatible with whatever you've built. They're not working for you. What happened with AngularJS? Vue 2?
Hotwire is easy to understand (React "just renders it" is a massive oversimplification)
If Hotwire rewrites? I create a private fork and continue on. Who cares
If I want to tweak how Hotwire works cause it'll benefit my app specifically? I do it myself
I'm not against adding complexity.. but if you care at all about longevity and long-term productivity then adding React really needs a tonne more consideration than it gets
Earlier quoted context omitted.
My recollection is that this is what many Capistrano setups were doing under the covers. Capistrano was just an orchestration framework for executing commands across multiple machines. More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku.
> More than that, I worked for many enterprises that were using Rails but had their own infrastructure conventions and requirements, and were unable or unwilling to explore tools like Capistrano or (later) Heroku. Well, OK, so you remember a bad setup that was bad for whatever reason. My point is that there's nothing about your remembered system that was inherent to Rails, and there were (and are) tons of ways to dep…
The main issue that, while not unique to Rails, plagued the early interpreted-language webapps I worked on was that the tail end of early CI pipelines didn't spit out a unified binary, just a bag of blessed files. Generating a tarball helped, but you still needed to pair it with some sort of an unpack-and-deploy mechanism in environments that wouldn't or couldn't work with stock cap deploy, like the enterprise. (I maintained CC.rb for several years.) Docker was a big step up IMV because all of the sudden the output could be a relatively standardized binary artifact.
This is fun. We should grab a beer and swap war stories.
Earlier quoted context omitted.
As someone who’s kind of a newbie in rails, but with 10 years of experience in other languages… It sounds ok to adapt tools if needed (won’t get into whether tools are actually needed, let’s assume they are). But Rails is supposed to be a giant, everything and the kitchen sink framework bringing everything from an ORM through its own console to scaffolding code generation. If adding tools to the setup is needed, isn’…
> But Rails is supposed to be a giant All the tools on the article are about client-side rendering and operations. It's ok if Rails decided to have opinions on client-side rendering and operations now, but it's far from expected. And it would alienate some users. Instead, the article's conclusion is the correct one. You don't need to mess with complex client-side and ops tools if you don't want to. You can build many…
On the other hand, Rails has had client-side opinions basically forever; when I started using Rails during the 2.x days in like, 2009, there were helpers that injected JavaScript to make forms better, Rails 3.1 included the asset pipeline, an attempt to compete with webpack, in 2011. Even the current generation of these things has been around for a long time, Hotwire is four years old at this point.