Bigger TypeScript projects should now become much more manageable in all code editors
Eh, not entirely. Typescript will build faster and the text editor can parse it quicker but once it hits the browser no speed is gained. It’s kinda stated in the article but it dances around it quite well I wouldn’t blame you for missing it.
This just makes transpilation quicker along with some other benefits while working with it in editor. It’s still just JavaScript in the end this just gets it there quicker. Still very cool though.
Extremely click bait title by the article author.
by microsoft. they used a similar headline for their YouTube video announcing it.
I feel this should be obvious to anyone who knows anything about programming, because typescript is just a development tool not a runtime.
I… Don’t know about that. I mean, you could implement a browser or even a runtime library that used typescript (or a subset thereof) to directly write LLVM; it would take a lot of work, but typescript doesn’t have to just be for transpiling.
But there is no such implementation AFAIK? How is it making Typescript faster if it’s a completely new implementation?
But certainly, in theory it could become unshackled from JavaScript. Have there been any serious attempts to do so though?
But there is no such implementation AFAIK? How is it making Typescript faster if it’s a completely new implementation?
Well a new implementation running TypeScript could be 10x faster than the traditional e.g., NodeJS implementation or something; it’s not unusual for things to be compared in such a way.
But certainly, in theory it could become unshackled from JavaScript. Have there been any serious attempts to do so though?
No idea! :)
There is a serious attempt for that actually: https://www.assemblyscript.org/
It doesn’t offer full compatibility with the regular TypeScript though, despite being very similar.
Nice! Thanks for sharing
That would be very difficult because Typescript isn’t sound.
TypeScript is a language, and traditionally languages are considered separate from their implementations. When I first saw the headline I hoped maybe it meant a non-JS runtime for compiled TS, and I’m well aware of the difference. Yes, that would be a much larger undertaking than porting the compiler to a new language, but the headline doesn’t indicate how large a project this is, and Microsoft certainly has the resources to write a new backend (even a native-code one) for the TS compiler.
Yeah, the article comes off as needing so much context that the article itself is sus. Like
Hejlsberg stated the obvious when saying that TS isn’t the fastest language. Although it can laughably run Doom at 0.0000009645 fps.
… which is referencing an implementation of Doom in the TS type system. It’s a funny idea, but an arbitrary reader who doesn’t know about that and doesn’t bother clicking through will get a very wrong impression.
The reimplementation (which they’ve done partially automated; Go apparently lets them do a very simple translation while Rust or C# would require more work to fit) should be a boon for TS devs, but not noticeable for those who just run stuff that happens to be written in TS.
Would be kinda interesting to see the effect if stuff targeted
denorather thannode, though.Thank you. I was wondering just that.
this probably won’t change anything for end-users, but transpiling 1.5M LOC from TS in 5.7s is pretty impressive.
The announcement blog post: https://devblogs.microsoft.com/typescript/typescript-native-port/
I feel like I’ve seen this headline about 15 times already
