3 ms·
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
by supermatt 2y ago
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.
What other basics are “missing”?
- o11c 2y agoIgnoring 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)
- supermatt 2y agoThe 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.