[LRUG] resolving JS dependencies on deploy
Mark Burns
markthedeveloper at gmail.com
Thu Nov 19 09:35:19 PST 2015
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/20151119/221528b4/attachment-0002.html>
More information about the Chat
mailing list