Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webpack 5

webpack.js.org

Post reply on HN
Print view View original

161–170 of 182 posts

Re: Webpack 5

#161

Post by fiddlerwoaroof »

amelius wrote: post #155
fiddlerwoaroof wrote: post #109

Earlier quoted context omitted.

Committing the package-lock.json file should do this for you: I always upgrade one dependency per commit and I put code changes in separate changes from upgrades. Also, you just have to learn which packages to avoid: react-router, for example, likes incompatible major version updates. Something simple like routedux that’s stable is almost always a better choice.

With all the different package managers out there, it's just not much fun to keep track of all the rules and special cases for each tool. Better to just have a "--rollback" option.

Isn’t this solved more generically by version control? As long as your package manager uses files to control the packages searched for, them you commit those files between upgrades and revert them to rollback. nix handles this at the system-level by making your system configuration match a declarative specification.

Re: Webpack 5

#162

Post by brodock »

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.

Re: Webpack 5

#163

Post by bichiliad »

marcins wrote: post #49
bichiliad wrote: post #29

Earlier quoted context omitted.

The biggest thing I've been excited about is having an offline cache for fast recompilations. It'll make startup times a lot faster, which is a big improvement for developer experence (especially in larger codebases).

Up to a point, eventually when the code base is large enough you spend more time serialising/deserialising and passing things between workers that it can be faster to disable the cache.

Are you saying that from experience with webpack 5, or is that a prediction?

Re: Webpack 5

#164

Post by ficklepickle »

searchableguy wrote: post #65
peterangular wrote: post #50

Earlier quoted context omitted.

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.

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/ Great community: https://discor…

I've been dabbling with Deno and I quite like it.

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.

Re: Webpack 5

#165

Post by ficklepickle »

drannex wrote: post #137
leptons wrote: post #124

Earlier quoted context omitted.

Deno is nowhere near ready for prime-time.

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.

Re: Webpack 5

#166

Post by ficklepickle »

gfodor wrote: post #94
cookiengineer wrote: post #55

Earlier quoted context omitted.

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

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.

Arguably not giving a damn caused the problem in the first place

Re: Webpack 5

#167

Post by SoSoRoCoCo »

kaishiro wrote: post #145
SoSoRoCoCo wrote: post #52

Earlier quoted context omitted.

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

Would be interested to hear what issues you ran into with Parcel. I've used it on dozens of projects without doing any sort of deep dive into their pipeline - just using the default no config compilation and it's worked pretty much perfect every time.

Sorry, my post was misleading, I was convinced to use -A- packer, so WebPack, Parcel and FuseBox in that order. WebPack had the best documentation hands-down because 4 weeks ago I didn't know what a packer did, I had been purposefully avoiding them for years. Now that I know way more about the concept/theory, I'll go down the list. Although I'm reluctant to waste too much time because my experience trying to bring all of the frameworks I already use into webpacker was so painful. But I really am pulled in by hot module swapping...

Re: Webpack 5

#168

Post by RobertKerans »

thiht wrote: post #150
earthboundkid wrote: post #75

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.

This is because it doesn't do anything yet. I look forward to the day it's usable in production, but today is not the day. And don't forget Parcel which also have the simplest possible UI.

This categorically not true. It does exactly the thing it's supposed to do. Yes, it is best that potential users wait for now, but that isn't because it "doesn't do anything".

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.

Re: Webpack 5

#169

Post by zamber »

nicoburns wrote: post #40
sinker wrote: 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.

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

Re: Webpack 5

#170

Post by zamber »

madeofpalk wrote: post #91
jebronie wrote: 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…

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