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

211–220 of 245 posts

Re: Rails 7.1 Released

#211

Post by hu3 »

nickjj wrote: post #169
caseyohara wrote: post #117

Earlier quoted context omitted.

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…

> But my point stands: the prescribed way of handling assets with Rails is ridiculous What would the alternative be for a 20 year old project? I think what we're seeing is a natural progression based on how the web changed over the last 2 decades. I'd be more concerned if Rails didn't change and `rails new` produced a jQuery / SCSS / CoffeeScript loadout and made it difficult to use modern tools. Now it's easier than…

I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

There's a point when change is just too much and the returns are diminishing.

Re: Rails 7.1 Released

#212

Post by bdcravens »

crystaln wrote: post #75
bdcravens wrote: post #40

Earlier quoted context omitted.

20+ years of experience here, I happily reach for loosely typed languages in most circumstances.

For quick scripts sure. For writing an application or something that actually require design and libraries? Why bother? You need to be meticulous anyway, why not be meticulous in code?

Literally every application I work on requires design, libraries, and meticulous code.

The focus for me is on the tools and frameworks, not the underlying language. Show me a Typescript-based or Go-based language that can go from zero to production as fast as Rails with the same-sized team with no productivity loss, and I'd happily use it.

Re: Rails 7.1 Released

#213

Post by yxhuvud »

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.

Don't upgrade your architecture all at once. First bump yourself to rails 7 (including any other gems you can upgrade), then do any other changes you want.

Re: Rails 7.1 Released

#214

Post by bdcravens »

lolinder wrote: post #59
bdcravens wrote: post #40

Earlier quoted context omitted.

20+ years of experience here, I happily reach for loosely typed languages in most circumstances.

Can you elaborate on what circumstances you're referring to? The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context —each career is unique and what projects you've worked on will have a huge impact on…

You perfectly illustrated the point: that there are no maxims like the grandparent comment made. Myself, I work on very small teams, usually building applications that are backend-heavy web apps or filled with tons of async background processing on the server. Applications that are funded by revenue, not VC. Applications where I typically have a high degree of autonomy and responsibility as to maintainability, with usually no insulation between me and stakeholders.

Given different parameters, I'm sure the decisions would be different as well.

Re: Rails 7.1 Released

#215

Post by lolinder »

bdcravens wrote: post #214
lolinder wrote: post #59

Earlier quoted context omitted.

Can you elaborate on what circumstances you're referring to? The field is extremely diverse these days, and tools that are appropriate for small data science teams may not work as well in enormous monorepos maintained by thousands of developers (and vice versa). What's missing from most discussions of static/dynamic typing is context —each career is unique and what projects you've worked on will have a huge impact on…

You perfectly illustrated the point: that there are no maxims like the grandparent comment made. Myself, I work on very small teams, usually building applications that are backend-heavy web apps or filled with tons of async background processing on the server. Applications that are funded by revenue, not VC. Applications where I typically have a high degree of autonomy and responsibility as to maintainability, with u…

Oh, for sure, I wasn't endorsing OP's position! I had another recent thread [0] that was full of highly dogmatic claims on my mind, where I noticed that very few people brought in the context for their opinions.

[0] https://news.ycombinator.com/item?id=37764326

Re: Rails 7.1 Released

#216

Post by dnoberon »

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…

Typing is coming!

Re: Rails 7.1 Released

#217

Post by nickjj »

hu3 wrote: post #211
nickjj wrote: post #169

Earlier quoted context omitted.

> But my point stands: the prescribed way of handling assets with Rails is ridiculous What would the alternative be for a 20 year old project? I think what we're seeing is a natural progression based on how the web changed over the last 2 decades. I'd be more concerned if Rails didn't change and `rails new` produced a jQuery / SCSS / CoffeeScript loadout and made it difficult to use modern tools. Now it's easier than…

I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech. There's a point when change is just too much and the returns are diminishing.

> I think your parent comment point is that they could have skipped half the changes and still kept up to date with frontend tech.

How tho?

Things naturally progressed from a lot of asset related things with few choices being baked into Rails to being more componentized but still tightly baked into Rails (Webpacker) to even more componentized and mostly decoupled from Rails (current state of things) to even more decoupled from Rails (Propshaft).

Current day if you want to use Webpack or esbuild or something else or nothing it's easy because Rails no longer cares. It only cares that assets end up in a specific directory. How they get there is up to you. The framework also provides value by giving you generators to tie things together based on the choices you want so you don't have to figure it out individually from ground zero.

If you look at it from that perspective I think things unfolded reasonably well.

Personally I didn't like Webpacker at all. Webpack was complicated enough on its own and then having to learn the Rails way of configuring it made it even harder. But I think it was a good tipping point to demonstrate that from a maintainer's POV it's hard and time consuming to create good abstractions over front-end tools on the back-end and from an end user's POV it's bad because of the complexity.

Being able to look directly at esbuild's documentation and apply it 1:1 is a much nicer outcome for everyone. Maintainers don't have to keep up with every change and users don't have another layer of abstraction to deal with.

It did take Rails a while to come to this solution but it's really good that they did. This is how I managed front-end tools in Flask and other frameworks for around the last ~decade. You have the framework look for assets in 1 spot and how they get there is up to you. It was easy for me to do that because I only had to make it work for my apps, my client's apps and the starter apps I posted on GitHub, but applying that to a framework that has hundreds of thousands of people using it is for sure a bigger project.

Re: Rails 7.1 Released

#218

Post by stevebmark »

gls2ro wrote: post #198
stevebmark wrote: post #14

Earlier quoted context omitted.

Goodreads is an example of a Rails victim like yours. They customized the app on top of Rails, and it's been so bad that Goodreads is dead in the water and has not received major tech updates despite Amazon throwing engineers at it. Ruby is a dangerous language to refactor, so often you're locked for a long time. See also: Every blog post about Rails upgrades ever (see also: Stockholm syndrome)

Are you sure Goodreads did not received updates because of Rails? Here is a competitor build with Rails https://thestorygraph.com/ Seems kinda cool. So I think Rails is not the problem here.

Yes. Goodreads received lots of updates, and they were slow and difficult because of Rails (and Ruby) https://news.ycombinator.com/item?id=36577444

Re: Rails 7.1 Released

#219

Post by 0xblinq »

arcanemachiner wrote: post #118
steve_gh wrote: post #41

Don't get me wrong, I love Rails, and have been using it off and on since Rails 2. It's a really good framework, and for someone like me who needs to stand up a website from time to time it really is the path of least resistance. What bugs me is the pain of setting up a new laptop to run Rails. I need node, which means npm. I'm a backend guy, I don't understand how to set up node, what order to do things in, etc. I d…

'asdf' (a version manager) is great for managing nodejs. I haven't dealt with Ruby before, though. https://asdf-vm.com/

asdf is awesome. It renders useless each language's own version manager.

Re: Rails 7.1 Released

#220

Post by 0xblinq »

crystaln wrote: post #67
crystaln wrote: post #36

Would anyone start a new project with Rails today? If someone suggested using Rails for a new project to me today, I would show them the door. There are so many more mature frameworks in more robust and performant languages. IMO the only reason to use Rails today is if you’re too uncurious to learn something better.

Looking at the new Hotwire stuff. It’s neat from a technical perspective but looks dreadful to me. Why double down on a sloppy backend language when hardly any of the needed logic for a web application is backend? Especially when the alternatives include a full stack of TypeScript, a robust, performant, strongly typed, fantastically tooled language? I was an RoR developer for a decade. These code bases do not age wel…

In my experience codebases that do not age well tell more about the developers and the managers than the tech stack.

I've seen marvels and disasters in every stack.

Post reply on HN