Vercel has previewed Scriptc on GitHub, a native compiler for TypeScript which is open source under the Apache 2 license.
Scriptc takes TypeScript code as input and outputs a native code executable, along with an embedded JavaScript engine if needed, using the existing QuickJS ng project. The JavaScript engine is needed if there is code included that cannot be statically compiled, including JavaScript code, such as npm dependencies, or code typed as “any” in TypeScript.
Scriptc runs on Apple Silicon and uses cross-compilation to target Linux and Windows. The project claims some big improvements in performance: startup time for an example workload reduced from 47ms to 2.4ms, memory usage down from around 100MB to 4MB, binary size reduced from around 80MB to 3MB.
The Node.js API is supported as well as the TypeScript language and the idea seems to be that server applications running on Node could be compiled to native using this tool.
Although this sounds promising, comments on Hacker News are not entirely favourable. “The architecture is idiotic, they have zero credible perf numbers,” said one, claiming that the “project reeks of weapons grade AI psychosis.” Expanding on this, complaints include the use of QuickJS, using floats for numbers, and resorting too quickly to an embedded JavaScript engine.
Vercel as a company is enthusiastic about AI and Scriptc appears to have been made largely with AI.
When Microsoft introduced a native code TypeScript to JavaScript compiler in TypeScript 7, greatly reducing compilation time, the awkward question was: if native code is so much faster than JavaScript, why not use a more performant language for the application code as well?
How did we get here? It all started with Brendan Eich’s LiveScript for Netscape Navigator, renamed JavaScript when first released in December 1995, and the beginning of interactive web pages. Part of the thinking behind JavaScript was that it could be used to script Java applets – Java components embedded in web pages – but JavaScript itself was always more popular. Adobe used a variant of JavaScript, called ActionScript, for its Flash add-in which at one time looked likely to dominate the web.
Using the web browser as an application runtime was critical for companies trying to bypass Microsoft’s desktop application dominance, and Google in particular invested in JavaScript, creating the V8 JavaScript engine for its Chrome browser, first released in 2008.
Then came Node.js, a server-side runtime for JavaScript based on V8 and first released in 2009 by Ryan Dahl. Dahl was particularly interested in improving concurrency in web applications, but another thing that drove adoption was that developers could use the same language both on the server and in the browser, and that JavaScript was an easy language to learn.
The mass adoption of JavaScript that followed also exposed its shortcomings. Microsoft’s Anders Hejlsberg, who also invented the C# language, believed that strong typing for JavaScript was essential in order to make large applications maintainable. He therefore came up with TypeScript, a superset of JavaScript with strong types that compiles to JavaScript for runtime compatibility.
TypeScript has proved wildly popular and most applications which target JavaScript are now written in TypeScript. If we add Scriptc or an equivalent into the mix, then the JavaScript element is all-but eliminated, though note that as currently designed Scriptc will run some of the code in a JavaScript engine so we are not there yet.
If you write in TypeScript and compile to native code though, why use TypeScript, why not use Go or Rust? Or if those languages are too demanding, Java or C# both of which have strong ecosystems?
The answer is the familiarity of TypeScript, the massive range of npm packages, and the ability to use the same language on the server and in the browser.
Nevertheless, the problem which Scriptc sets out to solve can perhaps be bettered simply by choosing a more performant application stack and reserving TypeScript for code that runs in the browser.