It's telling that most instructions deal with the Javascript toolchain and not Rails itself. And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old.

I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild. Every step away from the insane churn of the modern frontend world is welcome.

Creator of Tailwind here — if you don’t want to go deep into JS tooling and really just care about spitting out a CSS file, it's a lot simpler to just use our CLI tool: https://tailwindcss.com/docs/installation#using-tailwind-cli

I do kind of wish Rails had just taken the 'bring your own JavaScript and CSS' route instead of wrapping Webpack and adding a boatload of confusion due to multiple layers of things that don't feel like they were designed to work together.

Tell me where to output my .js, .css and other assets and let me worry about compiling - or not as is often the case.

If anyone wants to see a working example of this in Docker, I have an example app at: https://github.com/nickjj/docker-rails-example

Besides Rails / Webpacker 6 and Tailwind with the JIT compiler it also includes Sidekiq, Action Cable and Turbo along with Postgres and Redis.

I'm not married to the idea of Webpacker, but currently it's the most painless way to create bundles and process your CSS and JS even if you mostly use server side templates with sprinkles of JS. I'll switch the example app to what Rails defaults to in the future but right now we're in a limbo state where combining a bunch of other independent watchers (esbuild + Tailwind's watcher) and ESM isn't a better development experience IMO.

With Webpacker and Tailwind's JIT, CSS + JS changes take 100ms and you can further optimize startup times with using Webpack's disk cache. With the above Docker set up it's configured with multi-stage builds so your final Rails app only has the end result of running an assets precompile which only runs with RAILS_ENV=production. The Webpack watcher only runs in development too.

If anyone works with Phoenix instead, a similar example app is here https://github.com/nickjj/docker-phoenix-example. There's also example apps for Flask, Django, Node and Play too if you replace the name of the repo. All of them go over the motions of setting up a base line app with Tailwind and Webpack plus whatever else is idiomatic in that stack.

Plot twist: For the Flask, Django, Phoenix, Node and Play examples I've used nearly the same Webpack config for 2 years and I continuously keep Webpack and all of the JS dependencies up to date. There hasn't been any issues at all. I wouldn't consider myself an advanced front-end developer either. I glanced their docs, found something that works and stuck with it.

Love seeing the set of gems that folks tend to bring into all their projects. https://github.com/dejan/rails_panel Was a new one for me, will def be checking that out

Wait. So… you practically need to develop an app to start developing an app?

When someone tells me to ‘invoke these 3 magic incantations’, I can sort of keep track of it. But here it seems like the instructions are to invoke these 300 magic incantations.

Useful recap. I went through something similar a few weeks ago and the webpack/tailwindcss JIT/postcss setup has been a pain in the ass: dependency hell, outdated documentation, unintelligible error messages.

I'm glad to see that both rails and phoenix guys are looking for a way out of this madness. The writing is on the wall.

I started work on a (webpacker-like) esbuild integration for Rails: https://github.com/bouk/esbuilder

It works, but needs UX work, documentation and more extensive testing to be appropriate for general use

Using Vite with Ruby/Rails is also a modern option [1], really impressed after trying it out.

The article "A Rubyist's Guide to Vite.js"[2] from the author of ViteRuby provides a cool deep dive.

[1]: https://vite-ruby.netlify.app

[2]: https://maximomussini.com/posts/a-rubyist-guide-to-vite-js/

I think esbuild would have made webpack redundant soon if it hadn't already been removed.

What is Webpacker?

There are enough instances of webpacker in this thread (instead of webpack) making me think it's something different.

Another reason to move to Elixir from Ruby...