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

91–100 of 182 posts

Re: Webpack 5

#91

Post by madeofpalk »

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.

Re: Webpack 5

#93

Post by [deleted] »

d13 wrote: post #89
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…

We’ve banned npm install: It’s simply a party drug and completely unnecessary.

[deleted]

Re: Webpack 5

#94

Post by gfodor »

cookiengineer wrote: post #55
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.

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

Re: Webpack 5

#95

Post by runarberg »

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

Re: Webpack 5

#96

Post by tkzed49 »

jonahx wrote: post #87
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 like your advice, but I think there is a reason for the complaints. An indefensible complexity has become the new normal. And it's what many people are forced to suffer through at work. If having a chorus of complaining dissenters on HN threads sways even a small percentage of people to take simpler approaches, it has done some good.

When people are complaining about this kind of stuff at work, it raises the question of what the alternative is. The person you're replying to describes a great methodology for smaller projects, but in many cases there are great reasons to take on dependencies. Not taking a dependency means you pay in person-hours to reinvent it, and sometimes that cost is much higher than a couple extra seconds of build time.

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.

Re: Webpack 5

#97

Post by apeescape »

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…

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.

Re: Webpack 5

#98

Post by andy_ppp »

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

Okay, so rustc is compiling rust to machine code. Here we have some advanced version of JavaScript (es7?) going through a series of compilations, asset extraction, tree shaking, dependency graphs that are 10000+ packages long etc. The solutions rust and cargo choose (like having a decent standard library to reduce deps) are all better. Rust is fast and worth paying a compilation prise for, is it worth it in JS so we can have shiny semantic sugar everywhere? I don’t know how crate modules works but hopefully each library needs you to specify versions of all dependencies at the top level rather than magically hiding modules you’re adding 5 levels deep.

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.

Re: Webpack 5

#99

Post by vangelis »

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

Oh thats because you are missing the specific version manager for each part of your build toolchain 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.

How do you manage your version managers?

Re: Webpack 5

#100

Post by [deleted] »

apeescape wrote: post #97
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…

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.

[deleted]
Post reply on HN