Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary
github.com227 points by maxloh 15 hours ago
227 points by maxloh 15 hours ago
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.
That's a one big hell of a contribution ;-) https://github.com/vercel-labs/scriptc/commit/725b931cf43ba7...
I get so irritated every time Claude says "honest". Anthropic talks about how they specifically engineer for it to be "honest". I'm convinced they're just measuring how many times it says the word honest instead.
It's in the constitution, probably a lot. And in the RL training. You can tell Anthropic is really worried about it. I'm interested in just how dishonest the so-called 'helpful only' non-RL model they have floating around internally is. Probably pretty dishonest.
Do we have a name for such irony, remove the "honestly price" makes it less honest about what it is
Also the same vibe-code leader as zerolang, "The Programming Language for Agents" which Vercel launched with much fanfare in May, landed 1200 commits and then stopped ~mid-June.
Kind of funny seeing a serious (?), grown up, for-profit company acting the same way as my scatterbrain clinging into this month's fascination. Luckily, most of my things never see the light of day, so they don't get referenced a month later in a HN burn when I publish yet another project I'll stop working on in a month.
> 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=...
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.
this. it's also insane that some are willing to do anything but use something other than javascript. out of all the languages to die on a hill for...
the only group i noddingly approve of being that programmatically bigoted are the clojure-or-i'm-setting-myself-on-fire guys. they've earned it
>> 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
Most SaaS products have Vercel as partner, with Next.js and React as the tier 1 SDK on their tooling.
Careful using the term “most” when you mean “the ones I know of”. You would be surprised how much Angular is out there.
Name one that gives 100% parity to React in their SDK to write extensions.
Not works in some of the cases and you have to implement fetch calls yourself, or some iframe boilerplate and JS glue, everything they expose in React is fully available in Angular, including field extensions, inline previews, sidebar extensions, the whole lot.
That doesn't change the fact that there is a lot of Angular out there. No one's doubting how useful Next.js may or may not be, it's just a matter of fact that plenty of systems were created before it was available and not everyone has the luxury of rewriting their entire product.
Moving goalposts, the point was about SaaS SDKs giving tier1 support for React and nothing else, thus giving Vercel their current market position.
Invalidating the remark "I can't think of any serious company or project that would use this thing."
Where's the example?
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.
Maybe if it's a business level tool made in house with claude vs contracted to a software house in India. Never for a compiler, who even is that person?
> Never for a compiler, who even is that person?
Why do you care?
It's a stranger from the Internet. Same as with any other software you're using. In particular, same as with any OSS tool you're using.
“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.
I'm sure that single 800k line commit was created in a very conscientious and involved way.
Edit: Removed.
Indeed I am a random, but does it make me less qualified than another random ? (look up ^ )
>But apparently random HN commenters can now overrule an AI ML expert because the code "looks Claude-ish"!
And let’s imagine if LLM bots could do that as well, without any human caring to type the actual messages, just orchestrating the bot fleet. What trust could be we put in such a brainless peace of publications?
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.
> 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 for this industry.
"Actual engineers" don't really care about software engineering, much less a strong emotion at all like the "deepest contempt" and many of them already vibe code today for their work anyway.
Oh no, we do, because the software world has been abusing what engineering means for decades, in order to inflate job titles. Most people are programmers, not software engineers, and that's OK.
What we do is absolutely engineering, there’s just a lot less credentialing upfront and rigor before something is released, because usually people’s lives do not depend on it and it’s easy to release updates.
But it is indeed engineering, and that’s OK.
> already built the bridge, and it seems to not have collapsed yet, so we're already directing traffic there.
“Actual” engineering went through a phase where bridges and other structures did collapse due to structural flaws - it’s not like they magically figured out ahead of time how to avoid that.
Now, they can build structures that are some specified tolerance away from collapsing, but that’s only the case because the edges of what was possible were explored.
They landed 802,000 lines of code in a single commit: https://github.com/vercel-labs/scriptc/commit/23d5918a5381e0...
That makes sense. It also seems like this uses a lot more dependencies and tiers of compilation whereas Porforr is trying to do everything from scratch.
900k lines of code plus tons of deps for a compiler? Does that really make sense to you?
I don't actually see any dependencies other than node and typescript (and the optional quickjs package) (maybe they inlined dependencies? But the package.json files don't indicate any npm dependencies)
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.
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 that languages that are even slightly dynamic need dynamic JIT opts is very old; folks figured that out in the 80s.
This project reeks of weapons grade AI psychosis
As far as I can tell they pull in QuickJS (actually quickjs-ng) only in the case where the program has untyped dependencies that still need to be run by an interpreter - and they chose that library because it's pretty small (620KB). Did I miss something, are they using it outside of that purpose?
They will have untyped dependencies. That’s how the TS/JS ecosystem works.
Note that “untyped dependency” means any code that says `any`.
They won't have untyped dependencies for situations where someone used Scriptc as a way to build a fast binary executable for some custom-written TypeScript, which was the first use-case that came to mind for me.
Being able to build small, fast binaries without writing them in C or Rust - if you're already fluent in TypeScript - seems like a valuable capability.
Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea.
CanadaHonk has gotten further than the rest of us. It’s surprising and impressive.
You’re only replying to the quickjs issue I raised, but it’s not the only issue. Their approach to numbers is broken. Their approach to measurement is broken. The quickjs thing raises another red flag: it suggests to me that they are using reference counting, not GC. That’s guaranteed to make them too slow to be useful. (If they weren’t using RC, then they’d have a hard time on the boundary to quickjs.)
As to the `any` issue, let me explain it in a way you’ll appreciate. I asked Claude how likely it is that TS code uses any, and it found:
- 79.5% of TS repos use any explicitly. So, about 4/5 chance that newly written dep-free TS code will use it.
- the explicit any type is about as common as Boolean and void.
- a third of inferred types are any. That’s huge.
So, if you don’t believe me, then at least believe Claude: any is a super common type, so they will be falling off into quickjs a lot.
Oh, and in case it isn’t clear, quickjs-ng is no better than quickjs. They’re the same thing for the purpose of perf