13 ms·

Webpack 4 Beta released

168 points by schneidmaster 9y ago

simooooo 9y ago
Emoji in the first title? Emoji in every damn title? Are children developing webpack?
- crbelaus 9y ago
  After reading the title this was exactly my first thought. Polluting the titles with emojis feels unnecessary and childish to me. I them a mental burden that makes it difficult to read the important information. I can not imagine a new car announcement page filled with emojis and I don't know why it should be different for software.
  - TheCoreh 9y ago
    With emojis in the headlines, I look at a tiny picture for 0.2s (usually related to the headline) and then read the section as normal. How can that be a mental burden?
    - simooooo 9y ago
      here's my thoughts as I read through it rocket - webpack 4 beta... Guess that means launch present - A promise fulfilled... Present, I guess thats ok confused person - How to install.. hmmm rocket - performance.. I guess rockets are fast fire - Better defaults.. err... Strong arm - Better defaults.. err... cake - side effects.. what? Goat? I think it's a goat - Module Type’s Introduced. what the fuck.
      - haroldf 9y ago
        Thank you for putting my thoughts into words. Add shrugging guy on a skateboard ascii art here.
  - Latty 9y ago
    I must admit, as I searched, I didn't think I'd find something so on-point: http://media.gm.com/content/dam/Media/images/US/Release_Images/2015/06-2015/Cruze/Chevrolet_MediaAlert_10_MOL.jpg http://media.gm.com/content/dam/Media/images/US/Release_Imag...
    - nofilter 9y ago
      Ha! That's gold right there.
    - oblio 9y ago
      I always figured the Egyptians were wrong, with the hieroglyphics. It seems Chevrolet is proving me right :)
  - brailsafe 9y ago
    Because software development is dry as hell. Cars can go fast and take you places. Variety is nice and sometimes it's okay to be cheerful.
- smonff 9y ago
  Something that is also worrying is this culture of competition, by showing, right after the start of the post, "best" contributors, as if lined of code was a key of quality development. I remember some tools that I appreciate, that quote all contributors, in a non hierarchical way. Even if you contributed something minor, you are listed with "main" contributors.
  - thelarkinn 9y ago
    This isn't our intention, rather to recognize those who helped make webpack what it is today. I wouldn't have been able to fit everyone on one page of image otherwise :)
- mrmondo 9y ago
  Indeed, it does also feel like the JavaScript community or rather JavaScript related projects seem to be more attracted to emojifying blog posts, release notifications etc... while perhaps a bit informal it’s probably not the end of the world however perhaps indicative of a combination of excitement of the developers involved and some slight lack of maturity.
  - lwansbrough 9y ago
    > some slight lack of maturity I don't want to live in whatever grey world you folks are imagining where everything is done professionally with no personality.
    - Fifer82 9y ago
      I totally agree. At the very end of the day people shouldn't kid themselves in this industry. The whole thing is an evolving hack fest which changes each week. We are far closer to script kiddies on the web than we are software professionals but that hurts some peoples feelings.
- paperpunk 9y ago
  Something of an off-topic conversation but I think it's quite interesting how modern language is evolving to include pictograms that are common between different languages, and not childish at all. Why must it be a problem?
- deleted 9y ago
  [deleted]
- thelarkinn 9y ago
  We just find that it reaches people better!!! Sometimes in the JavaScipt ecosystem it takes a lot for a 6 year old tool to stay on top of people's focus and attn. But it got yours right?
- ikurei 9y ago
  I hate emoji too, but I think it's even more childish to care so much and be so judgemental about how other people use emoji. Using emoji everywhere is very much in vogue and many people like it. It doesn't make you childish. We (for some value of we that includes me and simooo) are just old, or old-fashioned youths.
  - muthdra 9y ago
    He's doing because he can, like we used to do with animated gifs in the early 2000s. It's a gimmick. There's no honor here.
- baby 9y ago
  What’s wrong with emojis?
toadkicker 9y ago
One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing. However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.
- roryisok 9y ago
  Transpilers are nasty alright, but I like being able to write in Typescript and LESS, and to have my src split into multiple files but my distribution as a single Js file
- gotofritz 9y ago
  Found the grumpy old coder
  - dang 9y ago
    Personal attacks will get you banned here. So will repeatedly posting unsubstantive comments, which I'm afraid you have. Could you please take the spirit of this site more to heart, as described at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html? That means posting civilly and substantively, or not at all.
- Sacho 9y ago
  Why are you using webpack, especially given your hate for build tools?
- gldalmaso 9y ago
  Not all web developers build complex web apps out of sport, it is demanded of us to deliver that. JS as a runtime language had poor first time support to help us manage that complexity. We are lucky that some well meaning folks decided to offer tools to help us with that, and the ecosystem has been maturing. Probably the reason you perceive this obsession with build tools is that incrementally each one had the goal to tackle a set of problems and it did, but then new pain points appeared and other tools were developed to help with that. That being said, we seem to have reached a rather stable period without major raptures in the landscape for a couple of years. Maybe the growing pains are subsiding.
realPubkey 9y ago
Has anyone ever updated a minor webpack-version without having to touch the config? Me not.
- lwansbrough 9y ago
  Only a masochist updates webpack once they get it working.
- deleted 9y ago
  [deleted]
- moogly 9y ago
  Certainly. And upgrading from v2 to v3 was mostly painless.
- adimitrov 9y ago
  In a complicated React SPA, and in two webextensions, one of which has a decent amount of dependencies and plugins. Yes. Never had a problem.
- joshribakoff 9y ago
  Upgraded from v2 to v3 just fine, the only issues I've had is with developers using esoteric plugins which isn't a fault I can attribute to webpack itself.
farnsworthy 9y ago
I've been running the alpha, to help get past the Webpack/Uglify ES6 support issues. It sounds like webpack-dev-server will also disappear soon, too? (Replaced with a more tightly integrated solution, or?)
- gotofritz 9y ago
  Yes, sorry cannot find the link, but they are going to get rid of it from what I read. There is no more tightly integrated solution in the pipelines, you'll have to roll out your own with Express or something (or, more likely, a third party will come up with a solution that will become the norm)
  - deleted 9y ago
    [deleted]
fenomas 9y ago
These look really solid! For anyone else who was confused by the minimal explanation of the "sideEffects: false" feature, apparently this targets cases where (1) module A exports some code, (2) module B imports from A and exports end points, some of which depend on A, and (3) module C imports code from B that doesn't reference code from A. In this situation by default webpack assumes that the code from A might have side effects inside B, but if A declares "sideEffects: false" in its package.json, the tree-shaker will assume it's safe to omit module A from the final bundle. Incidentally the end user can also declare in their config that module B should use sideEffects:false, even if the module doesn't declare it. Details here: https://github.com/webpack/webpack/issues/6065 https://github.com/webpack/webpack/issues/6065
- wereHamster 9y ago
  Too many assumptions, too many ways how developers can make mistakes, by declaring code side-effect free while it has some.
  - WorldMaker 9y ago
    Sure, but if you author a package and put sideEffects: false in your package.json, but don't actually follow through on that in your code, that's a bug in your library, and the easiest fix is a quick PR to remove sideEffects: false from package.json, with a stop gap that if I find a library with that sort of bug I could tell webpack sideEffects: true to override the behavior until the bug is fixed.
dmitriid 9y ago
As a web dev I am extremely happy Webpack team changed their stance from "webpack config is the way it is because everyone's needs are different and also because that's just how Javascript works" to "yes, we can provide sane defaults out of the box". Aaand that their communication has improved a thousand-fold.
y0ghur7_xxx 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. 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.
skrebbel 9y ago
I suspect that the Webpack team thinks that developers' favourite job is to upgrade tool configurations. I mean, it's great that improvements are being made, but breaking changes are not. Remember that the Webpack team has shown to be actively hostile to people who just want to keep their 2-year-old codebases work without doing needless upgrade work. They removed the webpack 1 docs [1], so if you have a few-years-old codebase that you want to get up and running, and somehow you get a webpack error, the message from Webpack is "screw you, upgrade to webpack 3 first and only then we'll allow you to read the docs". I have no reason to not expect the same to happen with Webpack 4, and the inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly removed, retired and forgotten. We're all forced to keep doing work to make something work that already worked perfectly fine. Now, I'm well aware that an angry rant on the internet about the voluntary work from open source contributors is not particularly constructive. I've singled out the Webpack team here, but the reality is that a big part of the web dev ecosystem, across languages, does not care much about backward compatibility. I'd love for that attitude to change. In semver, every major version is a tragedy. [1] https://webpack.github.io/docs/using-plugins https://webpack.github.io/docs/using-plugins
- deleted 9y ago
  [deleted]
- fenomas 9y ago
  > but this does not even include a list of breaking changes. TFA: > For the full list of changes, features, and internal API modifications, please refer to our change log!!! Link: https://github.com/webpack/webpack/releases/tag/v4.0.0-beta.0 https://github.com/webpack/webpack/releases/tag/v4.0.0-beta....
  - skrebbel 9y ago
    Oh damn, that was bad. Thanks, I edited my comment.
    - fenomas 9y ago
      Thanks! FWIW I think your other comments were plenty legitimate, and definitely don't deserve to be downvoted so low (below that inane "wtf emojis??" comment, of all things). Although with that said, I doubt webpack can do anything about what you're saying except to try to be conscientious. Obviously breaking too often is bad, but naturally that doesn't mean never ever breaking is necessarily preferable.
fiatjaf 9y ago
I use Browserify and it works great. Maybe there are some legitimate cases in which you would prefer Webpack, but I really don't understand why have EVERYBODY migrated to Webpack, with all its bloat and breaking changes and build errors and boilerplate.
- frou_dh 9y ago
  I'm happy with ES5 + npm + browserify. Just bundling. No lang->lang transpiling or asset munging.
  - haroldf 9y ago
    Use whatever works.
baybal2 9y ago
Shameless promotion https://rollupjs.org https://rollupjs.org - JS module loader with tree shaking and async loader that works out of the box. Asynchronous loading and code Take a try if webpack takes toll on your productivity
- 1_player 9y ago
  Isn't Rollup used mainly for libraries? The big selling point of Webpack is the plugin system to transform and store non-JS files in your bundle, which Rollup doesn't have, as far as I can tell.
  - rich_harris 9y ago
    Rollup has a powerful plugin interface that lets you transform and load files of any kind — see here for a (possibly non-exhaustive) list: https://github.com/rollup/rollup/wiki/Plugins https://github.com/rollup/rollup/wiki/Plugins Historically Rollup has indeed been more widely adopted among library authors (React, Vue, D3, Three.js, Leaflet, Moment, etc), though there's no reason it can't be used for apps — lots of us are doing just that.
    - dmitriid 9y ago
      > JS module loader with tree shaking and async loader that works out of the box and yet > Rollup has a powerful plugin interface that lets you transform and load files of any kind — see here for a (possibly non-exhaustive) list So yes, it is primarily aimed at libraries, and "out of the box" flies out of the window when you move to apps.
      - rich_harris 9y ago
        I don't follow your logic. What are you saying?
- rich_harris 9y ago
  I think generally only the creators of something get to use the term 'shameless promotion' :) We (the Rollup team) would never criticise webpack in a forum like this in order to promote our own alternative (except maybe on Twitter, because trolling Sean is just too tempting) — it's an outstanding project, and we all talk to each other and learn from each other. Rising tide lifts all boats, etc
danjoc 9y ago
Is there really any point to webpack now that we have http2? I'm looking for a way to code split all the things and webpack is making that difficult. I want cache performance over download speed now that I've gone mobile only on data.
- RobertRoberts 9y ago
  I asked this same question and got down voted for it. After probing some more though, I found out it's only any use for people that have many MBs of JS files. Which I can only assume comes from piles of npm dependencies getting sucked into their projects. Also, it's not for websites with some interactivity, it's for big giant web apps... apparently.
- joshribakoff 9y ago
  Yes. https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 To quote the article: There is still a protocol overhead for each request compared to a single concatenated file. The compression of the single large file is better than many small files. Servers are slower serving many small files than a single large file.
  - danjoc 9y ago
    I'm really less interested in speed though. I want to optimize for file transfer bandwidth. Going all mobile data for a week has shown me two problems. JS has severely bloated websites, and staying up to date with software patches is expensive. In both cases, the amount of new material being transferred is very low. A point update on a JS library or patch is a few lines change, but we must download the entire library again. Compounding this for JS is every site using the same libs are sending the same data, because of browser origin policies. One way around that is CDNs, but then you are submitting to a centralized point of failure/spying. Sending the whole file again is the easiest route for developers, but the most expensive for mobile only cord cutters.
    - joshribakoff 9y ago
onion-soup 9y ago
Jeez tone down them emojis a bit pal. And I'm seeing black squares on windows 7 anyway
paws 9y ago
Two years ago I would have invested some effort to read this thoroughly and try to stay on top of the API changes. I'm sure it's helpful to a lot of folks. For sure I do care about my build toolchain. The nice thing about being a React developer today, is that thanks to create-react-app, more specifically react-scripts [1], I'm thankful I get to choose to not worry about it. Just like I didn't have to worry about 2.0 -> 3.0 last time. Cheers to the CRA maintainers. Thanks for giving me some time back! [1] https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/package.json#L62 https://github.com/facebook/create-react-app/blob/next/packa...
- needcaffeine 9y ago
  In your experience, is CRA just for people starting out with a new project or can large apps implement and use it without ejecting and diverging?
  - paws 9y ago
    If your existing large app is a React app, the naive thing to try would be migrating the src/ folder into a new CRA app and see what happens. If you get a lot off runtime errors you have an easier time migrating to CRA, if you eject a new CRA app and gently/iteratively adjust the webpack config on your existing project to match CRAs.
RobertRoberts 9y ago
I don't use Webpack, would it help with regular website dev? Or is this just for web apps? Also, does it really make things faster? What about HTTP2/SPDY, do we really care about making everything one file anymore? This seems like a paradigm that is no longer valid (like using tables instead of grid for website layout).
- simonlc 9y ago
  You pretty much will always need a bundler, unless you write everything from scratch, and don't support legacy browsers. Webpack actually does do things like code splitting for you, so no, not everything goes into one file.
  - RobertRoberts 9y ago
    Can you explain if Webpack would help with Wordpress sites? Or is Webpack really only for webapps? What is the benefit gained from "code splitting"? Would it make a blog run faster? What if the largest amount of JS on your site is 5k? Why would there be a need to code split this?
    - slig 9y ago
      I'm not the parent, but you don't need webpack for something like a WP blog. Code splitting is great on bigger webapps such as GMail or Facebook. For instance, when you want to see your contacts on gmail, it can load the required JS file of that module on demand. Same thing on FB: the chat widget can be loaded separately, and only if needed.
      - RobertRoberts 9y ago
        Thank you, this explains some basic things that seem to be assumed by so many web devs/blogs/etc... :P A while back I went through the process of evaluating a lot of build tools, and I simply couldn't see any benefits of replacing my bash scripts with these tools, and you cleared it up nicely.
    - 9y ago
tjpnz 9y ago
A few years ago I was asked by a frontend team to investigate their Jenkins build. What used to take 90 seconds went to 15 minutes and it only started happening when the team switched to Webpack. I recall Webpack being hideously complicated with a lot of the documentation either missing or just plain wrong - no wonder they managed to make a mess of things so easily. Has any of that changed?
- schneidmaster 9y ago
  The documentation got substantially better in 2.0 (imo), and simplifying the configuration overall was a major initiative for 4.0. You can now start with zero config if you want to follow their defaults of putting your source in /src and built output in /dist, and they also added production/development "modes" that enable a bunch of sane defaults for each. You can still get into really complicated configuration cases depending on your project but it's definitely been on an upwards trajectory in that regard.
- joshribakoff 9y ago
  Webpack is fast. Tools like babel which webpack has to call into are slow. Using webpack+babel will be faster than gulp/grunt+babel since webpack can track which file(s) changed & rebuild only those files. Even ignoring that, it still faster because you don't have to kill it & cold restart it when switching branches or adding new files, like with a gulp build which typically globs for files only at startup.
unquietcode 9y ago
Oh good. I just finished upgrading my project to Webpack 3. Can't wait to do it all again... I'm all for rapid progress, but the pace of web development is absolutely breakneck.
- h1d 9y ago
  There are other options that requires no config.
deleted 9y ago
[deleted]

168 points by schneidmaster 9y ago

simooooo 9y ago

Emoji in the first title? Emoji in every damn title? Are children developing webpack?

crbelaus 9y ago
After reading the title this was exactly my first thought. Polluting the titles with emojis feels unnecessary and childish to me. I them a mental burden that makes it difficult to read the important information. I can not imagine a new car announcement page filled with emojis and I don't know why it should be different for software.
- TheCoreh 9y ago
  With emojis in the headlines, I look at a tiny picture for 0.2s (usually related to the headline) and then read the section as normal. How can that be a mental burden?
  - simooooo 9y ago
    here's my thoughts as I read through it rocket - webpack 4 beta... Guess that means launch present - A promise fulfilled... Present, I guess thats ok confused person - How to install.. hmmm rocket - performance.. I guess rockets are fast fire - Better defaults.. err... Strong arm - Better defaults.. err... cake - side effects.. what? Goat? I think it's a goat - Module Type’s Introduced. what the fuck.
    - haroldf 9y ago
      Thank you for putting my thoughts into words. Add shrugging guy on a skateboard ascii art here.
- Latty 9y ago
  I must admit, as I searched, I didn't think I'd find something so on-point: http://media.gm.com/content/dam/Media/images/US/Release_Images/2015/06-2015/Cruze/Chevrolet_MediaAlert_10_MOL.jpg http://media.gm.com/content/dam/Media/images/US/Release_Imag...
  - nofilter 9y ago
    Ha! That's gold right there.
  - oblio 9y ago
    I always figured the Egyptians were wrong, with the hieroglyphics. It seems Chevrolet is proving me right :)
- brailsafe 9y ago
  Because software development is dry as hell. Cars can go fast and take you places. Variety is nice and sometimes it's okay to be cheerful.
smonff 9y ago
Something that is also worrying is this culture of competition, by showing, right after the start of the post, "best" contributors, as if lined of code was a key of quality development. I remember some tools that I appreciate, that quote all contributors, in a non hierarchical way. Even if you contributed something minor, you are listed with "main" contributors.
- thelarkinn 9y ago
  This isn't our intention, rather to recognize those who helped make webpack what it is today. I wouldn't have been able to fit everyone on one page of image otherwise :)
mrmondo 9y ago
Indeed, it does also feel like the JavaScript community or rather JavaScript related projects seem to be more attracted to emojifying blog posts, release notifications etc... while perhaps a bit informal it’s probably not the end of the world however perhaps indicative of a combination of excitement of the developers involved and some slight lack of maturity.
- lwansbrough 9y ago
  > some slight lack of maturity I don't want to live in whatever grey world you folks are imagining where everything is done professionally with no personality.
  - Fifer82 9y ago
    I totally agree. At the very end of the day people shouldn't kid themselves in this industry. The whole thing is an evolving hack fest which changes each week. We are far closer to script kiddies on the web than we are software professionals but that hurts some peoples feelings.
paperpunk 9y ago
Something of an off-topic conversation but I think it's quite interesting how modern language is evolving to include pictograms that are common between different languages, and not childish at all. Why must it be a problem?
deleted 9y ago
[deleted]
thelarkinn 9y ago
We just find that it reaches people better!!! Sometimes in the JavaScipt ecosystem it takes a lot for a 6 year old tool to stay on top of people's focus and attn. But it got yours right?
ikurei 9y ago
I hate emoji too, but I think it's even more childish to care so much and be so judgemental about how other people use emoji. Using emoji everywhere is very much in vogue and many people like it. It doesn't make you childish. We (for some value of we that includes me and simooo) are just old, or old-fashioned youths.
- muthdra 9y ago
  He's doing because he can, like we used to do with animated gifs in the early 2000s. It's a gimmick. There's no honor here.
baby 9y ago
What’s wrong with emojis?

toadkicker 9y ago

One of things I absolutely despise about the JS community is this obsession with build tools. JS is meant to be a runtime language and the amount of transpilers, minifiers, uglifiers, obfusicationifiers, is absolutely endemic to the messy state of change the language is undergoing. However with this release I'm excited to start deleting a bunch of ridiculous build code to make Webpack work. Really a build tool is a tool, it should never be in the way of developing features. I haven't enjoyed using webpack until now. No sensible defaults, poor documentation, and no standard conventions. This release changes all of those complaints. A boost for productivity is a win in my book.

roryisok 9y ago
Transpilers are nasty alright, but I like being able to write in Typescript and LESS, and to have my src split into multiple files but my distribution as a single Js file
gotofritz 9y ago
Found the grumpy old coder
- dang 9y ago
  Personal attacks will get you banned here. So will repeatedly posting unsubstantive comments, which I'm afraid you have. Could you please take the spirit of this site more to heart, as described at https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html? That means posting civilly and substantively, or not at all.
Sacho 9y ago
Why are you using webpack, especially given your hate for build tools?
gldalmaso 9y ago
Not all web developers build complex web apps out of sport, it is demanded of us to deliver that. JS as a runtime language had poor first time support to help us manage that complexity. We are lucky that some well meaning folks decided to offer tools to help us with that, and the ecosystem has been maturing. Probably the reason you perceive this obsession with build tools is that incrementally each one had the goal to tackle a set of problems and it did, but then new pain points appeared and other tools were developed to help with that. That being said, we seem to have reached a rather stable period without major raptures in the landscape for a couple of years. Maybe the growing pains are subsiding.

realPubkey 9y ago

Has anyone ever updated a minor webpack-version without having to touch the config? Me not.

lwansbrough 9y ago
Only a masochist updates webpack once they get it working.
deleted 9y ago
[deleted]
moogly 9y ago
Certainly. And upgrading from v2 to v3 was mostly painless.
adimitrov 9y ago
In a complicated React SPA, and in two webextensions, one of which has a decent amount of dependencies and plugins. Yes. Never had a problem.
joshribakoff 9y ago
Upgraded from v2 to v3 just fine, the only issues I've had is with developers using esoteric plugins which isn't a fault I can attribute to webpack itself.

farnsworthy 9y ago

I've been running the alpha, to help get past the Webpack/Uglify ES6 support issues. It sounds like webpack-dev-server will also disappear soon, too? (Replaced with a more tightly integrated solution, or?)

gotofritz 9y ago
Yes, sorry cannot find the link, but they are going to get rid of it from what I read. There is no more tightly integrated solution in the pipelines, you'll have to roll out your own with Express or something (or, more likely, a third party will come up with a solution that will become the norm)
- deleted 9y ago
  [deleted]

fenomas 9y ago

These look really solid! For anyone else who was confused by the minimal explanation of the "sideEffects: false" feature, apparently this targets cases where (1) module A exports some code, (2) module B imports from A and exports end points, some of which depend on A, and (3) module C imports code from B that doesn't reference code from A. In this situation by default webpack assumes that the code from A might have side effects inside B, but if A declares "sideEffects: false" in its package.json, the tree-shaker will assume it's safe to omit module A from the final bundle. Incidentally the end user can also declare in their config that module B should use sideEffects:false, even if the module doesn't declare it. Details here: https://github.com/webpack/webpack/issues/6065 https://github.com/webpack/webpack/issues/6065

wereHamster 9y ago
Too many assumptions, too many ways how developers can make mistakes, by declaring code side-effect free while it has some.
- WorldMaker 9y ago
  Sure, but if you author a package and put sideEffects: false in your package.json, but don't actually follow through on that in your code, that's a bug in your library, and the easiest fix is a quick PR to remove sideEffects: false from package.json, with a stop gap that if I find a library with that sort of bug I could tell webpack sideEffects: true to override the behavior until the bug is fixed.

dmitriid 9y ago

As a web dev I am extremely happy Webpack team changed their stance from "webpack config is the way it is because everyone's needs are different and also because that's just how Javascript works" to "yes, we can provide sane defaults out of the box". Aaand that their communication has improved a thousand-fold.

y0ghur7_xxx 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. 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.

skrebbel 9y ago

I suspect that the Webpack team thinks that developers' favourite job is to upgrade tool configurations. I mean, it's great that improvements are being made, but breaking changes are not. Remember that the Webpack team has shown to be actively hostile to people who just want to keep their 2-year-old codebases work without doing needless upgrade work. They removed the webpack 1 docs [1], so if you have a few-years-old codebase that you want to get up and running, and somehow you get a webpack error, the message from Webpack is "screw you, upgrade to webpack 3 first and only then we'll allow you to read the docs". I have no reason to not expect the same to happen with Webpack 4, and the inevitable Webpack 5, 7 months from now. Webpack 2/3 docs will be subtly removed, retired and forgotten. We're all forced to keep doing work to make something work that already worked perfectly fine. Now, I'm well aware that an angry rant on the internet about the voluntary work from open source contributors is not particularly constructive. I've singled out the Webpack team here, but the reality is that a big part of the web dev ecosystem, across languages, does not care much about backward compatibility. I'd love for that attitude to change. In semver, every major version is a tragedy. [1] https://webpack.github.io/docs/using-plugins https://webpack.github.io/docs/using-plugins

deleted 9y ago
[deleted]
fenomas 9y ago
> but this does not even include a list of breaking changes. TFA: > For the full list of changes, features, and internal API modifications, please refer to our change log!!! Link: https://github.com/webpack/webpack/releases/tag/v4.0.0-beta.0 https://github.com/webpack/webpack/releases/tag/v4.0.0-beta....
- skrebbel 9y ago
  Oh damn, that was bad. Thanks, I edited my comment.
  - fenomas 9y ago
    Thanks! FWIW I think your other comments were plenty legitimate, and definitely don't deserve to be downvoted so low (below that inane "wtf emojis??" comment, of all things). Although with that said, I doubt webpack can do anything about what you're saying except to try to be conscientious. Obviously breaking too often is bad, but naturally that doesn't mean never ever breaking is necessarily preferable.

fiatjaf 9y ago

I use Browserify and it works great. Maybe there are some legitimate cases in which you would prefer Webpack, but I really don't understand why have EVERYBODY migrated to Webpack, with all its bloat and breaking changes and build errors and boilerplate.

frou_dh 9y ago
I'm happy with ES5 + npm + browserify. Just bundling. No lang->lang transpiling or asset munging.
- haroldf 9y ago
  Use whatever works.

baybal2 9y ago

Shameless promotion https://rollupjs.org https://rollupjs.org - JS module loader with tree shaking and async loader that works out of the box. Asynchronous loading and code Take a try if webpack takes toll on your productivity

1_player 9y ago
Isn't Rollup used mainly for libraries? The big selling point of Webpack is the plugin system to transform and store non-JS files in your bundle, which Rollup doesn't have, as far as I can tell.
- rich_harris 9y ago
  Rollup has a powerful plugin interface that lets you transform and load files of any kind — see here for a (possibly non-exhaustive) list: https://github.com/rollup/rollup/wiki/Plugins https://github.com/rollup/rollup/wiki/Plugins Historically Rollup has indeed been more widely adopted among library authors (React, Vue, D3, Three.js, Leaflet, Moment, etc), though there's no reason it can't be used for apps — lots of us are doing just that.
  - dmitriid 9y ago
    > JS module loader with tree shaking and async loader that works out of the box and yet > Rollup has a powerful plugin interface that lets you transform and load files of any kind — see here for a (possibly non-exhaustive) list So yes, it is primarily aimed at libraries, and "out of the box" flies out of the window when you move to apps.
    - rich_harris 9y ago
      I don't follow your logic. What are you saying?
rich_harris 9y ago
I think generally only the creators of something get to use the term 'shameless promotion' :) We (the Rollup team) would never criticise webpack in a forum like this in order to promote our own alternative (except maybe on Twitter, because trolling Sean is just too tempting) — it's an outstanding project, and we all talk to each other and learn from each other. Rising tide lifts all boats, etc

danjoc 9y ago

Is there really any point to webpack now that we have http2? I'm looking for a way to code split all the things and webpack is making that difficult. I want cache performance over download speed now that I've gone mobile only on data.

RobertRoberts 9y ago
I asked this same question and got down voted for it. After probing some more though, I found out it's only any use for people that have many MBs of JS files. Which I can only assume comes from piles of npm dependencies getting sucked into their projects. Also, it's not for websites with some interactivity, it's for big giant web apps... apparently.
joshribakoff 9y ago
Yes. https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 https://medium.com/webpack/webpack-http-2-7083ec3f3ce6 To quote the article: There is still a protocol overhead for each request compared to a single concatenated file. The compression of the single large file is better than many small files. Servers are slower serving many small files than a single large file.
- danjoc 9y ago
  I'm really less interested in speed though. I want to optimize for file transfer bandwidth. Going all mobile data for a week has shown me two problems. JS has severely bloated websites, and staying up to date with software patches is expensive. In both cases, the amount of new material being transferred is very low. A point update on a JS library or patch is a few lines change, but we must download the entire library again. Compounding this for JS is every site using the same libs are sending the same data, because of browser origin policies. One way around that is CDNs, but then you are submitting to a centralized point of failure/spying. Sending the whole file again is the easiest route for developers, but the most expensive for mobile only cord cutters.
  - joshribakoff 9y ago

onion-soup 9y ago

Jeez tone down them emojis a bit pal. And I'm seeing black squares on windows 7 anyway

paws 9y ago

Two years ago I would have invested some effort to read this thoroughly and try to stay on top of the API changes. I'm sure it's helpful to a lot of folks. For sure I do care about my build toolchain. The nice thing about being a React developer today, is that thanks to create-react-app, more specifically react-scripts [1], I'm thankful I get to choose to not worry about it. Just like I didn't have to worry about 2.0 -> 3.0 last time. Cheers to the CRA maintainers. Thanks for giving me some time back! [1] https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/package.json#L62 https://github.com/facebook/create-react-app/blob/next/packa...

needcaffeine 9y ago
In your experience, is CRA just for people starting out with a new project or can large apps implement and use it without ejecting and diverging?
- paws 9y ago
  If your existing large app is a React app, the naive thing to try would be migrating the src/ folder into a new CRA app and see what happens. If you get a lot off runtime errors you have an easier time migrating to CRA, if you eject a new CRA app and gently/iteratively adjust the webpack config on your existing project to match CRAs.

RobertRoberts 9y ago

I don't use Webpack, would it help with regular website dev? Or is this just for web apps? Also, does it really make things faster? What about HTTP2/SPDY, do we really care about making everything one file anymore? This seems like a paradigm that is no longer valid (like using tables instead of grid for website layout).

simonlc 9y ago
You pretty much will always need a bundler, unless you write everything from scratch, and don't support legacy browsers. Webpack actually does do things like code splitting for you, so no, not everything goes into one file.
- RobertRoberts 9y ago
  Can you explain if Webpack would help with Wordpress sites? Or is Webpack really only for webapps? What is the benefit gained from "code splitting"? Would it make a blog run faster? What if the largest amount of JS on your site is 5k? Why would there be a need to code split this?
  - slig 9y ago
    I'm not the parent, but you don't need webpack for something like a WP blog. Code splitting is great on bigger webapps such as GMail or Facebook. For instance, when you want to see your contacts on gmail, it can load the required JS file of that module on demand. Same thing on FB: the chat widget can be loaded separately, and only if needed.
    - RobertRoberts 9y ago
      Thank you, this explains some basic things that seem to be assumed by so many web devs/blogs/etc... :P A while back I went through the process of evaluating a lot of build tools, and I simply couldn't see any benefits of replacing my bash scripts with these tools, and you cleared it up nicely.
  - 9y ago

tjpnz 9y ago

A few years ago I was asked by a frontend team to investigate their Jenkins build. What used to take 90 seconds went to 15 minutes and it only started happening when the team switched to Webpack. I recall Webpack being hideously complicated with a lot of the documentation either missing or just plain wrong - no wonder they managed to make a mess of things so easily. Has any of that changed?

schneidmaster 9y ago
The documentation got substantially better in 2.0 (imo), and simplifying the configuration overall was a major initiative for 4.0. You can now start with zero config if you want to follow their defaults of putting your source in /src and built output in /dist, and they also added production/development "modes" that enable a bunch of sane defaults for each. You can still get into really complicated configuration cases depending on your project but it's definitely been on an upwards trajectory in that regard.
joshribakoff 9y ago
Webpack is fast. Tools like babel which webpack has to call into are slow. Using webpack+babel will be faster than gulp/grunt+babel since webpack can track which file(s) changed & rebuild only those files. Even ignoring that, it still faster because you don't have to kill it & cold restart it when switching branches or adding new files, like with a gulp build which typically globs for files only at startup.

unquietcode 9y ago

Oh good. I just finished upgrading my project to Webpack 3. Can't wait to do it all again... I'm all for rapid progress, but the pace of web development is absolutely breakneck.

h1d 9y ago
There are other options that requires no config.

deleted 9y ago

[deleted]