I think that it can still be useful with some things. However, recently, I've been limiting my reliance on gems outside of what Rails has provided. I'll still bring them in as needed if they are accomplishing something that either Rails doesn't offer or brings much developer happiness. For other gems, like simple_form, I likely wouldn't develop a new application with it anymore. Part of my reasons behind this is because I've upgraded many Rails applications with newer major and minor versions. The ones that were easiest to upgrade were smaller projects with just a few gems. A few gems that I don't have issues bringing in are friendly_id, devise, pundit, devise, and kaminari (however I may invest in pagy now instead). Over the years of upgrading apps and with what Rails offers today, these gems have been pretty solid and well maintained. Beyond these, I would really think twice about brining in a gem. For example, something like simple_form as you mentioned can be accomplished with form_with. Something like cocoon can be accomplished with StimulusJS.

I should add that these are just the functional gems for a Rails app. For development and testing, I'll still bring in better_errors, binding_of_caller, factory_bot_rails, rspec_rails, simple_cov and dotenv-rails. These fit my development workflow and makes my life a bit easier as a developer. Other gems which do not require to be in the Gemfile that I still like and use are annotate, brakeman, and bundler-audit.

I've looked into this package. It is really cool and I like that they're bringing self hosted options for performance monitoring. However, this tool is missing some key components to be a viable and recommended solution. It doesn't appear to have any kinds of alert settings or notification integrations which is critical for production applications. Otherwise, you would have to manually check the performance app for the health of your application. I can see this app providing some insights into the health of the application, but lacks a lot of the information that others provide.

```In early benchmarks, we’ve seen performance improvements over the existing rendering pipeline. For a test page with nested renders 10 levels deep, we’re seeing around a 5x increase in speed over partials: Comparison: component: 6515.4 i/s partial: 1251.2 i/s - 5.21x slower ``` It is interesting, they're showing 5x difference in some cases. Perhaps one level deep, the difference would be small, but on 10 levels deep, that's a pretty significant change.

I would assume that it has less to do with erb processing and more to do with the modules that are getting loaded in with a normal partial being rendered. In the last example of the episode, we saw how we could add in other modules for stuff like url helpers. There are likely a lot more helpers being loaded in which would account for the extra time to render the partials.