Live data from Hacker News

Rails 7.1 Released

github.com

131–140 of 245 posts

Re: Rails 7.1 Released

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

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

Django is great (and comparable) if you're doing just backend, or have a separate frontend/SPA.

The frontend situation in Django is terribly outdated. Just the templating system is the worst thing I've ever seen, and it doesn't even have an asset pipeline.

Re: Rails 7.1 Released

#132
post #129

Earlier quoted context omitted.

I'm using both on two different customers. I have a preference for Rails. The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that. That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortuna…

I've worked with both for years and one thing that always bother me is implicit over explicit in RoR. It can seems easy to write code and it's faster because of that, but reading code is harder, there is too much magic. Given that we spent more time reading code than writing code I prefer the python way.

I could agree with this but I think we're comparing here Django with Rails (the frameworks) not the languages.

But yeah, if I had an option I'd prefer things to be more explicit.

Re: Rails 7.1 Released

#133
post #83
post #79

Earlier quoted context omitted.

One good reason to avoid a job doing Hotwire is so that you can take a job doing React for a similar amount, where your experience applies better and where you'll gain more transferrable experience. In short, it's probably better for your career to work on React.

As a developer, I get it. What I don't get is why as an owner/stakeholder/CTO/lead would pick the worse tool (in some context) just because everyone is using it. Well, I do get it... I just don't agree. If you read between the lines here, everyone is just picking React because everyone else is picking React, that's the only reason apparently. It drives me mad, but honestly I do understand it.

Yeah, especially for crud apps when you get to implementing forms. So much easier with rails and hotwire.

But I would be tempted to go react and inertia js for MUI or EUI for the predesinged components and nice datagrids.

- https://eui.elastic.co - https://mui.com

Re: Rails 7.1 Released

#134

Earlier quoted context omitted.

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.

What led you to think that Ruby devs don't know the basics of Javascript?

I don't think that.

My last sentence on the parent message was directed to the comment I was replying to (which said they couldn't set up node properly).

What I do think is that there's a huge % of Rails devs that hate on JavaScript as if it were some kind of enemy to beat or something, and often that leads to people not wanting to learn it properly.

Re: Rails 7.1 Released

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

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

Re: Rails 7.1 Released

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

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)

It's just that amazon isn't that good. See the alexa app as another example

Re: Rails 7.1 Released

#137

Earlier quoted context omitted.

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

I'm using both on two different customers. I have a preference for Rails. The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that. That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortuna…

Thanks for the reply. Agreed on the templating side of things - it certainly makes building sophisticated UXs harder.

Great point around project structure and ability to move between codebases - I think the lack of enforced structure in Django absolutely helps increase codebase entropy over time.

Re: Rails 7.1 Released

#138

Earlier quoted context omitted.

Interesting to hear your comparison to Django and that you wouldn’t say they’re on par, at least for you, today. Any particular reasons for preferring Rails over Django?

Django is great (and comparable) if you're doing just backend, or have a separate frontend/SPA. The frontend situation in Django is terribly outdated. Just the templating system is the worst thing I've ever seen, and it doesn't even have an asset pipeline.

Agreed. I’ve had to create dedicated SPAs for several projects recently which is a huge shame. I’d be interested to understand the architectural goals of the Django project moving ahead to see if they’re even interested in solving for this type of problem.

Re: Rails 7.1 Released

#139
post #22

Earlier quoted context omitted.

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.

I’ve used slim for years and it’s incredible. Writing erb now feels painful. Slim is clean, terse, and correct.

The only downside is I am now spoiled.

Re: Rails 7.1 Released

#140

Earlier quoted context omitted.

Elixir is like an alien shiny flying soucer. It can do all types of technical marvels with a simplicity that is not possible without disfiguring more traditional frameworks. So I'd say having a cursory glance at it is a must. In terms of $$$ value, it is extremely efficient --including all the "alien" stuff, and that's why it's so cool. An Elixir team will generally create things cheaper to build and operate. Now, th…

It's a tough market for Elixir devs at the moment - there seem to be a lot more people who want to work with Elixir than there are companies hiring for it. But on the flipside, that means if you're a company who wants to take a chance on Elixir, there are lots of available devs to hire! Personally, I'm comfortable betting my career on Elixir at the moment. It's too goddamn good to remain a niche language - I expect i…

The craziest thing with Elixir is that you can do things all by yourself in the same time that would normally take a big team and consequent infrastructure to do.
Post reply on HN