I really wish browsers had continued to develop a "use strong" mode for JS. It sounded like there were significant challenges, but curbing some dynamism in order for more predictable optimisation sounds like a great tradeoffs for production-quality apps.
Yeah, I wonder where that performance increase actually comes from. This[1] lists their optimizations.
My guess is mainly the integer optimizations. And I guess making sure that functions are always called with the same argument types. The other optimizations is already done by the JITs.
> According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.
It's probably not as simple as that. If hotpaths are optimized, the 2x advantage is quite likely to vanish.
But then one could say - well, you're forced to write optimized JS in several places and that impacts readability. Sure, but the trade off was to use an entirely new compile-to-js language with less tooling support and mindshare. It seems now that it wasn't worth it. The blog post sort of sugarcoats this contentious previous technical choice.
While I'm not going to debate this particular instance, I would caution against assuming all moves (with or without blog posts written about them) are indeed the best and wisest moves that could be made given the situation.
It's incredibly hard to look at our industry at large and declare that teams/companies are doing the best thing they can at any given point (where "best" is defined here as the most prudent thing, all things considered).
crabmusket|1 year ago
dtech|1 year ago
It's also what JITers like V8 internally do, you'll get major performance hits if you do weird dynamic things.
nolist_policy|1 year ago
My guess is mainly the integer optimizations. And I guess making sure that functions are always called with the same argument types. The other optimizations is already done by the JITs.
[1] https://evanw.github.io/skew-lang.org/
jeswin|1 year ago
It's probably not as simple as that. If hotpaths are optimized, the 2x advantage is quite likely to vanish.
But then one could say - well, you're forced to write optimized JS in several places and that impacts readability. Sure, but the trade off was to use an entirely new compile-to-js language with less tooling support and mindshare. It seems now that it wasn't worth it. The blog post sort of sugarcoats this contentious previous technical choice.
59nadir|1 year ago
While I'm not going to debate this particular instance, I would caution against assuming all moves (with or without blog posts written about them) are indeed the best and wisest moves that could be made given the situation.
It's incredibly hard to look at our industry at large and declare that teams/companies are doing the best thing they can at any given point (where "best" is defined here as the most prudent thing, all things considered).
zellyn|1 year ago
I wonder if it’s possible to limit one’s use of typescript to just the subset that gives that same performance…