And it's an accident that could have been prevented.

The JS ecosystem looks like an isolated entity that contracted amnesia and a learning disability. It then proceeded to remake every single mistake done in 30 years of prior art, while ignoring every other communities warning again and again about it.

And to add insult to injury, devs from the community answered that everything was fine, and that it was us who didn't understand, and failed to live in modern times.

It's getting better. But it took a while because so many JS devs have only ever coded in JS, giving them an incomplete and crooked big picture.

If you think Webpack is solving an easy problem, you don't understand the problem.

I do not think so. And I think Webpack actually clearly shows the way where JS ecosystem goes – creating one layer of complexity on top of another. Each new layer, of course, solves the problem (not an easy one) of the previous one, but creates new problems, that will be resolved by the next layer.

Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.

Accidental complexity is when you have a tool that 99% of developers couldn't quickly grasp and need to spend many hours studying courses or reading books (!) on Webpack.

Someone should stop this madness.

Back in 1975 (43 years ago!) Tony Hoare said:

"The pursuit of complexity is easy... But the pursuit of simplicity is one of the most difficult and challenging activities of the human mind. Progress is likely to be extremely slow, where each complexity eliminated must be hailed as a breakthrough. We need not only brilliance of intellect but breadth of experience, nicety of judgement, excellence of taste, and even more than our fair share of good luck. And finally we need a puritanical rejection of the temptations of features and facilities, and a passionate devotion to the principles of purity, simplicity and elegance."

Front-end developers want more than to just run code, though. We want to be able to use modern JS and CSS without worry. We want live-reloading of styles. We want to minify and clean up our code, and to break it into smaller chunks. We want code-linting to keep ourselves and others in check.

All of those things I see as being essential to building quality code in a reasonable amount of time (and enjoying it), and all of those things are actually really easy to set up in Webpack (it's all in their docs). Webpack was overwhelming before I read through their docs, and their docs are not as nice as VueJS's docs, but it isn't as bad as everybody makes it out to be. Really.

You're right, web development is more than just run a code, but it's not an order of magnitude more. If you use sane defaults, find the most common patterns and workflows, identify trade-offs and come up with elegant conventions, you'll be able to hide the complexity and make it simple for people to learn, grasp, use and, consequently, to contribute and improve. But simplicity is complicated and it's way more easier to do a feature-rich extra-configurable monster and write books on how to use it.

As for the "reasonable" part – it's extremely subjective and we all should account our judgements for that. Back in 2005 I was OK with the fact that I need to go for the coffee break when I start compiling a C++ program. If you'd asked me "do you think C++ compilation time is slow" those days, I would reply "absolutely not" and find explanations why it's reasonable. Now, after Google couldn't stand C++'s complexity and compilation times and created Go language with its subsecond compilation times, my understanding of reasonable has shifted dramatically. It's just doesn't make sense anymore to compile something more than 10 seconds, and 15 mins compilation times are now in a "madness" bucket.

Shouldn't an IDE be able to do most of this?

> Essential complexity in this case is just a need to run a code. That's it. I just want to run one command, with one or two switches max, and get the result running in a browser.

So, why don't you just double click your index.html? Or is there more to the problem statement?

> So, why don't you just double click your index.html?

Oh, believe me, whenever it's possible I do exactly this. If I have a chance to avoid bringing 100500+ new overcomplicated tools from JS world just to be able to run small WebGL project, I do.

> I do not think so. And I think Webpack actually clearly shows the way where JS ecosystem goes – creating one layer of complexity on top of another. Each new layer, of course, solves the problem (not an easy one) of the previous one, but creates new problems, that will be resolved by the next layer.

If there ever a need for red blinky text that quote is it. That is exactly what is happening. And JS fan boys get pissed about it when you point at it.

Web developers get pissed because its a strawman. Nobody uses the layers of complexity needed to preprocess, compile, load, link and finally run C++ as a fundamental criticism. Everything anybody does when they work on modern programming platforms is stand on top of layers of complexity that would make anyone's head spin. But when you're writing code for a living what matters is the quality of your hand-tools, the quality of the open source code you rely on and the expressiveness of your language and thus your ability to ship products. Modern web-dev and JS-dev has no problems in this area, but hey what do I know I've only been doing it for 14 years. My day is spent working on products and features, not fighting the language or tooling. Just like anything it requires a little effort and experience.

Exactly this. I sometimes work on projects without all nice tools that I'm used to using, and it works out just fine. I wouldn't choose or suggest to start a new project that way, though.

Reading through Webpack's docs one night was all I needed to start creating my own configs, and I improved upon that config as time went on. It was worth the investment in time.

You are comparing C++, a bare metal language, to JS, a high level dynamic language running in the richest plateform ever created.

So what you are saying is that it's logical that the JS restaurant is hard to eat in, because for cooking you need to sharpen knife and chose the best fruits from the market.

To me, it's madness or dishonest.

My experience is that in JS it's usually both.

You sound like you haven't really had to do much real-world work in JS or C++.

Apart from managing memory, what makes C++ complicated is accounting for the differences between OSes and shared libraries and even different hardware capabilities.

But it's perfectly acceptable for many C++ developers to write code that only works on a single OS or to ship massive bundles that include various compatibility layers or specific versions of libraries to escape the hell that is dynamic library loading.

Developing rich applications (i.e. the kind of app that serves the same need as a desktop application you need to download and install) is similar, except it's rarely acceptable to say "oh, this web app only works in Safari" while it's often perfectly acceptable to say "oh, this desktop app only works on the latest macOS".

Instead of different OSes you have to deal with different browsers. Instead of shared libraries you have to deal with different implementation levels of web standards (which is rarely an "on or off" distinction but in practice often means having to deal with experimental prefixes, different draft stages and subtle differences with no easy way to determine in advance what the browser supports exactly). And you don't get to compile per platform and users will complain if your code bundle is too big or features aren't supported in their browser.

"But web sites are simpler" you might argue, but that's not webpack is used for. Or at least the web sites you'd complain aren't using it. A wordpress blog with tens of JavaScript files is the opposite of what you get when using a tool like webpack.

Ironically a simple blog with the same user-facing functionality would likely be much smaller and faster if built with webpack (because a lot of the redundancy and size stems from the good old days' "bolt-on" mentality which is still a common practice for web sites). But surprisingly enough that's not what webpack is used for because "everybody knows" it would be overengineering.

> Nobody uses the layers of complexity needed to preprocess, compile, load, link and finally run C++ as a fundamental criticism.

I do. C++ is an excellent example of accidental complexity got out of control. Actually, C++ complexity has been a main reason of why Google created Go. And Go embraced pursuit of minimizing accidental complexity at its best.

> Modern web-dev and JS-dev has no problems in this area, but hey what do I know I've only been doing it for 14 years.

Number of years in industry is clearly not an a argument. It's actually may work against you. For example, I can assume that you can't see "problems in this area" because you spent years deep inside them, learning workarounds and solutions. So what a newcomer would call a "weird and complex" you may call "normal and obvious". (just an example)

> I do. C++ is an excellent example of accidental complexity got out of control. Actually, C++ complexity has been a main reason of why Google created Go. And Go embraced pursuit of minimizing accidental complexity at its best.

Fair enough, but every HN thread about C++ isn't flooded with non-C++ devs crawling out the woodwork to complain about it being too complicated from a position of ignorance.

I've been working in and out of the web industry for 14 years. Until 2014 I was a Adobe Flash designer. I learned modern JS and web development in 2014, before that I had never written a line of JS or CSS commercially, and never opened a unix shell - it took me half a year or so of effort while working other freelance gigs. Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.

> but every HN thread about C++ isn't flooded with non-C++ devs crawling out the woodwork

The main difference between C++ and JS here, is that web has become a dominant platform. If you need to write anything that human should interact with, you're unlikely to build Desktop app, you'll go to the web – simply because it's a way to reach way more people. And by the twist of historic events it happened that the only programming language you can write it is something barely resembling real programming languages, something that has never been properly designed and thought of.

This actually feels like you're being forced to use JS without your consent, and that's where opportunity cost-like things start to happen. You know how effective you could be in a properly designed language and ecosystem, and when you spend hours fighting `function is undefined at index.js:2342342` bugs, and follow outdated tutorials just to realize that they are not working anymore, you know how much easier it would be if you had a choice in programming language, and you start hate it quite passionately.

> Other devs that complain about it are either are ignorant, or not willing to put in the required effort to learn something worthwhile.

I would not say so. I'm not a frontend dev, but I have 15+ years practical experience and can switch 2-3 languages almost daily. Right tool for the right job. While my main focus is server software, I like doing software with UI and was extremely happy in the early 2000-s doing this with C++/QT, and later developing Nokia N900 apps with Python and QML. That was just a great experience, and the learning path was logical and ecosystem is solid, so you can reuse what you've learned and advance this way.

Then around 2009 it become obvious that for apps with UI you need web. And I happily invested into learning how to do things. I was writing backends in PHP, then in Go, and for frontend I used jQuery, then Angular 1, then Angular 2 and React.

Backend part always took me around 5% of time, and 95% was frontend. From those 95% most time has been spent on trying to find logic in proposed solutions for the very basic things, and fighting with tooling and versions mismatches. Like, really, the real coding – i.e. solving "essential complexity" – was taking a tiny share of my time, but fighting with tooling, multiple approaches and solutions, that contradict each others, dynamic type absense errors, and simple stupid design desicions that made it to the mainstream was taking most of my time.

Needless to say, when I had to return to my projects in half a year, it just doesn't worked anymore, because ecosystem changed, tooling updated and become incompatible, and you find yourself trying to rewrite code to match newer versions. And it seems to be common thing in JS world – people just break APIs and libraries for almost no reason (`Button.Raised` -> `RaisedButton`, really?) and they fine with it. There is a whole mentality of "breaking API is totally OK" and a second generation of developers sees nothing bad in it. And, of course, you can't find anyone to help you, because that framework is already considered outdated and nobody wants to touch it.

So no, it's not an ignorance, it's merely respect of your time and mental health, and not accepting that you a) have no choice and should embrace technology no matter how bad it is b) your knowledge you're invested into will be outdated in half a year.

I hear you, your criticisms are valid but you've identified the wrong cause. It's not the tooling, or languages themselves, rather the web platform.

With the web platform everything is sat on top of shifting sand ... i.e. changing browsers, standards and devices. Almost nothing in the tech world has changed so fast over the last 15 years than the software and devices web platform code is expected to run on. I'd say that given that churn, the quality of modern web languages and tooling is remarkable.

Writing backends vs frontends is a totally different thing. Backends tend to run in stable environments, and mainly you concern yourself with data in and data out. That's not to say its easy, there can certainly be be plenty of "essential complexity", and infrastructure and scaling is a whole additional set of concerns. Frontend by contrast is a much more fuzzy issue, clients need to run across many unstable environments and require skills very far from traditional programming - sensitivity to design, UX and animation for example. If you're good at backend, it doesn't mean you're going to enjoy frontend too. And if you don't enjoy frontend it doesn't mean all the frontend tech is "bad".

Babel is solving a complex problem.

Webpack is not.

Webpack is basically a task runner, a bungler and a configuration system. It relies on plugins to do anything hard.

The fact it's breaking compat again is so few years itself is alarming.

But it's crazy that a tool that only glues things together is still unable to provide a better API that it currently is.

Do you have an better alternative? I haven't seen other tools which have a community this large, do automatic bundling and can handle (through plugins) all kinds of inputs. But that may just be my ignorance.

There is a reason we use this terrible tool: it's the only one that does everything it does.

That doesn't make it good.

It's like JS itself: it's a horrible language, but it's the only one that runs natively all popular web browsers.

When you have a monopoly, you don't need to be good. You just need to be here.