Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing Rails Wrong

bananacurvingmachine.com

Post reply on HN
Print view View original

121–130 of 288 posts

Re: Doing Rails Wrong

#121

Post by conradfr »

poorman wrote: post #30

Stimulus and Hotwire are the "rails way" now. I've read the docs and they still confuse the hell out me. Seems like you're reinveting your own javascript components over and over again. In my opinion Rails 8 + Intertia.js + React so much less "reinventing the wheel" (especially if you use shadcn components).

I use Stimulus with Symfony for small interactions and I quite like it, small and well designed api IMHO.

Didn't try the whole Turbo/Hotwire thing though. I usually use Vue for complex pages / need of state.

Re: Doing Rails Wrong

#122

Post by Zanfa »

treis wrote: post #63

This is the fundamental weakness of Rails. You can't just "do Rails" because the UI out of the box isn't usable. You've always had to add something on whether that was Bootstrap 10 years ago or React today. It's always been a bolt on and always has been changing.

I haven’t really found this to be true. You probably wouldn’t want to build Figma in Rails, but the average SaaS CRUD app is a perfect fit for Rails with a sprinkling of Turbo Frames.

It’s usually the lack of non-React knowledge to know what does or doesn’t require React.

Re: Doing Rails Wrong

#123

Post by JodieBenitez »

mkhalil wrote: post #76

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…

> and they're all necessary for a modern web application.

Modern doesn't mean much.

Re: Doing Rails Wrong

#124

Post by boplicity »

johnfn wrote: post #110

> (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.…

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.

Re: Doing Rails Wrong

#125

Post by moviedo »

zdragnar wrote: post #32
Zanfa wrote: post #17

I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.

Ember.js was created by big names in the rails community, and made big promises of being a rails like batteries included all in one framework. There's a reason it didn't really get the popularity the other frameworks got.

My reasoning for not using ember was it’s steep learning curve and easier libs(angular 1, backbone, react) to work with at the time(~2012 to 2014). Honestly, react wasn’t very big during this period, it was Angular that truly dominated.

Re: Doing Rails Wrong

#126

Post by mkhalil »

mosselman wrote: post #96
mkhalil wrote: post #76

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…

Complexity is not inherent to web development. If anything it is now possible to get more done with less. Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup. The de facto way to deliver JS in rails has also become far simpler through import maps. There is no build step for that. Tailwind support…

>> "Complexity is not inherent to web development"

>> "Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup."

My point was that web development isn't complex, but the core is simple; but modern web development is.

Your "Hotwire is sort of vanilla rails" statement is a perfect example.

What you claim to be simple, is a big list of tooling, web-sockets included, integrated together. The end result is using it might be a "one-liner", but that doesn't mean it's simple. And that's OKAY. Because simplicity should be the standard; and adding things, like sockets for live updates, should be something you explicitly enable (with modern web-apis, its definitely simpler than it used to be, but that doesn't mean its simple)

Re: Doing Rails Wrong

#127

Post by Zanfa »

b_e_n_t_o_n wrote: post #107
Zanfa wrote: post #17

I sorely miss the sheer amount of utility that you can get from Rails out of the box for free compared to anything in the JS universe. Most JS devs don’t have the faintest idea how much they’re missing out on. Then again reinventing wheels is the JS way of life.

JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails... The problems people solve with JS are different from the ones solved with Rails. Which is why the frameworks look different.

> JS has multiple full stack frameworks similar to Rails. There is even a framework called Sails...

But it doesn’t. Rails is not just a full-stack framework. It’s the entire ecosystem of gems that magically just work together. What JS has is like the Temu version of Rails.

Re: Doing Rails Wrong

#128

Post by dakiol »

mkhalil wrote: post #76

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…

> Tooling isn't the problem: The complexity is inherent to modern web development

> Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.

Depends. One can still write production-grade web applications with way less dependencies. You can write a Golang web server with minimal dependencies, keep writing CSS "like a peasant" and perhaps use jQuery in the client-side for some interaction. What's wrong with that? If you hire a strong team of engineers, they will be pleased with such a setup. Perhaps add Makefiles to glue some commands together, and you have a robust setup for years to come.

But some engineers feel that counterproductive. They don't want to learn new things, and stick to what they know (usually JS/TS); they think that a technology like CSS is "too old" and so they need things like Tailwind. Makefiles are not sexy enough, so you add some third-party alternatives.

Re: Doing Rails Wrong

#129

Post by boredtofears »

tra3 wrote: post #61
mystifyingpoi wrote: post #49

Earlier quoted context omitted.

> rsyncing or dropping a tarball into a fleet of instances Could you elaborate? Doesn't sound like a big deal.

The primary benefit of containerization is isolation. Before docker, you'd drop all your code on a shared host so you had to manage your dependencies carefully. Specifically I remember having to fight with mysql gem a lot to make sure that there no conflicts between installed versions. With docker, you build your image, test it and ship it.

I haven't shipped to a shared host since the 00's. We deployed to isolated VMs a decade before docker.

Re: Doing Rails Wrong

#130

Post by JodieBenitez »

b_e_n_t_o_n wrote: post #109
languagehacker wrote: post #38

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?

That might be a case where you want a SPA + backend API. But the point is that in many cases you either don't need a highly interactive frontend or the frontend is not that interactive (ie. progressive enhancements work).
Post reply on HN