Rails 7.1 Released • Hacker News Board

Re: Rails 7.1 Released

#241

Post by bradgessler » Tue, Oct 10, 2023, 7:34 PM UTC

caseyohara wrote: post #117

mosselman wrote: post #85

Earlier quoted context omitted.

This is all about to change. A totally new way of using assets is coming with Propshaft which replaces Sprockets

I honestly can’t tell if your comment is sarcastic because my biggest gripe with Rails is that the asset story changes radically with every major release. Starting with 3.2 and the introduction of the asset pipeline, every new version was “This is all about to change. A totally new way of using assets is coming.” Every new version is supposed to solve all of the problems of the previous version. It’s exhausting to co…

I think a lot of communities assumed letting JS asset pipelines manage JS, CSS, and image assets would lead to a better future. Sadly that didn’t materialize and it inflicted a lot of damage on DevUX.

Today the perception is that the JS community doesn’t seem to care about providing a stable experience for those outside of it, which is why projects like Rails and Phoenix are successful with “No/Low-JS” features.

Where Rails screwed up is not updating their docs to reflect this new reality for a really long time. It wasn’t clear what people should be using. They’re still creating confusion by making it unclear if Turbo is for Rails or all web frameworks, which you’ll notice when you go to the Hotwire landing page and see no mention of Rails.

Re: Rails 7.1 Released

#242

Post by 0xblinq » Wed, Oct 11, 2023, 4:55 AM UTC

technion wrote: post #29

ywain wrote: post #5

Earlier quoted context omitted.

I'm working on a fairly recent Rails 7 code base. We initially started using Stimulus, but are now considering switching to React for a few reasons: - if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger - it's getting harder and harder to find vanilla JS packages that you can wrap in Stimulus controllers for common tasks, compared to finding React packages -…

Mastodon runs as a rails api with a react frontend. Last time I discussed this people mentioned it was the worst of both worlds and I get the argument. But doing things that way means nearly every fronted dev can work with their favourite patterns and frameworks. I love that they can debate replacing create-react-app and i do not have to care beyond saying "as long you meet the openapi spec". Moreover, everything you…

> fronted dev can work with their favourite patterns and frameworks

And this is a big problem in my opinion. We should decide the stack that better solves the problem, and then hire people that are happy to work with that, not the other way around.

It's like saying you're in the business of putting screws into walls, but you do it always with hammers because most people like to use hammers.

Re: Rails 7.1 Released

#243

Post by 0xblinq » Wed, Oct 11, 2023, 5:00 AM UTC

gls2ro wrote: post #206

dinoreic wrote: post #150

I am Rails dev, and I don't like the fact that Rails in every new version has to REINVENT ALL THE WHEELS, ALL THE TIME. That creates huge problems for Rails devs and stakeholders. Rails is based on Ruby, which is backend language, and Rails should stay more on backend. That means - session management - routing and controllers - many API options (REST, json-rpc, ...) + JSON object exporters - ORM, Mailing, etc - serve…

Are you seriously comparing the speed of changes in Rails with React/Vue/Svelte?

People just look for ways to justify their already taken decisions.

Re: Rails 7.1 Released

#244

Post by ksec » Sat, Oct 14, 2023, 5:56 PM UTC

adverbly wrote: post #194

fredrikholm wrote: post #91

Earlier quoted context omitted.

I'd like to throw in Phoenix LiveView here. Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO. LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-t…

Just gave it a look. Dynamically typed. IMO if scalability is on the table, having types is a huge benefit. It saddens me that ruby, python, elixir, JS... many of the best and most productive backend frameworks have types as an afterthought only. Rust is cool, but it's also hard to write(did last year's AoC using it, and it was fast to run, slow to write). Anyone have any recommendations for me? Should I look at go/g…

If you search Crystal on HN, there are a few user who are happy with it. Unfortunately most of them are only using it for personal projects.

Re: Rails 7.1 Released

#245

Post by pier25 » Tue, Oct 17, 2023, 5:05 PM UTC

fredrikholm wrote: post #91

0xblinq wrote: post #66

Rails is great, and better than ever. I've spent most of my early years in the field working with Django and Laravel, then moved to frontend doing [all the usual stuff we do nowadays] and this year I was assigned back to a Rails + Hotwire project. I'm truly amazed how much simpler things are. I feel sad most of us have forgotten how easier things could be, and I'm terrified about new people joining this industry that…

I'd like to throw in Phoenix LiveView here. Rails wins every battle for initial development speed, as the conventions are so thorough and well thought out that nothing even remotely comes close. Laravel is creeping in, but it's not there yet IMO. LiveView however, scales better (in every sense of the word). It also comes with batteries included (auth, database access, jobs, mailer, complete testing kit etc), little-t…

> Laravel is creeping in, but it's not there yet IMO.

Could you elaborate on this?