typescript-go proves TypeScript is wrong

[hronro]

TypeScript's goal is to make JavaScript scalable, and it did pretty well, like the TypeScript compiler itself, such a complex codebase written in TypeScript, which ends up being transformed into JavaScript, is still maintainable today.

However, when the TypeScript team decided to move the codebase from TypeScript to Go, it basically means that TypeScript can't handle big projects like TypeScript, because it can't solve the performance problem of JavaScript, and as a project gets bigger and bigger, you end up facing performance issues, and so did the TypeScript project.

No offense here, now days there are many TypeScript projects like the TypeScript itself, are all having performance issues, I wonder if TypeScript can provide a way to help them on this, and here are some of my thoughts:

Can TypeScript adds a "native" target, which allows tsc to compile TypeScript code into a native binary, and also adds some new keywords specifically for the native target, like struct for using stack memory (which fall back to plain JavaScript object when targeting JavaScript), and also some keywords for concurrent programming. And also some JavaScript features may need to be disabled when targeting native since it's too flexible be optimized. And maybe some stricter type checking is also needed.

I know it sounds crazy, but here are some key benefits compared to porting to Go:

1. Not only the TypeScript compiler can gain the performance boost, all projects written in TypeScript could potentially gain the performance boost. Many backends are written in JS/TS just because they need to share code with front-end, with the native target capacity, they can compile the same code to JavaScript (or even WASM) for front-end and to native binary for backend.
2. It can still use the existing TypeScript codebase. Porting to Go is already much easier than rewriting from scratch, but reusing the existing codebase would be even easier. There are some other drawbacks to porting to Go as well, e.g. Go WASM performance is not good, so if we want tsc to still run in the browser, either it's even slower than the current TS version, or the team has to maintain TS/Go codebases simultaneously.
3. Microsoft will end up owning the best high-level programming languages of all kinds (C# for VM languages, TypeScript for compile-to-binary languages, and TypeScript for scripting languages).

Please consider this solution, if it becomes true, it will be a huge step for the TS/JS community.

[RyanCavanaugh]

See #537, microsoft/TypeScript#375

We've thought about how "tool to auto-port TS to [arbitrary native target]" might work, as have many other people around the industry, dozens of times. The problem here isn't that no one has thought of this idea, nor tried to think of how to do it, the problem is that... it's more or less impossible. Static Hermes comes somewhat close to this but can't provide much optimization without a ton of constraints that IMO feel very arbitrary in JS land.

and also adds some new keywords specifically for the native target, like struct for using stack memory ... also some keywords for concurrent programming ... And also some JavaScript features may need to be disabled

So the problem is that you have dependencies, and those dependencies aren't going to be written in this subset. Or maybe you disavow deps, at which point, you can and should pick any other programming language (C#, Rust, Go, to name a few?) which is actually designed around the task of being a modern concurrent native language and write your code there.

I'd also observe that being written in Go doesn't make this task a single bit easier, so proposing it specifically now as opposed to any time in the last 12 years doesn't really make much additional sense.

[DanielRosenwasser]

However, when the TypeScript team decided to move the codebase from TypeScript to Go, it basically means that TypeScript can't handle big projects like TypeScript, because it can't solve the performance problem of JavaScript, and as a project gets bigger and bigger, you end up facing performance issues, and so did the TypeScript project.

I think the original intent of "scaling" means something different than what you're pointing out. The original scaling problem is one of code cognition, navigation, maintainability, and collaboration. Writing a complex codebase in JavaScript (or more generally any language!) is difficult, and back when TypeScript was new on the scene, we were seeing more and more complex codebases growing in size. Introducing a type system and tooling solved many of the issues and allowed incredibly great projects like Visual Studio Code to be built. TypeScript
has arguably succeeded very well in that regard. Based on rankings like RedMonk and GitHub Octoverse, and surveys like StackOverflow and State of JS, modern JS developers choose TypeScript by default. Developers like using it, and it is one of the most popular and fastest-growing languages out there.

Now what is absolutely true is that scaling in terms of build speed and code navigation - it could certainly be better. We self-hosted/dogfooded/bootstrapped the compiler and toolset for years and it has let us make TypeScript a truly great experience. But modern compilers can leverage parallelism, and JS has a hard time competing on single-threaded throughput. So we wanted to push the TypeScript experience to the next level, and make it work better while using less resources. If you're building a huge project in TypeScript, you'll really see a big difference. But if you're in a smaller project, things will feel truly frictionless.

When it comes to generalizing TypeScript in such a way where it can grow to a runtime - there are lots of efforts to do something like this. I think they are cool, but to build on what Ryan said, there are some issues around carving the "right" subset that works with JavaScript/TypeScript. As we've mentioned a lot, the choice of language was heavily considered so that we could expedite a porting process to native and get something to TypeScript users as soon as possible. Specifying the requirements for a new runtime and adapting the TypeScript codebase would likely amount to something more like a rewrite plus the enormous task of building a custom runtime.

So what about those other projects? I am excited about the development of shared structs in ECMAScript. There may also be some new optimizations engine teams can uncover. In general though, most of the largest JS apps are in-browser where a custom runtime would not help much (even with wasm). What I do hope is that for those largest apps, a faster TypeScript gives developers that jolt of excitement and makes it pleasant/possible for them to jump into these massive projects and optimize.

[jonghyubkim]

Basically, without Go or C such a native language, how to make it faster than native? For the similar case of AI framework based on python, the code would be ported to C instead of python. The way porting to javascript would be good for the current users with js and ts, but adding many functions and codes in order to increase the perfomance looks not practical for now.

[rmtomal00]

I think you have some lags in VM language. Such as Java and C# they need lot of memory and CPU for run a small project. And their compilation time also much slower then Go.

Go route is the lightweight. It has some problem, i also know but they need fast and minimal language that's Go. Rust also could but Rust has lot of complications.

[Bainainai]

There really isn't any reason TypeScript couldn't have a native target. I'm surprised there are 21 thumbs down emoji and no real showing of support. Scope is a good and valid excuse, however, as keeping a clean, well defined scope has worked really well for the TypeScript language. I am pretty much certain that there will eventually be a good native target compiler for TypeScript, and it is maybe better if it is not tightly coupled to the TypeScript language effort itself.