Live data from Hacker News

Webpack 5

webpack.js.org

171–180 of 182 posts

Re: Webpack 5

#171
post #2

"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…

Out of curiosity is patching and updating all packages also a common consistent issue? Is there regularly breaking changes?

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.

Re: Webpack 5

#172

Earlier quoted context omitted.

That is all fine for personal projects. However, professional web apps typically have more complex requirement than just supporting the latest versions of major browsers without any further optimizations, so the only viable way of filling them is to use the complex tooling.

idk. I’ve worked with complex python codes and they also tend to have some complex setups like virtualenvs, django manage scripts, required system software, custom python version etc. Thankfully my workplace has this system set up by python experts who maintains all the complex config and documents how colleagues can get this thing running on their machine. At work I don’t need to understand the complex setup, and if…

Yes, but... chances are your backend dev will have a system-provided or just plain outdated Node version so they'll get a cryptic exception and will have to reach for assistance.

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.

Re: Webpack 5

#173

Earlier quoted context omitted.

And likely will have similar issues in five years as node has now. 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.

I think that is an unnecessarily negative view. By that logic, nobody should do anything because it will probably suck someday.

I do believe constant iteration is better, but Javascript has many problems at its very core, and many Node developers transitioning to Deno are going to create and write solutions that are more akin to their comfort in Node.

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.

Re: Webpack 5

#174
post #169

Earlier quoted context omitted.

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.

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

Not sure on the specifics, but my understanding is that the major improvements in Webpack 5 are related to caching.

Re: Webpack 5

#175
post #169

Earlier quoted context omitted.

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

Not sure on the specifics, but my understanding is that the major improvements in Webpack 5 are related to caching.

I got the same message. Still, having faster builds with one additional plugin without configuration needs on projects locked on 4 or waiting out the transition is a plus in my book :).

Re: Webpack 5

#176
post #170

Earlier quoted context omitted.

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.

That works until your team doesn't decide to eject because they want to play around with webpack...

Of course! Then you're just in the same hellish landscape of having to learn and maintain webpack configs, which "you" completely opted into!

Re: Webpack 5

#177
post #125

Earlier quoted context omitted.

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.

That is because it is NOT written in JavaScript. 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 langua…

please please please do not use google's results as an indication of really anything at all. Don't take my word for it, do this test: search something, like the name of someone you know that's not famous. You'll find that google will reports tens of thousands (or millions! lol) of results. But click through 10 or 15 pages. You'll soon find that many of the pages have almost nothing at all to do with what you searched (and may not even contain any word from the phrase!), but that if you get far enough, maybe 300 results or so in, you'll see that when google runs out of results it will magically just update to show the real number, which is often just a few dozen for a search like the one I described.

Re: Webpack 5

#178
post #125

Earlier quoted context omitted.

That is because it is NOT written in JavaScript. 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 langua…

> Google: nullpointerexception -> 4.360.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.

see above, but this basically this is inaccurate.

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

Re: Webpack 5

#179
post #13

Earlier quoted context omitted.

So far what I've been doing is keeping my webpack config as simple as possible ( 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…

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.

I just use laravel mix, as a wrapper around webpack, and then I can extend that if I need to for certain things, like maybe aliases, or something.

Re: Webpack 5

#180
post #2

"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…

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.
Post reply on HN