4 ms·

I see type safety as akin to the “Swiss cheese” model in aviation safety. It’s creating one more barrier against accidentally crashing your application. The th

I see type safety as akin to the “Swiss cheese” model in aviation safety. It’s creating one more barrier against accidentally crashing your application. The thing with type safety is that systems like typescript are so easy and cheap to deploy, relative to E2E or even unit tests; it’s a small investment that pays off in multiple ways over time (quality, documentation, developer onboarding). I really struggle to understand the sometimes vehement arguments against it. https://en.m.wikipedia.org/wiki/Swiss_cheese_model https://en.m.wikipedia.org/wiki/Swiss_cheese_model

SkyPuncher 3y ago
Our team actually dropped FE testing entirely with Typescript. We found that our E2E tests took way too long to write and didn’t really cover the visual defects we often hit.
- qudat 3y ago
  We definitely skip all automated tests with the exception of integration testing by mounting the app and robo-interacting via jsdom. I think our BE engineers are surprised by the lack of testing while at the same time rare runtime exceptions. We have enough critical flows tested and with TS to prevent runtime errors, we have a decent degree of confidence. If only we had a good way to test webauthn…
  - tmikaeld 3y ago
    > If only we had a good way to test webauthn Preach, we had to check the source of the official test suite to figure out how to test it.
johnnyworker 3y ago
Make it part of the Javascript standard and see me using it the second Firefox supports it. Are there any arguments against that?
- doctor_eval 3y ago
  The only real argument is an argument against waiting. Most developers would need to wait until all browsers support it, and the vast majority of users use it, and you could easily be looking at a decade of lost opportunities while you wait for that. That said, in a world of impending WASM, I don’t even know if TS on the browser makes sense. It seems like it won’t be long and we won’t need a JavaScript intermediary between TS and the browser at all.
  - conductr 3y ago
    I’m not a pro and don’t follow the development closely, but that said, I feel like I’ve been hearing about impending WASM for about 10 years
    - doctor_eval 3y ago
      Nah, it’s well and truly in production now. There are new features needed to support some languages better, and closer integration with the DOM may arguably be desirable, but my understanding is that it’s at the point where heavy lifting can be done in wasm, with automatically generated JS stubs. I might be wrong (not a front end specialist) but ISTM that a native TS implementation built today would more likely be a compiler to WASM than try to become a first class browser language. And anyway, direct browser support for TS would take as long as WASM has taken to gain broad support.
    - glimshe 3y ago
      This year is the year of WASM on the browser!
- uranusjr 3y ago
  Welcome to the Python community, where type highlighting is a first class syntax feature, but actually checking it is optional (unlike the TypeScript compiler), and you get people complaining their favourite languages is polluted by ugly stuff they don’t ever use (presumably) hurting readability. You can’t please everybody.

SkyPuncher 3y ago

Our team actually dropped FE testing entirely with Typescript. We found that our E2E tests took way too long to write and didn’t really cover the visual defects we often hit.

qudat 3y ago
We definitely skip all automated tests with the exception of integration testing by mounting the app and robo-interacting via jsdom. I think our BE engineers are surprised by the lack of testing while at the same time rare runtime exceptions. We have enough critical flows tested and with TS to prevent runtime errors, we have a decent degree of confidence. If only we had a good way to test webauthn…
- tmikaeld 3y ago
  > If only we had a good way to test webauthn Preach, we had to check the source of the official test suite to figure out how to test it.

johnnyworker 3y ago

Make it part of the Javascript standard and see me using it the second Firefox supports it. Are there any arguments against that?

doctor_eval 3y ago
The only real argument is an argument against waiting. Most developers would need to wait until all browsers support it, and the vast majority of users use it, and you could easily be looking at a decade of lost opportunities while you wait for that. That said, in a world of impending WASM, I don’t even know if TS on the browser makes sense. It seems like it won’t be long and we won’t need a JavaScript intermediary between TS and the browser at all.
- conductr 3y ago
  I’m not a pro and don’t follow the development closely, but that said, I feel like I’ve been hearing about impending WASM for about 10 years
  - doctor_eval 3y ago
    Nah, it’s well and truly in production now. There are new features needed to support some languages better, and closer integration with the DOM may arguably be desirable, but my understanding is that it’s at the point where heavy lifting can be done in wasm, with automatically generated JS stubs. I might be wrong (not a front end specialist) but ISTM that a native TS implementation built today would more likely be a compiler to WASM than try to become a first class browser language. And anyway, direct browser support for TS would take as long as WASM has taken to gain broad support.
  - glimshe 3y ago
    This year is the year of WASM on the browser!
uranusjr 3y ago
Welcome to the Python community, where type highlighting is a first class syntax feature, but actually checking it is optional (unlike the TypeScript compiler), and you get people complaining their favourite languages is polluted by ugly stuff they don’t ever use (presumably) hurting readability. You can’t please everybody.