by marksamman on 10/10/20, 8:12 PM with 175 comments
by jebronie on 10/10/20, 8:48 PM
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 and know how to avoid it, but a bozo like me does not. This is actually causing me stress irl.
by runarberg on 10/11/20, 1:00 AM
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 always start my websites with a simple index.html file and run a `python -m http.server`. That is it. Modern JavaScript has a really good module system that works in all major browser (even Edge), and node. If you want to write type safe JavaScript you can write your types as doc comments and have typescript check it without bundling or compiling. You literally need only two tools to write a website: a browser and a text editor.
I’m not here to tell you that people shouldn’t use these complex tools. Many people configure their front-end environment just fine with webpack, babel, typescript, etc. If they work better that way, that is fine. But if that bothers you, simply don’t do it. There is no reason for you to complain about it.
by bichiliad on 10/10/20, 10:01 PM
1. it is flexible enough to fit all of our weird edge cases.
2. it has a really solid community of people working on it.
3. it made adopting new features like TypeScript extremely simple for us.
I don't see us upgrading from 4 to 5 eagerly (at least until it's been production-proven), but I'm excited about this release, and I love all the hard work that's gone into it. Congrats to the team — it's no small feat.
Edit: formatting
by anderspitman on 10/10/20, 11:27 PM
For my latest project I'm even trying to make the entire interactive UI without any JS. I've sadly never done this.
The sense of relief getting out of "modern" JS has been palpable. No more build steps. No endless dependabot PRs. No painful dependency updates. Just good clean fun development.
There are tradeoffs. vdom frameworks really can add a lot of productivity vs hand-coding dom updates. But if I really need it I can use something like Mithril which still doesn't require a build step.
by acemarke on 10/10/20, 8:53 PM
https://nextjs.org/blog/next-9-5
and looks like Create-React-App plans to support Webpack 5 in an upcoming CRA 4.1 release (4.0 is in alpha now):
https://github.com/facebook/create-react-app/issues/9613#iss...
by anuila on 10/10/20, 11:11 PM
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 exchange it brings a slew of unfixed bugs in the most simple projects that lightly sway from the base usage.
Maybe in 2030 the JS community will have figured something out.
1: https://webpack.js.org/guides/asset-management/#loading-css
by rmrfrmrf on 10/10/20, 11:51 PM
by spiderjerusalem on 10/10/20, 10:27 PM
I gave a local related meetup talk, slides here.
by Waterluvian on 10/10/20, 8:54 PM
Any good reason to upgrade?
by emilsedgh on 10/10/20, 11:14 PM
A few months ago we started using esbuild for our development setups. Build times went from ~6 minutes to ~1.
This is a sweet spot for us as esbuild is performing really well and made our development much easier. we still rely on webpack for our staging and production builds.
The reason for this is esbuild doesn't support a variety of production necessary features (transpiling to older ES, uploading bundles to S3, etc)
But I'm very happy with our "esbuild for development, webpack for deployments" process.
Any reason other people are not taking a similar approach?
by ENGNR on 10/10/20, 10:25 PM
by nikivi on 10/10/20, 9:22 PM
And I guess webpack wins because you can configure it to do anything easily already? And with compiled languages 'configurability' is hard to do?
by simonw on 10/10/20, 10:12 PM
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.
by andy_ppp on 10/11/20, 12:57 AM
by ssijak on 10/11/20, 7:53 AM
by SimeVidas on 10/10/20, 9:44 PM
by __s on 10/11/20, 12:13 AM
https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-...
https://github.com/webpack/webpack/issues/11467
Seems rules: {test:/\.m?js$/,type:'javascript/auto',resolve:{enforceExtension:false,fullySpecify:false}} fixes
Also nothing in this doc mentions that webpack -p no longer works, instead you need to spell it out webpack --mode=production
by asdf-asdf-asdf on 10/11/20, 11:24 AM
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.
by sabellito on 10/10/20, 11:53 PM
by Jarred on 10/10/20, 9:37 PM
Did the cold build times get slower? This tweet shows a benchmark that makes it seem like cold build times got slower in Webpack 5
https://twitter.com/evanwallace/status/1314121407903617025?s...
by brodock on 10/11/20, 3:24 PM
by kumarvvr on 10/11/20, 1:42 AM
The paradigm and implementation is top notch. And its orders of magnitude better than programming in JS.
If you are doing data intensive apps, complex data handling and all, doing it in C# is a pleasure.
by preommr on 10/11/20, 2:10 AM
I've had some really horrible experiences with webpack.
When I first started with it, it was daunting. Seriously, just look at the docs, it's pages upon pages of complex behavior. Some of it fairly unintuitive.
It took me days to dive in, get used to it and kind of know what I was doing, and then promptly forget everything about I knew over the months/years.
Everytime I have to dive into the webpack related config, I basically set aside a whole and feel a deep sense of dread. This isn't normal.
Also, Webpack has horrible UX. At first I thought that was because it's complicated and covers a difficult problem space. But then I used parcel, which is leagues better in terms of usability. I absolutely love parcel and think it's so much better overall. Unfortunately, their team is much smaller and much less used so webpack is a couple more features that make it more "stable". Well actually, it goes both ways, but most of the time parcel has some very small error that webpack might not.
Whic is why I basically run both at the same time - parcel for it's speed and ease of use, webpack to catch a lot of errors (like those outputted by ts) that for some reason parcel (1.x at least, I think 2.x is coming soon) doesn't catch.
by bostonvaulter2 on 10/11/20, 12:08 AM
by WesolyKubeczek on 10/10/20, 10:46 PM