@fatkodima When ActiveJob is available mandating or requiring Sidekiq is not responsible, imo.

@mikker @jeremyevans0 It is almost to the point where the way to pick the best tools for frontend in Rails is giving up on _any_ tools whatsoever and just doing bare CSS and bare JS 🤷‍♂️

A great example where batching matters *a ton* is the recent addition of `enqueue_all` in ActiveJob adapters. Using `enqueue_all` can sometimes speed up your actions by a factor of 40x (!) - just because you bypass the fancy per-object/per-model indirection-fest with procedural code that is optimised for the task.

@danielbergholz @nextjs Frontend is not necessarily easy, but indeed it is not easy for other reasons. Not for using a kitchen-sink of React gunk and complex SSR/CSR flows, but because UI is hard. When proper UI gets done it is not necessarily easy - and that's ok :-)

If they "have a single singleton method called `.call`" they do so because they are built stateless, and are actually Commands or Workflows - and it is fine. The reason to have just `.call` is to indicate that any state of the command is ephemeral and should not be mucked with. This is good.

@MichaelDChaney @MorriceGavin Absolutely yes on both. On my last app where heavy use of commands was present some commands were 900+ lines - with ample comments and exactly to achieve the 2). It was meant as well-tested, very procedural, robust code that only makes sense executed "as whole".

@MorriceGavin Interesting choices on some of these. I think I would entirely forego Slim, not use SASS (hardly finding it useful these days), and I would certainly not use Sidekiq but solid_queue, good_job or Gouda (given it is PostgreSQL)

We did React, Redux, mobx, zustand, zod and SSR and localStorage. Most apps (including big cloud) still cannot handle one account logged in in one browser window and another in the second. And god forbid you want to live-switch inside the same window without state loss.

@marcoroth_ @fatkodima Strictly speaking, there are 6 if you use the following matrix: combinations = { syntax: [:do_end, :braces], args: [:named, :implicit_numbered, :implicit_it], } Like others mentioned - having multiple ways to do things is very Ruby, it is not Python or Go for good reasons.

@fatkodima Nah, it's going to be fine. The ergonomics of those trivial cases (single-arg map, filter and each, primarily) are so good that it's worth the mental remapping ("this used to be an rspec test definition call"). I did have 1 case of shadowing which was annoying, but that's it.

@inazarova @github @hackclub @evilmartians Would love to see a recording of that first discussion... /cc @mr_mig_en

@collin_jilbert So far my comment is this: this is the best syntax improvement since block rescue. It is very ergonomic and very useful, with the biggest downside being variable shadowing in nested blocks.

@dhh Seconded.

@igor_alexandrov And once you start having separate devs and ops (and didn't prepare for it very thoroughly nor have the reasons for doing so) - you will fail twice

@KennedyRichard @DigheroJorge @tom_doerr Didn't know about this one, cool!

@nateberkopec Yes.

@KennedyRichard @DigheroJorge @tom_doerr My pleasure! Love Nodezator even though I never needed to use it. If you are curious about the "cutting connections" bit, I've made a codepen for it a long while back: