4 ms·

Skew wasn't just a little bit faster than TypeScript. According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enable

Skew wasn't just a little bit faster than TypeScript. According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.

crabmusket 2y ago
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.
- dtech 2y ago
  Take that to the extreme and you get WASM, or it's predecessor asm.js It's also what JITers like V8 internally do, you'll get major performance hits if you do weird dynamic things.
  - hajile 2y ago
    If you want complete type erasure, then a system that ensures monomorphism is critical to good JS performance. If you can leave the type system in place, then you could move toward an ML-style type system and see massive improvements within strictly-typed parts of the code as you'd only need type guards and inline caches at the boundaries of the strictly-typed code.
  - crabmusket 2y ago
    I think taken to the extreme "use strong" is more like putting Dart in the browser. But yes, you can sort of get the benefits of use strong with the right discipline.
  - Dylan16807 2y ago
    > Take that to the extreme and you get WASM, or it's predecessor asm.js Only if your code was pure number crunching. Normal code can't just go through some belt tightening to become WASM/asm.js code. Compiling it down that way is very different from making the control flow more understandable to the optimizer.
- nolist_policy 2y ago
  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. [1] https://evanw.github.io/skew-lang.org/ https://evanw.github.io/skew-lang.org/
  - crabmusket 2y ago
    Forgot to link the "use strong" proposal https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp49nDQMZ1y7fwf5YjaI4/mobilebasic https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...
jeswin 2y ago
> 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.
- 59nadir 2y ago
  > It seems now that it wasn't worth it. 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 2y ago
The 2x speed difference was the most surprising part of the whole article to me! I wonder if it’s possible to limit one’s use of typescript to just the subset that gives that same performance…

Skew wasn't just a little bit faster than TypeScript. According to Evan Wallace (former Figma CTO), it was 1.5x to 2x faster due to better optimizations enabled by stricter type system.

crabmusket 2y ago

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.

dtech 2y ago
Take that to the extreme and you get WASM, or it's predecessor asm.js It's also what JITers like V8 internally do, you'll get major performance hits if you do weird dynamic things.
- hajile 2y ago
  If you want complete type erasure, then a system that ensures monomorphism is critical to good JS performance. If you can leave the type system in place, then you could move toward an ML-style type system and see massive improvements within strictly-typed parts of the code as you'd only need type guards and inline caches at the boundaries of the strictly-typed code.
- crabmusket 2y ago
  I think taken to the extreme "use strong" is more like putting Dart in the browser. But yes, you can sort of get the benefits of use strong with the right discipline.
- Dylan16807 2y ago
  > Take that to the extreme and you get WASM, or it's predecessor asm.js Only if your code was pure number crunching. Normal code can't just go through some belt tightening to become WASM/asm.js code. Compiling it down that way is very different from making the control flow more understandable to the optimizer.
nolist_policy 2y ago
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. [1] https://evanw.github.io/skew-lang.org/ https://evanw.github.io/skew-lang.org/
- crabmusket 2y ago
  Forgot to link the "use strong" proposal https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp49nDQMZ1y7fwf5YjaI4/mobilebasic https://docs.google.com/document/d/1Qk0qC4s_XNCLemj42FqfsRLp...

jeswin 2y ago

> 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.

59nadir 2y ago
> It seems now that it wasn't worth it. 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 2y ago

The 2x speed difference was the most surprising part of the whole article to me! I wonder if it’s possible to limit one’s use of typescript to just the subset that gives that same performance…