Really cool! Another idea for your gem, allow a block with the listing of columns. Kind of like a small DSL for the ordering and selection of columns. 

I've been working on a project which takes the ideas of the Datatables and is basically a full rewrite; allowing pagination, individual column searching, column selection and ordering, saving custom reports and setting defaults, etc. It's a pretty large library so far, but not ready to share with the world. 

On an existing established application, you would be adding extra dependencies for a micro framework. While Webpack would have long running benefits in the application, I wouldn't necessarily add it into one just for this. If I was tasked with refactoring the app and clean up a bunch of javascript files, vendor assets, etc. then I would consider adding it in.

It is mostly the extra dependencies needed; javascript runtime (NodeJS), yarn, etc. In my apps, I usually add mini_racer or the_ruby_racer to the Gemfile for handling the JS Runtime so I don't have to worry about machine dependencies. However, with Webpack, you would need it on there. Again, it's not a huge deal, but I would want a reason to add it in. Since their documentation does have a way to support Stimulus without a build system, this would be the route I would go with unless I was doing some other major kind of refactor where the introduction of a build system would benefit. https://github.com/stimulusjs/stimulus/blob/master/INSTALLING.md#using-without-a-build-system

Personally, I would probably use deliver_now. The background job is already asynchronous so there isn't much point to loop back to another job. However, if I were sending many emails within a background job, I would use deliver_later.

I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.