I've done the whole "I'll write it all in JS by hand" to a ludicrous degree: https://luduxia.com/whichwayround (and the rest) and while there were advantages when this started I am now looking to port the useful bits over to saner ways for future maintenance.
I came from many years of compiled languages in the games industry. I would not assume the current state of React and TypeScript is bad, far from it. There are reasons this stuff has eaten away at more native approaches, or inspired things like SwiftUI.
Edit to add: To also add that in my time I've seen more WebKit added to games in order to do the UI. For instance, that Sim City which was always connected to the cloud, or big bits of the PS4 interface.
To put this in perspective one team I was on built their own Android NDK, until the normal one caught up.
Versatility is one of Javascript's strengths, not a weakness. And with that versatility you get what seems like too many frameworks.
I've been trying to emulate conditional compilation using multiple directories, but that runs into problems with each tool using different path lookup logic.
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”?
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)
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.
For case 2 you can use esbuild, not something like webpack. Sub second builds are completely normal if you pick the right bundler. Tbh esbuild is the killer thing that moved this mode of js development into being acceptable from a total mess.
`tsc` is so slow that it seems the least bad approach in use is "automatically run it asynchronously in the background", which is not confidence-inspiring.
The background asynchronous incremental typechecking is how most typescript devs are working anyway, as issues are immediately highlighted or otherwise output in your dev environment of choice (whether that be inline, or as output in the console).