Live data from Hacker News

Webpack 5

webpack.js.org

111–120 of 182 posts

Re: Webpack 5

#111

The past year or so I've moved almost exclusively to backend at work (from Vue frontend) and simultaneously switched to vanilla JS for all new side projects. For those I use native ES modules heavily for internal code, and use very few external dependencies and import them as global scripts like a heretic. Heck I often don't even use npm for node projects anymore. For my latest project I'm even trying to make the ent…

For personal projects that I'm not certain are going to require a battle-tested, fully capable of handling any weird business requirement from product, I always start simple.

This strategy has worked great for personal projects. However, I would never start this way for a commercial product.

Re: Webpack 5

#112
post #87

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.

Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools we need to be successful. If you want to build a web app, you must target javascript and the browser. There are so many backend programming languages that enables developers to figure out their preferences. I get it, if I didn't have a choice but to build every web API using rails I think I would stop doing web development as well.

I learned to embrace the JS ecosystem and all of its quirks a long time ago. I think the ecosystem is first class and better than most other ecosystems I've part of. None of the dissenters ever have good enough arguments to sway me. To each their own, but JS is a fantastic, vibrant ecosystem with exceptional engineers solving problems that are wholly unique to the browser.

Re: Webpack 5

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

Once I had the freedom to decide, I gave up on using most of the standard Javascript ecosystem stuff in my front-end projects.

No node, no npm_modules, no build chain. I'm lucky to be able to get away with that. It is incredibly efficient, not only because it no longer gets in the way of what I'm trying to build. The previous team I was on, we spent roughly 15% of our time tending to these things.

Re: Webpack 5

#114

I’m scrolling and scrolling waiting for a paragraph that tries to sell me on why I’d bother and risk upgrading. I think the best I got were patch notes. Any good reason to upgrade?

The parser was updated which brings the ability to use new (stage 4) ES syntax without having to transpile:

- Nullish coalescing

- Optional chaining

- Numeric separators

- Logical assignment operators

I'm surprised it wasn't mentioned in the notes -- I guess everyone is transpiling for production anyway, but it's still nice not having to do so in development.

Now if only they had a way to activate support for stage 3 features (https://github.com/acornjs/acorn-stage3) so all the class field stuff could be added to that list (modern browsers have already supported it to varying degrees for a while now).

Re: Webpack 5

#115

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…

My setup for simple to somewhat complex web apps is to download a minified version of Preact and htm and just import it as ES6 modules. The builds from unpkg work just fine although it seems you can't use the hooks extension since it has an unpkg URL hard-coded. I haven't looked into building Preact myself.

Re: Webpack 5

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

Webpack itself is quite low level. `react-native init` or `create-react-app` gives you the ready to use developing environment and updating that is usually a breeze.

Re: Webpack 5

#117
post #77
post #27

Earlier quoted context omitted.

Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Or they're running things in parallel, and encountering data races and such, and randomly working as a result. But the real concern is that they don't really know what a correct installatio…

> Run it three times however is not part of such bugginess though. It means that they're randomly encountering different executions/run-states on what should be the same config/setup, each time you run it. And they have no idea why. Maybe we’ve interpreted that message in different ways, but I took it to mean you may need to try it again at a later date once the community have fixed those issues/bugs. I don’t think t…

[deleted]

Re: Webpack 5

#118
post #25

I’m scrolling and scrolling waiting for a paragraph that tries to sell me on why I’d bother and risk upgrading. I think the best I got were patch notes. Any good reason to upgrade?

MacOS's broken-ass filesystem will no longer be allowed to cause warnings on other operating systems, that's a feature I'm keen about! (removal of the dependency on chokidar and fsevents)

[deleted]

Re: Webpack 5

#119

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.

That makes perfect sense though. Older projects have a ton of baggage that they carry through all of the revisions. New-comers to the space can learn from the mistakes of previous approaches and also utilize the latest and greatest paradigms to solve the problem without worrying about backwards compatibility.

Re: Webpack 5

#120

I will forever swear by parcel-bundler. That thing takes so much of the suck out of web dev.

I came here to say the same thing. After my first tests with Parcel I haven't gone back to webpack again.
Post reply on HN