Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails 7.1 Released

github.com

Post reply on HN
Print view View original

21–30 of 245 posts

Re: Rails 7.1 Released

#21

Post by jshen »

eikenberry wrote: post #8
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

> Rails is great when you stick with the defaults and a land of pain as soon as you leave them. You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.

I've worked on tons of old code bases over decades. I've never seen a library based one that's in good shape either. They usually evolve into some half baked homegrown framework that no one understands.

Re: Rails 7.1 Released

#22

Post by groggo »

roboben wrote: post #15
itake wrote: post #6

Earlier quoted context omitted.

I lost faith in rails JS integrations. I either do SSR with slim or do API only with a separate frontend. Rails changed direction too many times trying to do JS (coffee script, asset precompiling, webpack, etc)

What is SSR with slim?

I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim

There's also SSR with react and other js frameworks, but I don't think that's what they meant.

Re: Rails 7.1 Released

#23

Post by crystaln »

roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

Loose typing is a nightmare.

The youngins always learn the hard way.

Re: Rails 7.1 Released

#24

Post by desireco42 »

I really like Rails and for a long time I used it and lived fairly well off of it.

I used to make good money doing upgrades from one version to another as well...

I hear your gripes here... I think with Rails if you run into problems, this is because you created (or someone in your org) them for you.

Re: Rails 7.1 Released

#25

Post by crystaln »

roboben wrote: post #17
ulizzle wrote: post #9

Rails on the backend doesn’t get the credit it deserves. On the front-end it’s been a mess for a really long while now though

I agree. What are options here? Rails in API-only mode?

But why? So many more performant frameworks for this in strongly typed languages to boot.

Re: Rails 7.1 Released

#26

Post by sibeliuss »

ywain wrote: post #5
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

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

Comparing the two: I have a hard time understanding how one could write FE code using classes (Stimulus) in 2023, when simple functions with inputs and outputs are there for the taking. It's just asking for trouble and hidden complexity. Choose wisely!

Re: Rails 7.1 Released

#27

Post by bradgessler »

ywain wrote: post #5
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

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

> if you're looking to hire frontend engineers, the candidate pool for React is a few orders or magnitude bigger

Can't these candidates quickly learn Hotwire? Seems like its much simpler than React (less moving parts)

Re: Rails 7.1 Released

#28

Post by 0xblinq »

ywain wrote: post #5
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

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

TL;DR use React because everyone uses React?

> if you're looking to hire frontend engineers, the candidate pool for React

While this is true, I think you will also need less people to achieve the same, the amount of work is incredibly less. So maybe finding one or two developers with an open enough mind and a good salary will provide even more value than a full team of backend devs + a full team of frontend devs + all the coordination efforts.

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

Any example of this? I don’t find this to be the case, given that any “vanilla” library will work out of the box and many of the react packages are there to solve react creates problems.

> Stimulus doesn't really offer a way to write unit tests for your controllers. With React, you can use jest and react-test-renderer like

This might be controversial, but I don’t find testing UI with unit tests useful at all. Tools such as cypress provide a lot more value for the effort it takes to write and maintain, and those tools work with any underlying implementation. Mocking browser APIs is not fun at all.

Regarding typescript, I honestly just don’t get the drama. It’s just a tool. If it solves a problem for you use it, if you don’t, don’t use it. And you can’t force others to use the tool you like the most.

Also, given how these tools work (mostly with data attributes and in the fly generated methods from those data attributes) I’m not convinced typescript or not will make any noticeable difference as the user of the library.

At the end of the day it’s all trade offs. But something I can guarantee is that going the React way is a ton more work, decisions, maintenance, people and headaches. If your app/project really requires react then you’ll have to bite the bullet and go for it. What’s sad to me is going with react just because everyone uses it.

Re: Rails 7.1 Released

#29

Post by technion »

ywain wrote: post #5
roboben wrote: post #2

Currently stuck on a fairly large code base on rails 6 with a ton of react and trying to upgrade to the new “non”-JS way with Hotwire. Wish me luck Rails is great when you stick with the defaults and a land of pain as soon as you leave them.

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've described along with most of what has changed recently in the ecosystem goes away. I don't have to care what is happening to hotwire, or the asset pipeline in general or around scss gems being deprecated.

Re: Rails 7.1 Released

#30

Post by aaronbrethorst »

groggo wrote: post #22
roboben wrote: post #15

Earlier quoted context omitted.

What is SSR with slim?

I think they mean Server Side Rendering (normal rails controllers/views), and Slim is just the name of the templating engine. It's a little nicer than the default ERB. https://github.com/slim-template/slim There's also SSR with react and other js frameworks, but I don't think that's what they meant.

I haven't used Slim before, but looking at the examples shown on the repo's README, it immediately brought to mind the thought experiment: 'what if Haml but Yaml?'

n.b., I've been building Rails apps since 2007. I was a diehard Haml user up until about 2021 when I made an all-in bet on Tailwind and had to switch back to ERB because Haml with Tailwind felt too obtuse.

Post reply on HN