Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

101–110 of 165 posts

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

#101

Post by tom1337 »

JoeDohn wrote: 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…

> I have the utmost respect to them (notably simonw)

seems like simon only changed the readme and wasn't really involved in the project.

https://github.com/vercel-labs/scriptc/commits/main/?author=...

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

#102

Post by lpribis »

panzi wrote: post #22
xiaodai wrote: post #15

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

Either it is only accepting a subset of TypeScript, or it is still interpreting the parts that don't have enough types. Given other comments here it sounds like the later.

No idea about this project, but it is very possible to compile a dynamically typed language, without large VM/runtime. See Common Lisp, Julia

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

#103

Post by lpribis »

zuzululu wrote: post #42

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?

Still need the entire browser DOM, APIs, layout, renderers, etc outside of JS.

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

#104

Post by risyachka »

pas wrote: post #72
risyachka wrote: post #57

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)

>> that doesn't mean much. it has a lot of tests

tests don't mean much if you are not an expert on the subject

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

#105

Post by jeswin »

bbor wrote: post #14
pizlonator wrote: post #12

Earlier quoted context omitted.

That explains why: - the architecture is idiotic. - they have zero credible perf numbers. I plan to benchmark it using generally accepted methods. Porffor makes careful trade offs that make sense and is benchmarked in a way that I can believe. (Source: I make dynamic languages fast for a living)

Putting aside the whole “team of professionals putting out a product vs solo dev fine tuning their opus” of it all: Can you clarify what about the architecture is ‘idiotic’? Not trying to catch you or demand a defense, just looking for a vague description. I don’t even know how to start examining the architecture of something like this.

Just randomly:

1. TS only has a "number" type. But what type of number is it? This is doable safely via keywords (or known markers), or sometimes via analysis, but I couldn't find it in the README.

2. A compiler that works only on macOS?

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

#106

Post by aluxian »

elendilm wrote: post #53

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…

Does that tool already exist, so do you have a specific TS subset in mind you are aiming for? Or you are simply trying to use fewer complex features?

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

#107

Post by badatnames »

themgt wrote: post #70
simonw wrote: 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...

They landed 802,000 lines of code in a single commit: https://github.com/vercel-labs/scriptc/commit/23d5918a5381e0...

This is not the Vercel ad they think it is.

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

#109

Post by mdavid626 »

ianberdin wrote: post #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…

Sometimes you are forced to use it - e.g. Bun in Claude Code. I like Opus models, but can't run them outside of Claude Code/Bun in subscription models.

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

#110

Post by Altern4tiveAcc »

pizlonator wrote: post #16
bbor wrote: post #14

Earlier quoted context omitted.

Putting aside the whole “team of professionals putting out a product vs solo dev fine tuning their opus” of it all: Can you clarify what about the architecture is ‘idiotic’? Not trying to catch you or demand a defense, just looking for a vague description. I don’t even know how to start examining the architecture of something like this.

Yeah - using quickjs at all in a thing that needs perf. Quickjs is hilariously slow. Midwits use it because it has “quick” in the name. - using floats for numbers and deferring int optimizations for later. Inferring ints is like half the problem of fast JS. - rejecting inadequately annotated or too dynamic code without a whole heck of a lot of self-reflection about how unlikely that is to work out. The observation th…

> using floats for numbers and deferring int optimizations for later. Inferring ints is like half the problem of fast JS.

For a project like this, isn't it worth introducing a TS type for Ints? Since they are trying to leverage TypeScript anyway...

Post reply on HN