[LRUG] resolving JS dependencies on deploy

[Mark Burns]

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:

https://www.reinteractive.net/posts/213-rails-with-webpack-why-and-how
On Fri, Nov 20, 2015 at 2:35 AM Mark Burns <markthedeveloper at gmail.com>
wrote:

> 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.
>
> 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.
> 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.
>
> 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.
> As for leaky abstractions, the whole packaging npm packages as ruby gems
> definitely feels leaky.
>
> 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:
>
> Gulp with webpack is (using personal anecdata), just faster than the asset
> pipeline for development and building.
> It's also nicer to only require what is needed by the application.
> 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.
> And the testing ecosystem feels more polished (compared to testing js
> inside rails apps).
>
> And for more fluffy stuff:
> 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. 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
>
> But I do still use the asset pipeline when there isn't enough javascript
> to warrant the leap.
>
> On Fri, Nov 20, 2015 at 1:50 AM Tom Armitage <tom at infovore.org> wrote:
>
>> On Thu, Nov 19, 2015 at 4:13 PM, Mark Burns <markthedeveloper at gmail.com>
>> wrote:
>>
>>> > onerous npm-derived asset preprocessing
>>>
>>> I'm curious about this statement.
>>> 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?
>>>
>>
>> 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.
>>
>>
>>> IMHO the tooling around the node ecosystem feels a lot more modern and
>>> suited to the task than the cludgy asset pipeline.
>>> Things like webpack, ES6, requirejs etc are fantastic for modern js
>>> development.
>>>
>>
>> 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.
>>
>> Hence trying to find a solution beyond “replace your entire front-end
>> tooling!”
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20151120/954434a9/attachment.html>