Live data from Hacker News

Rails 7.1 Released

github.com

221–230 of 245 posts

Re: Rails 7.1 Released

#221

Earlier quoted context omitted.

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…

What would be fully stack TS alternative to rails?

Ha, that's the problem! Everyone will give you a different list of 143 packages (minimum).

Also, the list they gave you will be different next month.

Re: Rails 7.1 Released

#222
post #115

Earlier quoted context omitted.

Why not? I have seen or worked on too many projects that would have been better off using Rails/Laravel/Django instead of whatever cobbled together mess was chosen instead. Not saying that those are the best choice under all circumstances but they certainly aren’t wrong.

The alternative to Rails is not "cobbled together mess".

It's either a cobbled together mess or reinventing the wheel (framework). There are not many more options.

Re: Rails 7.1 Released

#223
post #55
post #38

Earlier quoted context omitted.

Please name a few with the same comfort of having most things built-in. One example: database migrations. In the JS world it is knex all over and it is much less comfortable than ActiveRecord.

Personally I would rather use Fastify+MikroORM. Or Asp.Net. Or Flask with SqlAlchemy + the migration and validation libs(marshmallow?) Or whatever is good in Golang.

And none of those combinations reach 5% of the features Rails provides. These answers are incomplete and hide the underlying problem: You have to tie together 10s of third party libraries or services, or alternatively reinvent the wheel and implement everything from scratch. That's the point.

Re: Rails 7.1 Released

#224

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…

The Ruby/Rails community is one of the best and most friendly I've seen. But the worst part of it, by far is the hate for JavaScript. JavaScript is just a tool, like any other. And it's a very important one like it or not. And like it or not it's going to stay here for a long time. Just have a bit of an open mind and try to learn the basics at least, it will make things easier.

Here is what bothered me with JS and it might sound very stupid:

The idea to have a node_modules that has tens of thousands of folders/files for the simplest package that I needed to install. Ruby has gems, but they have few files, I can easily know where to go to understand how something works or add a debugger.

But just trying to read the name of all those seemed for me always like a task that I dont want to do.

The language itself letting aside some warts is good, can be enjoyed and good code maybe can be written.

Re: Rails 7.1 Released

#225
post #110
post #21

Earlier quoted context omitted.

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.

It seems that, at least in the enterprise world, eventually every software project evolves into a hairy monster "that no one understands", choke-full of traps and side-effects that turn around to bite you at the worst and least-predictable moment. As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon. Maybe AI can help? Instead of copilot writing new code…

That's a really interesting observation. Having been in enterprise for a long time I think there are 3 things that I've seen make a big improvement on the health of a system after a decade or more.

1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems

2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction.

3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.

Re: Rails 7.1 Released

#226

Earlier quoted context omitted.

What do you consider harder than rails? Something like Remix Run makes things very straightforward.

Those frameworks (Remix, Next, etc) give you like 5% of what you get with Rails or Laravel. There’s no point of comparison.

There is a comparison though. So there's 95% of things for you to give an example from but your comment is missing any useful examples

Re: Rails 7.1 Released

#227

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.

Rails is great for new projects, the opinionated structure and the Convention over Configuration is what makes it scale well!

Re: Rails 7.1 Released

#228

Earlier quoted context omitted.

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

This distinction is frequently emphasized in online discourse, but I've never found it to be super useful. Pretty much everyone can agree that Ruby on Rails is a framework, while underscore.js is a library, but things get really fuzzy in the middle. The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder…

It's generally considered a heuristic or rule of thumb. It is not meant to contain any hidden truth and if you've moved past the need of this level of basic heuristic it wouldn't be useful anymore.

Re: Rails 7.1 Released

#229
post #21

Earlier quoted context omitted.

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

This is almost 100% due to developer churn. Every mid-level developer introduced to the project will think they have the new abstraction that will fix everything. Eventually you end up with a monstrosity partially implementing half a dozen different abstractions with no overall architecture. I've seen it many times.

The fix for this is pretty easy though. Keep employees and avoid the churn.

Re: Rails 7.1 Released

#230

Earlier quoted context omitted.

Same reason as always—it's useful for rapid prototyping. It's not like the frontend was ever rails's strong suit.

For prototyping you don’t need a back end. You barely need one for production. Just some cloud functions and a cloud database. Firestore, gcf, or equivalent.

Can't use any of them on a plane.
Post reply on HN