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