31–40 of 132 posts
1. Rails retired Webpacker [that] compiled and bundled JS. Import maps, Turbo and Stimulus [are now the] default options, replacing Webpacker, Turbolinks and UJS . How do these new tools compare with the old? Versus Webpack, Vite etc?
Better. Much, much better than webpack/vite imo.
I was pretty sad to see the pattern matching PR reverted for 7.1 [0], but I guess the Rails team wants to make sure they nail the execution (?) even if that means being late to the pattern matching party, which is arguably one of the best additions to Ruby since the 1.9.3 hash syntax. For now, I'm good with the little gem that kddnewton put together ( https://github.com/kddnewton/rails-pattern_matching ). [0]: https:…
We're on Propshaft now and I expect far fewer asset issues in the future :P
Quoted post unavailable.
It's a battle tested and stable framework and I would use it anyday, but you no longer read much about it on the news, junior devs are not trying to pitch it as the next silver bullet. So, to be short, it's lacking buzz and online engagement. The tech is all there, the fad has passed.
Quoted post unavailable.
HN makes downvoted posts so low-contrast they're nearly illegible for me
I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?
Quoted post unavailable.
Shopify and Github being run on Rails sorta put it to bed a long time ago.
I've seen dozens of Rails projects going in production and many are still there. Same thing for any other programming language I guess. For normal sized companies Rails is OK.
What matters is: do you still find developers to work with your technology after 2, 5, 10, 20 years? If you don't, you have to move the project where the developers are. In the case of Rails they are still here for hire.
I was a devoted rails fan 10 years ago, but haven't looked back since full stack typescript. What's the general vibe on RoR nowadays?
> What's the general vibe on RoR nowadays? Most people that use it are fine and productive. Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.
Earlier quoted context omitted.
Because of lazy evaluation or because the developers aren't properly documenting their work? A language with a formal type system essentially forces you to provide type documentation, but there is an expectation with dynamically typed languages that you will still document the types (probably in your test suite). Rails in particular makes this a core function of the framework to really push you to do so.
> Rails in particular makes this a core function of the framework to really push you to do so. This sentence surprised me. How does Rails do it? I never documented types in Rails and all was well, since 2005.
If a function accepts an arbitrary type, as is the case for all inputs in a dynamic language, one needs to document how the function is expected to behave when given x type. This is ultimately the same as type checking in a typed language. It just moves where the documentation is located.
In that move, it is true that you often lose some strictness in the quality of the documentation. The developers who have an active hatred towards their co-workers may even forgo writing documentation entirely. But if you reach that point you've really got people problems, not technical problems.
1. Rails retired Webpacker [that] compiled and bundled JS. Import maps, Turbo and Stimulus [are now the] default options, replacing Webpacker, Turbolinks and UJS . How do these new tools compare with the old? Versus Webpack, Vite etc?
1. Your frontend js needs are pretty minimal and you don't want something approaching a single-page app. In this case, you lean into Turbo and Stimulus to have rails do most things for you that would previously have been done with some a heavy-weight react-based frontend.
2. Your frontend js needs are significant and you do want a single-page app. In this case, ignore/disable turbo + stimulus. Instead, build your rails app as just a json API and then have a separate project for your frontend built using a dedicated frontend build tool like vite/CRA/webpack/etc.
On one hand, I feel like the turbo/stimulus stuff is the rails community preferring to pretend that the JS world doesn't exist. On the other hand, maybe it's really just the rails world embracing the above dichotomy: they're tools for doing some light frontend work with no JS, and an acceptance of the fact that if you want an SPA, there are better non-rails tools that you'll wind up using anyway.