Live data from Hacker News

Webpack 5

webpack.js.org

141–150 of 182 posts

Re: Webpack 5

#141
post #105

Earlier quoted context omitted.

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…

Yes good luck shipping that main.rs to a web browser. The problem that Webpack solves is performance optimization in addition to what Rust offers: - writing in a higher-level language: "write modern code and ship to IE 5" is the same as "write in Rust and ship to x64" - take a bunch of files and make 1 or 2 out of it. Nobody stops you from loading jQuery and 3 plugins in a script tag and call it a day. Webpack exists…

Have you ever seen a 3000 line webpack config file. I think the analogy between webpack and rust is nonsense to be honest. They are doing different things, I just bit on the previous question.

Maybe you can justify the complexity in JS projects but I find it excessive.

Re: Webpack 5

#142

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…

Amen.

Re: Webpack 5

#143
post #105

Earlier quoted context omitted.

Yes good luck shipping that main.rs to a web browser. The problem that Webpack solves is performance optimization in addition to what Rust offers: - writing in a higher-level language: "write modern code and ship to IE 5" is the same as "write in Rust and ship to x64" - take a bunch of files and make 1 or 2 out of it. Nobody stops you from loading jQuery and 3 plugins in a script tag and call it a day. Webpack exists…

Have you ever seen a 3000 line webpack config file. I think the analogy between webpack and rust is nonsense to be honest. They are doing different things, I just bit on the previous question. Maybe you can justify the complexity in JS projects but I find it excessive.

If you replace Webpack with Parcel, the argument holds up. Webpack just offers more bells and whistles, which in our case we need to wrestle legacy projects into modern build pipelines. For a new project, maybe you don’t need all that, and you also don’t need Webpack with 3000 config lines. And fwiw, with every major, Webpack has moved to more sensible defaults for modern web bundling, meaning if you stick with it for a new project, likely you only need 5 config lines

Re: Webpack 5

#144
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…

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

Strange, because parcel in particular is zero configuration and I have used to it build client projects running in production. No complicated webpack configuration needed.

Re: Webpack 5

#145
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…

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

Re: Webpack 5

#146
post #96

Earlier quoted context omitted.

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, o…

Many people (including my self at work) handle webpack configs just fine. I started a vue project at work the other day and it was as simple as: npx @vue/cli@latest create my-project This scaffolded a fully configured project with webpack, babel, typescript, eslint, a custom dev server, etc. I think react developers have a similar tool called create-react-app. I personally (or professionally, since I only use this at…

> it was as simple as:

This just hides all the complexity behind a yet another layer of abstractions.

The moment something breaks due to a minor upgrade, you're screwed.

Re: Webpack 5

#147
post #13
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…

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…

Why not just use npm at that point?

Re: Webpack 5

#148
post #144

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…

Strange, because parcel in particular is zero configuration and I have used to it build client projects running in production. No complicated webpack configuration needed.

Parcel is a rare thing in the JS world: a tool I’ve actually found useful and efficient. As a bundler, it does indeed do a lot of things correctly out of the box, and as a direct result the experience of using it is far more pleasant than most such tools.

However, it is also a tool for one job: bundling. If you also want to do things like unit testing or running any sort of linter or style checker over your code, you probably need to figure out how to get those tools to read your TS or ES20xx code as well. You might still need a handful of additional libraries to implement your test suite. You might still need to configure your preferred style and which rules you want to enforce in your static analyser(s).

So even if Parcel was flawless about installing what you needed for your dev and production builds automatically, you’d still end up needing to install a bunch of other tools and write a bunch of other configuration files. The overall efficiency of setting up a realistic development environment, even using Parcel, is still limited by a kind of Amdahl’s Law problem.

Re: Webpack 5

#149
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…

Started my first React Native app some time ago and I can totally confirm that. It feels like a jungle of very fragile dependencies and mechanisms between code and output.

Yes RN is certainly the worst for that for me. I can't count how many hours I've had to put in to wrangle the RN packager in to a monorepo with TypeScript and code-sharing across packages, and it's still unbelievably fragile and I can't actually share components between them. At this point I've made so many little alterations to the config from GitHub issues and StackOverflow answers that I literally have no idea how it works or how to replicate it to a new project. It's an absolute nightmare.

Re: Webpack 5

#150

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…

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.

Post reply on HN