Webpack 5
webpack.js.org
webpack.js.org
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.
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.
I will definitely keep my version managers, thank you very much.
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.
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.
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.
[1] - https://github.com/mzgoddard/hard-source-webpack-plugin
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.
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)
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.
Typescript, Babel, Webpack, JSX, TSX, etc, etc.
It gets in the way of development as much as it helps.
Then you decide that not giving a damn is the sane option to maintain codebases.
Support for webgpu and local storage incoming. Makes it a delight to write scripts. You can also scope them by permission.
Great community: https://discord.gg/deno
Node was once thought to be the cleaner alternative that had a lot of these features built in, it was the supposed savior of Javascript, and now look at where we are.
This will lend itself to reproducing similar issues as they currently have.
I am primarily a javascript developer, I've written both Node and Deno projects, but I don't see the issues being solved by just rewrapping the source output.
I wrote a CLI tool to try it out. It monitors CPU/GPU temps then generates an HTML chart on SIGINT.
I like top-level await, the standard library and first-class typescript support.
I do wish the sandboxing was more granular. My small CLI tool requires: --allow-read --allow-write --allow-run and --unstable. I only need a read/write in a single directory, run a single binary. Unstable is required for signal handling, but that shouldn't be the case forever.
I'm glad someone is re-imagining JS/TS on the back end. A robust and stable standard library could well improve the dependency hell and broken projects issues.
But then I look at all the troubles the kids have with their fragile, short-lived tools. I recognise short-sighted design decisions they’re making because they’re being pushed into them by some shiny new library. I notice that many of those tools and libraries have big names behind them, and that the Zeitgeist people think you’re weird if you’re not using them, and remind myself that these things are only ever means to an end, no matter how popular they become.
Of course it’s useful to keep generally aware of what’s happening in the industry and from time to time a genuine improvement does come along. However, there is definitely a difference between not keeping up and not wasting your time repeating past mistakes or following blind alleys that often end up at dead ends.
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.
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.
I have written JS since 1997 and kept up with ES6 and so on over the years. Used it in frontend until now.
The JavaScript-ecosystem just isn't very productive [1] for multiple reasons. The language is untyped. You have no multi-threading. It's hard to debug. You have to spend many brain-cycles on learning Browser-problems, which muddles your understanding of the language. The web-way of: we can fix it and everyone will reload the browser, leads to a "don't care" attitude.
For web/backend this is approachable, though still not good.
For build-systems this is terrible. Why? Because if a bug shows up in a build-system you stop a million developers from being productive. The bug won't get fixed right away, most will just work around it, use different plugins, copy/paste yet another webpack config etc.
Plus JavaScript tends makes people realized what FP is, and they all start putting functions in their functions and making everything modular and plugin-able. (See high-order-components in React). While this can be nice, it leads to even more confusing bugs.
Writing plugin-architectures is hard in any language. Writing it in JavaScript is a recipe for disaster. Hence the modern JS-ecosystem.
[1]
Google: nullpointerexception -> 4.360.000 results
Google: undefined is not a function -> 800.000.000 results> Google: undefined is not a function -> 800.000.000 results
You didn't put quotation marks around the second, and the first has no spaces, so this is not a fair comparison. "undefined is not a function" with the quotation marks has 449,000 results.
I don't doubt that there are many results for "undefined is not a function", but I feel quite confident saying there aren't anywhere near 449,000. If you ask google for just 111 of them, you'll get "In order to show you the most relevant results, we have omitted some entries very similar to the 110 already displayed."
This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.
And don't forget Parcel which also have the simplest possible UI.
What it _doesn't_ do currently is provide an API which would allow it to be plugged in a similar way to Webpack (not exactly the same, as the deliberate aim is not to cover every usecase, as Webpack allows). This is a requirement for wider adoption as a competitor (rather than just as the module bundling step). Plus the tree shaking needs work, though I think that is less important than has sometimes been made out.
Parcel may have a simple API for simple things, but it's extremely slow and generally suffers from exactly the same issues outlined by OP.
To all package manager developers: make sure you have a rollback function, and make sure it is flawless.
However, it is also a tool for one job: bundling. If you also want to do things like unit testing or running any sort of linter or style checker over your code, you probably need to figure out how to get those tools to read your TS or ES20xx code as well. You might still need a handful of additional libraries to implement your test suite. You might still need to configure your preferred style and which rules you want to enforce in your static analyser(s).
So even if Parcel was flawless about installing what you needed for your dev and production builds automatically, you’d still end up needing to install a bunch of other tools and write a bunch of other configuration files. The overall efficiency of setting up a realistic development environment, even using Parcel, is still limited by a kind of Amdahl’s Law problem.
I'm usually conservative in the tools I choose, but I have to be especially conservative with js.
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.
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.
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.
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.
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.
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.
npx @vue/cli@latest create my-project
I suspect much of the complain about the complexity of the front-end ecosystem comes from people that either a) don’t do front-end regularly and are trying to build a website for them self but get bad advice for the tools needed, or b) are backend developers at work and think they know better about the front-end then their front-end counterparts. In the case of (a), they simply just need better advice on tooling (and which tools are an overkill), the tone of my original comment was more directed at the other group (b; although the advice I gave was for the former group—whoops).
This just hides all the complexity behind a yet another layer of abstractions.
The moment something breaks due to a minor upgrade, you're screwed.
After working at small shops managing frontends with 1-2 other people and then moving to frontends managed by larger numbers and divisions, especially in a culture of moving quickly, things can get hairy quite fast.
Even so, it helps to make a habit of revisiting things from first principles and to also assume the beginner’s mind, collectively, to work towards more refined, elegant, simpler systems/modules based on lessons of the past.
Speaking of “normals”... it used to be normal for most people to be undernourished. Now, the normal is that the majority of people in many developed countries are overfed. And overstimulated.
Same with the code we write.
Overfed. Overstimulated.
The dangers of prosperity and excess!
But at least we have the opportunity to focus and sharpen our realities.
... Anyway, back to Webpack. Webpack is great. It is one such system that went through a lot of growing pains and complexities to get used to, not to mentioned subpar documentation in the early days, but it has evolved gracefully and is quite elegant, and has been for a few years now!
Read the docs, people!
And modern refined tools like Vue CLI, create-react-app, Next.js, and now Vite can take care of most of the “boring” frontend configuration!
No one really needs to struggle with Webpack anymore.
I learned to embrace the JS ecosystem and all of its quirks a long time ago. I think the ecosystem is first class and better than most other ecosystems I've part of. None of the dissenters ever have good enough arguments to sway me. To each their own, but JS is a fantastic, vibrant ecosystem with exceptional engineers solving problems that are wholly unique to the browser.
Stop conflating the NPM ecosystem with JS.
No. Dissenters are almost always people who clearly understand how overly complex and at the same time extremely brittle frontend toolchains are. Understanding why you need these tools doesn't change the reality of what these tools are and how they work.
A complex front-end code in your workplace should be similar. Hopefully a seasoned front-end developer is maintaining this complexity and if a back-end developer needs to contribute a trivial change, they can just `npm start` (documented in the README.md) which sets in place a whole lot of complexity that the back-end developer doesn’t need to understand, but just works.
Ideally you would have a pipeline building the project on each branch commit so that the backend dev can push, wait 5 min, fetch the artifacts for that branch and run it locally to test it. Or even better - if there's a pipeline chances are there's a Dockerfile doing the build but it will not support live-reload.
Either ways it gets complex as soon as you have to get out of your comfort zone. Especially if the docs are outdated/verbose/non-existent.
One can complain that the tools could be better, but not that they exist. They exist because they solve a problem that other platforms don't have: real-time delivery over the web and compatibility with a variety of runtimes.
I didn't know that was a thing, so thanks for mentioning it - tips like these are one of the main reasons I read hn - and it'll save me hours of now needless file transfers.
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
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.
Didn’t the Buddha already teach us about the middle way?
This strategy has worked great for personal projects. However, I would never start this way for a commercial product.
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#iss...
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
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.
I gave a local related meetup talk, slides here.
Any good reason to upgrade?
- 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
The benchmark is dominated by terser and SourceMap performance. What you see are different terser configurations. Webpack 4 with compress.passes: 1 and webpack 5 with compress.passes: 2. Enabled SourceMaps makes minimizing extra expensive.
(removal of the dependency on chokidar and fsevents)
Failure of bundlers (Webpack, Parcel, Rollup, etc) to support import.meta.url has been a major headache for me. Making my JS library usable in sites that use such bundlers in their build chain has led to me making some - questionable, let's say - decisions in the library's code. The sooner I can remove my "solutions", the happier I will be!
- Nullish coalescing
- Optional chaining
- Numeric separators
- Logical assignment operators
I'm surprised it wasn't mentioned in the notes -- I guess everyone is transpiling for production anyway, but it's still nice not having to do so in development.
Now if only they had a way to activate support for stage 3 features (https://github.com/acornjs/acorn-stage3) so all the class field stuff could be added to that list (modern browsers have already supported it to varying degrees for a while now).
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?
Why are you using the bundler to do that?
Im sure there are alternative methods but with Webpack it's been super easy.
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.
And I guess webpack wins because you can configure it to do anything easily already? And with compiled languages 'configurability' is hard to do?
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.
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.
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.
Getting this information out of the documentation is like squeezing water from a rock. It seems to be written of the opinion that you don't need to know how and what is going on, and if you do you probably already know.
I don't think most people really "learn" Webpack. Mostly they just tweak cut+paste examples and get back to value add work. You can definitely achieve 99% of whatever task you have without going down the warren of Webpack rabbit holes. You're committing no crime if you just relegate Webpack to the "get it working and forget it" bin; it does what it says on the tin and you can rely on it despite not being an expert.
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.
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.
Maybe you can justify the complexity in JS projects but I find it excessive.
https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-...
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
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.
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...
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.
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.