One Language, No Runtime: Compiling a TypeScript-like language to Native

A developer at a recent SQ Collective demo day, Son, presented a compiler project with a straightforward demonstration. On the screen was a code sample written in a language that looked like TypeScript. He explained that his toolchain could take this single source and go in two completely different directions. One path transpiled it into normal JavaScript, runnable in any web browser. The other path was more direct. It compiled the code into C, which then became a native binary. He ran it, and a simple message printed to the console. "So this is not JavaScript," Son clarified. "It is a C program that runs and brings out the message. So that is the idea that we have, to write a script as we normally do and then compile and run it as a system language."

The project’s goal is to remove the layers between a developer’s high-level code and the machine it runs on. It takes the familiar syntax of a web language and gives it a path to native execution, aiming to eliminate the need for a JavaScript runtime on platforms from servers to mobile devices.

The Native Path and its Memory Model

The core of the project is its ability to generate C code. This isn't just a translation. It fundamentally changes the code's relationship with the underlying system. By compiling to a native binary, the program runs directly on the hardware without an intermediary like a JavaScript engine. This has significant implications for performance and memory management.

Son explained that the resulting native binary operates without a garbage collector. In many managed runtimes, garbage collection can introduce overhead and unpredictable pauses, as the system has to stop and clean up memory. This project avoids that. Instead, it uses a memory management strategy he described as "similar to the way that Rust managed to manage the memory." This deliberate choice signals a shift in philosophy away from the managed environments of most modern web development. The ambition is to offer system-level control while maintaining a high-level developer experience. As Son put it, "what we are trying to do here, is to eliminate the runtime."

A Vision for Multiple Platforms

This approach opens a path toward using a single language for a wide array of targets. Son listed a broad set of platforms where this code could run. "We use one to use to write the 3 stuff on desktop, on macOS, windows," he noted, adding, "with the same code base we can also run it on browsers." The vision extends beyond traditional computers. The same TypeScript-like language could be used for server-side components or even for applications on IoT devices.

This is an ambitious goal. The project points toward a future where developers could use one familiar language to build a web application, a server-side API, a native desktop program, and code for an internet-connected device. While the transcript does not claim a single codebase can already do all of this seamlessly, it presents a clear direction: using one language to rule them all, reducing the need for context switching between different programming environments for different parts of a product.

Native UI, No JavaScript Engine

The most concrete example of this vision was in user interface development. Son showed how the language could be used to write UI code in a declarative style familiar to web developers. "It's pretty similar to how we normally write UI in the directs," he explained. The key difference is what happens under the hood. While this code can be compiled to JavaScript to run in a browser, it can also be compiled into a fully native mobile application.

Crucially, that native application does not need to bundle a JavaScript engine like V8 to execute its logic. Son acknowledged the standard approach for running JavaScript-based code on mobile, noting, "on mobile, we can use V8 engine. So it has a long, tight script on JavaScript runtime." His project bypasses this entirely. The UI code is compiled directly to a native binary that runs on the mobile hardware. "We don't need to have the runtime. So it has platform performance." This delivers a tangible payoff, connecting a high-level, productive developer experience with the low-level performance and responsiveness of a truly native application.

System-Oriented by Design

During the Q&A session, a question from the floor asked for a comparison to another project in the TypeScript-to-native space. The specific project name was unclear in the recording, but Son’s answer revealed a core architectural decision. He contrasted his approach with projects that try to maximize compatibility with the existing JavaScript and TypeScript ecosystem. "I think the difference is that what we're trying to do is they're trying to maximize the compatibility," he said.

His project makes a different trade-off. "The most interesting thing is that we are super set of a script," he explained. By being a superset, the language can add features that don't exist in standard JavaScript, like distinct number types for integers and floats. "In the script, we only have numbers. We don't have an int or a flow." This extra information allows the compiler to generate more efficient, system-oriented code. "It's very much trying to become system-oriented. We're not trying to compatible with that script." The interesting tradeoff is adoption versus control. While full compatibility lowers the barrier for new developers, creating a superset gives the language more power and control at the system level, prioritizing native performance over fitting neatly into the existing web ecosystem.

A second question from the audience pushed this idea further, asking about a future where the same language could enable communication "between browser, edge, and factor... and different devices." Son embraced the idea, connecting it to a larger shift in computing. "Now we have AI," he said. "Normally, we've designed for human-driven, directly computers. Now we have AI. So, AI work with a computer in a different way." He suggested that our existing design patterns were built for a pre-AI world. This project, by creating a single, system-oriented language that can run anywhere, might provide a better foundation for building the kinds of distributed, AI-driven applications that are now emerging. A previous post exploring The Opportunity of Being Human in the Age of AI suggested that the most meaningful new platforms will be those that understand users as multifaceted people rather than simple profiles.

The thing to watch is whether this compiler can deliver on its ambitious cross-platform promise. Can a single language effectively serve the different needs of a browser, a mobile app, a server, and an IoT device without compromising its performance goals? Son's approach is a powerful answer for builders who feel forced to choose between the high-level abstractions they love and the low-level performance their products demand. Its most interesting potential may be in giving builders a new toolset for an AI-native world.

---

SQ Collective hosts Coworking Fridays for founders, operators, and AI builders working through real product questions in Singapore.

Join an upcoming Coworking Friday: https://lu.ma/ai-labs

Explore SQ Collective: https://www.sq-collective.com

Michael