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

141–150 of 245 posts

Re: Rails 7.1 Released

#141

Post by Lutger »

tom_walters wrote: post #109
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…

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've worked with them both, although Rails has been a while. Some things that stand out to me:

Rails has pretty good code generation. If I want just want to get started and add a birthday field to the settings page, I can run a short one sentence command and it will go off: it will know how to do schema migration, routing, views, controller, etc. This is possible because everything is so straightfoward and consistent. I'm not saying generators are a good way to write your code, its just one example of how rails has very a high level of abstractions.

Django however has the admin. Once you have a model, it will generate a fully functional cms for it and its very tweakable. For a lot of businesses, the admin is quite servicable as a cms or administation tool, and it is a _huge_ timesaver.

I generally prefer django over rails, it just seems all much more explicit and easier to discover to me, however I do agree you can be a lot faster with rails once you learn how things fit together.

Re: Rails 7.1 Released

#142

Post by andrei_says_ »

0xblinq wrote: post #134
brigandish wrote: post #120

Earlier quoted context omitted.

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.

A couple of Rails versions ago, I had to deal with webpack and that surely felt like an enemy trying to fight me at every step.

Luckily, I no longer need a PhD in webpack or node packages in order to run rails s successfully.

Re: Rails 7.1 Released

#143

Post by steve1977 »

gardenhedge wrote: post #136
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)

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

See pretty much everything Amazon. AWS, Kindle, you name it. Successful, yes. Technically good, oh no.

Re: Rails 7.1 Released

#144

Post by JodieBenitez »

pmontra wrote: post #124
tom_walters wrote: post #109

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…

> If I count the cumulative hours, days, weeks spent at writing templatetags

Django has support for Jinja templates so you could just use that and call methods in your templates, which negates the need for most template tags.

Re: Rails 7.1 Released

#145

Post by arrowsmith »

julienmarie wrote: post #140
arrowsmith wrote: post #130

Earlier quoted context omitted.

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.

As someone who's spent the bulk of his career in Rails and then Phoenix, to me it's the other way around: everything else is just so goddamn slow and unproductive. Don't people realise that it doesn't have to be like this?

Re: Rails 7.1 Released

#146

Post by Lutger »

pmontra wrote: post #124
tom_walters wrote: post #109

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…

> 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. Unfortunately that means that you have to waste time by writing those imports.

Although its been a while, I do remember struggling a lot with autoloading in rails for two reasons: you can't find your dependencies from the code itself and when it breaks down its quite hard to debug. Maybe things are better now with rails and when you get really proficient you know how to find where things are - however that increase the learning curve which is supposed to be a benefit with rails. With django, I can generally look at the imports to see what this module is using. With the help of the right tools I can:

- 'go to definition' of any symbol and 99% of the time land in the source, even of django itself - automatically add imports so you don't have to write them - automatically sort and format imports and see the unused ones

With the optional static typing that is being greatly improved with recent releases, things get even easier.

I prefer this a lot above the rails 'magic', for me it is a huge time saver because my memory is not so good, there is minimal friction moving around between code and is various dependencies to see exactly how its done. With rails I'm more often looking at the docs (not so great) or examples, with django I'm most of the time looking at the source code itself or running the shell (which is very, very good).

> Model.objects.filter(...)

Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

> The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python.

I hate both but prefer the django template language. I'm surprised this is such a time waster for you. I think its good practice to not put too much logic in the templates so the division of labor in django is much better imo. But then again, I'm not a good frontend person and have problems with the deeply nested structures in html. Everything can help me simplify the template is a huge timesaver for me, bugs in the frontend code are terribly annoying. Honestly I hate frontend.

Re: Rails 7.1 Released

#147

Post by cookiengineer »

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…

A lot of rails devs I know have switched to ember.js [1], because it's also a framework based on conventions rather than having a million third-party plugins that break all the time.

Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc.

But it's not as cool as the other ones I guess, because it just works too well enough!?

[1] https://emberjs.com/

Re: Rails 7.1 Released

#148

Post by petepete »

aaronbrethorst wrote: post #30
groggo wrote: 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.

Slim is really nice for some things but the moment you want to style words within sentences or paragraphs it gets really messy and you have to start using unintuitive syntax like `|` to get the spacing right.

You can of course just drop to `markdown:`.

Still, I use it where I can on personal stuff, but tend to opt for Erb when collaboration with others is needed.

Re: Rails 7.1 Released

#149

Post by tonyedgecombe »

cookiengineer wrote: post #147
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…

A lot of rails devs I know have switched to ember.js [1], because it's also a framework based on conventions rather than having a million third-party plugins that break all the time. Architecture-wise I really like the ember-data approach because it allows a lot of automations when it comes to left join/right joins of datasets, with an integrated mockup server etc. But it's not as cool as the other ones I guess, beca…

I thought Ember was a front end framework or am I missing something?

Re: Rails 7.1 Released

#150

Post by dinoreic »

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
  - server template renders (ViewCells are still not part of Rails)
  - tasks, logging and other helpers
In the same way Rails adopted rake gem as default task runner, without re-inventing it as "ActiveCliTasks", they could have created standardised connector layer that will exchange objects between backend and frontend.

So no Stimulus, TurboLinks, HotWire and other stuff one HAS TO learn and re-learn between versions. Svelte, Vue and React should have been officially supported with thin connectors. Rails server render layer can easily be integrated in any existing frontend tech, as alternative to React server components insanity.

Also, there is no reason to have to have socket connection to pass HTML between server and client, good old RPC is just fine as 99% of big app scaling problems are Database problems, no need for another layers of complexity one has to ensure it works.

I think, in that way Rails could "shine" far into the future, using its strong points but adopting new frontend stuff on the way, not re-inventing it all the time.

Post reply on HN