> (John runs a single command. The app boots instantly, working forms, instant loading times, blazing fast navigation.)
Sure it does. If you're not using Vite, how are you bundling? Oh, you're not bundling? I guess that means you're not using TypeScript? Interesting, how do you catch errors? Oh you just let things crash in production? How do other engineers understand the intent behind your code? Oh they don't I see. If you're not using React, what are you using? Vanilla JS? Have you considered that it's a statistical fact that every single person who has said "I don't need React, it's just a big complex mess, I'll just invent it myself" ends up creating an informally-specified, bug-ridden, slow implementation of half of React? Oh you don't use Prettier? OK, how are you formatting your code? Oh you're not, it's just a giant mess? Oh you're not using ESLint, interesting, how do you keep code consistent across your team? Oh that's not a concern? Hm.
Almost every technology in the article exists for good reason, and solves a real issue[1]. Maybe not an issue the author has encountered, but the author shows no understanding of the issues they are solving, and the final "punchline" implies that anyone could just toss all this tech out and improve their developer experience. "Learn the rules before you break them" applies here.
This is an uncurious article which mocks at abstractions rather than taking the effort to understand why they exist.
[1]: OK, I do think some abstractions are more trouble than their worth. But why did the author choose all the reasonable ones, like React? Why not dunk on Angular, I mean come on!
The problem is these issues are only issues for a certain subset of software. Many, many pieces of software don't need to be very robust, don't need to be developed by a team at all, and the occasional runtime bug is well worth the literal cost of maintaining compatibility with dozens of packages.
Most projects are very simple CRUD apps anyways.
Correct me if I'm wrong but I believe you're interpreting this as if the rails app needs the same amount of is that exists in the described vite solution.
But in reality if you're using hotwire you can get away with almost no JavaScript at all comparatively. That's why stimulus is in vanilla js generally, it's meant for sprinkling behavior onto the dom vs controlling the dom.
So if you don't have a js framework that needs to control the whole Dom and doesn't need a gigantic optimization step or tree shaking or typescript or whatever, you can get away with a whole lot less than it you embraced those frameworks that _do_ want to own the dom wholesale.
I think the point of the article it's that these tools are redundant since rails a full stack framework, already has the features to help you make a web app
Really love that a main criticism is missing static typing in a Ruby system. I assume the Rails devs know how to work with dynamically typed code on the backend — the same practices will work fine on the frontend with vanilla JS.
If static types are so fundamental for you, I'd suggest skipping Rails entirely and reading other content.
> how do you catch errors? Oh you just let things crash in production?
You write code differently, and you write tests. Rigorously testing business logic also has the nice side effect of catching type errors. "crash at runtime" in the real world means "crash in your tests". I've written a tonne of Ruby and it's simply not an issue
Plenty of businesses have been built on the back of dynamic languages. Nubank runs their somewhat critical business on millions of lines of gasp dynamic Clojure
> ..ends up creating an informally-specified, bug-ridden, slow implementation of half of React?
VS Code is written with custom JavaScript
Obsidian is written with custom JavaScript
Here's one reason to do it: the churn in these ecosystems is insane. Imagine writing a huge app in backbonejs back in the day when it was popular.. and then subsequently abandoned as people moved on to the new better way. That's an existential threat to your business if you're a small team. Even a big team takes a huge hit there
Vue2 to Vue3 was a shitshow. AngularJS -> Angular 2..
I'm still annoyed at React Query straight up deleting the documentation for the version a project I was on was using. Rails still has their docs up for the version released in 2009? The JS community just doesn't care about longevity
What happens when the React team decides "oh well actually WASM is the way forward" and redoes everything.. or maybe Svelte ends up taking over 4 years from now? Or hell if they even just evolve the framework in a direction that isn't in line with with what you want out of it
> The JS community just doesn't care about longevity
That's a real problem... and it's largely cultural and not technical which makes it even worse.
You're not getting it. A modern Rails 8 application has so few lines of JS that you don't have to deal with all the problems you introduce with a heavy JS application.