21–30 of 147 posts
Earlier quoted context omitted.
Typescript by itself is just the language. You could try a different typescript compiler like esbuild for example.
> However, esbuild does not do any type checking so you will still need to run tsc -noEmit in parallel with esbuild to check types.
This seems like a great time to announce my successor to CoffeeScript: Civet, a language that transpiles to TypeScript. https://github.com/DanielXMoore/Civet
Anders Hejlsberg (Microsoft) and Lars Bak (Google): TypeScript, JavaScript, and Dart
With that said, TS is definitely a blessing; I recently had the privilege of migrating to it after having written a hobby project in plain JS, and the difference in usability between the two is night and day. But I can't help but feel that I've seen this all before years ago in AS3.
We need: - exact object type - match expression flow is still better at: - OO - nominal typing for classes, conforming to liskov substitution principles - first class opaque types - first class exact object types - better flow based inference - comment types - no extra dsl, full access to the language, so simple, so powerfull for the times you don't want transpilation phase - [edit] spread types map to spread in runt…
I don’t understand the benefit of nominal typing when structural typing is available?
The number one problem with typescript is how slow it is. Compiling a 14k line project takes 5s. This is absurdly slow.
[1]https://github.com/microsoft/TypeScript-wiki/blob/main/Perfo...
Given the number of codebases littered with 'any', and the fact that TS is known to produce app bundles that perform slower than handwritten JS code, I'm in two minds about celebrating those ten years... But it is strange to think it's been ten years.
Do you have examples of slower code generated by typescript? TS is a superset of JS so it changing anything that has a large performance impact seems odd, but maybe I’m missing something here. The types aren’t even available at runtime, what’s the biggest slow down you’ve seen?
Also see https://rescript-lang.org/ if you're considering learning Typescript Looking forward to more great ideas in the future of ways to 'fix' Javascript.
Earlier quoted context omitted.
Ts does produce code, ie. for enums, modules/namespaces.
Const enums get completely erased by the compiler, and modules are a native js feature. Non-const enums and namespaces are probably the only aspects of typescript that actually have any significance at runtime, but they get compiled into simple objects. The compiler output is very close to what you'd write by hand. Take a look at this compiler output here [1]. Unless you're constantly recreating enums and namespaces…
We need: - exact object type - match expression flow is still better at: - OO - nominal typing for classes, conforming to liskov substitution principles - first class opaque types - first class exact object types - better flow based inference - comment types - no extra dsl, full access to the language, so simple, so powerfull for the times you don't want transpilation phase - [edit] spread types map to spread in runt…
I don’t understand the benefit of nominal typing when structural typing is available?
This is easily solved by a tagged type in TS [1], though a bit of syntactic sugar over it would be nice.