Hacker News Reader

Comment by toberoni | Hacker News Reader

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.

View on HN

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

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.

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!

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

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

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.

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.

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.

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.

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

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)

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

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

Reply on news.ycombinator.com