101–110 of 182 posts
The incremental build time improvements look great. 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...
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.
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…
npx @vue/cli@latest create my-project
I suspect much of the complain about the complexity of the front-end ecosystem comes from people that either a) don’t do front-end regularly and are trying to build a website for them self but get bad advice for the tools needed, or b) are backend developers at work and think they know better about the front-end then their front-end counterparts. In the case of (a), they simply just need better advice on tooling (and which tools are an overkill), the tone of my original comment was more directed at the other group (b; although the advice I gave was for the former group—whoops).
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.
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.
A complex front-end code in your workplace should be similar. Hopefully a seasoned front-end developer is maintaining this complexity and if a back-end developer needs to contribute a trivial change, they can just `npm start` (documented in the README.md) which sets in place a whole lot of complexity that the back-end developer doesn’t need to understand, but just works.
Earlier quoted context omitted.
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…
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 because jQuery and 3 plugins can't deliver the same results nowadays.
Also, do you want to improve your code with types and linting? Do that without Webpack, it's not going to be much more efficient.
---
In short, Webpack and Babel basically match the Rust compiler in functionality. If you don't use them, your web app’s code will be harder to manage, not easier. That's all.
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.
After working at small shops managing frontends with 1-2 other people and then moving to frontends managed by larger numbers and divisions, especially in a culture of moving quickly, things can get hairy quite fast.
Even so, it helps to make a habit of revisiting things from first principles and to also assume the beginner’s mind, collectively, to work towards more refined, elegant, simpler systems/modules based on lessons of the past.
Speaking of “normals”... it used to be normal for most people to be undernourished. Now, the normal is that the majority of people in many developed countries are overfed. And overstimulated.
Same with the code we write.
Overfed. Overstimulated.
The dangers of prosperity and excess!
But at least we have the opportunity to focus and sharpen our realities.
... Anyway, back to Webpack. Webpack is great. It is one such system that went through a lot of growing pains and complexities to get used to, not to mentioned subpar documentation in the early days, but it has evolved gracefully and is quite elegant, and has been for a few years now!
Read the docs, people!
And modern refined tools like Vue CLI, create-react-app, Next.js, and now Vite can take care of most of the “boring” frontend configuration!
No one really needs to struggle with Webpack anymore.
I've been putting off learning Webpack for far too long. 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.
This pretty much nails the problem with Webpack in my view. It doesn't seem to be based on any kind of strong, logical, easy to understand core, but instead is comprised of lots of interwoven threads of magic that no-one really understands. This makes any attempt to debug and solve problems with it a total nightmare, like crawling through a tar pit. You might make it, but you're gonna feel all sticky and dirty coming…
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…
One can complain that the tools could be better, but not that they exist. They exist because they solve a problem that other platforms don't have: real-time delivery over the web and compatibility with a variety of runtimes.
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…
> 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.
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.