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

221–230 of 288 posts

Re: Doing Rails Wrong

#221

Post by eggbrain »

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.

I’m glad someone called this out. “Let’s just use vanilla rails” — sure, except basically every version of rails for the past 5 years has decided to completely change how they do JS.

So many gems are also still built on sprockets — even when you want to use the “rails” way, you are stuck now with a hodgepodge of JS anyways.

It’s a mess — maybe one day we’ll get it fixed, but don’t pretend it’s not partially rails fault as well.

Re: Doing Rails Wrong

#222

Post by nickelpro »

the__alchemist wrote: post #178
nickelpro wrote: post #149

Earlier quoted context omitted.

That's like saying the Unix philosophy adds complexity because it dictates a tool should do one thing well. Composition of tooling (consisting of many individual tools) is the basis for lots of rock-solid stacks. I don't think the Unix philosophy is universally correct either, but "too many tools" is a complaint without much consequential basis. It's an aesthetic problem not a functional one.

I am speaking specifically to examples used in the article, and related web dev paradigms that are popular. In the general case, there are tradeoffs to be made when adding tools, libraries, additional code of any sort to a work flow. In the case of web dev, adding these are bad tradeoffs.

You don't have any concrete complaint beyond the number of tools, and the nebulous idea that solving the problem each addresses within a smaller ecosystem would be somehow better.

Removing ESLint means... you don't have a linter. It doesn't have an upside. Removing Tailwind means you need to write more verbose CSS. Removing Babel means you have to use older JS idioms for browser compatibility. Etc.

Re: Doing Rails Wrong

#223

Post by JodieBenitez »

b_e_n_t_o_n wrote: post #202
JodieBenitez wrote: post #182

Earlier quoted context omitted.

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.

Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ

I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.

Re: Doing Rails Wrong

#224

Post by b_e_n_t_o_n »

JodieBenitez wrote: post #223
b_e_n_t_o_n wrote: post #202

Earlier quoted context omitted.

Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ

I fail to see the connection with jquery. Anyway brittle and hard to maintain is what we experience now with frontend stacks and codebases with very short lifespan. I can't keep track of components libs du jour that come and go and keep being reinvented with very little value added on each iteration, along with constant api breakage. Brittle, indeed. Meanwhile, Rails and Django have been rock solid.

Both jquery and htmx style approaches lack the concept of components, data flow, template binding etc. At most you get string templates. You end up manually wiring up dom updates when state changes, and that kind of thing is brittle and is why stuff like React was invented in the first place.

React has been very stable throughout its life time. You can run 10yo react code in v19x without issues.

Re: Doing Rails Wrong

#226

Post by michaelcampbell »

prakashn27 wrote: post #225

And you forgot the js library that lets you check if the number is odd https://www.npmjs.com/package/is-odd Funny enough there is another library which checks if it is even https://www.npmjs.com/package/is-even

Both written by the same (somewhat notorious) purveyor of trivial shenanigans disguised as resume bullet points.

Re: Doing Rails Wrong

#227

Post by vhcr »

nine_k wrote: post #215
ricardobeat wrote: post #183

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.

I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.

You also have to take into account the browser and OS call stack.

Re: Doing Rails Wrong

#228

Post by nine_k »

vhcr wrote: post #227
nine_k wrote: post #215

Earlier quoted context omitted.

I don't think a typical React rendering call is even 100 calls deep. React itself adds maybe a dozen frames. Your components could be complicated, but likely they don't add more than another dozen or two. React is pretty efficient if you hold it right, and use for its intended purpose, that is, large and complex interactive UIs.

You also have to take into account the browser and OS call stack.

This does not change if you write pure Javascript that directly mutates DOM without calling any intermediate functions.

Given the speed of rendering that browsers achieve, I would say that their call stack during this is highly optimized. I don't see OS doing much at all besides sending the drawing buffers to the GPU.

Re: Doing Rails Wrong

#229

Post by thingortwo »

AstroBen wrote: post #219
ahallock wrote: post #216

I'm going to make the case that it's actually the opposite. Rails might seem simpler out of the box, but this is all surface level. Rails is massive and extremely complex, especially its ORM, which encourages really bad database practices in my experience. And it doesn't have strong typing. If you went head-to-head with Rails on a slightly complex project with say shadcn/ui, Convex DB, and TanStack Start, I guarantee…

You're just choosing a random tech stack without even knowing the requirements... complex how? Go build a web analytics tool with that

Why would you not be able to build a "web analytics tool" with what parent comment mentioned? At the end of the day it is just data and if you are just starting out pretty much anything will scale and if you already have millions of customers you also have capital and people to think about how to make some homegrown solution to specifically cater to that.

The market for these new breed of frameworks is not huge companies with crazy scaling needs but freelancers and your very early stage startups who haven't even found a product market fit since they are starting new they don't have anything to loose with newer stuff and chances are that newer stuff also helps them do more quickly like I haven't used convex but on it's marketing page it does mention a lot and same for other frameworks like pocketbase or SvelteKit combined with a db etc. Like always there is no silver bullet and every stack can seem "random"

Re: Doing Rails Wrong

#230

Post by gls2ro »

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

Some of these extra tools are added because someone wants to display "a blog post" using React and so they think they need all those extra tools for FE.

If there is no need for the level of reactivity that is on the level of facebook style then everything provided by a simple rails new is enough.

But I would say that you kinda need to think about the UX with simplicity in mind or else everything becomes a blog with React because everything can be forced to look like it needs to be reactive and do a lot of unnecessary stuff.

Post reply on HN