If you’ve been paying attention to the larger development ecosystem, Javascript is the rage. For example, ”GitHub is home to open source projects written in 337 unique programming languages—but especially JavaScript.“ There are many Javascript frontends available, and even the backends are written in Javascript. But if you love Ruby like I do, using more Javascript always causes a feeling of remorse or regression from the joy of Ruby on Rails. The syntax idiosyncrasies cause concern about bugs and using lots of different Javascript files, even with Sprockets to manage them, was tricky. Webpack is an attempt to smooth over the problems, and Webpacker makes it work in Rails.
Why even consider Javascript then?
The amount of tooling available to use Javascript in a website is astounding. For example, there is a tool called Babel that will convert your cutting edge ECMAScript into plain old Javascript that 99% of browsers can run. And writing in cutting edge ECMAscript is actually a joy. Your == does what you expect, you don’t need to un-inspiringly insert semi colons everywhere, and objects are really respected. But look at the setup page for Babel: https://babeljs.io/docs/setup/. There are lots of options, from frameworks that you can use, to different build systems. Webpacker is an attempt conventionalize a particular way of using Javascript in your app, especially if Sprockets isn’t good enough. Once you begin writing more Javascript, you realize there are some lovely Javascript libraries, just like all the great gems in Ruby.
If you like Bundler, you’ll like Yarn’s integration into Webpacker
Just like how bundler manages all those Ruby dependencies relatively easily, webpacker uses one of Javascript’s package managers, Yarn, to abstract away Javascript dependency management. Even though there are over 700 dependencies downloaded, they will only cached for future performance, and you don’t have to worry about what each one does. When you’re ready to deploy, webpacker packs all those Javascript libraries, including CSS and image assets, into Sprocket’s like Javascript, CSS, image files.
A Slow Slog to Setup
Since these are relatively new systems, there are certainly going to be small issues for certain setups, especially if you’re migrating an existing project. I’d recommend starting with a new project just to test setting everything up from scratch. I learned a lot reading the first chapter of Rails, Angular, Postgres, and Boostrap, which covered setting everything up in a new project. Then once you’ve succeeded with a small, isolated project, you can try it on your current project.
Since it’s a new technology stack, expect some form of a learning cureve. For example, I spent half an hour debugging why some CSS stylesheet appeared in the my pack in the browser, but didn’t have any CSS in it. I finally realized that I was missing the stylesheet_pack_tag in the application.html.erb, and when I put that line of code in, everything worked well.
I’d recommend Webpack for your Rails app
Think of setting up webpack like an investment in being able to use modern web technologies. Unlike the revolving doors of a new Javascript build tool of the week, it’s built into the Rails stack, with reasonable defaults, and the ability to configure everything, if need it.
Then try out it out with one of my Stimulus.js Tutorials that I’ve been publishing. I think you’ll begin to see the full potential of Webpack inside your Rails app, despite the occasionally obtuse setup.
Feel free to leave comments or questions below.
Want To Learn More?
Try out some more of my Stimulus.js Tutorials.