[porker]

As a data point I've just joined a small project which already has a JS framework (Vue) and 2 build systems (1 broken) and the developer has just added React and a third build system. No talk of migration - they're going to run in parallel.

[ratww]

The migration is often also a source of problems in itself.

There's nothing wrong with neither Vue or React, but adding a second one of those for no reason deserves the flogging thing that the grandparent poster is talking about.

Build systems... well they're a dime a dozen and in Javascript all build tools kinda suck (yes, including Vite), but still no excuse for having two.

[wizofaus]

Curious why you suggest all JS build tools suck... previous company I was at had .NET, Java (backend), golang, iOS, Android and JS (react) builds, that all compiled, ran unit tests, packaged and deployed to relevant targets. The react build was the least problematic by far (though we did get bitten on upgrading the host OS which upgraded node to a version incompatible certain older packages being used, but it didn't take too long to fix). Accepted, there was probably a little less functionality in that component than the mobile apps , but iOS was far and away the most problematic, FWIW).

[ratww]

"Suck" doesn't mean "worse compared to others". It means it has problems by itself that I would prefer not having to deal with. Ideally we'd need no build tools for JS. Except for JSX, modern browsers are mature enough. Other languages build tools are often terrible too, the only one I actually enjoy is probably Cargo.

As for the real answer: for trivial stuff, all build tools work fine. For anything beyond that they still have varying degrees of problems. You seem to have encountered those in iOS but not in the JS tool you used. An engineer working on a super vanilla iOS project but a complex JS project would probably say the opposite.

Vite works quite well for most part, but there's still quite a lot that can go wrong with it. It depends on two other build tools (esbuild and Rollup), so some otherwise trivial configurations are difficult and prone to break with upgrades. But for happy-path stuff it works perfectly.

Most of the time a vanilla configuration is fine, but sometimes you have special requirements (sometimes due to vendors or specific technologies) that the younger tools aren't good for, while older tools have their own issues.

[wizofaus]

What's a language for which you don't think build tools "suck" then? Btw another data point is the C++ open source project I contribute to regularly, where I continually have all manner of problems with local debug builds (the CI builds are generally OK except for being unbearably slow, and it's a single desktop application!).

[ratww]

I said it in my reply. Rust/Cargo.

Amusingly, I'm using Cargo and CC for a large C++ project I have. It's unholy and certainly wrong, but works beautifully and is not as bad as every other C++ build tool I have to use.