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.
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.
To all package manager developers: make sure you have a rollback function, and make sure it is flawless.
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.
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)
Typescript, Babel, Webpack, JSX, TSX, etc, etc.
It gets in the way of development as much as it helps.
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.
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.
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.
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.
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.
I'm usually conservative in the tools I choose, but I have to be especially conservative with js.
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’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.
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.
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 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.
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.
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.
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
(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).
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.
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.
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.
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.
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?
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.
Why are you using the bundler to do that?
Im sure there are alternative methods but with Webpack it's been super easy.
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.
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
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.
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...
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...
I gave a local related meetup talk, slides here.
And I guess webpack wins because you can configure it to do anything easily already? And with compiled languages 'configurability' is hard to do?
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.
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.
