Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

This is why I can’t use anything too complicated. I’m just not smart enough to wrangle complex configurations and dependencies.

So I keep producing Rails apps that get the job done without the bells and whistles and without much polish.

I wish I could hire a config expert for half an hour and have them create the setup I want. Because I will never get my masters in webpack/rollup/postcss/stimulusjs/mystery sauce working config du jour.



sort by: page size:

In the time it takes to configure Webpack I can write an app in Rails. Convention. Over. Configuration.

Yes, but Ruby on Rails dependencies aren't a fucking headache to manage.

I've only had one issue with Rails dependencies. They work fucking great if you just want to drop them and leave in the default configuration but the moment you try to customize them... holy shit balls.


> tooling, dependency hell

I used Rails when it was still `config.gem` with no dependency resolution, and it was an absolute nightmare, so I think I know what you're talking about here. But then bundler came along and, well, completely solved the problem.


I do kind of wish Rails had just taken the 'bring your own JavaScript and CSS' route instead of wrapping Webpack and adding a boatload of confusion due to multiple layers of things that don't feel like they were designed to work together.

Tell me where to output my .js, .css and other assets and let me worry about compiling - or not as is often the case.


Every time I try to write some "super simple web app" that I think is much too small for Rails I always end up in spots like this: migrations, then asset fingerprinting, then some quick sanity tests, oh, now I need this other thing and I've cobbled together a creaky messed up version of Rails.

modern Rails requires lots of configuration, convention and prerequisites.

Err, I love Rails and all, but don't confuse ease of use with ease of learning. The thing about putting convention over configuration is that you have to learn a lot of conventions.

Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating that trying to get a mildly complex Rails app deployed on a mutable server.

So, you are not encountered the dependency and version hell yet and just assumed that maintaining all the libs and tools a rails app is implicitly requires is a easy task?) Good luck, then.)

No, really, just use modules - they are testable and reusable and any truly professional Rails dev is going to have zero problems understanding and working with them. This smells of someone very new to Ruby/Rails.

I have two applications in the wild— one a monorepo with a rails API and front end built with deploy scripts, and one with rails Webpacker. The Webpacker one feels like I have an arm tied behind my back. There’s a bunch of ‘Rails way’ extras I have to do to keep things ‘organized’, but I don’t even get proper state-maintaining hot reloading in dev. It does smooth over some rough edges (though through magic) but the next one will probably prefer the self-management strategy.

I agree it’s way too complex, it’s a problem I’m working on actively.

I’d like to first help https://vxrn.dev find some consistent contributors and get it stable.

And then I ported Expo Router to work with it, so shared single file system routes and no more need for a monorepo.

So now you’ve simplified from two bundlers, two stacks, four folders down to one stack, one bundler, and one folder.

And then I have some interesting ideas to make data a lot simpler which I’d like to try on top.

All together no reason we can’t make a modern Rails like experience work, but it is crazy how much work it is with all the modern stuff, but imo will pay off with something actually great for universal apps.


Seriously I see no reason why a no-code config tool couldn’t autogenerate vast swaths of Django or Rails or Next.js projects for common usecases

"Rails... ...doesn't play well with SPAs"

Huh? Rails ships with built-in, no-config webpack support (https://github.com/rails/webpacker#installation) as well as install tasks for the most-popular front-end solutions (https://github.com/rails/webpacker#integrations)


A couple of Rails versions ago, I had to deal with webpack and that surely felt like an enemy trying to fight me at every step.

Luckily, I no longer need a PhD in webpack or node packages in order to run rails s successfully.


There may be packages in the community but the entire point of the article was highlighting the advantages of having framework level choices that 1. Are maintained by the framework team, 2. Establish patterns where the community can build other packages based on those assumptions. For example, now that yarn and webpack are standard in rails, we can build gems that can import and configure JS packages in a consistent and modern way, knowing exactly how most rails projects will manage JS. I have been frustrated that rails doesn’t have default admin, authentication, and authorization for this exact reason.

I think if you find rails to be too hard you ought to be looking for some hosted solution to do what you want or just pay somebody else to do it.

I built a new Rails app with importmap-rails last year and it was an absolute joy to work with. Being able to forgo all of the JS compilation bs was a massive simplification. I've wasted so much time in the past dealing with Babel and Webpack so finally being able to kick all of it to the curb was a joyous day.

Thank you for this, you are absolutely right. I've had to watch a coworker (who's new to Rails) struggle through this same bullshit. After the 5 days it took him to set it up and run our Rails app locally, I showed him Smalltalk's Seaside and how it takes a minute and a half from downloading to having it work, so that at least he would have some perspective of how so far off the Rails experience is from what it could be.

Please keep this up at least until I get to the office tomorrow so I can send him the link. :)

next

Legal | privacy