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

131–140 of 182 posts

Re: Webpack 5

#131

Post by pwdisswordfish4 »

runarberg wrote: post #95
andy_ppp wrote: post #81

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?

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)?

It's not. rustc + cargo + crates.io is bad, too.

Re: Webpack 5

#132

Post by martijnvds »

fendy3002 wrote: post #107
faichai wrote: post #44

Earlier quoted context omitted.

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…

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.

So, a complicated Makefile?

Re: Webpack 5

#133

Post by fn1 »

eurleif wrote: post #126
fn1 wrote: 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.

Right, thank you.

Re: Webpack 5

#134

Post by djaychela »

runarberg wrote: post #82

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

>I always start my websites with a simple index.html file and run a `python -m http.server`. That is it

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.

Re: Webpack 5

#135

Post by akmittal »

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…

Deno seem great, But third party libraries seem non existent compared to npm.

Re: Webpack 5

#136

Post by ssijak »

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.

Re: Webpack 5

#137

Post by drannex »

leptons wrote: post #124
searchableguy wrote: post #65

Earlier quoted context omitted.

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…

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.

Re: Webpack 5

#138

Post by regularfry »

sibeliuss wrote: post #127
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.

> It’s basically already better than any of the existing JS JS bundlers This statement assumes that there's basic feature parity between ESBuild and tools like webpack, which is straight up false.

And that assumes that more features is necessarily better, which is also false.

Re: Webpack 5

#139

Post by topspin »

simonw wrote: post #34

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.

> I've been putting off learning Webpack for far too long.

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.

Re: Webpack 5

#140

Post by fedlarm »

root_axis wrote: post #12
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…

Why do you feel the need to upgrade to webpack 5? What particular feature do you need that justifies the upgrade?

For me the module federation is a new feature that I can take advantage of to improve integrations.
Post reply on HN