[deleted]
Doing Rails Wrong
201–210 of 288 posts
Re: Doing Rails Wrong
#202Earlier quoted context omitted.
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.
Those are part of what I'm talking about re. brittle and hard to maintain. Similar to jquery, just server sideZ
Re: Doing Rails Wrong
#203Earlier quoted context omitted.
What if you're building a highly interactive front end?
Yes, when the thing you are building is a web application, you should use web application tools. When you are building a data browser, you should use web tools.
It sounds nice in theory but then eventually you wind up needing to implement a feature where you wish you had React et al to implement it.
Easier just to start with it from the beginning. Assuming you're a full stack / front end guy of course, or else I get the appeal of html only.
Re: Doing Rails Wrong
#204Then you watch someone use Hey.com for 10 seconds and realize that it's kinda embarrassing to have a worse web mail client in 2025 than Gmail was in 2005. And you probably actually do want a JavaScript SPA if you want to match Gmail's interactivity.
Re: Doing Rails Wrong
#205Earlier quoted context omitted.
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.
Industry standards are not platform standards. React (enabled by Inertia) is in many ways is an industry standard for building UIs on the web today, yet it's not part of the platform. Same with Vite, it's the standard way to bundle on the web.
Decidedly, Import Maps are not used as a standard for dependency management in the web dev industry.
Re: Doing Rails Wrong
#206Earlier quoted context omitted.
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
Islands probably have some runtime performance benefits, but the dev experience and build-time complexity is probably just as high or higher than most JavaScript SPA setups.
Re: Doing Rails Wrong
#207Earlier quoted context omitted.
You know Stimulus is for writing JS, right?
Yes. It's also recommended to not use much of it and do almost everything else with turbo drive, or turbo frames, or with turbo streams, or with whichever convoluted magic you can do to avoid it until you can't anymore. Then you use Stimulus. Yes, I know it. The fact people can't escape JavaScript doesn't stop people from being JS haters.
> The fact people can't escape JavaScript doesn't stop people from being JS haters.
It just creates more of them.
The nice thing about stimulus is that it binds the pages I'm making to the javascript. It's all easy to find.
90% of what I want react for is to update just part of the page. This is simple with Hotwire now. There is no added marshalling/unmarshalling of json -- just regular crud requests the same as everywhere else. There is no second programming language. There is no added toolchain.
Adding in Stimulus and I can do most of the other things I've been wanting to do -- like modifying dropdowns.
The one place I can see React perhaps being better is when something happens on the page and I don't talk to the server. For most of my business applications, this doesn't come up as much. But say I was organizing a schedule, only to submit it to the server at the very end, React might be better at dragging things around, labelling them, then one big update at the end. Maybe it's easy in Hotwire also, I don't know yet.
Re: Doing Rails Wrong
#208Any 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.
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.
> and in some cases, pretty much all the business logic
and you still have to enforce that business logic in the backend as well.
Re: Doing Rails Wrong
#209Earlier 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?
IMO it's that frontend wasn't really a separate discipline at the time. Ember came out of Sproutcore, which was a framework created by some Apple MobileMe developers. They were building something that was very much an application development framework for single page apps before the term 'SPA' even existed. And I think people doing front end just weren't ready for that level of complexity yet. Most web developers were self taught and didn't have experience with UI frameworks and "real programming". At the time, doing frontend largely meant using jQuery to do ad hoc DOM manipulation and AJAX requests. Angular and then React came out and only tried to solve a subset of the problem that Ember was trying to solve, so they were easier for people to get started with. Then as time went on, it turned out that everyone did actually need solutions for everything else, but by then React had won.
Re: Doing Rails Wrong
#210Am 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.
>I just can't understand even using Rails for web dev. Some people are building real web applications, not PHP toys. I get not wanting to keep up with the latest JS insanity, but simple MVC frameworks are popular for a reason.
I've been a web developer for over 20 years. I remain totally unconvinced of the need for frameworks.