5 ms·

I hate webpack, it has been a hack from the start. I can't wait till HTTP2 is more widely supported. My latest projects use polymer and a custom built service

I hate webpack, it has been a hack from the start. I can't wait till HTTP2 is more widely supported. My latest projects use polymer and a custom built service (in go) to automatically parse entry points to my application and index the required files. When a HTTP2 connection is made -- and the browser supports push, I will automatically push all the required files. With browsers like chrome the results are near instant and I have full control over what gets pushed or not. Personally I think we need to stop hacking the web together and properly solve these problems. I think HTTP2 with push is a good step in that direction.

jaredklewis 9y ago
I don't see how HTTP2 can replace webkack. Even if websites stop making single file bundles of JS, I think we'll still need something to: - Transpile from latest ES standards, to browser supported code - Compile from non-JS languages like TypeScript, Flow, and so on - Do dead code elimination, minification, and tree shaking - Bundle code shared by other bundles - Optimize images And on and on... I think webpack is a mess, but I think it really is just a reflection of the complexity of the web platform.
- paulddraper 9y ago
  HTTP/2 can't. But it can't make builds less complex. You're not longer bundling every script, inlining every image, etc.
  - always_good 9y ago
    Still just a drop in the bucket of what Webpack can do, so the HTTP/2 post above shows a major misunderstanding of what people are using Webpack for, and probably what HTTP/2 actually is. I don't see how you can work on a modern JS application, understand HTTP/2, and think HTTP/2 replaces Webpack. Pick two...
    - mbrumlow 9y ago
      Yes, you don't agree with what I said so you attack the author and not the content. Webpack is used for a lot of things -- that it should not be used for. As I posted above many of the things it is used for should out of band of your blunder. HTTP2 removes the need for bundling by allowing a smart web server either learn, or be told what files will be required for rendering to be pushed on the first request from the client. This eliminates the multiple request / and connections required in HTTP1 -- even with 4 pipelines that can be a lot of round trip request. If your application was not smart enough to know what to push to the client HTTP2 can allow multiple request over the same connection again negating the need for bundling.
      - igravious 9y ago
        Oi. They were not attacking the author. Their conclusion is sound. Given that Webpack is a lot _more_ than just bundling files together (as has been pointed out twice now) it is incorrect to say that HTTP/2 is a replacement for Webpack. No amount of explaining how HTTP/2 works obviates that fact.
        JimDabell 9y ago
        They said they didn't understand Webpack/HTTP2 and misrepresented what they said. Looks like attacking the author to me. > it is incorrect to say that HTTP/2 is a replacement for Webpack. Take a look back over the thread. They didn't say that. They said it was a step in the right direction. Then somebody started putting words in their mouth.
      - thelarkinn 9y ago
        Hi @mbrumlow. Sean here from the webpack team. We did a lot of study and testing on HTTP/2 and we found that your claims are entirely incorrect. But don't take my word for it, see the stats! https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 HOWEVER! HTTP/2 and webpack become even more powerful when used together! This is something we are really excited to share and build on!
    - 9y ago
- mbrumlow 9y ago
  You are just highlighting more of the problem. The fact a blunder is responsible for doing all these things is just proof of more hacking. Most of the things you described live outside of webpack, and webpack is NOT required to use them.
  - jaredklewis 9y ago
    Sure, I don't disagree that webpack merely brings those features together into one place. But webpack was born because 80% of the time you make a webapp you don't want just minifcation, or just transpiling, or just cache busting file names, or just file event based recompiles, or just bundling, or just tree shaking, and on and on. Most of the time, you want all of that stuff. People got tired of maintaining their 1000 line npm/gulp/grunt task files, so a bunch of projects were launched with the goal of eliminating that glue code. Webpack is the most popular, but there are of others like Brunch or more recently, Parcel. I think webpack is a mess, but will probably end up being the mess we're stuck with for sometime, because while it is complicated, it does solve a lot of problems. I see a lot of parallel with the GNU make and autotools setups used to build most C projects. The layered way that autoconf, configure, and make build configuration to compile and install programs is pretty complex (to my eye). Sure, it could probably be simplified a bit, but cross compiling code that dynamically links to libraries and installing it on different operating systems is just a complex problem.
    - petepete 9y ago
      I use and am very happy with Brunch. Yes, Webpack might have more features but my Brunch config is like 25 lines and it just works. It took me fifteen minutes to set up having struggled with Webpack for a couple of days.
- vbezhenar 9y ago
  I think that it's possible to use reasonably latest JavaScript without all those eliminations/minifications/tree shakings/sharing, etc for many projects. But writing entire project in one JavaScript file or issuing dozens of HTTP 1 requests is a real deal breaker for a lot of projects. I know that for most of my projects build tool is only used because of modularization. Everything else is good to have but not required and not worth build complexity.

jaredklewis 9y ago

I don't see how HTTP2 can replace webkack. Even if websites stop making single file bundles of JS, I think we'll still need something to: - Transpile from latest ES standards, to browser supported code - Compile from non-JS languages like TypeScript, Flow, and so on - Do dead code elimination, minification, and tree shaking - Bundle code shared by other bundles - Optimize images And on and on... I think webpack is a mess, but I think it really is just a reflection of the complexity of the web platform.

paulddraper 9y ago
HTTP/2 can't. But it can't make builds less complex. You're not longer bundling every script, inlining every image, etc.
- always_good 9y ago
  Still just a drop in the bucket of what Webpack can do, so the HTTP/2 post above shows a major misunderstanding of what people are using Webpack for, and probably what HTTP/2 actually is. I don't see how you can work on a modern JS application, understand HTTP/2, and think HTTP/2 replaces Webpack. Pick two...
  - mbrumlow 9y ago
    Yes, you don't agree with what I said so you attack the author and not the content. Webpack is used for a lot of things -- that it should not be used for. As I posted above many of the things it is used for should out of band of your blunder. HTTP2 removes the need for bundling by allowing a smart web server either learn, or be told what files will be required for rendering to be pushed on the first request from the client. This eliminates the multiple request / and connections required in HTTP1 -- even with 4 pipelines that can be a lot of round trip request. If your application was not smart enough to know what to push to the client HTTP2 can allow multiple request over the same connection again negating the need for bundling.
    - igravious 9y ago
      Oi. They were not attacking the author. Their conclusion is sound. Given that Webpack is a lot _more_ than just bundling files together (as has been pointed out twice now) it is incorrect to say that HTTP/2 is a replacement for Webpack. No amount of explaining how HTTP/2 works obviates that fact.
      - JimDabell 9y ago
        They said they didn't understand Webpack/HTTP2 and misrepresented what they said. Looks like attacking the author to me. > it is incorrect to say that HTTP/2 is a replacement for Webpack. Take a look back over the thread. They didn't say that. They said it was a step in the right direction. Then somebody started putting words in their mouth.
    - thelarkinn 9y ago
      Hi @mbrumlow. Sean here from the webpack team. We did a lot of study and testing on HTTP/2 and we found that your claims are entirely incorrect. But don't take my word for it, see the stats! https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 HOWEVER! HTTP/2 and webpack become even more powerful when used together! This is something we are really excited to share and build on!
  - 9y ago
mbrumlow 9y ago
You are just highlighting more of the problem. The fact a blunder is responsible for doing all these things is just proof of more hacking. Most of the things you described live outside of webpack, and webpack is NOT required to use them.
- jaredklewis 9y ago
  Sure, I don't disagree that webpack merely brings those features together into one place. But webpack was born because 80% of the time you make a webapp you don't want just minifcation, or just transpiling, or just cache busting file names, or just file event based recompiles, or just bundling, or just tree shaking, and on and on. Most of the time, you want all of that stuff. People got tired of maintaining their 1000 line npm/gulp/grunt task files, so a bunch of projects were launched with the goal of eliminating that glue code. Webpack is the most popular, but there are of others like Brunch or more recently, Parcel. I think webpack is a mess, but will probably end up being the mess we're stuck with for sometime, because while it is complicated, it does solve a lot of problems. I see a lot of parallel with the GNU make and autotools setups used to build most C projects. The layered way that autoconf, configure, and make build configuration to compile and install programs is pretty complex (to my eye). Sure, it could probably be simplified a bit, but cross compiling code that dynamically links to libraries and installing it on different operating systems is just a complex problem.
  - petepete 9y ago
    I use and am very happy with Brunch. Yes, Webpack might have more features but my Brunch config is like 25 lines and it just works. It took me fifteen minutes to set up having struggled with Webpack for a couple of days.
vbezhenar 9y ago
I think that it's possible to use reasonably latest JavaScript without all those eliminations/minifications/tree shakings/sharing, etc for many projects. But writing entire project in one JavaScript file or issuing dozens of HTTP 1 requests is a real deal breaker for a lot of projects. I know that for most of my projects build tool is only used because of modularization. Everything else is good to have but not required and not worth build complexity.