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.
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.
The main point of webpack isn't minification and so on, it's wrangling dependencies. It lets you define a JS module, which can declare dependencies on other modules or assets, and so on recursively, and webpack parses everything out and bundles the necessary pieces together such that they can all see each other.
If your JS isn't in modules, but just files that can be uploaded and minimized, why were you using webpack in the first place?
Uploading some files is fine for simple websites with no availability guarantees or security requirements. Mod_pagespeed is fine for most websites too, I should install it for my wordpress instance sometime. It's not effective for single page apps though.
- parcel bundler (Real fast, cached compilation is under 1 second) : This bundles all my TypeScript as 1 JS that works in the browser and Stylus into 1 CSS along with dependencies such as jQuery and I no longer have to place script tag for those external dependencies but they're bundled among their dependencies from npm installed copies.
- ts-node-dev : Reloads the node server automatically in about a second as I update my server side TypeScript and it doesn't even require compilation process to spit out .js files.
- monit : To monitor those 2 processes to make sure they're alive and auto restarted in case the process quits for some reason.
The point is, setting them up is very easy. I don't even have a config file for the former 2 and easy readable one for monit.
I don't like client side transpilation and bundling as it requires every machine even under different OS to be set up properly exactly the same.
Now I no longer do any manual build or wait on each incremental changes but the "good old days" are back with the added benefit of using TypeScript and npm ecosystem in the browser with no effort. I'm impressed.
Yep.
That in sense is webpack's job: It allows you to boil down a huge list of interconnected complex dependencies into a neat, portable, highly deployable package.
Build tool - with this way of organizing things - can be `cat`, simple 20 line php script to bundle icons together with `montage` that comes with imagemagick and direct invocation of `sassc`. Build times are 100ms. Simplicity is priceless. There's never any migration, no new features, no deprecations, no maintenance issues, no instability, because everything is so stupidly basic. You can jump 10 years forward, and app will still be buildable from git with only tools available in your OS distro.
It's written in ES5 though.
Live reload with ExtJS app would be a nightmare even with webpack. On-demand code loading optimizations are not necessary. Tree shaking would not help much at this point, because I've removed unused components manually. Proper namespacing (if you mean ES6 imports) would not help much. The app is self-contained and uses only a few external dependencies.
Not really.
Just copy/pasting the menu from their website:
- Asset Management
- Output Management
- Hot Module Replacement
- Tree Shaking
- Development
- Production
- Code Splitting
- Lazy Loading
- Caching
- Authoring Libraries
- Shimming
- TypeScript
- Progressive Web Application
- Migrating Versions
- Environment Variables
- Build Performance
- Development - Vagrant
- Dependency Management
- Public Path
- Integrations
The V4 will add features like WebAssembly support.
My thought is that I would have to do specific work that I can't imagine Webpack could "guess" would work for me in every circumstance...
var myComponent = import('./myComponent')
import myComponent from './myComponent'
Reference: https://webpack.js.org/guides/lazy-loading
If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready? I looked at their page, and it doesn't seem to answer questions like this simply. It just says when a user requires the code it loads it.... huh?
How much code are people putting into their apps that this would ever be needed? (serious question)
When I do site analyzing, 99/100 the images/css are the biggest contributors to site size, have JS libraries gone nuts?
> If so, what does this improve? Time to first paint? Time to first interaction? Time to DOM ready?
Could be any or all of those, yes, depending on architecture. Webpack bundles CSS, images, etc into combined JS files ("chunks"), tries to get the important hot path stuff into the first chunk, and then load other chunks as needed. With dynamic loading you can further make sure that additional chunks load out of the hot path, after first paint/first interaction/DOM ready/whatever else.
So this static async bundle creation helps ensure that you are only shipping what you need on initial download.
To be redundant (for absolute clarity) you know how to use Webpack, you do use it, it offers value to you, but not for building websites? Can I assume it only has value (for you) with building complex webapps? (can I also assume this is for Node.js?)
https://electronjs.org/docs/tutorial/about
This says it's made with Node.js...
import('./myComponent').then(myComponent => /* ... */)
const myComponent = await import('./myComponent')
const dynamicComponent = await import(/* webpackChunkName: "components" */ `./components/${componentType}/index`)Actually I did!
What I do now is this: there is a websocket connection always open with the connected browsers, and when there are some assets that reallyreallyreally should be refreshed, I send a command though the websocket and the browser (after a few client side checks, like making sure the user is not in the middle of filling out a form) executes ´window.location.reload(true);´
For example, with version 4 there are opinionated defaults and for some cases all you need to do is `webpack`, you don't even have to have webpack configuration file if you stick to the defaults.
Now the other problem, however there are no defaults in web - one uses react with less, other angular with sass, etc..
In search for something that makes me work like the good old times, but with modern javascript solutions, I stumbled upon mod_pagespeed[1]: it minifies your javascript and html, optimizes images, and more or less does what webpack does (minus the typescript -> js compilation).
The good old times are back for me: deploying is now an scp away.
For important projects I copy the static assets to the server, let jenkins run integration tests on staging and if everything works as expected just copy it over to production. One less thing to worry about for me.
[1]https://www.modpagespeed.com/