This sounds more like lack of knowledge/experience of the tooling rather than problems with the tooling itself.
Many build tools will “tree-shake” unused code and support conditionals when compiling their bundles.
Build time varies considerably depending on the tooling you use and the size/complexity of the project, and is definitely much slower than many other languages, but while developing people will use incremental builds which can complete faster than you can type a new statement.
Ignoring the massive vtable problem for a moment ...
If tree shaking is so good, show me how to write something like this:
* when targeting browser, use dom
* when targeting node, use process/fs
* typescript should bail out if a mixture of APIs is used. That is, the type-checking must be done twice - once for browser-only, once for node-only.
(nodejs is also rather abominable for implementing APIs that really, really only make sense in browsers, like `navigator`, breaking everybody's runtime detection, but all non-browser environments require evil hacks anyway)
The obvious way is to use separate configs for each target - most bundlers support running these builds in parallel.
It seems like you are trying to do something in a specific way instead of using the available tooling correctly. That’s not a problem with the tool. You just need to RTFM
As for the “massive vtable problem”, that’s not even a tooling issue. Why are you even using JavaScript if that’s a problem for you.
Many build tools will “tree-shake” unused code and support conditionals when compiling their bundles.
Build time varies considerably depending on the tooling you use and the size/complexity of the project, and is definitely much slower than many other languages, but while developing people will use incremental builds which can complete faster than you can type a new statement.
What other basics are “missing”?