Possible reversion back to pure Ruby processing in frontend bundling #170
jaredcwhite
started this conversation in
General
Replies: 1 comment
-
Just pushed a PR up to Render hosting platform with the new custom plugin…previously esbuild was taking 23 seconds to build before, now it's down to 12! Wow |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey @rubys,
As awesome a feat as it was to compile Ruby2JS's Ruby code with Opal so it could be used in a pure-Node environment, I've found several challenges working within that setup… A few months ago I had to pin to an older Opal version because new ones totally broke my builds, and I suspect that may still be an issue. Another issue is the Ruby syntax is mismatched between the environments: I can use Ruby 3.1 hash shorthand in my Ruby code but not in my Ruby2JS code. Maybe successfully upgrading Opal would help with that, but there could be other similar lag periods down the road.
I also recently switched a large Rails project with quite a robust set of .js.rb files to esbuild, and was a little surprised the bundling build speeds weren't great…almost 8 seconds total (that's also including Sass styles and a few other JS files). On a whim, I decided to write a replacement esbuild plugin which spawns a Ruby process (similar to my original Webpack plugin back in the day) to compile each file. This happens in parallel for each file so a lot of Ruby processes can happen at once.
I was shocked to find the build speed improved to under 4 seconds! It was an almost 2x improvement.
So I'm inclined to switch the esbuild plugin's default processing mode to use Ruby spawns. Maybe keep the Opal/JS method around as an option, or a separate package. Not sure. Before I plow ahead with this I wanted to get your take on the matter. TIA!
Beta Was this translation helpful? Give feedback.
All reactions