Ahh, I have here my big Phoenix project at work currently running in dev mode, eating up a measly 143 megs while it is hosting a few dozen websocket connections and database work and such.
And side-by-side to it is node, eating a wtf 305megs just to compile assets…
Only thing higher than Phoenix’s node in memory right now is dwm.exe (because windows sucks) and chrome.exe (because I have OGodHowManyTabs open right now).
/me sighs
Still low, but just surprising it is that high compared to a full-out erlang server that is actually doing a lot of stuff is quite a bit smaller.
If only there were a way to toss out node for handling all the front-end assets. ^.^
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.
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.
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!
I’m not actually sure how serious I am but here it goes:
Identify the most annoying webpack/gulp/grunt dependencies you know of
Start a topic listing these “todo” items as ports to Brunch.
Whenever somebody proclaims they want to learn JavaScript/Phoenix point them to the topic for their “JavaScript” projects that they can also put on Github as part of their portfolio.
You get the drift … no, I don’t think it will work but you never know.
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 have it go over a single file multiple times for different passes, say so that you can extract javascript in one and a template in another.
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):
Gulp
Grunt
Webpack
JSPM
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 capable of processing arbitrary files via javascript and/or binary executables?
Which are fully asynchronous and which are serialized, and if asynchronous how they handle things that need to be serialized.
Overall raw speed.
Etc…
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.
We are not committed to brunch. The reason we chose brunch is because it is the tool that required the least amount of configuration and fiddling for someone who wants to write just enough javascript to complement their server side work.
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
not very helpful, I know.
