It's different from using a C++ compiler to build a Qt application because it's in the opposite direction. Qt is a toolkit that lays on top of C++, which your compiler translates to machine code. Qt is still C++. Everything is the same language and gets compiled directly into the code that the machine knows how to execute.

With JavaScript transpilers, this happens in reverse; there is an entirely separate secondary language loosely bolted on here, which compiles to JavaScript, which compiles to some IR, which compiles to machine code. From the developer point of view, the code they wrote in the top-level language executes as JavaScript, not native code, and must be debugged at that level.

I'm sure you're not actually naive enough to pretend this is the same as using a library like Qt. Language semantics are very different and can be difficult and bug-prone to cross-implement. Third-party libraries and modules have large, potentially interdependent module webs that have to be resolved and will often result in massive includes on such transpiled pages (talking 10M+). Bugs at runtime will have to be debugged as the transpiled language, not as the code you originally wrote.

If you use Qt, everything is written in the same language, built by the same compiler, and that language's typical pipeline, including dependency resolution, is unaltered. Bindings in non-reference languages link out to shared objects that do not use transpilation, but long-established and well-understood OS-level linking conventions. This is a greatly reduced complexity surface (== fewer bugs).

My experience with transpilers is that people avoid them whenever possible because they introduce very intricate and difficult-to-use bugs. Now that I think of it, the most well-known transpilers are specially-made to service a large project's needs, like the recently-announced Grumpy [0], which converts YouTube's Python codebase to Go.

[0] https://github.com/google/grumpy