Rails 6 with Webpacker 6, Tailwind 2 with JIT, Postcss 8 and some default setup | Hacker News Reader

Rails 6 with Webpacker 6, Tailwind 2 with JIT, Postcss 8 and some default setup

nauman.medium.com

169 pointsnauman97 comments

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.

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).

It works until you try using a library not available with Sprocket...

How can it not be available with Sprockets? You can just add .js files.

I started a saas company 2 weeks ago with the tool list described in the article. Already at $1k MRR.

IMO, use whatever gets you to paid users fastest.

Can you show it?

Closingcredits.com

Rails will soon default to using ESM instead of Webpack.

https://world.hey.com/dhh/modern-web-apps-without-javascript...

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.

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).

I don't think it's telling of anything. Rails was not made to work seamlessly with these tools, so obviously there's going to be some setup cost.

Compare with something like NextJS where the aforementioned setup takes almost no effort.

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!

Can’t speak for the integration into non-JS ecosystems, but since I started using Create React App instead of rolling my own Webpack configs a few years ago, I’ve had approximately zero weird npm issues.

I maintain a Rails codebase and a Node codebase. We are using esbuild for Node / JS bundling, along with TypeScript. The Node project is much less of a headache than the Rails one, mostly due to TypeScript. We’ve also made an effort to minimize our dependencies. We have fewer npm modules than gems.

All that to say, Rails is fine. But Node is also fine, if you treat it more like Go (minimal dependencies, lean on the vanilla underpinnings).

Depends what you're comparing. Barebones Node with few dependencies is more like a Rack application. Rails is the other end of the spectrum.

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.

Phoenix was using brunch until it switched to webpack in 1.4.0 (2018-11-07)

This is why Phoenix is ditching webpack! The story on the Elixir side is more compelling. I'm glad the team made this decision.

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!

Thank you very much for the blog post, it will save a lot of time and hair.

It’s something I wish I had handy a week ago. Hope it helps!

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.

> 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.

I don't like the churn either, but ditching X for Y only contributes to the churn.

Looks like Rails wants off Webpacker as well https://github.com/rails/importmap-rails

Yes, Rails 7 will not use webpack (or almost any other “modern JS”) by default. https://github.com/rails/rails/pull/42999 is the big change.

This is too broad to be true in general. It depends on what Y is...

Phoenix is the maintainer of the Elixir esbuild package--it's just a binary.

It seems that swc is gaining more traction than esbuild, deno is using it, nextjs hired swc dev and rome is using swc too.

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.

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.

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.

[1] https://swc.rs/docs/spack-basic/#mode

> 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.

Why not just use fixed versions and upgrade when you have a reason to?

That sounds like a nightmare waiting to happen. You have a package which hasn't been upgraded by your team for two years and suddenly someone finds a vulnerability in every version before 3.xyz.something. When you check, your version package is 1.3.5. Now you have to upgrade multiple major versions, and in all likelihood the package had transitive dependencies which have had many updates themselves as well. After several months/years of neglect, "upgrade when you have a reason to" has turned into a major undertaking and if you are especially unlucky it will take multiple devs many weeks to sort out the mess. All this time, your app will be running an unsafe version of the package and you can only hope that nobody finds out before the dependency upgrade is completed.

Keeping your dependencies is boring and takes a lot of time, but the alternatives are far worse.

Another option is to ditch the dependency and roll your own, which for many things will be Good Enough(TM), especially as the JS standard library becomes more useful.

Like, do you really need to import half of lodash or ramda just so you can one-line a few calls?

I try to be judicious about adding dependencies, but Lodash is very well-understood and stable. It's actually the type I would add without any concerns whatsoever. I can't even remember hitting an issue due to it making a breaking change.

Or just backport the fix

“Why not just”…

I'm sure you have a lived experience that guides what you said, but this just hasnt been my experience.

We just use dependabot to issue PRs for updating dependencies, and we merge automatically when tests pass. It's never caused an issue.

I actually have dependabot enabled on a side project that I've stopped maintaining and every once in a while I get package update notifications.

It works great but the underlying problem still remains I guess

If you want things to be more stable use clojure

I sincerely do not understand this complaint. Do you dislike bug fixes and new features? Would you be happier with a stagnant tooling ecosystem?

Sadly it’s the constant barrage of breaking changes. It’s not just a version number bump and everything keeps running. Patch version breaks the app. Minor version breaks the app. Major version breaks the app (understandable in semver) but multiple inter-dependencies need to be updated in parallel.

So part of my job is maintaining a complex webpack build system, and I do get that it's not a small amount of work. However, the changes I see aren't wonton. They're typically aimed toward a world that's more interoperable and more standards-compliant.

For instance, Webpack 5 deprecated worker-loader in favor of a construction using new URL() and import.meta.url. Adopting this was a huge pain, but what we get in exchange is a system that can load workers using standard syntactic constructions that work under e.g. our test runner or in a NodeJS microservice. Something like that is worth the hassle to me.

As for minor and patch versions causing breaking changes, this has happened to me a few times. Terser Webpack Plugin 3.0.6 exposed flaws in a custom Webpack plugin we'd written for internal use, which I cannot fairly blame on anybody but ourselves. Babel 7.5 broke CommonJS targets in a way that wasn't fixed until 7.6, which was truly unpleasant and something I hope to never deal with again. TypeScript doesn't use Semver and usually has breaking changes in every point release. For the most part, however, semver has proven trustworthy.

The Darwinian foment that characterizes the front-end ecosystem has created the best tools I've ever used. When I look at the quality of tooling available on stacks that prioritize stability, I am not jealous.

I maintain oodles of npm packages, several of which enjoy over 5 million weekly downloads. They have dependencies, and I cannot support your claims.

Sure - some packages in the ecosystem will not follow semver, some will let breaking changes sneak in where they aren't supposed to be. But you'll find this in any pluggable or package manager ecosystem. Please, measure your frustration and choose not to paint with such a wide brush.

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.

Large companies often have security mandates that dependencies should be regularly updated.

Well, sure. Dogmatic policies like that will cause all kinds of problems.

I used to do this on rails projects. Then 3 years later you're running all ancient libraries, and you need to upgrade one with dependencies that conflict with your older locked versions. So now instead of dealing with one thing at a time, I've got 30 libraries (many not even direct dependencies) that have all got to get upgraded, and it's a nightmare to unwind and update it all.

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.

That’s a good point. If it were possible to successfully “railsify” the front end that would be amazing.

I'm looking forward to Phoenix 1.6 which ditches Webpack for esbuild.

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.

For the record, next Rails version (v7) is on the path of ditching webpack, too.

What? It was just integrated as default. Do you have a source/link for more information?

yup, https://world.hey.com/dhh/modern-web-apps-without-javascript...

"Unless new evidence comes to bear that refutes the basic tenets of this analysis, Rails 7.0 will aim to give you a default setup based on import maps, and leave the Webpacker approach as an optional alternative."

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

Good to note!

Any plans for adding integration guides for back-end frameworks like Rails and Phoenix?

It seems like Tailwind is popular enough now to support guides for more than just JS frameworks and Laravel :)

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.

Django went that route and it's not great either.

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.

Rails 7 is heading more that way.

https://world.hey.com/dhh/modern-web-apps-without-javascript...

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.

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.)

My point about Devise was more “if you’re not using auth, why have you included this?”. I think Rails should probably have a Devise-lite in the box, though.

This sounds like the second of my options i.e. gl;hf when the next major Rails release comes around.

Rails choosing not to provide a standard auth solution is 100% the right call. There are a wide variety of auth scenarios, and Devise is highly opinionated. If you're doing a pretty standard B2C type system where you have individual users, Devise fits well, but when you get to more B2B multi tenant with users spanning tenants, and more complicated workflows with users managing other users, Devise breaks down quickly.

Rails still works just fine out of the box. The bulk of this article is setting up Tailwind JIT, which is not required.

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.

This is due to adding a JavaScript framework. Rails can be up and running immediately.

They are only generators. You don't need to use them but they are there if you choose to use them.

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.

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 agree, this feels like the direction the framework should go in the future

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

What is Webpacker?

Webpack packaged for use in rails.

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...

Where setting up a new app with Tailwind JIT is substantially easier?

Where Phoenix does a better job with all this and you don't have Ruby's baggage anymore.

What is "all this"? This post is almost entirely about setting up Tailwind.

(I have developed professionally with both Rails and Phoenix and enjoy both.)

https://pragmaticstudio.com/tutorials/adding-tailwind-css-to...

Right, this process looks basically equivalent in steps and complexity.

It's literally the same process and it still uses webpacker...

Elixir is like the alternate town in Blazing Saddles. It looks great but you find out there aren’t really people nor library depth there. After it blows up your staffing and project plans you end up moving back.

I built my startup in elixir. yes, there aren't as many libraries but the ones I've needed have been available and reasonably documented in most cases.

one thing I like in elixir is that the whole language (and thus libraries) are more composable. its easier forme to break and reform functionality from libraries in ways the authors didnt envision. Takes more time to integrate but the end result is way more maintainable.

Yeah, Elixir is great, but zealots keep acting like it's happening, and it is totally not happening.

Elixir isn't even in Tiobe's top 50 https://www.tiobe.com/tiobe-index/

Whilst I agree with you that Elixir is an also-ran Tiobe is the worst yardstick by which to measure a programming language. I can never understand why anyone takes it seriously.

Agreed. Redmonk then? Not in the top 20 https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2...

I think Elixir fans should learn a lesson in being humble...

Reply on news.ycombinator.com