I don't think an scp ever went wrong for me. But maybe your lan network is different.
> 2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.
Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.
> 3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.
I don't know your specifics, but recovering from a disaster in this case is getting up an other server (or serverS) and copy the files over.
> 4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source.
That's the nice thing about mod_pagespeed: you don't compile anything.
> 5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway.
What's wrong with scripting everything? I like automation.
When I started doing web things rcp (or scp, or rsync, etc) access was quite unusual. You had FTP and that was it. It failed a lot.
Does webpack handle db migrations too? I didn't know. I was talking about js/html/css assets. Not the backend.
Fair enough. I don't really see the front end asset pipeline as being separate to the backend. It's all just stuff you build and deploy.
That's the nice thing about mod_pagespeed: you don't compile anything.
Well, you do, but you're happy just accepting the mod_pagespeed defaults are doing a great job (which they are). I want a bit more control over things, and I want to do things that mod_pagespeed can't do, which is why I use Webpack instead. A trivial example: mod_pagespeed doesn't do subresource integrity hashes. Webpack has webpack-subresource-integrity as a plugin that can automatically write hashes to your html. That's useful to me. It's good that there are different options for different things, and better that the industry is coalescing around small number of different tools so there aren't too many different ways of doing things.
What's wrong with scripting everything? I like automation.
Nothing at all. Automate all the things! My point is that back in the olden days of making web things we didn't automate things, so it was much, much harder. Today's tools (eg things like Webpack) make automating your build process pretty trivial. It's far better now.
And sure, staging then copying everything would be faster and safer than deploying straight on top of the old version, but that's still a not-insignificant amount of time when the app is in a transient, partially-upgraded state. And that would only get worse as your app grew.
I suppose to way around that would be to deploy twice and use a load balancer that you could temporarily disable, upgrade one deployment, point the load balancer only to there, upgrade the other one, then re-enable load balancing between them.
Man, that's a lot of work, though.
I'll agree that maybe it's a relatively minor complaint, because there are likely plenty of solutions I just never needed to find, but I really do like avoiding anything that can and should be avoided. I'd rather have a "Please wait while we upgrade" page than risking something going south due to some kind of race condition.
FTP did fail a lot indeed. That is why scene (FTP / FXP) used .rar, .sfv and Usenet .rar, .par(2). Download clients had resuming support but did not attempt verification. That's why checking checksum is important (Sfv is just CRC32 and Par is Reed Solomon, other examples are MD5 and SHA1).
Later on scene used so-called auto traders, which utilized FXP and automatically verifying checksums plus anticipating on errors (such as dupes). The I know was called Preee (Windows only, worked in Wine). Later protocols like BitTorrent implemented checksum verification within the protocol.
I do remember. I've been doing web stuff for a little over 20 years. It was not a good time.
1. If a file upload failed your site was broken until you managed to upload it again.
2. Deploying something that required a database migration had to be done out of hours, or the site had to be taken offline to do it.
3. Recovering from a disaster was hard, and pretty much always resulted in significant data loss.
4. Moving a site from one server to another was awful, because it meant SSH'ing (or telnet'ing...) on to the box and compiling things from source. If you got anything in the environment wrong the site didn't work and you had to start again.
5. If you worked on anything that ran on multiple servers you pretty much had to script it all anyway. Essentially there were thousands of different (much worse) build-and-deploy processes people had stuck together with various different tools. Going to a new company meant learning a completely new set of processes. Today's processes are just an industry-standard best-in-class approach to doing the same thing.
I'll take Webpack to compile a site and terraform/compose/puppet to deploy the infrastructure over old way of doing things every time.