14 ms·

Webpack 5

250 points by marksamman 6y ago

jebronie 6y ago
"There is a good chance that upgrading fails and you would need to give it a second or 3rd try." Sad that this has almost become the norm when developing in the modern javascript ecosystem. I dread touching those projects and creating one even more because stuff just rots away and your app might break in days, weeks or If you are lucky months. I'm sure there are better developers out there that can handle all of this and know how to avoid it, but a bozo like me does not. This is actually causing me stress irl.
- vmception 6y ago
  Oh thats because you are missing the specific version manager for each part of your build toolchain And dont forget to make a script that automatically sets the right versions of npm, webpack, and python all at once! This is fine, I am okay with the events that are unfolding currently.
  - zdragnar 6y ago
    If you have multiple projects of almost any language that are stuck on different versions, you basically end up with the same problem and solution. I will definitely keep my version managers, thank you very much.
  - haar 6y ago
    I've been using ASDF (https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf) for a while now to manage each of the language (and sometimes build tool) versions for a folder/repo in a consistent manner. I'd definitely recommend taking a look at it.
  - vangelis 6y ago
    How do you manage your version managers?
- throwanem 6y ago
  The way you avoid problems with a .0.0 release is by not upgrading to a .0.0 release. You would have to do that by hand; npm and yarn have been pinning major versions for a long time now, so that upgrade only happens when you do it by hand. So if you don't want to deal with breaking changes, all you have to do is nothing. Meantime webpack 4 is not going anywhere.
  - SilasX 6y ago
    I'm reminded of when npm released 5.7.0 (which some got upgraded to automatically because it wasn't tagged as pre-release) and had a critical bug that deleted your system files. https://news.ycombinator.com/item?id=16435305 https://news.ycombinator.com/item?id=16435305
    - throwanem 6y ago
      Why? What on Earth do you imagine that having to do with this?
      - SilasX 6y ago
        It was a new version (with significant nasty surprises), albeit .7.0 instead of .0.0.
        throwanem 6y ago
        It was a new minor version, of a totally different package, which was version-tagged in such a way that some distro packagers picked it up when they shouldn't have, and which happened to contain a bug affecting a use case that's been deprecated for at least half a decade now. Look, I get that there's a lot of hate for modern JS, and it's hardly as if there is any lack of basis for criticism, just as there is with every other highly active, heavily adopted, and fast-evolving software ecosystem. But mistaking this kind of uninformed slagging for meaningful commentary says more about the person who does it than about the subject of their ire.
- tqkxzugoaupvwqr 6y ago
  It helps to pin dependencies so that only the exact specified version is downloaded/installed/used. I recently updated the dependencies of a frontend project. `vue-apollo` from version 3.0.3 to 3.0.4 had a breaking change. The discussion in the commit on GitHub proposed to release it as v4. But in the dev’s mind it was a fix so he released it as a patch version.
- root_axis 6y ago
  Why do you feel the need to upgrade to webpack 5? What particular feature do you need that justifies the upgrade?
  - fedlarm 6y ago
    For me the module federation is a new feature that I can take advantage of to improve integrations.
- sinker 6y ago
  So far what I've been doing is keeping my webpack config as simple as possible (< 40 lines) and just relying on default behavior. I know I'm losing out by not bothering with some of the more intricate configuration properties like caching, etc. But one of my big pet peeves is when you clone a project and the installation says all you need to do is run make install or npm i, but in reality requires 20 google searches and an hour of banging your head to get the project running and even then you end up with 50 cryptic warning messages in your terminal so you don't even know if you did it correctly. With a very simple webpack config you might lose out on optimizations but at least you can get just about anyone running a project locally and if things go awry you can generally pinpoint the problem to a specific line of configuration.
  - nicoburns 6y ago
    I've found that a slightly longer (~100 lines) webpack config allows me to use all the caching and fancy tricks I want and is still just as debuggable. I think the main thing is setting it up yourself so you know what all the plugins/settings do.
    - nwienert 6y ago
      The key is don’t abstract it. No function builders, one big object with inline conditional spreads.
    - zamber 6y ago
      Caching was a major dissapointment for me. DllPlugin is a nightmare to setup and other caching plugins I tried don't really speed things up. What eventually worked for me is HardSourceWebpackPlugin [1] - two lines added and went from 2min to 15s (with a tradeoff of a slightly longer initial build). [1] - https://github.com/mzgoddard/hard-source-webpack-plugin https://github.com/mzgoddard/hard-source-webpack-plugin
      - nicoburns 6y ago
        Not sure on the specifics, but my understanding is that the major improvements in Webpack 5 are related to caching.
- jakub_g 6y ago
  Webpack is kind of more "build your own bundler" than a bundler. The configurability and extensibility is immense and with that level of complexity, it's guaranteed things won't work smoothly for everyone (incompatible plugins, unexpected configurations etc.). Anyway, every big project always has hiccups with new major X.0.0 release. Think about your own code for a second. It's typically a well defined code that doesn't have to accommodate a combinatorial explosion of configurations. It is bug free? Keep in mind that 90% of code is written by one guy. It's not Webpack Corp. with a legion of QA testers.
  - setr 6y ago
    Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Or they're running things in parallel, and encountering data races and such, and randomly working as a result. But the real concern is that they don't really know what a correct installation looks like, or they'd just check-and-retry on a loop until it succeeded (the easiest hack around such problems)
    - ENGNR 6y ago
      I think it’s more if 5.0.0 doesn’t work the first time, you could simply let the community find those issues for you and by 5.0.xx it will mostly likely cover your specific setup (except for the documented api changes)
    - jayflux 6y ago
      > Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Maybe we’ve interpreted that message in different ways, but I took it to mean you may need to try it again at a later date once the community have fixed those issues/bugs. I don’t think they meant literally 3 runs of the same setup. They’re still working through stuff so there may be edge cases for some where 5 won’t work right now.
- jacob019 6y ago
  I know the feeling. It's not just modern stuff, I have an old ExtJS app that I dread to update. The best solution I have found is a dev / build environment in a dedicated VM that I can spin up once or twice a year to make updates. Bringing libraries up to date is a fucking nightmare and often a waste of time. For continuously updated apps I have moved away from complicated build processes. Most web apps are fine without a build process, I think there is a lot of premature optimization going on.
  - cjauvin 6y ago
    I too maintain an old and complex ExtJS 4.1 app and I never dared upgrading the framework. I carry a big zip around and it will be that until the end of its life or when I finally decide to rewrite it using React. For such an old framework it’s surprisingly bug free though.
- ronaldj 6y ago
  Configuring the modern JS toolkit (webpack, Babel, your framework of choice, Jest, etc) is such a pain. I’ve been doing front-end for 10+ years. You’re probably not a bozo.
  - folkhack 6y ago
    Same, and it's just layer on layer of extra tooling and complexity. Typescript, Babel, Webpack, JSX, TSX, etc, etc. It gets in the way of development as much as it helps.
    - cookiengineer 6y ago
      ... And suddenly, you want to insert your UI components of choice and you end up with segfault errors of node-gyp. Then you decide that not giving a damn is the sane option to maintain codebases.
      - gfodor 6y ago
        Yeah not-giving-a-damn-driven-development is also the only way to stay sane and not be over come with paralysis from being surrounded by a thousand broken windows in need of fixing.
        ficklepickle 6y ago
        Arguably not giving a damn caused the problem in the first place
    - searchableguy 6y ago
      Deno does away with most of the tooling configuration. You get linter, bundler, docs generator, formatter, watcher, version manager, std library, inbuilt tests, and many things that you would otherwise source from third parties in node ecosystem. Support for webgpu and local storage incoming. Makes it a delight to write scripts. You can also scope them by permission. https://deno.land/ https://deno.land/ Great community: https://discord.gg/deno https://discord.gg/deno
- GordonS 6y ago
  I frequently have to rerun `npm i` when it fails for seemingly spurious reasons. We used to laugh at Windows years ago, when the solution was so often "turn it off and on again", but it's basically what you need to constantly do with tools like npm and webpack.
  - nicoburns 6y ago
    Yarn is much better in this regard. I'd thoroughly recommend it. It's drop-in compatible (except it will generate it's own lock file), so it's pretty easy to try it.
    - sebmellen 6y ago
      Yarn also gives much cleaner output. NPM is extremely verbose, but it seems that "verbosity" doesn't really confer any benefit. And yarn is also generally much faster.
    - pwdisswordfish4 6y ago
      "Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right."
- hsbauauvhabzb 6y ago
  Out of curiosity is patching and updating all packages also a common consistent issue? Is there regularly breaking changes?
  - zamber 6y ago
    Depends on what packages you use and how well they do semver. Chances are you will get major version bumps for most of your dependencies after 1-2 years of development. What works well then is to do upgrades partially. Each major library separately, fix issues, go with the next one. Otherwise it's hard(er) to track what breaks your app. My current project has 100 dependencies and 150 devDependencies. Upgrading takes a week if not longer for one experienced dev. We tend to do it every 3-4 months.
- SoSoRoCoCo 6y ago
  > modern javascript ecosystem. I recently was convinced to start using a packer (webpack, parcel) and was blown away by the hoops people have to jump through to make stuff work. I've been spending an hour or so a day coming up to speed for the past few weeks, and every yarn/npm package I installed had some kind of error/warning that required a hack, or version contortion. I naively thought I could webpack with electron+vue+pug+ts and was soundly smacked down repeatedly, even after trying the boilerplate from each components' docs. I appreciate what the developers are trying to do, I really do. Only, it is too many cooks + death by a thousand cuts. As I read through pages of closed-but-not-really GitHub issues for each package, sometimes going back years and years, it feels like a constant stream of hacking that erodes the well-intentioned first versions. > but a bozo like me does not. This is actually causing me stress irl. Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above.
  - earthboundkid 6y ago
    To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.
    - dntrkv 6y ago
      That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
      - ch4s3 6y ago
        They usually have fewer features as well, and not having to support features with weird edge cases always helps.
    - 6y ago
- pknopf 6y ago
  jQuery and full-page postbacks are my go-to, unless there is an actual need to introduce something else (React, etc). I'm usually conservative in the tools I choose, but I have to be especially conservative with js.
  - darepublic 6y ago
    Full page postbacks are not necessary even if you want to go zero dep
    - pknopf 6y ago
      Most of the time, it isn't very useful to have javascript even exist, even though there isn't 3rd party dep. For example, have you even been in the settings areas of GitHub and thought "I wish there was more async here!"? In ASP.NET MVC, doing full postbacks means very simple controllers/actions/views that a junior could understand.
- manigandham 6y ago
  It's specifically the frontend ecosystem. A problem caused by the numerous languages, assets, and formats that have to come together, the lack of JS standard library, poor module system, and the disaster of browser compatibility mixed with transpilers, polyfills. Webpack has already had zero/very-little config required by default. That's what most should use, and that's if you even need to use Webpack directly. Otherwise I recommend sticking to the major site frameworks like Next/Nuxt/Gatsby and let those do all the config wiring for you.
- hankstenberg 6y ago
  Started my first React Native app some time ago and I can totally confirm that. It feels like a jungle of very fragile dependencies and mechanisms between code and output.
  - lukeramsden 6y ago
    Yes RN is certainly the worst for that for me. I can't count how many hours I've had to put in to wrangle the RN packager in to a monorepo with TypeScript and code-sharing across packages, and it's still unbelievably fragile and I can't actually share components between them. At this point I've made so many little alterations to the config from GitHub issues and StackOverflow answers that I literally have no idea how it works or how to replicate it to a new project. It's an absolute nightmare.
- d13 6y ago
  We’ve banned npm install: It’s simply a party drug and completely unnecessary.
  - deleted 6y ago
    [deleted]
- madeofpalk 6y ago
  This is why I’m such a fan of the meta-bundlers/frameworks, like create-react-app or Next.js I like the features that we pack gives me, but knowing webpack and spending the effort on configuring it just seems like a waste. I’m incredibly grateful for the CRA maintainers to handle that for me.
  - zamber 6y ago
    That works until your team doesn't decide to eject because they want to play around with webpack...
    - madeofpalk 6y ago
      Of course! Then you're just in the same hellish landscape of having to learn and maintain webpack configs, which "you" completely opted into!
- btbuildem 6y ago
  Once I had the freedom to decide, I gave up on using most of the standard Javascript ecosystem stuff in my front-end projects. No node, no npm_modules, no build chain. I'm lucky to be able to get away with that. It is incredibly efficient, not only because it no longer gets in the way of what I'm trying to build. The previous team I was on, we spent roughly 15% of our time tending to these things.
- noway421 6y ago
  Webpack itself is quite low level. `react-native init` or `create-react-app` gives you the ready to use developing environment and updating that is usually a breeze.
- thelarkinn 6y ago
  Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship major versions+bring new features. You don't have to use them, you can just use webpack's zero config out of the box.
acemarke 6y ago
Next.js 9.5 added opt-in support for Webpack 5: https://nextjs.org/blog/next-9-5 https://nextjs.org/blog/next-9-5 and looks like Create-React-App plans to support Webpack 5 in an upcoming CRA 4.1 release (4.0 is in alpha now): https://github.com/facebook/create-react-app/issues/9613#issuecomment-689405958 https://github.com/facebook/create-react-app/issues/9613#iss...
- tunesmith 6y ago
  I believe the opt-in support only works if you use yarn, is that right? I didn't think npm supported resolutions.
Waterluvian 6y ago
I’m scrolling and scrolling waiting for a paragraph that tries to sell me on why I’d bother and risk upgrading. I think the best I got were patch notes. Any good reason to upgrade?
- acemarke 6y ago
  Per https://webpack.js.org/blog/2020-10-10-webpack-5-release/#general-direction https://webpack.js.org/blog/2020-10-10-webpack-5-release/#ge... : - Improve build performance with Persistent Caching. - Improve Long Term Caching with better algorithms and defaults. - Improve bundle size with better Tree Shaking and Code Generation. - Improve compatibility with the web platform. - Clean up internal structures that were left in a weird state while implementing features in v4 without introducing any breaking changes. - Prepare for future features by introducing breaking changes now, allowing us to stay on v5 for as long as possible
  - randtrain34 6y ago
    Are there any benchmarks to get a rough idea on how much improvement in all these areas we can expect to get by upgrading?
    - xwdv 6y ago
      The only benchmark that matters is how much more money you will make from customers after upgrading.
      - dmitryminkovsky 6y ago
        Put that coffee down! Coffee is for closers only.
  - lhnz 6y ago
    I've heard that build performance is actually worse than webpack 4, if you're not using persistent caching. See: https://twitter.com/FredKSchott/status/1314220659984146432 https://twitter.com/FredKSchott/status/1314220659984146432
nikivi 6y ago
Eventually the packing part can be done in a compiled language. https://github.com/evanw/esbuild https://github.com/evanw/esbuild is very fast at doing some things already but not others. And I guess webpack wins because you can configure it to do anything easily already? And with compiled languages 'configurability' is hard to do?
Jarred 6y ago
The incremental build time improvements look great. Did the cold build times get slower? This tweet shows a benchmark that makes it seem like cold build times got slower in Webpack 5 https://twitter.com/evanwallace/status/1314121407903617025?s=21 https://twitter.com/evanwallace/status/1314121407903617025?s...
- deleted 6y ago
  [deleted]
- moltar 6y ago
  I think so. Look at esbuilt benchmarks - they show 4 and 5 comparisons. Seems to be significantly slower.
SimeVidas 6y ago
If anyone at webpack reads this, consider adding an RSS feed to your blog.
- montogeek 6y ago
  Interesting, it is not a blog per se. But we can build one, will take it into consideration.
- mminer 6y ago
  Seconded. RSS is how I stay abreast of project updates. For ones like Webpack that lack RSS, GitHub’s releases feed can be a substitute: https://github.com/webpack/webpack/releases.atom https://github.com/webpack/webpack/releases.atom
bichiliad 6y ago
I have to sing some praises for Webpack for a second. I work at a company with a large (> 10k files) old (> 10 years) JS codebase. It used to rely on a home-grown build tool, but making our builds both fast and modern took the time of multiple full-time engineers. Webpack isn't "fast" like Rust is fast, and it's not old enough to be as well-documented or understandable as I'd wish, but: 1. it is flexible enough to fit all of our weird edge cases. 2. it has a really solid community of people working on it. 3. it made adopting new features like TypeScript extremely simple for us. I don't see us upgrading from 4 to 5 eagerly (at least until it's been production-proven), but I'm excited about this release, and I love all the hard work that's gone into it. Congrats to the team — it's no small feat. Edit: formatting
- null_deref 6y ago
  I don't use webpack anymore, but I have to say it was nice reading your story, I aspire to build a product which users will appreciate like this.
- dailygrind___ 6y ago
  I can totally relate. I have been working on a similar codebase (6k modules), once built with Grunt and then migrated to Webpack. It has proven to be a mature tool.
simonw 6y ago
I've been putting off learning Webpack for far too long. Can anyone provide some kind of a syllabus to help me figure out what there is to learn about it, starting from almost no knowledge at all? I feel like it's a critical enough piece of modern web infrastructure that it's worth me taking the time to fully understand how to use it and what it's capable of.
- jiofih 6y ago
  Nah. EDIT: ok, some more context. You should be glad you haven’t had to deal with this shit show yet. Don’t walk willingly into it, there are much less painful tools like Rollup, Vite and Parcel around.
- faichai 6y ago
  This pretty much nails the problem with Webpack in my view. It doesn't seem to be based on any kind of strong, logical, easy to understand core, but instead is comprised of lots of interwoven threads of magic that no-one really understands. This makes any attempt to debug and solve problems with it a total nightmare, like crawling through a tar pit. You might make it, but you're gonna feel all sticky and dirty coming out the other side. That said, kudos to the developers, I use it every day, but I wish it were a lot simpler.
  - fendy3002 6y ago
    For me, I need webpack to make packs of "configuration set" that's easy to use. Let's say that one of them is react jsx to js "set", bundled with css, style, file and url loader. So for those who want to start with webpack and typescript react, they only need to use that "set", and define only the input/output.
    - martijnvds 6y ago
      So, a complicated Makefile?
- idointernet 6y ago
  https://survivejs.com/webpack/ https://survivejs.com/webpack/
ENGNR 6y ago
As someone who fought battles with webpack and webpack 2, I’ve since been pleasantly surprised that each upgrade has just gotten simpler and more stable, and I can progressively delete more of my own code as the features get built in. Big thanks to the maintainers!
spiderjerusalem 6y ago
The last time I tried to bump webpacker from 3 to 4 at <dayjob> was absolute hell. The fancy chunk splitting logic was spewing out non-deterministic bundles across different machines in our infra. Took a lot of deep digging in the internal graph representation to find the root cause. I gave a local related meetup talk, slides here. https://vheis.su/slides/curing-webpack-cancer/#11 https://vheis.su/slides/curing-webpack-cancer/#11
WesolyKubeczek 6y ago
So I guess it's safe now to try migrating a project from Webpack 3.x to 4.x?
anuila 6y ago
Version 5 and this tool still has absolutely awful UX. I have no problem configuring Webpack, but it's ridiculous that: - it needs two plugins to generate CSS files [1], when the homepage lists it as one of the supported outputs in front and center; [2] - it needs a plugin have a non-trash output log. [3] Parcel was supposed to fix the situation, and in many cases its UX is an order of magnitude better, but in exchange it brings a slew of unfixed bugs in the most simple projects that lightly sway from the base usage. Maybe in 2030 the JS community will have figured something out. 1: https://webpack.js.org/guides/asset-management/#loading-css https://webpack.js.org/guides/asset-management/#loading-css 2: https://webpack.js.org https://webpack.js.org 3: https://github.com/GoogleChromeLabs/size-plugin https://github.com/GoogleChromeLabs/size-plugin
- rado 6y ago
  Exactly my problem with it, it doesn’t just work with CSS, which is a part of the bigger problem seen above: equating Frontend with JS.
- sod 6y ago
  IMO it's the beauty of webpack that they are dogfooding their own APIs and even the basics are implemented as plugins & loaders. Maybe out there is a better way to design a bundler api. But up until now I only see a flood of one-click bundlers that cover the happy path.
emilsedgh 6y ago
We've been using Webpack for a number of years now with our massive webapp. A few months ago we started using esbuild for our development setups. Build times went from ~6 minutes to ~1. This is a sweet spot for us as esbuild is performing really well and made our development much easier. we still rely on webpack for our staging and production builds. The reason for this is esbuild doesn't support a variety of production necessary features (transpiling to older ES, uploading bundles to S3, etc) But I'm very happy with our "esbuild for development, webpack for deployments" process. Any reason other people are not taking a similar approach?
- manigandham 6y ago
  > "uploading bundles to S3" Why are you using the bundler to do that?
  - emilsedgh 6y ago
    Because it could and it knows my assets the best. Im sure there are alternative methods but with Webpack it's been super easy.
- earthboundkid 6y ago
  ESBuild will transpile to different versions of ES6. It won’t drop down to 5. I assert that you don’t need 5 support because you aren’t actually QAing IE11 and if you did, you’ll learn that it’s actually been broken and no one reported it.
  - emilsedgh 6y ago
    That may not be far from truth. Maybe I will have our people test IE11 and if it's not really working we'll drop it.
anderspitman 6y ago
The past year or so I've moved almost exclusively to backend at work (from Vue frontend) and simultaneously switched to vanilla JS for all new side projects. For those I use native ES modules heavily for internal code, and use very few external dependencies and import them as global scripts like a heretic. Heck I often don't even use npm for node projects anymore. For my latest project I'm even trying to make the entire interactive UI without any JS. I've sadly never done this. The sense of relief getting out of "modern" JS has been palpable. No more build steps. No endless dependabot PRs. No painful dependency updates. Just good clean fun development. There are tradeoffs. vdom frameworks really can add a lot of productivity vs hand-coding dom updates. But if I really need it I can use something like Mithril which still doesn't require a build step.
- nwienert 6y ago
  Ascetics brag about asceticism, vegans brag about veganism, the world turns. Didn’t the Buddha already teach us about the middle way?
  - anderspitman 6y ago
    Buddhists brag about Buddhism
    - sebmellen 6y ago
      Turtles all the way down
- manigandham 6y ago
  Why not just stick with Vue then? It runs with a script tag and no build step, and works with HTML templates by default.
- aniforprez 6y ago
  People tend to recommend alpinejs for very light js interactivity without a full framework. The tailwind folks use it a lot
- 6y ago
rmrfrmrf 6y ago
I saw this headline and kind of winced because I just finished doing battle with our webpack config(s), but top-level await, automatic Worker entry points, cjs tree shaking, and import.meta support are huge! I'm also grateful for the removal of Node polyfilling -- it tends to just add confusion when you're testing across different environments.
sabellito 6y ago
I will forever swear by parcel-bundler. That thing takes so much of the suck out of web dev.
- greggh 6y ago
  I came here to say the same thing. After my first tests with Parcel I haven't gone back to webpack again.
bostonvaulter2 6y ago
Am I the only one who was annoyed that they made the beta docs the main docs before version 5 was even released?
- WesolyKubeczek 6y ago
  Not only that, but also with every release links pointing to older versions stop working, breaking stackoverflow answers, blog posts, and a host of other things.
__s 6y ago
Doesn't work with new JSX transform of react & babel if you have "type": "module" in your package.json https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-... https://github.com/webpack/webpack/issues/11467 https://github.com/webpack/webpack/issues/11467 Seems rules: {test:/\.m?js$/,type:'javascript/auto',resolve:{enforceExtension:false,fullySpecify:false}} fixes Also nothing in this doc mentions that webpack -p no longer works, instead you need to spell it out webpack --mode=production
andy_ppp 6y ago
I was joking just the other day, could you imagine if someone you worked with came up with the set of design decisions that required webpack + Babel + node_modules ? You would think they were insane and laugh them out of the design meeting, even the company. Maybe it’s time for a reframing - which problem are we trying to solve?
- runarberg 6y ago
  Honest question: How is that any different from someone coming up with a set of design decisions that required rustc + cargo + crate modules in (target/*/deps)?
  - andy_ppp 6y ago
    Okay, so rustc is compiling rust to machine code. Here we have some advanced version of JavaScript (es7?) going through a series of compilations, asset extraction, tree shaking, dependency graphs that are 10000+ packages long etc. The solutions rust and cargo choose (like having a decent standard library to reduce deps) are all better. Rust is fast and worth paying a compilation prise for, is it worth it in JS so we can have shiny semantic sugar everywhere? I don’t know how crate modules works but hopefully each library needs you to specify versions of all dependencies at the top level rather than magically hiding modules you’re adding 5 levels deep. I could probably go on further if I knew rust better. The ecosystems are completely different IMO and webpack as a build system leads to complexity not clarity - its like a machine where an animal goes in and a sausage comes out, whereas other build systems are more logical in their steps.
    - anuila 6y ago
      Yes good luck shipping that main.rs to a web browser. The problem that Webpack solves is performance optimization in addition to what Rust offers: - writing in a higher-level language: "write modern code and ship to IE 5" is the same as "write in Rust and ship to x64" - take a bunch of files and make 1 or 2 out of it. Nobody stops you from loading jQuery and 3 plugins in a script tag and call it a day. Webpack exists because jQuery and 3 plugins can't deliver the same results nowadays. Also, do you want to improve your code with types and linting? Do that without Webpack, it's not going to be much more efficient. --- In short, Webpack and Babel basically match the Rust compiler in functionality. If you don't use them, your web app’s code will be harder to manage, not easier. That's all.
runarberg 6y ago
Reading through the comments here has been predictable. A lot of people complaining about the complexity of the front-end ecosystem. Too many tools, to much configuration, etc. I’d like to say that you don’t need that complexity. If you just want to write a dumb front-end you don’t need typescript, you don’t need babel, you don’t need pug, you don’t need webpack, etc. If these things bother you, just skip it. I always start my websites with a simple index.html file and run a `python -m http.server`. That is it. Modern JavaScript has a really good module system that works in all major browser (even Edge), and node. If you want to write type safe JavaScript you can write your types as doc comments and have typescript check it without bundling or compiling. You literally need only two tools to write a website: a browser and a text editor. I’m not here to tell you that people shouldn’t use these complex tools. Many people configure their front-end environment just fine with webpack, babel, typescript, etc. If they work better that way, that is fine. But if that bothers you, simply don’t do it. There is no reason for you to complain about it.
- jonahx 6y ago
  I like your advice, but I think there is a reason for the complaints. An indefensible complexity has become the new normal. And it's what many people are forced to suffer through at work. If having a chorus of complaining dissenters on HN threads sways even a small percentage of people to take simpler approaches, it has done some good.
  - tkzed49 6y ago
    When people are complaining about this kind of stuff at work, it raises the question of what the alternative is. The person you're replying to describes a great methodology for smaller projects, but in many cases there are great reasons to take on dependencies. Not taking a dependency means you pay in person-hours to reinvent it, and sometimes that cost is much higher than a couple extra seconds of build time. And, once you have a lot of dependencies, ES modules won't save you. People expect web apps to load fast, and code is big. Things like Webpack help make it a lot smaller. My point isn't that this is good, it's that it's not "indefensible". There are very real practical reasons that big companies deal with the debt of dependencies and bundlers.
twirlock 6y ago
Please save us, typescript devs.
kumarvvr 6y ago
I would encourage everyone to try out Blazor. It's shaping up to be quite nice and is great for a lot of apps. The paradigm and implementation is top notch. And its orders of magnitude better than programming in JS. If you are doing data intensive apps, complex data handling and all, doing it in C# is a pleasure.
preommr 6y ago
tl;dr Try parcel I've had some really horrible experiences with webpack. When I first started with it, it was daunting. Seriously, just look at the docs, it's pages upon pages of complex behavior. Some of it fairly unintuitive. It took me days to dive in, get used to it and kind of know what I was doing, and then promptly forget everything about I knew over the months/years. Everytime I have to dive into the webpack related config, I basically set aside a whole and feel a deep sense of dread. This isn't normal. Also, Webpack has horrible UX. At first I thought that was because it's complicated and covers a difficult problem space. But then I used parcel, which is leagues better in terms of usability. I absolutely love parcel and think it's so much better overall. Unfortunately, their team is much smaller and much less used so webpack is a couple more features that make it more "stable". Well actually, it goes both ways, but most of the time parcel has some very small error that webpack might not. Whic is why I basically run both at the same time - parcel for it's speed and ease of use, webpack to catch a lot of errors (like those outputted by ts) that for some reason parcel (1.x at least, I think 2.x is coming soon) doesn't catch.
ssijak 6y ago
Coding something in java/kotlin after months or years in only browser world is so relaxing. Maven (or Gradle) just works and upgrading packages is never a scary thing. And if update does break something, it is usually a small API change in some library which IDE will happily highlight for you with a red squiggly line. And what I love about Java is that you have very stable libraries for everything, where as in javascript world of you don’t touch it for a year your already a dinosaur.
asdf-asdf-asdf 6y ago
it is really frustrating to read infinite variations of the comment "javascript development is too complicated", "it is much simpler in other languages" etc. yes, it is complicated. the problem is, there are certain constraints that we just cannot ignore: we want to write code in a "normal", efficient way (code organized in namespaced modules, perphaps static typing etc.), but we need it to be executed by the web-browser, maybe an old version of a web-browser. so we need solutions that work with these constraints. if you know about simpler solutions, i'm very interested hearing about them. but please note, it has to work with those constraints, so ideas like "just write a native application" does not help.
brodock 6y ago
I wish we all were using swc.rs by now. Last time I checked it was still relying on nightly rust, but it seems not anymore. This we I saw someone complaining that webpack-dev-server was taking 4.5GB (not a mistake) to "concatenate strings for older browsers" in a fairly large codebase. There is just no excuse for that.

250 points by marksamman 6y ago

"There is a good chance that upgrading fails and you would need to give it a second or 3rd try." Sad that this has almost become the norm when developing in the modern javascript ecosystem. I dread touching those projects and creating one even more because stuff just rots away and your app might break in days, weeks or If you are lucky months. I'm sure there are better developers out there that can handle all of this and know how to avoid it, but a bozo like me does not. This is actually causing me stress irl.

vmception 6y ago
Oh thats because you are missing the specific version manager for each part of your build toolchain And dont forget to make a script that automatically sets the right versions of npm, webpack, and python all at once! This is fine, I am okay with the events that are unfolding currently.
- zdragnar 6y ago
  If you have multiple projects of almost any language that are stuck on different versions, you basically end up with the same problem and solution. I will definitely keep my version managers, thank you very much.
- haar 6y ago
  I've been using ASDF (https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf) for a while now to manage each of the language (and sometimes build tool) versions for a folder/repo in a consistent manner. I'd definitely recommend taking a look at it.
- vangelis 6y ago
  How do you manage your version managers?
throwanem 6y ago
The way you avoid problems with a .0.0 release is by not upgrading to a .0.0 release. You would have to do that by hand; npm and yarn have been pinning major versions for a long time now, so that upgrade only happens when you do it by hand. So if you don't want to deal with breaking changes, all you have to do is nothing. Meantime webpack 4 is not going anywhere.
- SilasX 6y ago
  I'm reminded of when npm released 5.7.0 (which some got upgraded to automatically because it wasn't tagged as pre-release) and had a critical bug that deleted your system files. https://news.ycombinator.com/item?id=16435305 https://news.ycombinator.com/item?id=16435305
  - throwanem 6y ago
    Why? What on Earth do you imagine that having to do with this?
    - SilasX 6y ago
      It was a new version (with significant nasty surprises), albeit .7.0 instead of .0.0.
      - throwanem 6y ago
        It was a new minor version, of a totally different package, which was version-tagged in such a way that some distro packagers picked it up when they shouldn't have, and which happened to contain a bug affecting a use case that's been deprecated for at least half a decade now. Look, I get that there's a lot of hate for modern JS, and it's hardly as if there is any lack of basis for criticism, just as there is with every other highly active, heavily adopted, and fast-evolving software ecosystem. But mistaking this kind of uninformed slagging for meaningful commentary says more about the person who does it than about the subject of their ire.
tqkxzugoaupvwqr 6y ago
It helps to pin dependencies so that only the exact specified version is downloaded/installed/used. I recently updated the dependencies of a frontend project. `vue-apollo` from version 3.0.3 to 3.0.4 had a breaking change. The discussion in the commit on GitHub proposed to release it as v4. But in the dev’s mind it was a fix so he released it as a patch version.
root_axis 6y ago
Why do you feel the need to upgrade to webpack 5? What particular feature do you need that justifies the upgrade?
- fedlarm 6y ago
  For me the module federation is a new feature that I can take advantage of to improve integrations.
sinker 6y ago
So far what I've been doing is keeping my webpack config as simple as possible (< 40 lines) and just relying on default behavior. I know I'm losing out by not bothering with some of the more intricate configuration properties like caching, etc. But one of my big pet peeves is when you clone a project and the installation says all you need to do is run make install or npm i, but in reality requires 20 google searches and an hour of banging your head to get the project running and even then you end up with 50 cryptic warning messages in your terminal so you don't even know if you did it correctly. With a very simple webpack config you might lose out on optimizations but at least you can get just about anyone running a project locally and if things go awry you can generally pinpoint the problem to a specific line of configuration.
- nicoburns 6y ago
  I've found that a slightly longer (~100 lines) webpack config allows me to use all the caching and fancy tricks I want and is still just as debuggable. I think the main thing is setting it up yourself so you know what all the plugins/settings do.
  - nwienert 6y ago
    The key is don’t abstract it. No function builders, one big object with inline conditional spreads.
  - zamber 6y ago
    Caching was a major dissapointment for me. DllPlugin is a nightmare to setup and other caching plugins I tried don't really speed things up. What eventually worked for me is HardSourceWebpackPlugin [1] - two lines added and went from 2min to 15s (with a tradeoff of a slightly longer initial build). [1] - https://github.com/mzgoddard/hard-source-webpack-plugin https://github.com/mzgoddard/hard-source-webpack-plugin
    - nicoburns 6y ago
      Not sure on the specifics, but my understanding is that the major improvements in Webpack 5 are related to caching.
jakub_g 6y ago
Webpack is kind of more "build your own bundler" than a bundler. The configurability and extensibility is immense and with that level of complexity, it's guaranteed things won't work smoothly for everyone (incompatible plugins, unexpected configurations etc.). Anyway, every big project always has hiccups with new major X.0.0 release. Think about your own code for a second. It's typically a well defined code that doesn't have to accommodate a combinatorial explosion of configurations. It is bug free? Keep in mind that 90% of code is written by one guy. It's not Webpack Corp. with a legion of QA testers.
- setr 6y ago
  Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Or they're running things in parallel, and encountering data races and such, and randomly working as a result. But the real concern is that they don't really know what a correct installation looks like, or they'd just check-and-retry on a loop until it succeeded (the easiest hack around such problems)
  - ENGNR 6y ago
    I think it’s more if 5.0.0 doesn’t work the first time, you could simply let the community find those issues for you and by 5.0.xx it will mostly likely cover your specific setup (except for the documented api changes)
  - jayflux 6y ago
    > Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Maybe we’ve interpreted that message in different ways, but I took it to mean you may need to try it again at a later date once the community have fixed those issues/bugs. I don’t think they meant literally 3 runs of the same setup. They’re still working through stuff so there may be edge cases for some where 5 won’t work right now.
jacob019 6y ago
I know the feeling. It's not just modern stuff, I have an old ExtJS app that I dread to update. The best solution I have found is a dev / build environment in a dedicated VM that I can spin up once or twice a year to make updates. Bringing libraries up to date is a fucking nightmare and often a waste of time. For continuously updated apps I have moved away from complicated build processes. Most web apps are fine without a build process, I think there is a lot of premature optimization going on.
- cjauvin 6y ago
  I too maintain an old and complex ExtJS 4.1 app and I never dared upgrading the framework. I carry a big zip around and it will be that until the end of its life or when I finally decide to rewrite it using React. For such an old framework it’s surprisingly bug free though.
ronaldj 6y ago
Configuring the modern JS toolkit (webpack, Babel, your framework of choice, Jest, etc) is such a pain. I’ve been doing front-end for 10+ years. You’re probably not a bozo.
- folkhack 6y ago
  Same, and it's just layer on layer of extra tooling and complexity. Typescript, Babel, Webpack, JSX, TSX, etc, etc. It gets in the way of development as much as it helps.
  - cookiengineer 6y ago
    ... And suddenly, you want to insert your UI components of choice and you end up with segfault errors of node-gyp. Then you decide that not giving a damn is the sane option to maintain codebases.
    - gfodor 6y ago
      Yeah not-giving-a-damn-driven-development is also the only way to stay sane and not be over come with paralysis from being surrounded by a thousand broken windows in need of fixing.
      - ficklepickle 6y ago
        Arguably not giving a damn caused the problem in the first place
  - searchableguy 6y ago
    Deno does away with most of the tooling configuration. You get linter, bundler, docs generator, formatter, watcher, version manager, std library, inbuilt tests, and many things that you would otherwise source from third parties in node ecosystem. Support for webgpu and local storage incoming. Makes it a delight to write scripts. You can also scope them by permission. https://deno.land/ https://deno.land/ Great community: https://discord.gg/deno https://discord.gg/deno
GordonS 6y ago
I frequently have to rerun `npm i` when it fails for seemingly spurious reasons. We used to laugh at Windows years ago, when the solution was so often "turn it off and on again", but it's basically what you need to constantly do with tools like npm and webpack.
- nicoburns 6y ago
  Yarn is much better in this regard. I'd thoroughly recommend it. It's drop-in compatible (except it will generate it's own lock file), so it's pretty easy to try it.
  - sebmellen 6y ago
    Yarn also gives much cleaner output. NPM is extremely verbose, but it seems that "verbosity" doesn't really confer any benefit. And yarn is also generally much faster.
  - pwdisswordfish4 6y ago
    "Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right."
hsbauauvhabzb 6y ago
Out of curiosity is patching and updating all packages also a common consistent issue? Is there regularly breaking changes?
- zamber 6y ago
  Depends on what packages you use and how well they do semver. Chances are you will get major version bumps for most of your dependencies after 1-2 years of development. What works well then is to do upgrades partially. Each major library separately, fix issues, go with the next one. Otherwise it's hard(er) to track what breaks your app. My current project has 100 dependencies and 150 devDependencies. Upgrading takes a week if not longer for one experienced dev. We tend to do it every 3-4 months.
SoSoRoCoCo 6y ago
> modern javascript ecosystem. I recently was convinced to start using a packer (webpack, parcel) and was blown away by the hoops people have to jump through to make stuff work. I've been spending an hour or so a day coming up to speed for the past few weeks, and every yarn/npm package I installed had some kind of error/warning that required a hack, or version contortion. I naively thought I could webpack with electron+vue+pug+ts and was soundly smacked down repeatedly, even after trying the boilerplate from each components' docs. I appreciate what the developers are trying to do, I really do. Only, it is too many cooks + death by a thousand cuts. As I read through pages of closed-but-not-really GitHub issues for each package, sometimes going back years and years, it feels like a constant stream of hacking that erodes the well-intentioned first versions. > but a bozo like me does not. This is actually causing me stress irl. Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above.
- earthboundkid 6y ago
  To me what’s interesting is that ESBuild (which is a Go based JavaScript bundler) has come out of nowhere in a relatively short period of time, and it’s basically already better than any of the existing JS JS bundlers. Not just faster: it also has a radically simpler UI.
  - dntrkv 6y ago
    That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.
    - ch4s3 6y ago
      They usually have fewer features as well, and not having to support features with weird edge cases always helps.
  - 6y ago
pknopf 6y ago
jQuery and full-page postbacks are my go-to, unless there is an actual need to introduce something else (React, etc). I'm usually conservative in the tools I choose, but I have to be especially conservative with js.
- darepublic 6y ago
  Full page postbacks are not necessary even if you want to go zero dep
  - pknopf 6y ago
    Most of the time, it isn't very useful to have javascript even exist, even though there isn't 3rd party dep. For example, have you even been in the settings areas of GitHub and thought "I wish there was more async here!"? In ASP.NET MVC, doing full postbacks means very simple controllers/actions/views that a junior could understand.
manigandham 6y ago
It's specifically the frontend ecosystem. A problem caused by the numerous languages, assets, and formats that have to come together, the lack of JS standard library, poor module system, and the disaster of browser compatibility mixed with transpilers, polyfills. Webpack has already had zero/very-little config required by default. That's what most should use, and that's if you even need to use Webpack directly. Otherwise I recommend sticking to the major site frameworks like Next/Nuxt/Gatsby and let those do all the config wiring for you.
hankstenberg 6y ago
Started my first React Native app some time ago and I can totally confirm that. It feels like a jungle of very fragile dependencies and mechanisms between code and output.
- lukeramsden 6y ago
  Yes RN is certainly the worst for that for me. I can't count how many hours I've had to put in to wrangle the RN packager in to a monorepo with TypeScript and code-sharing across packages, and it's still unbelievably fragile and I can't actually share components between them. At this point I've made so many little alterations to the config from GitHub issues and StackOverflow answers that I literally have no idea how it works or how to replicate it to a new project. It's an absolute nightmare.
d13 6y ago
We’ve banned npm install: It’s simply a party drug and completely unnecessary.
- deleted 6y ago
  [deleted]
madeofpalk 6y ago
This is why I’m such a fan of the meta-bundlers/frameworks, like create-react-app or Next.js I like the features that we pack gives me, but knowing webpack and spending the effort on configuring it just seems like a waste. I’m incredibly grateful for the CRA maintainers to handle that for me.
- zamber 6y ago
  That works until your team doesn't decide to eject because they want to play around with webpack...
  - madeofpalk 6y ago
    Of course! Then you're just in the same hellish landscape of having to learn and maintain webpack configs, which "you" completely opted into!
btbuildem 6y ago
Once I had the freedom to decide, I gave up on using most of the standard Javascript ecosystem stuff in my front-end projects. No node, no npm_modules, no build chain. I'm lucky to be able to get away with that. It is incredibly efficient, not only because it no longer gets in the way of what I'm trying to build. The previous team I was on, we spent roughly 15% of our time tending to these things.
noway421 6y ago
Webpack itself is quite low level. `react-native init` or `create-react-app` gives you the ready to use developing environment and updating that is usually a breeze.
thelarkinn 6y ago
Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship major versions+bring new features. You don't have to use them, you can just use webpack's zero config out of the box.

acemarke 6y ago

Next.js 9.5 added opt-in support for Webpack 5: https://nextjs.org/blog/next-9-5 https://nextjs.org/blog/next-9-5 and looks like Create-React-App plans to support Webpack 5 in an upcoming CRA 4.1 release (4.0 is in alpha now): https://github.com/facebook/create-react-app/issues/9613#issuecomment-689405958 https://github.com/facebook/create-react-app/issues/9613#iss...

tunesmith 6y ago
I believe the opt-in support only works if you use yarn, is that right? I didn't think npm supported resolutions.

Waterluvian 6y ago

I’m scrolling and scrolling waiting for a paragraph that tries to sell me on why I’d bother and risk upgrading. I think the best I got were patch notes. Any good reason to upgrade?

acemarke 6y ago
Per https://webpack.js.org/blog/2020-10-10-webpack-5-release/#general-direction https://webpack.js.org/blog/2020-10-10-webpack-5-release/#ge... : - Improve build performance with Persistent Caching. - Improve Long Term Caching with better algorithms and defaults. - Improve bundle size with better Tree Shaking and Code Generation. - Improve compatibility with the web platform. - Clean up internal structures that were left in a weird state while implementing features in v4 without introducing any breaking changes. - Prepare for future features by introducing breaking changes now, allowing us to stay on v5 for as long as possible
- randtrain34 6y ago
  Are there any benchmarks to get a rough idea on how much improvement in all these areas we can expect to get by upgrading?
  - xwdv 6y ago
    The only benchmark that matters is how much more money you will make from customers after upgrading.
    - dmitryminkovsky 6y ago
      Put that coffee down! Coffee is for closers only.
- lhnz 6y ago
  I've heard that build performance is actually worse than webpack 4, if you're not using persistent caching. See: https://twitter.com/FredKSchott/status/1314220659984146432 https://twitter.com/FredKSchott/status/1314220659984146432

nikivi 6y ago

Eventually the packing part can be done in a compiled language. https://github.com/evanw/esbuild https://github.com/evanw/esbuild is very fast at doing some things already but not others. And I guess webpack wins because you can configure it to do anything easily already? And with compiled languages 'configurability' is hard to do?

Jarred 6y ago

The incremental build time improvements look great. Did the cold build times get slower? This tweet shows a benchmark that makes it seem like cold build times got slower in Webpack 5 https://twitter.com/evanwallace/status/1314121407903617025?s=21 https://twitter.com/evanwallace/status/1314121407903617025?s...

deleted 6y ago
[deleted]
moltar 6y ago
I think so. Look at esbuilt benchmarks - they show 4 and 5 comparisons. Seems to be significantly slower.

SimeVidas 6y ago

If anyone at webpack reads this, consider adding an RSS feed to your blog.

montogeek 6y ago
Interesting, it is not a blog per se. But we can build one, will take it into consideration.
mminer 6y ago
Seconded. RSS is how I stay abreast of project updates. For ones like Webpack that lack RSS, GitHub’s releases feed can be a substitute: https://github.com/webpack/webpack/releases.atom https://github.com/webpack/webpack/releases.atom

bichiliad 6y ago

I have to sing some praises for Webpack for a second. I work at a company with a large (> 10k files) old (> 10 years) JS codebase. It used to rely on a home-grown build tool, but making our builds both fast and modern took the time of multiple full-time engineers. Webpack isn't "fast" like Rust is fast, and it's not old enough to be as well-documented or understandable as I'd wish, but: 1. it is flexible enough to fit all of our weird edge cases. 2. it has a really solid community of people working on it. 3. it made adopting new features like TypeScript extremely simple for us. I don't see us upgrading from 4 to 5 eagerly (at least until it's been production-proven), but I'm excited about this release, and I love all the hard work that's gone into it. Congrats to the team — it's no small feat. Edit: formatting

null_deref 6y ago
I don't use webpack anymore, but I have to say it was nice reading your story, I aspire to build a product which users will appreciate like this.
dailygrind___ 6y ago
I can totally relate. I have been working on a similar codebase (6k modules), once built with Grunt and then migrated to Webpack. It has proven to be a mature tool.

simonw 6y ago

I've been putting off learning Webpack for far too long. Can anyone provide some kind of a syllabus to help me figure out what there is to learn about it, starting from almost no knowledge at all? I feel like it's a critical enough piece of modern web infrastructure that it's worth me taking the time to fully understand how to use it and what it's capable of.

jiofih 6y ago
Nah. EDIT: ok, some more context. You should be glad you haven’t had to deal with this shit show yet. Don’t walk willingly into it, there are much less painful tools like Rollup, Vite and Parcel around.
faichai 6y ago
This pretty much nails the problem with Webpack in my view. It doesn't seem to be based on any kind of strong, logical, easy to understand core, but instead is comprised of lots of interwoven threads of magic that no-one really understands. This makes any attempt to debug and solve problems with it a total nightmare, like crawling through a tar pit. You might make it, but you're gonna feel all sticky and dirty coming out the other side. That said, kudos to the developers, I use it every day, but I wish it were a lot simpler.
- fendy3002 6y ago
  For me, I need webpack to make packs of "configuration set" that's easy to use. Let's say that one of them is react jsx to js "set", bundled with css, style, file and url loader. So for those who want to start with webpack and typescript react, they only need to use that "set", and define only the input/output.
  - martijnvds 6y ago
    So, a complicated Makefile?
idointernet 6y ago
https://survivejs.com/webpack/ https://survivejs.com/webpack/

ENGNR 6y ago

As someone who fought battles with webpack and webpack 2, I’ve since been pleasantly surprised that each upgrade has just gotten simpler and more stable, and I can progressively delete more of my own code as the features get built in. Big thanks to the maintainers!

spiderjerusalem 6y ago

The last time I tried to bump webpacker from 3 to 4 at <dayjob> was absolute hell. The fancy chunk splitting logic was spewing out non-deterministic bundles across different machines in our infra. Took a lot of deep digging in the internal graph representation to find the root cause. I gave a local related meetup talk, slides here. https://vheis.su/slides/curing-webpack-cancer/#11 https://vheis.su/slides/curing-webpack-cancer/#11

WesolyKubeczek 6y ago

So I guess it's safe now to try migrating a project from Webpack 3.x to 4.x?

anuila 6y ago

Version 5 and this tool still has absolutely awful UX. I have no problem configuring Webpack, but it's ridiculous that: - it needs two plugins to generate CSS files [1], when the homepage lists it as one of the supported outputs in front and center; [2] - it needs a plugin have a non-trash output log. [3] Parcel was supposed to fix the situation, and in many cases its UX is an order of magnitude better, but in exchange it brings a slew of unfixed bugs in the most simple projects that lightly sway from the base usage. Maybe in 2030 the JS community will have figured something out. 1: https://webpack.js.org/guides/asset-management/#loading-css https://webpack.js.org/guides/asset-management/#loading-css 2: https://webpack.js.org https://webpack.js.org 3: https://github.com/GoogleChromeLabs/size-plugin https://github.com/GoogleChromeLabs/size-plugin

rado 6y ago
Exactly my problem with it, it doesn’t just work with CSS, which is a part of the bigger problem seen above: equating Frontend with JS.
sod 6y ago
IMO it's the beauty of webpack that they are dogfooding their own APIs and even the basics are implemented as plugins & loaders. Maybe out there is a better way to design a bundler api. But up until now I only see a flood of one-click bundlers that cover the happy path.

emilsedgh 6y ago

We've been using Webpack for a number of years now with our massive webapp. A few months ago we started using esbuild for our development setups. Build times went from ~6 minutes to ~1. This is a sweet spot for us as esbuild is performing really well and made our development much easier. we still rely on webpack for our staging and production builds. The reason for this is esbuild doesn't support a variety of production necessary features (transpiling to older ES, uploading bundles to S3, etc) But I'm very happy with our "esbuild for development, webpack for deployments" process. Any reason other people are not taking a similar approach?

manigandham 6y ago
> "uploading bundles to S3" Why are you using the bundler to do that?
- emilsedgh 6y ago
  Because it could and it knows my assets the best. Im sure there are alternative methods but with Webpack it's been super easy.
earthboundkid 6y ago
ESBuild will transpile to different versions of ES6. It won’t drop down to 5. I assert that you don’t need 5 support because you aren’t actually QAing IE11 and if you did, you’ll learn that it’s actually been broken and no one reported it.
- emilsedgh 6y ago
  That may not be far from truth. Maybe I will have our people test IE11 and if it's not really working we'll drop it.

anderspitman 6y ago

The past year or so I've moved almost exclusively to backend at work (from Vue frontend) and simultaneously switched to vanilla JS for all new side projects. For those I use native ES modules heavily for internal code, and use very few external dependencies and import them as global scripts like a heretic. Heck I often don't even use npm for node projects anymore. For my latest project I'm even trying to make the entire interactive UI without any JS. I've sadly never done this. The sense of relief getting out of "modern" JS has been palpable. No more build steps. No endless dependabot PRs. No painful dependency updates. Just good clean fun development. There are tradeoffs. vdom frameworks really can add a lot of productivity vs hand-coding dom updates. But if I really need it I can use something like Mithril which still doesn't require a build step.

nwienert 6y ago
Ascetics brag about asceticism, vegans brag about veganism, the world turns. Didn’t the Buddha already teach us about the middle way?
- anderspitman 6y ago
  Buddhists brag about Buddhism
  - sebmellen 6y ago
    Turtles all the way down
manigandham 6y ago
Why not just stick with Vue then? It runs with a script tag and no build step, and works with HTML templates by default.
aniforprez 6y ago
People tend to recommend alpinejs for very light js interactivity without a full framework. The tailwind folks use it a lot
6y ago

rmrfrmrf 6y ago

I saw this headline and kind of winced because I just finished doing battle with our webpack config(s), but top-level await, automatic Worker entry points, cjs tree shaking, and import.meta support are huge! I'm also grateful for the removal of Node polyfilling -- it tends to just add confusion when you're testing across different environments.

sabellito 6y ago

I will forever swear by parcel-bundler. That thing takes so much of the suck out of web dev.

greggh 6y ago
I came here to say the same thing. After my first tests with Parcel I haven't gone back to webpack again.

bostonvaulter2 6y ago

Am I the only one who was annoyed that they made the beta docs the main docs before version 5 was even released?

WesolyKubeczek 6y ago
Not only that, but also with every release links pointing to older versions stop working, breaking stackoverflow answers, blog posts, and a host of other things.

__s 6y ago

Doesn't work with new JSX transform of react & babel if you have "type": "module" in your package.json https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-... https://github.com/webpack/webpack/issues/11467 https://github.com/webpack/webpack/issues/11467 Seems rules: {test:/\.m?js$/,type:'javascript/auto',resolve:{enforceExtension:false,fullySpecify:false}} fixes Also nothing in this doc mentions that webpack -p no longer works, instead you need to spell it out webpack --mode=production

andy_ppp 6y ago

I was joking just the other day, could you imagine if someone you worked with came up with the set of design decisions that required webpack + Babel + node_modules ? You would think they were insane and laugh them out of the design meeting, even the company. Maybe it’s time for a reframing - which problem are we trying to solve?

runarberg 6y ago
Honest question: How is that any different from someone coming up with a set of design decisions that required rustc + cargo + crate modules in (target/*/deps)?
- andy_ppp 6y ago
  Okay, so rustc is compiling rust to machine code. Here we have some advanced version of JavaScript (es7?) going through a series of compilations, asset extraction, tree shaking, dependency graphs that are 10000+ packages long etc. The solutions rust and cargo choose (like having a decent standard library to reduce deps) are all better. Rust is fast and worth paying a compilation prise for, is it worth it in JS so we can have shiny semantic sugar everywhere? I don’t know how crate modules works but hopefully each library needs you to specify versions of all dependencies at the top level rather than magically hiding modules you’re adding 5 levels deep. I could probably go on further if I knew rust better. The ecosystems are completely different IMO and webpack as a build system leads to complexity not clarity - its like a machine where an animal goes in and a sausage comes out, whereas other build systems are more logical in their steps.
  - anuila 6y ago
    Yes good luck shipping that main.rs to a web browser. The problem that Webpack solves is performance optimization in addition to what Rust offers: - writing in a higher-level language: "write modern code and ship to IE 5" is the same as "write in Rust and ship to x64" - take a bunch of files and make 1 or 2 out of it. Nobody stops you from loading jQuery and 3 plugins in a script tag and call it a day. Webpack exists because jQuery and 3 plugins can't deliver the same results nowadays. Also, do you want to improve your code with types and linting? Do that without Webpack, it's not going to be much more efficient. --- In short, Webpack and Babel basically match the Rust compiler in functionality. If you don't use them, your web app’s code will be harder to manage, not easier. That's all.

runarberg 6y ago

Reading through the comments here has been predictable. A lot of people complaining about the complexity of the front-end ecosystem. Too many tools, to much configuration, etc. I’d like to say that you don’t need that complexity. If you just want to write a dumb front-end you don’t need typescript, you don’t need babel, you don’t need pug, you don’t need webpack, etc. If these things bother you, just skip it. I always start my websites with a simple index.html file and run a `python -m http.server`. That is it. Modern JavaScript has a really good module system that works in all major browser (even Edge), and node. If you want to write type safe JavaScript you can write your types as doc comments and have typescript check it without bundling or compiling. You literally need only two tools to write a website: a browser and a text editor. I’m not here to tell you that people shouldn’t use these complex tools. Many people configure their front-end environment just fine with webpack, babel, typescript, etc. If they work better that way, that is fine. But if that bothers you, simply don’t do it. There is no reason for you to complain about it.

jonahx 6y ago
I like your advice, but I think there is a reason for the complaints. An indefensible complexity has become the new normal. And it's what many people are forced to suffer through at work. If having a chorus of complaining dissenters on HN threads sways even a small percentage of people to take simpler approaches, it has done some good.
- tkzed49 6y ago
  When people are complaining about this kind of stuff at work, it raises the question of what the alternative is. The person you're replying to describes a great methodology for smaller projects, but in many cases there are great reasons to take on dependencies. Not taking a dependency means you pay in person-hours to reinvent it, and sometimes that cost is much higher than a couple extra seconds of build time. And, once you have a lot of dependencies, ES modules won't save you. People expect web apps to load fast, and code is big. Things like Webpack help make it a lot smaller. My point isn't that this is good, it's that it's not "indefensible". There are very real practical reasons that big companies deal with the debt of dependencies and bundlers.

twirlock 6y ago

Please save us, typescript devs.

kumarvvr 6y ago

I would encourage everyone to try out Blazor. It's shaping up to be quite nice and is great for a lot of apps. The paradigm and implementation is top notch. And its orders of magnitude better than programming in JS. If you are doing data intensive apps, complex data handling and all, doing it in C# is a pleasure.

preommr 6y ago

tl;dr Try parcel I've had some really horrible experiences with webpack. When I first started with it, it was daunting. Seriously, just look at the docs, it's pages upon pages of complex behavior. Some of it fairly unintuitive. It took me days to dive in, get used to it and kind of know what I was doing, and then promptly forget everything about I knew over the months/years. Everytime I have to dive into the webpack related config, I basically set aside a whole and feel a deep sense of dread. This isn't normal. Also, Webpack has horrible UX. At first I thought that was because it's complicated and covers a difficult problem space. But then I used parcel, which is leagues better in terms of usability. I absolutely love parcel and think it's so much better overall. Unfortunately, their team is much smaller and much less used so webpack is a couple more features that make it more "stable". Well actually, it goes both ways, but most of the time parcel has some very small error that webpack might not. Whic is why I basically run both at the same time - parcel for it's speed and ease of use, webpack to catch a lot of errors (like those outputted by ts) that for some reason parcel (1.x at least, I think 2.x is coming soon) doesn't catch.

ssijak 6y ago

Coding something in java/kotlin after months or years in only browser world is so relaxing. Maven (or Gradle) just works and upgrading packages is never a scary thing. And if update does break something, it is usually a small API change in some library which IDE will happily highlight for you with a red squiggly line. And what I love about Java is that you have very stable libraries for everything, where as in javascript world of you don’t touch it for a year your already a dinosaur.

asdf-asdf-asdf 6y ago

it is really frustrating to read infinite variations of the comment "javascript development is too complicated", "it is much simpler in other languages" etc. yes, it is complicated. the problem is, there are certain constraints that we just cannot ignore: we want to write code in a "normal", efficient way (code organized in namespaced modules, perphaps static typing etc.), but we need it to be executed by the web-browser, maybe an old version of a web-browser. so we need solutions that work with these constraints. if you know about simpler solutions, i'm very interested hearing about them. but please note, it has to work with those constraints, so ideas like "just write a native application" does not help.

brodock 6y ago

I wish we all were using swc.rs by now. Last time I checked it was still relying on nightly rust, but it seems not anymore. This we I saw someone complaining that webpack-dev-server was taking 4.5GB (not a mistake) to "concatenate strings for older browsers" in a fairly large codebase. There is just no excuse for that.