Originally published at rossta.net
Photo by Alice Donovan Rouse on Unsplash
I've been getting this question lately from Rails developers in some...
For further actions, you may consider blocking this person and/or reporting abuse
To anyone on the fence: Do not switch to webpacker. Its a magic abstraction and it will cause you a lot of problems. People who know webpack very well, suddenly have this wall of complexity in front of it, with a lot of weird errors, conventions, quirks and you have to learn all that to have basically nothing new. And its slower.
Im after a long battle to remove this thing in favor of pure webpack (after all, all it does is package assets) from our application and i (and everyone in the project) couldnt be happier. One docker image less, one complexity less, one thing to learn less, one thing that breaks and hogs resources less, one thing to remember to update less, one gem less (in reality, a lot less, because integration has also dependencies), couple configuration files less.
If you think your company needs webpacker on top of webpack that is already working, you must have too much time on your hands and its probably just because you are bored.
Couldn't agree more with this sentiment. Webpacker should never have been integrated into Rails, IMO. All it's really doing is increasing complexity, but not capability. There's also another complex DSL in the webpacker.yml file, loaders, environments, etc., which forces the user to not only know Webpack AND Webpacker, but how they interact with each other when things are breaking. The only real advantage I ever got out of it was to get some configuration into the frontend via an ERB file, but I'm happily doing that with a rake task that dumps a JSON config into the webapp's directory. I would recommend staying away from Webpacker at all costs.
I'm interested to hear more about your perspective. For context, I wrote this article with the following audience in mind: "Rails developers currently using the Rails asset pipeline to bundle assets with little or no prior experience with Webpack". I was in this camp up until about three years ago. WebpackER, as you suggest, is not perfect, but it provided the gateway I needed to get my hands dirty with Webpack, learn more about it, and get comfortable configuring and setting up—this is a big hurdle for many developers regarding Webpack.
From your comment, it sounds like you already have that experience with Webpack and don't need to be convinced of its benefits in relation to the Rails asset pipeline. For this use case, I can see how WebpackER might add some unnecessary abstraction. Still, I think many of the points in this article still hold, which, in truth, are more about Webpack's benefits than WebpackER itself.
That said, I'm familiar with other prominent projects that try to solve this problem, like create-react-app and the vue-cli. I'm curious if you have opinions about these approaches and whether they have similar problems or are more successful in providing an appropriate level of abstraction and utility.
Thanks!
Yeah, im a front-end dev using webpack since 1.0, so my view is different to solo rails devs that are treating frontend as bootstrap-alike thing.
Having said that, my recommendation was only to companies, who already use webpack with success, and considering adding webpacker. This was a nightmare excercise, a lot of time, sweat (ergo, money) wasted to just remove this complexity that turned out to slow down assets packaging and was obscuring other problems, that were visible (ergo, possible to fix) after removal.
For someone who just wants to START new rails app and has backend background, going webpacker is probably their best bet. Having said that, i think, if there is one tool from frontend toolbelt that is worth learning, that would be webpack. It truly can make or break your frontend performance. Ive seen both.
Also, webpack in 2020 (or rather, since version 3 or 4, which is couple years old) is very easy to start with, and there is plenty of boilerplates to just start with it without deep knowledge.
We're moving everything from Webpacker to vue-cli after a VERY short and very painful stint with it. It allows you to keep an entirely isolated webapp without depending on a library like Webpacker to knit the two together and handle the entire surface area of the abstraction. While we happen to host both in the same repo, you're not required to do so as you are with Webpacker, either. I also think that the modern advantages of the Rails asset pipeline are way overstated, given that tools like vue-cli have all the same capabilities out of the box and allow you to further separate your front- and backend concerns.
Have you tried Stimulus?
Looked briefly at it, supposedly it works well in combination with Turbolinks (the life cycle of StimulusJS is compatible with that of Turbolinks). It's even possible to use Stimulus and Turbolinks with other frameworks, e.g. Laravel.
However after having looked at a few tutorials I wonder how well it "scales" to more complex UIs, even for pretty simple UIs I had the impression that the amount of boilerplate was on the high side, it seemed to require a lot of code even compared to when I'd code the same thing with jQuery.
I could be wrong though because I haven't actually used it on a real project.
I have seen many users having issues with it and not being able to find solutions in the internet. The framework adoption is not so great, so it is hard to work with it (for now).
That is the problem, the community around it is small. I severely doubt if it solves that many problems which you can't just as easily solve with jQuery or vanilla JS.
My impression (when looking at the docs and examples) was that it was a bit heavy on boilerplate, and I'd even go as far as calling it "invasive", it permeates through both your HTML templates (via the data attributes) and obviously the "controllers".
And, I think it sort of breaks down when your use case requires you to create/append new DOM elements, because it relies heavily on server generated markup with "data" elements. I'm not saying that it wouldn't work with dynamically generated DOM elements but that doesn't seem a natural use case.
Look at this thread:
reddit.com/r/rails/comments/df01hd...
If you read through it it confirms some of my doubts. I wouldn't paint myself in a corner by tying my app to a somewhat obscure library like StimulusJS.
It is a nice concept but I think that for many use cases the risks and drawbacks exceed the advantages.
It’s worth mentioning I work on app that has scaled stimulus. And the community is growing larger and larger in my limited view.
I don’t think I can adequately convey my counterpoints without turning this in to an argument or writing a novel so I’ll just leave it at: it’s not for everyone or every product (which is true of everything) but truly shines when you are already leveraging turbolinks and even more in an app backed by Rails 🙂
Right, yes the combo with Turbolinks is its sweet spot I think ...
Do you think it works well when you need to dynamically generate/append DOM elements (as opposed to working with existing server side generated markup only)? For instance, in a heavily AJAX based UI where you need to add new elements to a list after an AJAX call (without a page re-render) ...
Not yet!
That's a really thorough and very neat and extensive overview! Bookmarked it.