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

151–160 of 182 posts

Re: Webpack 5

#151

Post by thiht »

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.

Agree. The only flaw of Parcel is that its tree shaking support sucks.

Re: Webpack 5

#152

Post by asdf-asdf-asdf »

it is really frustrating to read infinite variations of the comment "javascript development is too complicated", "it is much simpler in other languages" etc.

yes, it is complicated. the problem is, there are certain constraints that we just cannot ignore: we want to write code in a "normal", efficient way (code organized in namespaced modules, perphaps static typing etc.), but we need it to be executed by the web-browser, maybe an old version of a web-browser. so we need solutions that work with these constraints.

if you know about simpler solutions, i'm very interested hearing about them. but please note, it has to work with those constraints, so ideas like "just write a native application" does not help.

Re: Webpack 5

#153

Post by dmitriid »

qudat wrote: post #112
jonahx wrote: post #87

Earlier quoted context omitted.

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…

> Dissenters are almost always people who haven't spent enough time in the JS ecosystem to understand why we need the tools

No. Dissenters are almost always people who clearly understand how overly complex and at the same time extremely brittle frontend toolchains are. Understanding why you need these tools doesn't change the reality of what these tools are and how they work.

Re: Webpack 5

#154

Post by pknopf »

darepublic wrote: post #90
pknopf wrote: post #66

Earlier quoted context omitted.

jQuery and full-page postbacks are my go-to, unless there is an actual need to introduce something else (React, etc). I'm usually conservative in the tools I choose, but I have to be especially conservative with js.

Full page postbacks are not necessary even if you want to go zero dep

Most of the time, it isn't very useful to have javascript even exist, even though there isn't 3rd party dep.

For example, have you even been in the settings areas of GitHub and thought "I wish there was more async here!"?

In ASP.NET MVC, doing full postbacks means very simple controllers/actions/views that a junior could understand.

Re: Webpack 5

#155

Post by amelius »

fiddlerwoaroof wrote: post #109
amelius wrote: post #80

Earlier quoted context omitted.

> Me too! I dread package upgrades because it can instantly turn into an all-hands-on-deck emergency, and these are just the stand-alone packages, not all the ones I mentioned above. To all package manager developers: make sure you have a rollback function, and make sure it is flawless.

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.

Re: Webpack 5

#156

Post by Chris_Newton »

peterangular wrote: post #50
ronaldj wrote: post #22

Earlier quoted context omitted.

Configuring the modern JS toolkit (webpack, Babel, your framework of choice, Jest, etc) is such a pain. I’ve been doing front-end for 10+ years. You’re probably not a bozo.

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.

I have found that over time, I have become more sceptical about new shiny things in the programming world. Every now and then, I wonder if I’m becoming the dreaded veteran dinosaur type, the developer who has more demands on their time now and who just hasn’t kept up with the tech.

But then I look at all the troubles the kids have with their fragile, short-lived tools. I recognise short-sighted design decisions they’re making because they’re being pushed into them by some shiny new library. I notice that many of those tools and libraries have big names behind them, and that the Zeitgeist people think you’re weird if you’re not using them, and remind myself that these things are only ever means to an end, no matter how popular they become.

Of course it’s useful to keep generally aware of what’s happening in the industry and from time to time a genuine improvement does come along. However, there is definitely a difference between not keeping up and not wasting your time repeating past mistakes or following blind alleys that often end up at dead ends.

Re: Webpack 5

#157

Post by rikroots »

spankalee wrote: post #51
Waterluvian wrote: post #4

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?

Support for import.meta.url is huge, especially inside fetch() and new URL().

Thank you for making this comment - without it I would've ignored this new release.

Failure of bundlers (Webpack, Parcel, Rollup, etc) to support import.meta.url has been a major headache for me. Making my JS library usable in sites that use such bundlers in their build chain has led to me making some - questionable, let's say - decisions in the library's code. The sooner I can remove my "solutions", the happier I will be!

Re: Webpack 5

#158

Post by sod »

anuila wrote: post #54

Version 5 and this tool still has absolutely awful UX. I have no problem configuring Webpack, but it's ridiculous that: - it needs two plugins to generate CSS files [1], when the homepage lists it as one of the supported outputs in front and center; [2] - it needs a plugin have a non-trash output log. [3] Parcel was supposed to fix the situation, and in many cases its UX is an order of magnitude better, but in exchan…

IMO it's the beauty of webpack that they are dogfooding their own APIs and even the basics are implemented as plugins & loaders.

Maybe out there is a better way to design a bundler api. But up until now I only see a flood of one-click bundlers that cover the happy path.

Re: Webpack 5

#159

Post by sixbrx »

djaychela wrote: post #134
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.

"npx serve" is another good way to serve static files quickly without needing python or any npm installs even. npx is packaged with npm for a while now.

Re: Webpack 5

#160

Post by lights0123 »

dmitriid wrote: post #146
runarberg wrote: post #102

Earlier quoted context omitted.

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.

Although, I do think that Vue handles the webpack config in a great way. I've been using vue-cli to manage my webpack config for years now, and never had a minor upgrade of any dependency break the build. It also provides a nice way to hook into the webpack config, so you can still add your own plugins and loaders without having to opt out of it managing it for you.
Post reply on HN