4 ms·

Could you give some examples of these many missing basics?

o11c 2y ago
Two blatant ones: 1. conditional compilation (typecheck and use these apis only in some environments), and 2. being able to compile "hello world" in under 1 second. I know I keep finding more but these ones I can't even write trivial programs without running into. I've been trying to emulate conditional compilation using multiple directories, but that runs into problems with each tool using different path lookup logic.
- 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 ago
    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)
    - supermatt 2y ago
      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.
- fidotron 2y ago
  For your case 1 my extended obfuscator does do preprocessor style stuff, but that is a giant hack. 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.
  - o11c 2y ago
    The problem with `esbuild` is that it silently does the wrong thing whenever there are type errors. The main job of a compiler is producing error messages; actually producing an output file is secondary. `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.
    - supermatt 2y ago
      You can separate type checking and building. Have tsc to check types and esbuild to build. These can run in parallel, or at different stages of your pipeline. 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).

o11c 2y ago

Two blatant ones: 1. conditional compilation (typecheck and use these apis only in some environments), and 2. being able to compile "hello world" in under 1 second. I know I keep finding more but these ones I can't even write trivial programs without running into. I've been trying to emulate conditional compilation using multiple directories, but that runs into problems with each tool using different path lookup logic.

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 ago
  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)
  - supermatt 2y ago
    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.
fidotron 2y ago
For your case 1 my extended obfuscator does do preprocessor style stuff, but that is a giant hack. 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.
- o11c 2y ago
  The problem with `esbuild` is that it silently does the wrong thing whenever there are type errors. The main job of a compiler is producing error messages; actually producing an output file is secondary. `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.
  - supermatt 2y ago
    You can separate type checking and building. Have tsc to check types and esbuild to build. These can run in parallel, or at different stages of your pipeline. 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).