[hudo]

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tutorials (unofficial blog posts) on internents, none of them work. Front end dev work is broken.

Also, funny experience: asked few senior FE devs how to configure React, webpack and TS manually, absolutely nobody could do it.

[blenderdt]

Not only this. Try to change the app two years later. Dependencies gone, wrong NPM version, Webpack config depricated and what not.

That's why I like to use vanilla JS as much as possible. It will be maintainable years later.

[8bitsrule]

And even then, browsers will probably respond differently.

After a recent FF upgrade, it balked at JS that worked fine for years ... on occasion, not always ...because: navigator.onLine === true, internet.connection === false.

[iamsaitam]

Yes, if you don't fix your dependencies. But that will happen in any language.

[threads2]

Always wanted to learn about webpack - doesn't feel good using CRA (create-react-app), needing to configure webpack, ejecting CRA, and then being the "owner" of the config without knowing anything about it - thanks for the impetus.

[btbuildem]

The best part: all of the utils in the tool chains "evolve" and so your one script has to be regularly modified and kept up to date. A project that "just worked" but has been on ice for several months, will now not even build after you pull updates etc. It's infuriating. I used to work on a front-end team, and a good 20% of our time was spent babying the build chain, I kid you not.

[maxloh]

It is not quite hard to learn actually. You just need to go through the webpack Concepts section[0]. Documentations in the JavaScript ecosystem are quite good and explanatory compared to other languages (like Java).

Not every front-end developers learn the internals of the tool they chose, like create-react-app. Most of them settled down if the solution "just work".

[0]: https://webpack.js.org/concepts/

[lucidguppy]

X is not hard, you just have to Y.

Be careful of these statements, you have to understand why a person says X is hard. The OP stated he did extensive work trying to get it to work and found it difficult.

You posted one link out of thousands. When talking about these things - its not like there's a problem with one solution.

There's one problem with thousands of answers that are frustratingly close to correct, but not correct.

That's why X is hard.

[BigJono]

That "one link out of thousands" is the first page of the official docs for pretty much the only complex bit of getting started doing frontend.

If people are getting stuck because they're trying to get into something by following a "Frontend stack in 10 minutes!" blog post that introduces 10 dependencies and aims to skip all the actual learning bit in the interest of "getting up to speed" then they fucking deserve to get stuck.

There's only thousands of answers because everyone is too stupid to just go and read the obviously correct one and thousands of people try and exploit that for some industry cred or something.

[fendy3002]

I agree with this view, but not everything is black and white. Webpack is hard because it's a tooling, and a big and complex one at that. And usually it lacks resources other that official documentations in which can be used to learn/debug it.

However your view is also correct. They're too overwhelmed with the capabilities and complexities of webpack that they missed how there are hundreds of working webpack configuration for react etc, that they can use as reference, or how easy it is to be configured when you follow the tutorial and know what is babel, loader, presets, etc.

[TameAntelope]

Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit.

Also Parcel is easier by a factor of 10, skip Webpack entirely.

[dahauns]

>Having just gone through all of this (two years ago), it isn’t “hard”, you just have to stop assuming it’s easy and will only take a bit.

So it isn't hard - it's just not easy and it's time consuming. Wait, what?

[TameAntelope]

Correct, I deal with "difficulty" as a spectrum. The consensus so far here seems to be that this is "hard". I disagree, I think it's not "easy" but surely not "hard" either. Somewhere in between, leaning closer to "easy".

Mostly it takes the willingness to learn and patience to recognize that it's a whole class of knowledge, separate from actually writing a javascript app.

[dahauns]

Ok, I see where you're coming from. I'd call that "tedious" and "taking up a lot of time I'd rather spend productively". ;)

But snark aside - good point with the reference to Parcel. I haven't had time yet to delve into the new generation of JS tooling that have come up in the last few years, but yeah - its approach looks much saner. (vite also looks promising.)

Its' just...sigh maybe I'm just a bit jaded WRT to project age/maturity. I mean, it's only 4 years old! At least it has a V2 already. ;)

[throwaway4aday]

Webpack can be rather complex but that's because you can do a lot with it. It's not really any harder to learn than any other piece of software and the person you were replying to is correct in referring to the official documentation. If you go through the official tutorials you will come out the other end knowing perfectly well how to configure it from scratch.

If you don't want to dedicate a few hours to learning Webpack and your goal is to just set up a basic React + Typescript app then I'd strongly encourage using an opinionated bundler that provides standard templates for setting up such a project. Vite is very good for that https://vitejs.dev/guide/#scaffolding-your-first-vite-projec... you should be able to just type a few lines in the shell and be up and running.

[zelphirkalt]

This works until you need to have one tiny thing different than the standard path, that a tool implements. Usually the problems come, when you do not want to do the thing "everyone else" does, but want to avoid some downside of that mainstream approach.

The contrast is other programming language ecosystems. Once you understand how they look up modules from which to import things you need, you are set and can deliver a working program. Not so in JS. Multiple half backed module systems and for a long long time no proper support for modules in the browser, so that things like requirejs had to be shipped, in order to have modules working. All of that is a huge crutch and hack. Also it is mostly unnecessary. It is not like JS apps do sooo much more than traditional desktop apps. It is their dependencies, which make the load big. That in itself is a problem, which then creates the problem of "Oh I must minimize my JS files!" and that creates the need for a tool and then we get to a place, where we have things like webpack, which you configure for a day and no guide does exactly what you want to do in your project. You might even find out, that webpack cannot do what you need it to do, because of being "opinionated". Then you might look for the next tool and the cycle starts again. I have experienced very little of that nonsense in any other ecosystem. Most do not deal with the same problems, because they avoided getting into those problems in the first place and they do not have to deal with a badly designed language as a basis.

In the frontend development world you might even run into people integrating things like webpack into projects needlessly, say a plain JS project of a few files under 100kB, just because they always do, and because of silly project standards they have. In some way we were better off when JS was simply in a script tag and you had to put the script tags in the correct order. None of the webpack and similar tool overhead was there. Heck, those tools even seem to encourage people to include more and more stuff into their projects, because they think, that webpack and similar tools will magically fix it all and make all their code small in size when delivered. Over time this grows into multiple megabytes bundled minified unreadable JS crap.

[throwaway4aday]

> Once you understand how they look up modules from which to import things you need, you are set and can deliver a working program

Sure, being restricted to a single paradigm can simplify things in this regard but it comes with its own set of problems. I've used build systems and package managers for C/C++, Nim, D, Python and a number of others and they all come with their own headaches, learning curves, bugs, and WTFs. Software is never perfect, documentation is incomplete and inaccurate and sometimes shit just doesn't work the way you need it to. You can write terrible code in any language, if you need proof just do a filtered search on GitHub for your language of choice and page through some of the projects. I don't think JS is any more at fault than the rest, it just has more people learning it and hacking things together so you see more of it. It's not the programming language's fault if you write bad code, that's always up to your own proclivities and time constraints so I don't think we should try to pin it on the existence of such and such a module or library or the design of the package manager.

The hugely positive side is that there are a large number of people in the JS ecosystem actively trying to solve these problems and also educating others on how to solve their own. It's a bigger tent than any other programming language I've used, more active, welcoming, less judgemental and more beginner friendly. For people just beginning programming I'd still recommend starting with JS for those reasons.

[s__s]

He’s saying X is not hard if you read X’s docs.

I don’t think that’s unreasonable.

What’s unreasonable is this culture in web dev that you shouldn’t have to read the docs!

[dahauns]

You're kidding, right? Just going through the Concepts of webpack doesn't even scratch the surface - and will arguably leave many unsuspecting devs more confused than before, by e.g. still insisting on calling itself a "module bundler". You're a build system, ffs!

[maxloh]

You cannot learn programming just by reading. Try using it in practice. The concepts part should be enough to get you started for a simple vanilla JavaScript project.

If you need more (e.g. TypeScript/JSX/CSS support), You will need some third-party loaders or plugins. webpack itself is just a JavaScript bundler.

[dahauns]

Well duh.

So it's "You just need to go through the webpack Concepts section"...except if you want to actually do some work with it.

See, that's the thing:

If like OP you are an experienced developer freshly coming to web frontend development, the Concepts pages of the webpack docs will tell you very little that you'd find unfamiliar. It's stuff that you've seen a variation of in countless other build systems. (At least that's how it was with me all those years ago.)

But as the docs themselves say: "Plugins are the backbone of webpack". And that's where Pandora's box opens...and where the designation as "just a JavaScript bundler" becomes ridiculous.