Deploying a PHP application: 10 seconds.
Deploying a JS application: 120 seconds.
Do people who have experience with modern JS notice a similar trend, or is it only my project?
Maybe it's all the npm stuff. I know composer is significantly faster when it comes to package managers.
@afilina Working with both, and I absolutely feel you. Can confirm that package management in JS feels clumsy at best. It is not only the time it takes, also how it handles conflicts (basically it does not) and that installing packages does not even seem to be deterministic.

@afilina I realize this is probably not helping with your question but I wonder anyway: WHY do you *deploy* using composer or npm?

Shouldn't that be used for, well, managing dependencies? So by the time you want to deploy the stuff it's either already there or only copied based on an already resolved set of dependencies from local cache and then turned into a build artifact?

What am I missing? Is that just nitpicking on choice of words?

@theseer Oh no, I'm not deploying with the package manager. It seems that the deploy script builds a docker container locally, which in turn pulls deps and builds JS stuff, to then push the container to the repo. I usually get things of that sort running on CI, but I don't do much hands-on Docker or JS configurations.

@afilina That makes a lot more sense than what I originally understood :)

Sorry, can't be of much help with npm I'm afraid. Not sure if it's an option for you, but maybe using Yarn instead of NPM speeds things up for you? As far as I remember you could even fail the build if an install would alter the locked state with yarn..

@theseer @afilina Modern versions of npm basically fix the issues that yarn was trying to correct, including both performance and state.

It can still be far slower than composer; I know that installing deps for my CSS toolchain takes something like 2x or 3x the time of installing my PHP app deps. From what I can tell, it's a combination of the sheer NUMBER of deps getting installed, and the crazy dep graph it builds (as it nests). 😐

@mwop @theseer I think I'll use npm as an example of why an unnecessarily large number of microservices is a bad idea.

@mwop @afilina Speaking of CSS: It's crazy how things can turn bigger for no aparent reason.

For instance, I use sass for my CSS stuff, and I used to rely on their C implementation (sassc + libsass) which, after compilation, is a 24k (!!) binary and a ~2MB libsass.so.

Sadly, it got deprecated.

The NPM install is roughly doubled in size: ~6MB.

The recommended standalone installation - a single binary including the dart vm - already eats ~9 MB. But at least it's a single file and no deps.

@mwop @theseer @afilina
PNPM (performant NPM πŸ€ͺ) just might give composer a run for its money.
@afilina I ditched npm and am using yarn on almost every js project. It is significantly faster!

@phaberest Ah yes, I had that suggestion from other folks. Sounds like something to try.

Love the username by the way. I had this gem on a website just yesterday:

@afilina yeah, it makes quite a difference! I had to keep npm only on a few projects that have a complex webpack configuration and only work with npm for some unknown reasons

haha, [object Object] in prod means they really enjoyed testing that login πŸ˜…

@afilina I agree with other replies, it's the huge number of dependencies, but it's also the fact that you need a build step to combine and minifiy them.

With PHP, it's as easy as copy-pasting them.
Well, there are some exceptions with stuff like Symfony, that requires cache warmup, but it's still faster by a long shot.

And this is one of the reasons why I think that PHP is fantastic in a containerized world, the other being the low resources needed, that makes horizontal scaling sooooo easy