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.
> And let's hope that everything works and none of the 2000 imported node_modules blow up when this tutorial is 3 months old.
We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
In curious why you feel the need to do that? I typically only update dependencies either for serious security issues or new features I really, really want to use.
I still have a few projects running Webpack 1 without issue.
If rails is only used as an API, I found it much cleaner to have a separate codebase for the SPA and run webpack separately (or nowadays maybe use something like esbuild instead?).
I was able to work with rails & webpacker precisely because I had experience with webpack separately, but webpacker had some weird limitations.
One thing that's important to keep in mind is that esbuild is a bundler, in that it can take an input file that imports other JS files and create an optimized ready-for-production output bundle file. SWC cannot, yet, accomplish this.[1] It is in the works, however! But if I was choosing a replacement for Webpack to use today, I'd definitely go with esbuild.
It’s very easy to hook into esbuild. The simplicity and ease of integration is a big part of what I like about esbuild. I haven’t used swc, however, so I can’t comment on how it compares.
I found it compelling but was concerned it was a bit early and not enough others would be using esbuild that issues I hit would be googleable. Now that it's the Phoenix default, that won't be a problem.
It's still perfectly possible and valid to use Sprockets instead of webpack in a Rails app. That's what i do with every one of my applications and it works flawlesly
When I used to use Rails pre-webpacker I felt like I was constantly fighting with sprockets. Trying to use it with assets from node modules isn't always straightforward, and it's pretty slow (or used to be).
That has been the most disappointing thing to me with rails. The ruby part of it is so nice. The front end has always made me feel doubtful. It’s not really the rails team fault that the frond end landscape is so tumultuous.
I think a huge part of the problem is that they keep trying to Railsify the front-end. It's impossible to build a decent abstraction over as fractured and fast-moving a target as the whole front-end tool chain. Webpack is already annoying as is, hiding it behind the webpacker gem for no good reason was a shitshow.
Oh, this is great news. I thought everyone involved with js (and coffescript) in rails were completely insane. Glad to see they were just doing the best they could in a crazy world (the early js world).
Wow that sounds great. It looks like it's still quite new, but I love having webpacker as optional in Rails 7 and just using ESM instead, which seems much more sane.
Still, there's the need to install NPM packages. You can use Skypack as a patch, but ideally you should be able to host all of your JavaScript. I guess you could use `npm` and manually link to those files in your configuration map, there could even be an automated Rake task to do it, but I don't know if that's the direction DHH has in mind.
How often does your webpack setup blow up? We haven’t touched our configuration in a year and it still works perfectly fine. What complex things must you be doing for you config to not even last 3 months !!!
3 months might be (close to) hyperbole, but webpack/JS package management is a source of consistent pain. It sticks out like a sore thumb across my web stacks (PHP/WP, Ruby, Elixir) and its brittle complexity causes the most unpleasant dev experience I have to deal with.
I doubt it's my incompetence alone - npm is involved in over 25% of Phoenix's issues!
I could be wrong but didn’t phoenix just switch to webpack from some other package manager? I guess that was 3ish years ago so a lifetime more or less in JS.
Thanks for responding, I wrote this to keep a record of my steps for future reference. I did not intend that this was the only way or the right path
As I've seen many tutorials that were too complex to set up JIT with Tailwind, I thought it might be helpful to others as well who were having difficulty.
The next version of Rails will eliminate webpacker anyway, so I'll write for it
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.
I think the ideal would be some kind of middle ground: an optional contrib module, plugin, or even just documented pattern that can serve as an officially supported approach without baking a strong opinion directly into the framework.
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.
Yeah, one of the key selling points of Rails was that it was Omakase (Japanese: "I'll leave it up to you", i.e. you take the defaults Rails provides) and "batteries included" (i.e. there's enough provided in the box to get a working application).
Having to jump through all these hoops (I'll note that one of the suggested gems is Devise, which provides a framework for user authentication) suggests either this is very much no longer the case or this is tacking on a lot of stuff Rails was never intended to use, which could be fun to maintain down the line.
The majority of hoops jumped through in the article are entirely of the writer’s own making. They changed the default CSS pipeline and added functionality Rails deliberately does not define.
Devise is common for user authentication (and good choice, in my opinion) but it is extremely opinionated and does not like you departing from the blessed path.
Rails tends to avoid enforcing patterns beyond the base building blocks of MVC. User authentication is out of scope. (Turbo links is strongly opinionated but also very limited and very easy to remove.)
Having just been playing around with Rails and different CSS frameworks for a new project, this is entirely due to Tailwind's dependencies. Adding other CSS frameworks is as easy as yarn add X then importing it into your application.css file.
This setup is deviating quite a bit from a default rails setup: using the beta webpacker, tailwind + plugins, some extra gems.
Also - I noticed the author says "foreman is the best way to develop locally". I encourage the author to give overmind a try - it is a drop in, more featureful replacement for foreman. I love it.
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.
What disappoints me is that the Rails team fell for this madness in the first place. Rails in particular has planted its flag on the maximize server-side work camp for the sake of overall tool simplicity. It seems like the Rails team was getting insecure of all the JS hype and "is Rails dying" articles and decided to start chasing trends. I called this the second they shoved webpacker into Rails6 and am not at all surprised this is where we are.
Readit News
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.
We have recurring Jira tickets for updating npm dependencies every two weeks. One developer is occupied between half a day and two days because the amount of breakage in the npm ecosystem is enormous. It’s ridiculous and sucks the life out of us.
We just use dependabot to issue PRs for updating dependencies, and we merge automatically when tests pass. It's never caused an issue.
I still have a few projects running Webpack 1 without issue.
I was able to work with rails & webpacker precisely because I had experience with webpack separately, but webpacker had some weird limitations.
https://sergiotapia.com/phoenix-160-liveview-esbuild-tailwin...
Also medium sucks, please don't use it to write developer blogs. People can't read your article!
Also one limitation by design of esbuild is lack of customization, you cannot hook into esbuild and do your own things, but I read you could with swc.
But either way, both are way faster than the most popular ones.
[1] https://swc.rs/docs/spack-basic/#mode
I don't like the churn either, but ditching X for Y only contributes to the churn.
So am I!
I read Mitchell Hanberg's blog post on using it with 1.5 a while back: https://www.mitchellhanberg.com/how-i-handle-static-assets-i...
I found it compelling but was concerned it was a bit early and not enough others would be using esbuild that issues I hit would be googleable. Now that it's the Phoenix default, that won't be a problem.
Compare with something like NextJS where the aforementioned setup takes almost no effort.
https://world.hey.com/dhh/modern-web-apps-without-javascript...
Still, there's the need to install NPM packages. You can use Skypack as a patch, but ideally you should be able to host all of your JavaScript. I guess you could use `npm` and manually link to those files in your configuration map, there could even be an automated Rake task to do it, but I don't know if that's the direction DHH has in mind.
I doubt it's my incompetence alone - npm is involved in over 25% of Phoenix's issues!
IMO, use whatever gets you to paid users fastest.
It seems like Tailwind is popular enough now to support guides for more than just JS frameworks and Laravel :)
As I've seen many tutorials that were too complex to set up JIT with Tailwind, I thought it might be helpful to others as well who were having difficulty.
The next version of Rails will eliminate webpacker anyway, so I'll write for it
Deleted Comment
Tell me where to output my .js, .css and other assets and let me worry about compiling - or not as is often the case.
I think the ideal would be some kind of middle ground: an optional contrib module, plugin, or even just documented pattern that can serve as an officially supported approach without baking a strong opinion directly into the framework.
https://world.hey.com/dhh/modern-web-apps-without-javascript...
Deleted Comment
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.
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.
Having to jump through all these hoops (I'll note that one of the suggested gems is Devise, which provides a framework for user authentication) suggests either this is very much no longer the case or this is tacking on a lot of stuff Rails was never intended to use, which could be fun to maintain down the line.
Devise is common for user authentication (and good choice, in my opinion) but it is extremely opinionated and does not like you departing from the blessed path.
Rails tends to avoid enforcing patterns beyond the base building blocks of MVC. User authentication is out of scope. (Turbo links is strongly opinionated but also very limited and very easy to remove.)
Also - I noticed the author says "foreman is the best way to develop locally". I encourage the author to give overmind a try - it is a drop in, more featureful replacement for foreman. I love it.
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.
It works, but needs UX work, documentation and more extensive testing to be appropriate for general use