Live data from Hacker News

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

github.com

91–100 of 165 posts

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

#91
post #72

Earlier quoted context omitted.

From contributions tab, it looks like 99% was vibe-coded by 1 person, and it does not look like they have any compilers background. Edit: typo

that doesn't mean much. it has a lot of tests, the architect seems sane, it fits a niche (for example scripts baked into container images don't need full (Node + tsx + esbuild) or Bun/Deno)

Personally my benchmark for a compiler is way higher than "it has a lot of tests". Way higher.

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

#92
post #50

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…

Claude-directed code by someone being conscientious and getting involved in the important decisions is going to be better than a whole swathe of existing open-source that was hand-written.

“Better”, maybe or maybe not. But there’s an underlying truth here. If you’ve ever LOOKED at the open source libs you use, some of them are very very rough.

Going in to a project hoping to make a change and seeing no tests and spaghetti used to be soul crushing. These days I’d have Claude go refactor and add tests and make pull requests for me to look at to fix it.

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

#93
post #41

Earlier quoted context omitted.

If you’re writing Typescript with zero dependencies and trying to target native I feel like it makes more sense to write it in a different language like Rust or Go. The main reason for this I think is getting cheap perf wins by running existing code natively.

For some new custom small thing you'd be better off using not this though, right?

Personally i can kind of see a use case here. I've shipped some simple server side packages as a "compiled" Node single executable written in TS, but you're stuck with the big overhead of Node.

I've just been teaching myself Go, also a single binary but without the overhead. But in Go i miss the expressiveness of the TS type system sometimes.

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

#94
post #6

Earlier quoted context omitted.

> I'm more than a little suspicious of how Vercel has made so much progress so fast Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...

Christ. Imagine if bridges, skyscrapers, dams, cars, airplanes were designed and built like that. I vibeslopped thousands of pages of blueprints, nobody reviewed them, but another team of digital monkeys with the intellect of an ant have already built the bridge, and it seems to not have collapsed yet , so we're already directing traffic there. I can't imagine actual engineers feeling anything but deepest contempt fo…

as long as they stay away from boeing or anything that flies...

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

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

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

#96
post #50

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…

Claude-directed code by someone being conscientious and getting involved in the important decisions is going to be better than a whole swathe of existing open-source that was hand-written.

I'm sure that single 800k line commit was created in a very conscientious and involved way.

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

#97
post #84

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

Recent versions of Node can package a backend into a single binary already, it'll just be 100MB+ and embed the whole Node runtime.

This is more equivalent to Go, with a single static native binary that does not include the whole Node runtime

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

#99

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?

This is a really important question. If true, it could end a lot of Electron wastefulness.

Im 99% certain it cannot. This seems better suited to server side projects.

Deno is building a less-wasteful Electron style framework for native desktop apps

Post reply on HN