2 ms·

Call me old fashioned, but "mission-critical" and "rock-solid" are inherently at odds with anything that runs a on a clients machine. Doubly so for something th

by donatj 7y ago

Call me old fashioned, but "mission-critical" and "rock-solid" are inherently at odds with anything that runs a on a clients machine. Doubly so for something that runs in an interpreted language, especially one that doesn't ship with it's own interpreter to said client. In these cases I'd far rather see an old fashioned reliable server-side application built in a language with a lot of built in safety. The less you ask the client to do, the more reliable the application.

pas 7y ago
Engineering has to consider cost too. Haskell might be amazing at this, but that might cost a lot more. TS sounds like a complicated beast, and of course has a lot of security trade offs (npm, myriad of unverified/unaudited packages), but using TS on both the client and the server makes things simpler, can cut down costs, help with time to market, yadda-yadda. Sure, TS has other problems too. (Soundess issues in its type system.) But still much safer than C/C++ in many aspects. Java might be an old fashioned server-side thing. But again, it has a rather old ecosystem and it's not exactly know for its high quality and security consciousness. Contrast that with Rust, which is young, but tries to (or had already?) establish itself as the de-facto ecosystem for critical/safety/performance things. TS is basically that. Rust for the masses. For anyone who picked up JS and found themselves at end of a bootcamp, or anyone who wants to step beyond being a webdev. So compared to vanila JS (and pure C, and pure python, and maybe even pure Java) TS stuff is rock solid. (Thanks to browser vendors spending a lot on browser/DOM/JS-engine security.) Furthermore. Security _must_ consider ergonomics. Otherwise it will be bypassed. (Eg it simply won't spread, users will work around the secure way, etc.) So if you can simply use the same validation things on your client to provide early in-situ feedback about what's wrong with the input, you can build more robust user interaction flows, which help with people using your secure product.

by donatj 7y ago

pas 7y ago

Engineering has to consider cost too. Haskell might be amazing at this, but that might cost a lot more. TS sounds like a complicated beast, and of course has a lot of security trade offs (npm, myriad of unverified/unaudited packages), but using TS on both the client and the server makes things simpler, can cut down costs, help with time to market, yadda-yadda. Sure, TS has other problems too. (Soundess issues in its type system.) But still much safer than C/C++ in many aspects. Java might be an old fashioned server-side thing. But again, it has a rather old ecosystem and it's not exactly know for its high quality and security consciousness. Contrast that with Rust, which is young, but tries to (or had already?) establish itself as the de-facto ecosystem for critical/safety/performance things. TS is basically that. Rust for the masses. For anyone who picked up JS and found themselves at end of a bootcamp, or anyone who wants to step beyond being a webdev. So compared to vanila JS (and pure C, and pure python, and maybe even pure Java) TS stuff is rock solid. (Thanks to browser vendors spending a lot on browser/DOM/JS-engine security.) Furthermore. Security _must_ consider ergonomics. Otherwise it will be bypassed. (Eg it simply won't spread, users will work around the secure way, etc.) So if you can simply use the same validation things on your client to provide early in-situ feedback about what's wrong with the input, you can build more robust user interaction flows, which help with people using your secure product.