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

@afilina yep, it's not fast by default. There are ways to improve that though.

Things to check for:
- verify it's only installing prod dependencies and no dev dependencies
- use a lockfile and have a cache that will restore deps if the lockfile hasn't changed instead of downloading again

Hope that helps πŸ‘

@nicoespeon Do people normally build push containers *with* the giant deps folder, or do they push containers that then install deps on premise? I'm asking because after it took a long time to pull deps, it took additional time to push container and pull it on the other side. It felt like too many transfers for such a big deps folder.

@afilina in general the code is pushed on the container *without* the deps folder. Then it install deps (or fetch from some cache).

Typically, node_modules/ isn't versioned with the code

@nicoespeon This is not about pushing code. This is about pushing docker containers as a deployment mechanism.

@afilina oh sorry, I misunderstood your point.

I'm not 100% sure as I haven't done that recently. But here is a recent post from a relevant actor (Snyk) that details best practices for deploying Node.js apps with Docker: https://snyk.io/blog/10-best-practices-to-containerize-nodejs-web-applications-with-docker/

Maybe that will help!

10 best practices to containerize Node.js web applications with Docker | Snyk Blog | Snyk

Are you looking for best practices on how to build Node.js Docker images for your web applications? Then you’ve come to the right place!

Snyk

@afilina already built or including transpires/npm install? Apparently npm 9, which just came out, is a bit better in this regard. And npm ci helps.

But ya, without a bag of tricks JS deploys kinda slowly

@ian It does npm install while building locally.

@afilina hmm, via npx or something else? Running install rather than npm ci seems odd.

Lmk if you aren't familiar with npm ci +'s/-'s; it may be applicable here.

Also, server side or client side, and is this from scratch or incremental? Incremental stuff has gotten reasonably fast but from-scratch builds...aren't.

@ian I have no idea about anything you just said. I inherited a project and stuff is going on there that is longer than I'd like, but I'm not planning any overhaul. I last touched frontend in any noteworthy way in 2015.
@afilina I feel the same. Even Maven has given me a much better time
@afilina that’s what happens when you move much of the web app from the server to the client :)
@afilina Build time of one of our JS apps is currently at 13 minutes(!). It's a fucking nightmare. No one on the team really knows why because it's a big mess of webpack configuration hidden and obfuscated by vendor dependencies.
@weph Gotta love magic. It's fun while it works, but when it fails, you have to become an expert in things you didn't sign up for :)
@afilina Worst part is that the app is too big to migrate to something supposedly fast like Vite (or whatever is hip for the next 6 months), because some parts were built on stuff that was hip 12 months ago, but was abandoned 6 months later, and now needs to be replaced with a new hip thing. Most of the time I have nothing but contempt for the JS world.
@afilina oh, it's global like that. Any JS project takes SO MUCH MORE time than other languages deploys. I thought I was the only one seeing it, as I hate JS to the core, but glad to know I am not alone to see it.
@sekhmetdesign That made my impostor syndrome a but better, thanks!
@afilina only 120? That's pretty good!

@afilina Depends on what you do on deploy. We are generally building the production assets in development and commit them. Thus, there are usually no npm packages needed on production, no build steps and deployment is just instant.

And since using vite, building only takes a couple of seconds.