Dev Memory Usage

Phoenix doesn’t have asset management yet?

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.

As somebody who has been through Sprockets hell, I couldn’t agree more. Let node do its thing, and focus on what isn’t out there yet, like Phoenix did with PubSub

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.

Thank you for the references.

Very! Re-creating the javascript asset pipeline would be beyond painful and not work with everything very well. Using node is the right way, regardless of how heavy node is. ^.^

EDIT: My main complaint with the node stuff is the 50-thousand asset pipelines that do not interoperate (Brunch, Webpack, Gulp, Grunt, JSPM, Bower, NPM, etc… etc.. etc.) and where certain libraries will only work with certain things (I have 4 of the above things in my big project right now because of javascript ecosystem utter-stupidity). I do not care ‘what’ is chosen, but there needs to be only one thing chosen…

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.

True, but by ‘one thing’ I mean one style that everything can follow, I.E. a standard.

That is basically how they all work, but all the plugins work differently in each system, there is no sharing of code and there is a massive duplication of efforts.

Yeah… >.>

standards.png500×283 23.8 KB

not very helpful, I know.