npm Inc recently joined TC39 so maybe that will change. Also if deno takes off, it's ES6 modules only.

Also, I noticed when the display area is resized, the slider resets (with animation) to the first slide, while the bottom text stays the same.

Also I'll make sure the bottom text resets

https://github.com/TypeStrong/ts-loader/tree/master/examples...

https://github.com/TypeStrong/ts-loader/tree/master/examples...

https://github.com/TypeStrong/ts-loader/tree/master/examples... (written by Kenneth Chau of the Outlook.com team)

You may of course you may be using another typescript loader (there are several!). I thought it worth sharing in case you are using ts-loader and your config is catching you out.

Best of luck!

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."

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

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.

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.

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.

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.

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.

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)

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.

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.

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".

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.

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.

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.

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.

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.

A several horrific hours of googling how to fix its configs so that it just works

A question you’ll find yourself Googling every month as the “best approaches” change.

Did Webpack do that or did Babel?

Does it, though? No project of moderate complexity will be able to reuse a Webpack config. Conversely, how large of a problem was this for simple sites?

I looked at doing it with webpack but frankly 2 lines of bash that'll work the same in a decade vs haha no wasn't a hard choice.

Now... that doesn't really favor Webpack. And I still don't quite understand why that tool is so popular.

That's just back to Gulp.

WebPack 1.x was very powerful but very difficult to understand and configure. There weren’t a lot of sane defaults and the docs did very little to adequately explain the core concepts. The problem(s) WebPack wolves are pretty complex and I haven’t seen anything else do quite what it does.

Starting with 2.x, the docs are great. They explain the concepts pretty well. They give you basic setups and examples throughout. 2+ also has a simplified base config: you only need a few items in your config to start getting some pretty big benefits.

While WebPack was not the first and certainly isn’t the only tool that provides what it does, it does provide a sort of one stop shop for a lot of what used to be separate tools. I don’t feel like it locks me in however.

Along with the ability to minify and other such “utility” functions (which you don’t have to do with WebPack), you get things like tree shaking. This can drastically shrink your final bundle.

As someone who does a lot of UI development, it’s also nice to be able to use ES2015 features like import without having to worry.

tl;dr I see complaints about WebPack being complicated and config heavy. It used (1.x) to be exactly that. It’s much better and the benefits from using it far beyond worth the (now little) upfront learning IMO.

This is such a great typo. I'm going to keep this sentence next time I need to explain webpack in my trainings.

create-react-app and vue-cli and much better designed in that regard. And yet they are using webpack.

External projects manage to be better at webpack than the webpack team.

A vanilla install of Phoenix with Brunch yields a node_modules with 388 packages. What are the odds of one of them becoming rogue due to a hack, and how would I know?

Add to this the overall (perhaps perceived) fragility of having to maintain a node project and fumbling with JavaScript. Node was a great new thing for server-side stuff, but whose idea was it to start using it for building every single command-line tool?

Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.

You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.

"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."

More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.

No. Using a package for a single function doesn't preclude code reuse.

Look at underscore.get package. You could write your own recursive key finder (which I have before), and so could every package author, and you'd have 10x the amount of implementations of a recursive key finder.

A single require of underscore.get by you and other authors means you have a single, well tested implementation with a million other users rather than 10 low quality ones.

   const {get} = require("underscore.get");

   get(obj, 'a[0].b', defaultValue);

[1] https://github.com/NarHakobyan/underscore.get

Exactly. If it's a difficult line of code, with edge cases, requiring unit tests, etc. then sure. Algorithms are a great example of this.

Using your own example: how many badly written copies of https://github.com/NarHakobyan/underscore.get/blob/master/un... do you want?

It has one dependancy.

No, there are 2 reasons for this dependency creep:

- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.

- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.

Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.

https://blogs.msdn.microsoft.com/webdev/2018/04/17/library-m...

because of that, plus now it is also used for frontend, it is no surprise the "packaging" tool becomes mandatory and complex.

so it's not really webpack's fault.

It also has a fantastic summary at the end describing what's wrong with Webpack and how to write better tools.