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