7 ms·

Do you remember the time when you just copied your file over to the server, and magically everything was deployed? I do. It was a good time. Yes, I am old. In

Do you remember the time when you just copied your file over to the server, and magically everything was deployed? I do. It was a good time. Yes, I am old. 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/ https://www.modpagespeed.com/

romanovcode 9y ago
I think Webpack is actually slowly moving into that direction. 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..
onion2k 9y ago
I do. It was a good time. Yes, I am old. 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.
- y0ghur7_xxx 9y ago
  > 1. If a file upload failed your site was broken until you managed to upload it again. 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.
  - onion2k 9y ago
    I don't think an scp ever went wrong for me. But maybe your lan network is different. 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.
HyperMassive 9y ago
> Do you remember the time when you just copied your file over to the server, and magically everything was deployed? I do. It was a good time. Yes, I am old. 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.
fenomas 9y ago
> it minifies your javascript and html, optimizes images, and more or less does what webpack does (minus the typescript -> js compilation). 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?
moogly 9y ago
Did you also have to tell your users to press Ctrl+F5 to get the updated assets?
- linkmotif 9y ago
  What is there a better way??!
  - staz 9y ago
    Assuming your are not just joking, the keyword to look for is "cache busting"
    - linkmotif 9y ago
      Hehe I was joking. Really enjoying the cache busting functionality in webpack :)
- y0ghur7_xxx 9y ago
  > Did you also have to tell your users to press Ctrl+F5 to get the updated assets? 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);´
deleted 9y ago
[deleted]
Cthulhu_ 9y ago
I do, then I worked on single page apps with dozens if not hundreds of screens, dozens of developers, and tens of thousands of lines of code; modern Javascript standards and new transpile-to-javascript languages that all had to work down to IE 9; front-end application frameworks and 3rd party libraries that helped us to structure the application and not reinvent the wheel without having to manually sift through all files at every release (thrice or more a day) to filter out what we needed. 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.
ggregoire 9y ago
> mod_pagespeed does more or less what webpack does 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.
- RobertRoberts 9y ago
  I don't use Webpack but have looked into it, please explain (google lazy) how Webpack implements "lazy loading"? 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...
  - ggregoire 9y ago
    You need to use dynamic imports var myComponent = import('./myComponent') instead of classic imports import myComponent from './myComponent' Then Webpack automatically generates separate js files and these files are loaded by the browser only when the dynamic imports are called. Reference: https://webpack.js.org/guides/lazy-loading https://webpack.js.org/guides/lazy-loading
    - RobertRoberts 9y ago
      Ok, so it doesn't lazy load CSS and images, just js? 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?
      - 9y ago
megous 9y ago
I'm still doing it that way for a big 150kloc SPA. It's the way ExtJS3 apps were put together and it works fine. Everything is neatly namespaced in a global namespace and always accessible. At some point we even stopped minifying JS code, because it's gzipped/cached most of the time anyway. 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.
- joshribakoff 9y ago
  You're missing out on lots of features like easily managing many entry points, live reload / hot reload, code splitting, async chunk loading, tree shaking, proper namespacing, transpilers so you can write ES8 but support IE, and tons of other great features.
  - megous 9y ago
    I only miss not being able to use some ES6 features, because of IE11 requirement. We can use closure compiler to get ES6 syntax support at this point, because browsers usable for development support ES6+, so it wouldn't need to be run during development, only for deploy. Webpack is not necessary for that 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.
h1d 9y ago
Yes, current build process complication makes me laugh how it's actually making the development harder. With that said I've come to a pretty decent setup that's pretty much upload and reload style. - 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.

romanovcode 9y ago

I think Webpack is actually slowly moving into that direction. 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..

onion2k 9y ago

I do. It was a good time. Yes, I am old. 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.

y0ghur7_xxx 9y ago
> 1. If a file upload failed your site was broken until you managed to upload it again. 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.
- onion2k 9y ago
  I don't think an scp ever went wrong for me. But maybe your lan network is different. 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.

HyperMassive 9y ago

> Do you remember the time when you just copied your file over to the server, and magically everything was deployed? I do. It was a good time. Yes, I am old. 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.

fenomas 9y ago

> it minifies your javascript and html, optimizes images, and more or less does what webpack does (minus the typescript -> js compilation). 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?

moogly 9y ago

Did you also have to tell your users to press Ctrl+F5 to get the updated assets?

linkmotif 9y ago
What is there a better way??!
- staz 9y ago
  Assuming your are not just joking, the keyword to look for is "cache busting"
  - linkmotif 9y ago
    Hehe I was joking. Really enjoying the cache busting functionality in webpack :)
y0ghur7_xxx 9y ago
> Did you also have to tell your users to press Ctrl+F5 to get the updated assets? 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);´

deleted 9y ago

[deleted]

Cthulhu_ 9y ago

I do, then I worked on single page apps with dozens if not hundreds of screens, dozens of developers, and tens of thousands of lines of code; modern Javascript standards and new transpile-to-javascript languages that all had to work down to IE 9; front-end application frameworks and 3rd party libraries that helped us to structure the application and not reinvent the wheel without having to manually sift through all files at every release (thrice or more a day) to filter out what we needed. 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.

ggregoire 9y ago

> mod_pagespeed does more or less what webpack does 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.

RobertRoberts 9y ago
I don't use Webpack but have looked into it, please explain (google lazy) how Webpack implements "lazy loading"? 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...
- ggregoire 9y ago
  You need to use dynamic imports var myComponent = import('./myComponent') instead of classic imports import myComponent from './myComponent' Then Webpack automatically generates separate js files and these files are loaded by the browser only when the dynamic imports are called. Reference: https://webpack.js.org/guides/lazy-loading https://webpack.js.org/guides/lazy-loading
  - RobertRoberts 9y ago
    Ok, so it doesn't lazy load CSS and images, just js? 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?
    - 9y ago

megous 9y ago

I'm still doing it that way for a big 150kloc SPA. It's the way ExtJS3 apps were put together and it works fine. Everything is neatly namespaced in a global namespace and always accessible. At some point we even stopped minifying JS code, because it's gzipped/cached most of the time anyway. 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.

joshribakoff 9y ago
You're missing out on lots of features like easily managing many entry points, live reload / hot reload, code splitting, async chunk loading, tree shaking, proper namespacing, transpilers so you can write ES8 but support IE, and tons of other great features.
- megous 9y ago
  I only miss not being able to use some ES6 features, because of IE11 requirement. We can use closure compiler to get ES6 syntax support at this point, because browsers usable for development support ES6+, so it wouldn't need to be run during development, only for deploy. Webpack is not necessary for that 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.

h1d 9y ago

Yes, current build process complication makes me laugh how it's actually making the development harder. With that said I've come to a pretty decent setup that's pretty much upload and reload style. - 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.