Live data from Hacker News

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

nauman.medium.com

51–60 of 101 posts

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

#51
post #5

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.

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

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

#52

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.

[deleted]

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

#53
post #51

Earlier quoted context omitted.

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

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

#54

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.

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

#55
post #18

Earlier quoted context omitted.

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

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

#56
post #7

Earlier quoted context omitted.

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

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.

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

#57
post #5

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.

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.

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

#58

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.

Rails 7 is heading more that way.

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

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

#59
post #5

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.

Rails will soon default to using ESM instead of Webpack. https://world.hey.com/dhh/modern-web-apps-without-javascript...

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

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

#60
post #5

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.

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.
Post reply on HN