A lot of people are trying this now with AI, a native TypeScript compiler, for example https://github.com/PerryTS/pry. It's a compelling value proposition, TypeScript is already well typed and barring a few cases it can be turned into machine code without a JS runtime.
Porforr<https://porffor.dev> has been working towards the same goal for a while. The creator, CanadaHonk<https://honk.foo>, is extremely talented and the project still only passes ~68% of Test262. I'm more than a little suspicious of how Vercel has made so much progress so fast, unless I'm misunderstanding the scope of this project.
One of the strengths of TypeScript besides its expressiveness is that it's compatible with the massive npm ecosystem. Most packages only ship untyped JavaScript with type declarations defining the interface,[0] so realistically you'd still need a JavaScript engine if you use any packages.
But if you're starting from scratch and know you won't be using any npm packages, you might as well use AssemblyScript.[2]
[0]: Publishing packages in TypeScript is explicitly discouraged by Node[1]. TypeScript isn't backwards compatible even in minor releases, and its compiler settings aren't portable for packages.
Funny to see vercel is loosing all credibility under the influence of AI.
Never liked their products anyway, so I believe it's a net positive for the industry :)
Im 99℅ certain this could not handle an Electron project.
The use case, imo, is to be able to write server side code in familiar TypeScript, then deploy it as a small single native binary (vs Node and Bun which embed the entire 100MB+ runtime when you build a native binary.) Electron for the record ships their own modified Node runtime (not ABI compatible) on top of the whole Chromium renderer
Vercel sloping it's way to clout again, they do this every month or so, clearly they want to stay in the news and some how credible and relevant.
I can't think of any serious company or project that would use this thing.
P.S: I just checked the contributors list, I have the utmost respect to them (notably simonw), but clearly this code is claude'ish but it is not among the contributor which makes it even more suspect.
We are increasingly using a subset of typescript in our backend so as to be amenable to a tool, in the long run, which can convert the ts subset to rust source code.
This project will enable an alternative of that vision earlier - except of course without the parallelism.
Also I am curious as to whether this will compile to a static lib which can be linked to an existing cpp app to be run on android/ios targets. In theory it should be able to. The docs mention ffi, but I didn't dig deep.
I have forked Fabrice Bellards QuickJS and extended it heavily to adopt anti-npm/node stance.
all of the essential standard lib and top npm packages will be built natively in C17 with every build and minor release focred through CPU, IO and memory profiling.
Currently it supports MacOS and Linux, FreeBSD and Windows in future.
I desperately want to see some of these projects used in production by the companies or people making them, at best it might prove that it isn't just a sloppy publicity stunt
It's nice they acknowledge and confirm the need for small, fast native executables.
Having followed the story for this in Java over the decades I'm skeptical about the practicality.
GCJ existed in the 90s and the technology was good, but there was no ecosystem support.
After many small steps between GraalVM Native finally tackled the problem more holistically and the ecosystem followed. All the major libraries and frameworks put effort into being GraalVM compatible.
And, still it's a major pain to make even simple existing applications run flawlessly natively.
I'm glad something like scriptc exists but I'm afraid until this is of practical use it will be s long thorny way.
I think the Graal team was also trying to take a meta-interpreter approach like this too. For cases where you need to dynamically load bytecode or do reflection where native couldn't handle it they would try to interpret with their espresso java implementation.
this is enough to keep them on the first page of HN and similar services. Its a growth strategy: invest tokens, build some "nice" project nobody wants, get some reach through publishment. Rinse and repeat.
Heads up, in 12 months from now, 90% of open source projects will be vibecoded, without actual users - only looking "interesting" (if not already?).
Its easy to vibe code a full blown compiler these days, the question is: will it be maintained? A catchy title is not enough to get sticky users, long term maintenance, community around the project is (or at least used to be).
Having said that, the only viable reason for these kind of projects I see is getting attention for a moment, boosting reach of Vercel logo across the web and then disappearing (or stop development).
If Vercel would think seriously about this project: they would show skin in the game - for example implement it as their own experimental runtime.
I've heard stories like this before, how one or a few people miraculously coded up an alternative to Node.js. But can you name even one that actually works properly in production? Not a single one.
Take Bun, for example. Nobody is actually running it in production as a runtime. Why? Memory leaks and a whole bunch of other issues. I've personally tried it multiple times, and something always breaks. Come on, it's just not that simple.
Sure, you can build something that has similar interfaces and even works to some degree. But making a production-ready solution is a completely different level of complexity. There's that well-known chart where the first 90% of implementation happens almost instantly, and the remaining 10% takes forever to polish out all the rough edges.
On one hand, I really like the idea, and I've always wondered why TypeScript doesn't compile to native code. On the other hand, I'm quite skeptical that Vercel can actually pull this off. I'd be happy to be proven wrong, but I have very little faith in it.
Either way, good luck to them, but honestly, even if they succeed, I probably won't use it. Knowing their track record with vendor lock-in and Next.js, where they do everything possible to push you onto Vercel Cloud — no thanks.
40 comments
[ 2.2 ms ] story [ 42.0 ms ] threadBut if you're starting from scratch and know you won't be using any npm packages, you might as well use AssemblyScript.[2]
[0]: Publishing packages in TypeScript is explicitly discouraged by Node[1]. TypeScript isn't backwards compatible even in minor releases, and its compiler settings aren't portable for packages.
[1]: https://github.com/nodejs/node/blob/main/doc/api/typescript....
[2]: https://www.assemblyscript.org/
whats the use case for this , make it hard to reverse engineer my node projects?
The use case, imo, is to be able to write server side code in familiar TypeScript, then deploy it as a small single native binary (vs Node and Bun which embed the entire 100MB+ runtime when you build a native binary.) Electron for the record ships their own modified Node runtime (not ABI compatible) on top of the whole Chromium renderer
I can't think of any serious company or project that would use this thing.
P.S: I just checked the contributors list, I have the utmost respect to them (notably simonw), but clearly this code is claude'ish but it is not among the contributor which makes it even more suspect.
We are increasingly using a subset of typescript in our backend so as to be amenable to a tool, in the long run, which can convert the ts subset to rust source code.
This project will enable an alternative of that vision earlier - except of course without the parallelism.
Also I am curious as to whether this will compile to a static lib which can be linked to an existing cpp app to be run on android/ios targets. In theory it should be able to. The docs mention ffi, but I didn't dig deep.
Also, does "Linux and Windows binaries build by cross-compilation" mean that you can't run it on non-MacOS? If so, that's pretty lame...
I have forked Fabrice Bellards QuickJS and extended it heavily to adopt anti-npm/node stance.
all of the essential standard lib and top npm packages will be built natively in C17 with every build and minor release focred through CPU, IO and memory profiling.
Currently it supports MacOS and Linux, FreeBSD and Windows in future.
https://github.com/corporatepiyush/dynascript
API reference : https://github.com/corporatepiyush/dynascript/blob/master/do...
Having followed the story for this in Java over the decades I'm skeptical about the practicality. GCJ existed in the 90s and the technology was good, but there was no ecosystem support.
After many small steps between GraalVM Native finally tackled the problem more holistically and the ecosystem followed. All the major libraries and frameworks put effort into being GraalVM compatible.
And, still it's a major pain to make even simple existing applications run flawlessly natively.
I'm glad something like scriptc exists but I'm afraid until this is of practical use it will be s long thorny way.
Heads up, in 12 months from now, 90% of open source projects will be vibecoded, without actual users - only looking "interesting" (if not already?).
Its easy to vibe code a full blown compiler these days, the question is: will it be maintained? A catchy title is not enough to get sticky users, long term maintenance, community around the project is (or at least used to be).
Having said that, the only viable reason for these kind of projects I see is getting attention for a moment, boosting reach of Vercel logo across the web and then disappearing (or stop development).
If Vercel would think seriously about this project: they would show skin in the game - for example implement it as their own experimental runtime.
Take Bun, for example. Nobody is actually running it in production as a runtime. Why? Memory leaks and a whole bunch of other issues. I've personally tried it multiple times, and something always breaks. Come on, it's just not that simple.
Sure, you can build something that has similar interfaces and even works to some degree. But making a production-ready solution is a completely different level of complexity. There's that well-known chart where the first 90% of implementation happens almost instantly, and the remaining 10% takes forever to polish out all the rough edges.
On one hand, I really like the idea, and I've always wondered why TypeScript doesn't compile to native code. On the other hand, I'm quite skeptical that Vercel can actually pull this off. I'd be happy to be proven wrong, but I have very little faith in it.
Either way, good luck to them, but honestly, even if they succeed, I probably won't use it. Knowing their track record with vendor lock-in and Next.js, where they do everything possible to push you onto Vercel Cloud — no thanks.