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

231–240 of 288 posts

Re: Doing Rails Wrong

#231

Post by cycomachead »

marcosdumay wrote: post #190
torben-friis wrote: post #157

Earlier quoted context omitted.

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…

I mean, I think the problem with SPA-like client-side approaches are that there aren't any that have felt _good_ with Rails, let alone great.

Absolutely true that not every app needs to be a SPA from day one, but I do with there were a few more common solutions for "hybrid" apps, which use some pages as a SPA. That said, it's not that bad once you've got it setup. I like that Rails offers a solution like import maps, but I do also wish there were better core functionality for using some kind of package manager.

Like the redis analogy: Whether or not you need Redis, there are good defaults and very good 'third party' solutions for background jobs (or caching). You don't even need Redis is many cases, but it's easy to grow into.

Re: Doing Rails Wrong

#232

Post by cycomachead »

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 don't think complexity comes just from the number of tools, but the disparate things you "need" them to do. Redis, Vite, large CSS toolkits -- you're learning a bunch of large components.

I mean complexity comes from many places, but compared to the 'Unix philosophy' most of these tools are quite large. Obviously, there's quite a bit to learn about the way a *nix OS works, but if you treat tools as small and composable for simpler interfaces it helps a lot.

The web dev example of pub/sub is funny, because chances are if you're using Rails your primary DB (probably Postgres) already has a pub/sub system in or. Or you can just use any RDBMS for your job management system.

Re: Doing Rails Wrong

#233

Post by cycomachead »

asplake wrote: post #75
timr wrote: post #46

Earlier quoted context omitted.

> I'm old enough to remember what it was like to deploy a Rails application pre-Docker: rsyncing or dropping a tarball into a fleet of instances and then `touch`ing the requisite file to get the app server to reset. If this is what you remember, then you remember a very broken setup. Even an “ancient” Capistrano deployment system is better than that.

Or there was “git push heroku main” or whatever it was back in the day. Had quite a moment when I first did that from a train – we take such things for granted now of course...

Honestly this is still a great way to deploy apps and still some of the best DX there is, IMO.

Costs a crap ton for what it is, but it is nice.

Re: Doing Rails Wrong

#234

Post by tills13 »

hu3 wrote: post #34
b_e_n_t_o_n wrote: post #31

If you're gonna rant about the JS ecosystem at least get it right. You can set up a Vite + React + Tailwind setup with two commands npm create vite npm i @tailwindcss/vite tailwindcss If you want automatic code formatting and linting install biome, that's one more command. You don't need to think about React Refresh or babel or typescript, it's all handled by vite. I've never even seen a .babelrc file. And why does t…

What about the backend? Rails covers that, your solution doesn't. I guess I should draw the rest of the owl.

Use NextJS, then. I think everyone in this thread and the author of the post is intentionally choosing sub-optimal setups for the side they don't like.

Re: Doing Rails Wrong

#235

Post by conradfr »

em-bee wrote: post #143
fhd2 wrote: post #68

Earlier quoted context omitted.

I was hiring for a Django dev earlier this year. For the case study, almost all of them built a thin API backend in Django, and a React monster for the frontend (and in some cases, pretty much all the business logic). When asked about their motivations, almost nobody could explain it. We hired one of the very few people that just used SSR.

i can explain it. (ok, i can't explain why someone would create a react monster instead of using a better suited frontend framework, but i can explain why i prefer to separate backend and frontend) ever since i started using frontend frameworks for websites, the backend has become trivially simple. so simple that i have been able to reuse the same backend for all my websites built since. most websites do not need mor…

I don't see much difference between returning some json or displaying the same data in a server side template.

Re: Doing Rails Wrong

#237

Post by troad »

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…

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

I have no idea how one manages to be a HN reader and come out with a proclamation like "there are no greenfield projects left".

Neither venerable monoliths nor Fortune 500 companies represent the mean website. You're looking at highly visible outliers and ignoring the forest for the few redwoods that poke above the rest.

The care that's put into ensuring `rails new` creates something sane and basically production ready is exemplary. It's the missing middle between Hello World and terse API autodocs that so many tools just lack. Whether one uses Rails or not, this is something to emulate, not glibly denigrate.

Re: Doing Rails Wrong

#238

Post by troad »

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

Going against the grain here, but I liked Stimulus so much I lifted it out of Rails and plopped it into a Phoenix app.

I think the problem here is a disconnect of assumptions. Stimulus isn't meant to be an alternative to React.

If your app is (tens of) thousands of lines of JS, and that is all you know a web app to be, then React may be a sensible, battle-tested approach for you.

But if all you need is a few dozen lines of JS to polish the UX of an overwhelmingly server-side app, then Stimulus is a neat way to encapsulate and surface it when desired. In Phoenix, it slots nicely between static HTML views and dynamic LiveViews.

I don't think anyone has ever suggested you should use Stimulus to try to replicate a SPA, and I imagine you'd have a very bad time if you tried.

Re: Doing Rails Wrong

#239

Post by JodieBenitez »

wackget wrote: post #22

Am I the only one who still thinks any kind of build process does not belong in web development? If I'm making a typical website, all I'm using is a few PHP files, a single CSS file and maybe some JavaScript. There are no build steps. No minification. No compilation. No frameworks. I just can't understand even using Rails for web dev.

Minification... how many times have I seen devs claiming that adding a whole toolchain for saving a few kilobytes is crucial to performance and simultaneously failing to serve assets with proper compression and cache headers ? Heck, how many times have I seen "web" devs with no basic understanding of the HTTP protocol ?

And they look at me like I'm the lunatic when I tell them their 3 text fields 2 buttons "app" is over-engineered and needs no build step.

Re: Doing Rails Wrong

#240

Post by troad »

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…

I think the pushback isn't so much against the existence of the tools per se, more against the pervasive idea that everyone needs them.

When every other learning resource is titled something like "Ten reasons you need to be using the MONGOOSE stack right NOW!", it's no wonder we've got people trying to shove redis into their baking blogs.

Matter of fact is, the average website would be fine without a "stack" of any kind, but no YouTuber sells sponsorships telling their viewers that. Ergo, many junior devs genuinely don't know that.

While I agree that people should be primarily learning the core tech, it's a difficult message to deliver amongst the cacophony of corporations trying to promote their services.

Post reply on HN