9 ms·

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

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.

masa331 5y ago
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
- ch4s3 5y ago
  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).
- Madeindjs 5y ago
  It works until you try using a library not available with Sprocket...
  - sleepyhead 5y ago
    How can it not be available with Sprockets? You can just add .js files.
buf 5y ago
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.
- edoceo 5y ago
  Can you show it?
  - buf 5y ago
    Closingcredits.com
airblade 5y ago
Rails will soon default to using ESM instead of Webpack. https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript...
- gosukiwi 5y ago
  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.
- e12e 5y ago
  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).
sergiomattei 5y ago
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.
Lapz 5y ago
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 !!!
- toberoni 5y ago
  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!
  - christophilus 5y ago
    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).
    - cutler 5y ago
      Depends what you're comparing. Barebones Node with few dependencies is more like a Rack application. Rails is the other end of the spectrum.
  - jakelazaroff 5y ago
    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.
tqkxzugoaupvwqr 5y ago
> 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.
- gboss 5y ago
  Why not just use fixed versions and upgrade when you have a reason to?
  - WJW 5y ago
    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.
    - ljm 5y ago
      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?
      - AlchemistCamp 5y ago
        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.
CapriciousCptl 5y ago
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.
- andruby 5y ago
  Phoenix was using brunch until it switched to webpack in 1.4.0 (2018-11-07)
sergiotapia 5y ago
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-tailwind-jit-alpinejs-a-brief-tutorial 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!
- scns 5y ago
  Thank you very much for the blog post, it will save a lot of time and hair.
  - sergiotapia 5y ago
    It’s something I wish I had handy a week ago. Hope it helps!
fouc 5y ago
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.
xdennis 5y ago
> 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.
- joelbluminator 5y ago
  Looks like Rails wants off Webpacker as well https://github.com/rails/importmap-rails https://github.com/rails/importmap-rails
  - ghiculescu 5y ago
    Yes, Rails 7 will not use webpack (or almost any other “modern JS”) by default. https://github.com/rails/rails/pull/42999 https://github.com/rails/rails/pull/42999 is the big change.
- sedeki 5y ago
  This is too broad to be true in general. It depends on what Y is...
- seanclayton 5y ago
  Phoenix is the maintainer of the Elixir esbuild package--it's just a binary.
norman784 5y ago
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.
- IggleSniggle 5y ago
  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.
- dstaley 5y ago
  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 https://swc.rs/docs/spack-basic/#mode
mberning 5y ago
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.
- blacktriangle 5y ago
  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.
  - mberning 5y ago
    That’s a good point. If it were possible to successfully “railsify” the front end that would be amazing.
AlchemistCamp 5y ago
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-in-my-phoenix-apps/ 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.
stanislavb 5y ago
For the record, next Rails version (v7) is on the path of ditching webpack, too.
- appaone 5y ago
  What? It was just integrated as default. Do you have a source/link for more information?
  - stanislavb 5y ago
    yup, https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 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."

masa331 5y ago

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

ch4s3 5y ago
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).
Madeindjs 5y ago
It works until you try using a library not available with Sprocket...
- sleepyhead 5y ago
  How can it not be available with Sprockets? You can just add .js files.

buf 5y ago

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.

edoceo 5y ago
Can you show it?
- buf 5y ago
  Closingcredits.com

airblade 5y ago

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

gosukiwi 5y ago
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.
e12e 5y ago
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).

sergiomattei 5y ago

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.

Lapz 5y ago

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

toberoni 5y ago
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!
- christophilus 5y ago
  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).
  - cutler 5y ago
    Depends what you're comparing. Barebones Node with few dependencies is more like a Rack application. Rails is the other end of the spectrum.
- jakelazaroff 5y ago
  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.

tqkxzugoaupvwqr 5y ago

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

gboss 5y ago
Why not just use fixed versions and upgrade when you have a reason to?
- WJW 5y ago
  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.
  - ljm 5y ago
    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?
    - AlchemistCamp 5y ago
      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.

CapriciousCptl 5y ago

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.

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

sergiotapia 5y ago

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-tailwind-jit-alpinejs-a-brief-tutorial 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!

scns 5y ago
Thank you very much for the blog post, it will save a lot of time and hair.
- sergiotapia 5y ago
  It’s something I wish I had handy a week ago. Hope it helps!

fouc 5y ago

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.

xdennis 5y ago

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

joelbluminator 5y ago
Looks like Rails wants off Webpacker as well https://github.com/rails/importmap-rails https://github.com/rails/importmap-rails
- ghiculescu 5y ago
  Yes, Rails 7 will not use webpack (or almost any other “modern JS”) by default. https://github.com/rails/rails/pull/42999 https://github.com/rails/rails/pull/42999 is the big change.
sedeki 5y ago
This is too broad to be true in general. It depends on what Y is...
seanclayton 5y ago
Phoenix is the maintainer of the Elixir esbuild package--it's just a binary.

norman784 5y ago

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.

IggleSniggle 5y ago
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.
dstaley 5y ago
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 https://swc.rs/docs/spack-basic/#mode

mberning 5y ago

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.

blacktriangle 5y ago
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.
- mberning 5y ago
  That’s a good point. If it were possible to successfully “railsify” the front end that would be amazing.

AlchemistCamp 5y ago

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-in-my-phoenix-apps/ 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.

stanislavb 5y ago

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

appaone 5y ago
What? It was just integrated as default. Do you have a source/link for more information?
- stanislavb 5y ago
  yup, https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 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."