More like JS doesn't do anything to discourage writing slow code. Typescript should have been that tool IMO, but instead, it is so flexible that it doesn't do a thing to help developers understand that they are writing slow code.

I appreciate typescripts stance to be a non-optimizing compiler. Having two optimization layers would make things weird

I don't think that's what the other commenter suggested. The point is that TypeScript should disallow (or at least make harder) to write code which is hard to optimize by the VM - e.g. allowing function parameters to be of multiple types.

But TS has a design constraint to be essentially a superset of JavaScript so it would be difficult to realize this goal.

I had the impression, my code gets less polymorphic when I use TypeScript.

If only.

This is polymorphic because union types are polymorphic.

    let stringProcessor = (foo: string | number): string => {
      //do stuff with foo
      return "string" + foo
    }

It's super easy to make non-optimized arrays and objects this way.

    type MyFoo = string | number //somewhere in the codebase

    //you will get zero hints that this is a polymorphic function
    let formatFoos = (foos: MyFoo[]) => foos.map((foo) => `${foo} deoptimized`))
    

Any use of optional object properties also immediately leads to polymorphism too. I doubt you can find ANY significant TS codebase where this isn't used pervasively.

    interface Foo {
      foo: MyFoo  //polymorphic
      bar: string
      baz?: number //this is polymorphic too
    }

    let doStuff = (obj: Foo): string {
      //do stuff with obj
      return "string"
    }
    doStuff({bar: "abc"})
    doStuff({bar: "abc", baz: 123}) //we're now polymorphic

Even if we remove the `?`, it can still be polymorphic because the TS compiler doesn't reorder object properties when compiling.

    interface Foo {
      bar: string //all basic types, so we're good?
      baz: number //no more optional, so we're fine right?
    }

    let doStuff = (obj: Foo): string {
      //do stuff with obj
      return "string"
    }
    doStuff({baz: 123, bar: "abc"})
    doStuff({bar: "abc", baz: 123}) //we changed order, so now we're now polymorphic

I'm very surprised the property ordering would matter. Seems like the JS engine itself could easily fix that, no? Silently re-order the properties to fit its own optimization

Do you have a source for the above info? (both because I'm a little skeptical of some parts of it, but also because I'd love to learn more about this topic and I've had trouble finding concrete info in the past)

JS specifies that the order keys are added makes a difference. For this reason, entering them in two different ways is a fundamentally different, non-interchangeable object type.

You could preserve that information and still have the same native struct, since it only becomes relevant when iterating the keys

This seems like a moving target though, and I still don’t think the typescript compiler should be responsible for it. I think a linter could make sense though for obviously bad cases.

A linter can't tell if it's polymorphic -- only a compiler which is actually analyzing the types.

Just because it can be faster doesn't mean it's fast.

When you get down to basics, JS has arrays, structs, ints, floats, and strings+regex (both backed by very fast C++ implementations. If you stick to these things as if they were C analogs, the performance potential is very high.

Viewed in those terms, it shouldn't be surprising that JS can be incredibly fast (faster than C in some cases).

No, it's possible to write dodgy code in other languages too - 2 of the examples in this article are in go rather than JS

really? the article looks all js