The Phoenix philosophy for asset management is, just use npm/node - we have brunch as a default but it is easily replaceable by whatever. So I also think it’s not going to come.
I like this very much. We don’t have to reinvent the wheel every time around and cook something new up. Most node/npm tooling is far more advanced than in other language which is also why people on frameworks with asset management (like rails) constantly look for ways to integrate, for instance, webpack with it - which is a pain (or at least it was for both Rails and JS experts at my former company).
I love the flexibility and pragmatism of Phoenix here.
Thing is, I never used anything beyond Sprockets – and I absolutely hate that software piece. Plus I always stayed away from the hardcore frontend development.
I didn’t realize the Node variant was that good as people claim. Although to be fair, Node by itself is pretty bad but that’s another discussion entirely. It doesn’t help my negative bias against anything in Node though, that’s a sad fact.
What exact combo of software pieces from the Node land must be assembled to have a full-blown asset management?
Not sure what exactly you mean, but you gotta have node and npm (package manager) installed. By default phoenix comes with brunch which is a somewhat not so popular choice but was chosen by the time for its ease of use. The most popular/hyped for quite some time one as far as I’m aware of is webpack. If you google webpack phoenix you’ll find a wealth of blog posts and other how tos.
In general, as far as I’m aware you’ve gotta (of course) install some other packages for, you know get babel running or sass or whatever - as plugins for webpack. That can sometimes be a bit fiddly as far as I know but I haven’t had the pleasure yet of going through this myself
Well, we’re devs. We have to fiddle with stuff. As long as it’s only once per machine, it’s fine. As I already stated, I am usually staying away from the frontend stack but if I can nail it once and for all + use Phoenix, it’ll be worth the pain.
While I completely sympathize with your position - be careful what you wish for. “but there needs to be only one thing chosen” has driven a lot of people and organizations to simply restrict themselves to a single corporation’s (like Microsoft) offerings and we all know that doesn’t lead to “best of breed tools” either. Open Source Software tends towards a proliferation of alternatives.
I’ve observed this first with Java Web frameworks and which one did I ultimately use? The lowest common denominator: Servlet/JSP - while not getting any of the benefits of the more sophisticated alternatives it didn’t place any constraints on what I could do - i.e. it didn’t lock me into anything. Now obviously the lowest common denominator isn’t always the best choice.
That being said I think that an environment which fosters “does only one thing but it does it well” contributions would be ideal - basically an build/asset management tool that follows the PostCSS model - some of the more commonly needed services are provided to plugins but the plugins do most of the dirty work.
The other issue is that people will often gravitate towards the solution that looks like its the fastest/easiest to learn/adopt, not because it best serves their needs.
Bower needs to die! Like now. It is not only wasted but it is entirely harmful by splitting the ecosystem across two nearly identical package managers since NPM hit 3.0. It has fewer packages, most things are only on npm, very few things are only on bower (hence why I need both, GAH!), and there is no point to it since NPM hit 3.0
webpack/gulp/brunch need to merge, they all do the same thing, quit copying each other!
As much as I would love to, Brunch has some major design faults that I’ve run across having made 3 brunch plugins for phoenix. Let me list just a few that come immediately to mind:
There is no way to cancel a file output, say you have a pass that holds metadata or whatever (or something like elm that transpiles to js but outputs its own files), you cannot tell brunch to just ‘not output this js model’, no instead you get your output file polluted with tons of crap like this (copy-pasted):
No way to output multiple files in a pass, say you have an input file that generates both a js file and a template, you can either return to Brunch the JS file, or you can return it the template, you have to write the other file to disk manually, where brunch will then later notice it and then parse it in as normal.
There is no way to redirect it to pull a file from an external compiler, instead you have to run the external compiler, have it output to a temp directory somewhere, wait for it to finish (and on windows wait for the file to sync to disc, do it too soon and you crash!), then read it back and give it back to brunch.
There is no way to handle multiple files in a single pass, say for something that handles all files of a given type (say, Elm), so the compiler gets called for every-single-file even though the compiler invocation compiles all files, so you end up calling the compiler for all files, which compiles everything n*n times, so you instead have to do your own synchronization to be careful to only call it once (which it does), however if a file updates during that time and it tells you about it while another compiling is already happening then you miss it and have to wait for the compile to finish just to save your file again so brunch calls it again.
And there are others upon others. It is a design fault in brunch. Honestly Phoenix needs to change to one of the others, sadly I’ve no clue which would really be best… Gulp seems to be the one most capable of working with everything so maybe it, but I’m unsure…
gulp is… okay. It’s the successor of grunt in many ways, my last prolonged exposure to it is 1.5 years ago - and basically the same feeling I get with webpack: people I respect very much spent way too much time (imo) fiddling with it to make it work in a not super special context (CoffeeScript, React, Sass, autoprefixer) but in the end it all worked fine
I’d be curious of everyones experiences with all the various things. The popular ones are (in no specific order):
And a few other minor ones that I barely hear about. I’m especially curious in:
Which are capable of watching files and reloading dynamically
Which are fully asynchronous and which are serialized, and if asynchronous how they handle things that need to be serialized.
Overall raw speed.
I’m curious because honestly Brunch is so restricted (and unused out in the ‘wild’) that I’m thinking it should be replaced as the default handler in Phoenix, or at least for an alternate to be supplied via a new template.
Because, let’s be honest, if we are targeting advanced JS users, there is no single choice that will make the majority of them happy.
I believe both Chris and I are open to change Phoenix to something given it is stable, we can interact with it through a single configuration file (at least initially), it is fast and it supports fs watching.
webpack hit 2.0 and it seems the most popular choice, although that might be my bubble. Personally I think that this is nothing that NEEDS to change much less NOW - I think this might be something worth revisiting in ~a year and see what’s going on in JS land then and if it’s stable. Maybe with a Phoenix 2.0 some day