Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

Despite the hate it is receiving, I thought lets test it at least, and tried it to any project that I have locally. For every single of them the coverage generates hundreds of errors and so it is basically useless. I get that I can write a project from scratch, don't use any third party library, and it'll compile to binary, but then why should I not use Rust, Go, Zig, D, C, V, Ada, C++, Nim, Swift, Kotlin Native, Haskell... literally anything designed to be compiled and compiled well?

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.

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.

  static double sc_f_fib(double sc_l_n_0) { /* /private/tmp/fib.ts:1 */
    double sc_t0 = sc_l_n_0;
    double sc_t1 = 2.0;
    bool sc_t2 = sc_t0 < sc_t1;
    double sc_t3;
    if (sc_t2) {
      double sc_t4 = sc_l_n_0;
      sc_t3 = sc_t4;
    } else {
      double sc_t5 = sc_l_n_0;
      double sc_t6 = 1.0;
      double sc_t7 = sc_t5 - sc_t6;
      double sc_t8 = sc_f_fib(sc_t7);
      double sc_t9 = sc_l_n_0;
      double sc_t10 = 2.0;
      double sc_t11 = sc_t9 - sc_t10;
      double sc_t12 = sc_f_fib(sc_t11);
      double sc_t13 = sc_t8 + sc_t12;
      sc_t3 = sc_t13;
    }
    return sc_t3; /* /private/tmp/fib.ts:2 */
  }

Vercel doing Vercel: 5 days old, entirely vibecoded, already 1.5k stars for no reason, solves no one's issue and will stop being maintained in a few months (if more than this week).

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.

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.

[1]: https://github.com/nodejs/node/blob/main/doc/api/typescript....

[2]: https://www.assemblyscript.org/

Excellent problem space.

Related problem: Using AI to write compilers that optimize runtime code. I did this for Zod.

https://github.com/gajus/zod-compiler

Zod schemas, compiled at build time into raw boolean chains. 2-74x faster. No code changes. The plugin swaps Zod with compiled parse.

I wrote almost none of the optimizations. Claude did, in a loop, over 100+ iterations.

It works because the compiled version can be diffed against real Zod. Correctness isn't a judgment call. Same as scriptc.

This applies to every program with a reference implementation and a benchmark. Compilers, serializers, formatters, query planners, etc.

Excited for faster Internet.

This is very interesting and a potential huge win like .NET AOT if it lasts. This has been around for days, so I'm not going to invest any more time than just playing with it at this point, but if this can continue development and not get abandoned, it could be a really nice win for the ecosystem.

As we see more and more heavily AI built open source projects, I wonder how the perception of them becomes. There's a huge spectrum of AI developed code, the same way there is with human code, except a human at least had to think a bit about what they wrote. If you generate code with an LLM to the standards that you'd write it yourself (which is the only way I'd consider for anything important) and you review every bit that's written, I think that's wonderful. Even if you don't, I don't think that's bad, but I will have more friction to adopt that project as there's likely lower quality code and less personal investment into it.

I find that a lot of online discussion has gone either "AI generate everything" or "never AI generate anything", with the middle ground being mostly silent. That's probably just because it's the internet and most people I talk to IRL have a reasonable middle ground take. I'm all for it if it accelerates a person making thoughtful decisions. If not, more power to you, but I'm less inclined to use the software out of fear of using something of poor quality or something that'll be abandonware.

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.

This look very promising.

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.

no JavaScript engine in the binary, but optionally bundles a 620KB quickjs runtime. giving up JavaScript but keeping a flask in the desk drawer.

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

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.

It's difficult to ignore how the README is filled with Claudisms.

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 :)

Hasn't quickjs and GraalVM been able to do this for a while now?

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...

It is technically possible to drink soup with a shovel but I don't really wanna do it.

I might be wrong here. What's the use case?

Interesting, I wonder what does no-runtime option mean, no event loop and no async code then?

This project is 5 days old going by the commit history and seems to be entirely vibecoded.

178kb?! What are you putting in there, a JVM?

another vercel labs thing that's been slopped together, hyped up on twitter and then left to be forgotten about in a few months time.

Does this mean I can turn my JS-based backend into single executable and easily ship it, like in Go?

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.

how can you compile it if javascript is a valid subset of typescript? confused.

Not glamorous but it works

Shameless plug but worth reading :

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...

I like the idea.

Whatever happened with their new programming language for agents? I expect this will follow the same path.

finally someone did this

Does it compiles to C? Wasm? I couldn’t find it the readme slop

this is interesting , so i can turn electron into a native app now?

whats the use case for this , make it hard to reverse engineer my node projects?