Apologies that this doesn't really address the initial question. But here is a blog post which expresses the majority of what I wanted to say: <br><br><a href="https://www.reinteractive.net/posts/213-rails-with-webpack-why-and-how">https://www.reinteractive.net/posts/213-rails-with-webpack-why-and-how</a><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 20, 2015 at 2:35 AM Mark Burns <<a href="mailto:markthedeveloper@gmail.com">markthedeveloper@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In which case it absolutely makes sense to just find the thing that works. I wasn't advocating that you definitely should jump into bed with a new server-side platform, just questioning the assumption.<div><br><div>I've found there's a deal of time can be spent in fiddling with JS dependencies via individual gems, or third-parties like rails-assets, or curl and vendor/assets, plus the suite of problems you tend to find only seem to happen when deploying to production with the asset pipeline. </div><div>And that this tends to be comparable to the pain of getting your assets to work in what I will for now describe in a fluffy way as fantastic.</div><div><br></div><div>It also seems like there can be a knee jerk reaction to avoid node when we are ruby developers, so I think it's important to question this.</div><div>As for leaky abstractions, the whole packaging npm packages as ruby gems definitely feels leaky. </div><div><br></div><div>I probably won't get a chance tomorrow to formulate a proper comparison and try and remember the aha moments so I'll just say the following:</div><div><br></div><div>Gulp with webpack is (using personal anecdata), just faster than the asset pipeline for development and building. </div><div>It's also nicer to only require what is needed by the application.</div></div><div>And it's nice to not have magic things happen in comments and in some big global space for javascript, but to be able to write code that defines how your dependencies will work. </div><div>And the testing ecosystem feels more polished (compared to testing js inside rails apps).</div><div><br></div><div>And for more fluffy stuff:</div><div>JS has always felt like a second class citizen in Rails apps, when in a lot of applications it can be as important as the backend. Yet often less well tested, with lower code quality. <span style="line-height:1.5">Making the leap to treating the other language we all work with, as important as the server-side language feels right. I feel more comfortable doing all I need to do on the command line, and I get things like colors and progress bars during package installs. Stuff that just makes the experience feel nicer. And you don't have to read blog-posts about javascript and think about how you can map this to your Rails-world snippets of coffeescript here and there. And you can try things like ES6 features</span></div><div><br></div><div>But I do still use the asset pipeline when there isn't enough javascript to warrant the leap.</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 20, 2015 at 1:50 AM Tom Armitage <<a href="mailto:tom@infovore.org" target="_blank">tom@infovore.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>On Thu, Nov 19, 2015 at 4:13 PM, Mark Burns <span dir="ltr"><<a href="mailto:markthedeveloper@gmail.com" target="_blank">markthedeveloper@gmail.com</a>></span> wrote:<br></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> onerous npm-derived asset preprocessing<br><br>I'm curious about this statement.<br>Is it that you are loathe to have to put in the groundwork now for little benefit or that the asset pipeline is less onerous?<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Well, it’s that I have a working application that’s entirely fine, and which utilises the asset pipeline, and I am wary of the big leaky abstraction of “adding a completely different serverside platform” into the mix just to pull down an external dependency. I tend to think that “just install npm” is a significant dependency, not a trivial one. But it’s onerous because of the unnecessary change it introduces at this phase, and because of the scale of the dependency.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IMHO the tooling around the node ecosystem feels a lot more modern and suited to the task than the cludgy asset pipeline. <br>Things like webpack, ES6, requirejs etc are fantastic for modern js development.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Well, yes, although again, I’ve been getting on fine! There’s only one component of this application that resembles a single-page application; the rest is fairly straightforward transactional web pages. I’m well aware my front-end JS could probably be brought up to the mark in terms of trendiness - and I like the principle of ES6, if not the transpiler. I guess I’m being conservative in introducing new ideas to the project when most of it works fine as it is.</div><div><br></div><div>Hence trying to find a solution beyond “replace your entire front-end tooling!”</div></div>
</div></div>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" rel="noreferrer" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</blockquote></div></blockquote></div>