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

181–190 of 288 posts

Re: Doing Rails Wrong

#181

Post by creakingstairs »

AstroBen wrote: post #180
mkhalil wrote: post #126

Earlier quoted context omitted.

>> "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 clai…

This really is different. Hotwire is simple. You can read through the library's codebase and understand what it's doing fairly easily, and then when working with it the flow is straightforward. Good luck doing that with React

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

Re: Doing Rails Wrong

#182

Post by JodieBenitez »

b_e_n_t_o_n wrote: post #145
JodieBenitez wrote: post #130

Earlier quoted context omitted.

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).

Ime progressive enhancements are brittle and hard to maintain. If your site doesn't need any JS it's fine, but as soon as it needs some interactivity beyond the absolute basics you benefit from having reusable components and automatic change detection / data binding.

Not true anymore, as tools like unpoly, htmx and the like make it really easy to integrate and maintain with very little dependency and no build step.

Re: Doing Rails Wrong

#183

Post by ricardobeat »

creakingstairs wrote: post #181
AstroBen wrote: post #180

Earlier quoted context omitted.

This really is different. Hotwire is simple. You can read through the library's codebase and understand what it's doing fairly easily, and then when working with it the flow is straightforward. Good luck doing that with React

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

Re: Doing Rails Wrong

#184

Post by adamors »

butlike wrote: post #158

This is all moot because greenfield projects rarely exist anymore outside of being an entrepreneur, and if you're selling something, you're probably using a shopify wrapper of some sort 99% of the time. If you're working on a greenfield project at a Fortune company, then you probably have a bunch of considerations and in-house frameworks you'll use as a jumping off point instead of running `rails new` at any point. T…

I couldn’t agree more, I’ve worked with Ruby/Rails for the past 10 years, and the youngest codebase I saw was 5 years old at that point.

I did work on greenfield Rails apps but they were API only “microservices” so none of this FE stuff was needed.

In any nontrivial company, the Rails homegrown FE solutions are ignored entirely because you can’t hire Hotwire devs but you can hire plenty of React/Vue devs.

Also, the Rails “FE” stack has changed plenty and it’s also hard to keep up with it (remember CoffeeScript?), is poorly documented beyond the trivial hello world and like I said, has absolutely no mindshare.

So these discussions are entirely disconnected from the real world.

Re: Doing Rails Wrong

#185

Post by wild_egg »

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

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.

Re: Doing Rails Wrong

#186

Post by cullenking »

mvdtnz wrote: post #119
bdcravens wrote: post #74

Earlier quoted context omitted.

It's useful, but not necessary. Plenty of 10+ year old Rails apps in the wild. Github was running Rails 2.3 until 2018 while the entire software world that depended on it didn't fall apart. Even if you follow best advice and update your dependencies for security sake, you can effectively run the same code using the old "trends" (aside from things like safe parameters, etc).

Large rails apps tend to be on older versions not because they're so very stable but because Rails upgrades are a nightmare at scale. Even point versions have lots of undocumented breaking changes. There was a lot I didn't like during my 4 years as a rails developer but upgrades were the very worst of it.

it all depends on your philosophy on dependencies. if you maintain a small set of core dependencies that are there for good reasons and are actively maintained, then rails upgrades are pretty easy. if you have a Gemfile that has a bunch of third party gems that you bring in for small problems here and there, you have to occasionally pay down that debt on version upgrades. we have an 18 year old rails codebase currently on 7.1 that hasn't proven to be a big pain for upgrades. the hardest upgrade we did was because of a core dependency that had been dead for 5 years broke with a new version of rails. but that was a story of letting technical debt ride for too long and having to pay it back.

this is a common problem in any complex codebase that has a culture of using third party dependencies to solve small problems. you see this conversation all the time with modern frontend development and the resulting dependency tree you get with npm etc....

Re: Doing Rails Wrong

#187

Post by adamors »

ksajadi wrote: post #105

This is cute but fails to mention how many times in the life a rails application we have to go from bundler to webpacker to sporkets to Propshaft and importmaps to jsbundling. Or from autoloader to zeitwerk or from Turbo to Hotwire and god knows what else. Take a look at ads on rails newsletters and how many of them are professional services to upgrade your rails app.

Don’t forget Coffeescript. Just recently I worked at a company that was still postponing porting their Coffescript code, only new code was using Vue.

Re: Doing Rails Wrong

#189

Post by WillPostForFood »

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…

they're all necessary for a modern web application

Everything wrong with modern web applications.

Re: Doing Rails Wrong

#190

Post by marcosdumay »

torben-friis wrote: post #157
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…

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 things perfectly well without them.

Post reply on HN