6 ms·
In other words: JavaScript is fast, JavaScript developers are slow.
by Yahivin 4y ago
In other words: JavaScript is fast, JavaScript developers are slow.
- hajile 4y agoMore 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.
- klysm 4y agoI appreciate typescripts stance to be a non-optimizing compiler. Having two optimization layers would make things weird
- The_Colonel 4y agoI 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.
- k__ 4y agoI had the impression, my code gets less polymorphic when I use TypeScript.
- hajile 4y agoIf 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
- brundolf 4y agoI'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)
- hajile 4y agoJS 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.
- brundolf 4y agoYou could preserve that information and still have the same native struct, since it only becomes relevant when iterating the keys
- klysm 4y agoThis 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.
- hajile 4y agoA linter can't tell if it's polymorphic -- only a compiler which is actually analyzing the types.
- croes 4y agoJust because it can be faster doesn't mean it's fast.
- hajile 4y agoWhen 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).
- maccard 4y agoNo, it's possible to write dodgy code in other languages too - 2 of the examples in this article are in go rather than JS
- deleted 4y ago[deleted]