4 ms·

You can use something like JSDoc and achieve basically the same thing, but it's very likely that your developer experience will be way worse as you sort of poin

You can use something like JSDoc and achieve basically the same thing, but it's very likely that your developer experience will be way worse as you sort of point out. If you're a VSC enjoyer your tooling will be absolutely horrible compared to the Typescript tooling. We use Typescript as our general JavaScript "language" but most of our internal libraries are written in actual JavaScript for performance reasons. They key difference is those libraries are worked on by far fewer people.

evilduck 2y ago
My gut reactions would be to still do whatever performance-related weirdness was absolutely required in a Typescript codebase and either alter the .tsconfig to allow for that project's required style, or to explicitly ts-ignore and type cast the output of the hand-tuned performance code while still maintaining type checking surrounding it so I could still easily produce typedefs for consumers. Even keeping TSC as a type checker while dropping it as a compiler would have been on my list of options before eschewing TSC entirely. I'm not here to challenge your decisions, but there's a real dearth of information on this topic and knowing when something applies to your situation is hard. Someone writing a web server has different problems and concerns than someone writing React or Vue websites, or someone processing IO on a microcontroller. Can you go into some details about your situational how and why? I'm curious to hear more about the nature of these pure-JS-for-performance libs and what was measured as non-performant in the TSC output?
- Quothling 2y ago
  You're correct in most scenarios but TSC can be an unwieldy beast when you deal with large amounts of unstructured data. We work with inverter data from solar plants and let's just say that the engineers who build these things aren't using any sort of data standards. TSC falls short (for us) on things like reflection and type transformation. Which means that we have to actually check if TSC does it the way we want it. Maybe you could configure TSC to always do it the performant way, but then you'll have to work with that, and probably still check if it actually worked. For some things we use C (and a few Rust) services with a local cache of data, but there is so much data that we can't do this for everything. In the perfect world, we would handle this on-site (as the inverter manuals will also tell you to do) but that's not what the bosses have prioritized. We've tried getting some standard solutions, that have so far all come up short. As a result we wasted so much money that we could've had a full team of engineers put up an ARM device to deal with data on every solar inverter and still had literal millions of Euro left over... but corporate will corporate. It's not like we aren't still doing TS. We're achieving this through the use of JSDoc (and possibly ECMAScript type annotations in the future). Though a little non-performance related added advantage is that when our developers click on "go to implementation", they'll get to the actual code. It has advantages and disadvantages as I said. You'll really, really, need to know the inner workings of JS to outdo the big transpilers, and you're not getting a lot of help working with it (especially not if you're using VSC). I'm not sure you would want to do this in JS at all for the most part, it's just that we are primarily TS developers. I'm the only one who knows C well enough to use it reliably, as an example. Which isn't exactly "maintainable" for the business. So as I said in at the beginning, I think your gut reaction is correct 99% of the time, but it is an alternative the GP I was replying to asked for.
  - evilduck 2y ago
    Thanks for following up. That helps shed some light on what you"re running into.

evilduck 2y ago

My gut reactions would be to still do whatever performance-related weirdness was absolutely required in a Typescript codebase and either alter the .tsconfig to allow for that project's required style, or to explicitly ts-ignore and type cast the output of the hand-tuned performance code while still maintaining type checking surrounding it so I could still easily produce typedefs for consumers. Even keeping TSC as a type checker while dropping it as a compiler would have been on my list of options before eschewing TSC entirely. I'm not here to challenge your decisions, but there's a real dearth of information on this topic and knowing when something applies to your situation is hard. Someone writing a web server has different problems and concerns than someone writing React or Vue websites, or someone processing IO on a microcontroller. Can you go into some details about your situational how and why? I'm curious to hear more about the nature of these pure-JS-for-performance libs and what was measured as non-performant in the TSC output?

Quothling 2y ago
You're correct in most scenarios but TSC can be an unwieldy beast when you deal with large amounts of unstructured data. We work with inverter data from solar plants and let's just say that the engineers who build these things aren't using any sort of data standards. TSC falls short (for us) on things like reflection and type transformation. Which means that we have to actually check if TSC does it the way we want it. Maybe you could configure TSC to always do it the performant way, but then you'll have to work with that, and probably still check if it actually worked. For some things we use C (and a few Rust) services with a local cache of data, but there is so much data that we can't do this for everything. In the perfect world, we would handle this on-site (as the inverter manuals will also tell you to do) but that's not what the bosses have prioritized. We've tried getting some standard solutions, that have so far all come up short. As a result we wasted so much money that we could've had a full team of engineers put up an ARM device to deal with data on every solar inverter and still had literal millions of Euro left over... but corporate will corporate. It's not like we aren't still doing TS. We're achieving this through the use of JSDoc (and possibly ECMAScript type annotations in the future). Though a little non-performance related added advantage is that when our developers click on "go to implementation", they'll get to the actual code. It has advantages and disadvantages as I said. You'll really, really, need to know the inner workings of JS to outdo the big transpilers, and you're not getting a lot of help working with it (especially not if you're using VSC). I'm not sure you would want to do this in JS at all for the most part, it's just that we are primarily TS developers. I'm the only one who knows C well enough to use it reliably, as an example. Which isn't exactly "maintainable" for the business. So as I said in at the beginning, I think your gut reaction is correct 99% of the time, but it is an alternative the GP I was replying to asked for.
- evilduck 2y ago
  Thanks for following up. That helps shed some light on what you"re running into.