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.
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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.
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.