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

171–180 of 288 posts

Re: Doing Rails Wrong

#171

Post by multiplegeorges »

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

> If adding tools to the setup is needed

It is not needed.

Re: Doing Rails Wrong

#172

Post by AstroBen »

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?

"Islands" are really nice for this. The highly interactive pieces are usually only a small part of the app - just mount a component there if it's suitable. You don't need a full blown SPA

Re: Doing Rails Wrong

#173

Post by molszanski »

the__alchemist wrote: post #98
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…

Counterpoint: These tools add complexity, and you don't need them. If you step out of the system and look in, you see madness. The problems they solve are created by other tools; they are problem-generating systems.

Not really I guess. Of course some tools are not mature, but many are mature and solid enough to solve real tech tasks.

Real problems are not caused by tools / problem generating systems but by silly people who fetishize complex tooling for simple jobs. Tooling is chosen not by merit but by hype.

Re: Doing Rails Wrong

#174

Post by bwilliams »

barumrho wrote: post #36
zdragnar wrote: post #32

Earlier quoted context omitted.

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.

What was the reason?

There's definitely a number of reasons, but I vividly remember _struggling_ with Ember data at the time. The framework itself was already complicated and the data management story felt immature and rigid in addition to complex. That definitely pushed me towards and a number of others towards backbone and eventually React.

Re: Doing Rails Wrong

#175

Post by multiplegeorges »

hashbig wrote: post #141
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).

Most of the reason I've started losing interest in Rails and the DHH cult is their insistence that their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite. I am maintaining a Rails app with Vite + Interia + Vue, and it's many times easier to manage, develop, especially when working with LLMs that haven't been trained on DHH's ne…

> their homemade JS solutions (Stimulus, Hotwire, JS import maps) should be the default choice instead of industry standards like Intertia and Vite.

Funny you should list those out. JS Import Maps (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) are literally an industry standard while Inertia and Vite are decidedly NOT standards in any way, shape, or form.

Re: Doing Rails Wrong

#176

Post by JamesSwift »

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…

The core rails philosophy has been, and continues to be, "reasonable defaults out of the box". In other words, if you are running `rails new` today, you should just start day 1 with the things that are preconfigured. One day you may need React/tailwind/etc, but vanilla rails will ship you to prod just fine on day 1 without configuring anything.

That doesnt mean you should rewrite an existing app to a more 'vanilla rails' config. You've already eaten the migration cost.

Re: Doing Rails Wrong

#177

Post by Lukas_Skywalker »

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.

Github is now running on the main branch:

> Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day.

https://github.blog/engineering/building-github-with-ruby-an...

Re: Doing Rails Wrong

#178

Post by the__alchemist »

nickelpro wrote: post #149
the__alchemist wrote: post #98

Earlier quoted context omitted.

Counterpoint: These tools add complexity, and you don't need them. If you step out of the system and look in, you see madness. The problems they solve are created by other tools; they are problem-generating systems.

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.

Re: Doing Rails Wrong

#179

Post by multiplegeorges »

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.

Huh? HTML is sitting right there and it's out of the box with Rails. CSS3 is basically scss now.

I don't understand the aversion to actually writing HTML and CSS!

Re: Doing Rails Wrong

#180

Post by AstroBen »

mkhalil wrote: post #126
mosselman wrote: post #96

Earlier quoted context omitted.

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 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
Post reply on HN