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 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)
>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?
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?
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.
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.
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.
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.
> 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.
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.
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 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
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.
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.
> so realistically you'd still need a JavaScript engine if you use any packages.
Looks like Scriptc's solution to that problem is that it can optionally bundle a 620KB quickjs-ng JavaScript engine if you have dependencies that need to be executed that way.
Those are good reasons to publish untyped libraries as a rule, sure. But the contention that those reasons outweigh the value of types kinda boggles the mind, ngl!
Publishing a lib as JS with .d.ts type files gives you JS compatibility and TS types for using the lib, but no TS source so no types inside.
I’ve seen people want to publish TS libs but there are issues: TS will type check the libs as well as your project. You can’t tell it to stop just because it’s going inside node modules. And the app may have tighter settings than the library and you will get type errors if your configs were setup differently. It would be interesting to standardize publishing real typescript libs but I haven’t seen it. Maybe deno tried? I haven’t looked.
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
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.
This is like putting lipstick on a pig. Give me an AI written README or tests but actually thoughtful codebase over human written readme but aislop code any day of the month
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 :)
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.
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.
This is one of the things that is tiring me out the most. Previously people could have these "ohh shiny" ideas and would lose steam before they could be implemented, especially in areas they're clueless about.
Now people can have these ideas, slop together an awful solution that works at a surface level, maybe, but will never really go places because the foundation is slopped with no party involved actually capable of thinking thing through. But hey we launched something so let's make lots of noise! Oh look, a banana ... Sorry, what were we talking about?
There's an engineer on a team at work that I routinely engage with who slops together stuff so fast his team is basically exhausted all the time. They're stuck picking up a whole stream of pieces of crap because the engineer is incapable of actually doing the hard work of getting things to production because there's more "ohh, shiny" stuff they can spend tokens on, and their leadership aren't stepping in because it all looks terribly productive (it really isn't)
another use case is getting standalone self-contained binaries which are easier to ship.
other projects like claude code use something like `bun build --compile`[^1] for that, which instead of producing a small native binary just bundle the JS runtime into the executable.
Don’t see how compiling Typescript changes how little Electron cares about the host OS in terms of UI and how it just ships Chromium in order to show any UI at all
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.
What it can actually compile is a subset of well-behaved typescript. For anything else it bails out and asks you to ship a JS engine (albeit, not NodeJS) again.
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.
Edit: typo
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?
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.
Coding agents. They landed 918,000 lines of code in a single week: https://github.com/vercel-labs/scriptc/graphs/contributors?s...
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” 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.
- 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)
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.
- 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
Note that “untyped dependency” means any code that says `any`.
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.
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
If I was using this project for something I'd expect to write custom TypeScript for it.
The floats rather than integers thing does look bad though. I tried compiling their fibonacci example to C (--backend c) and got this:
I had to do a triple take on this.
This part made me laugh out loud
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/
Looks like Scriptc's solution to that problem is that it can optionally bundle a 620KB quickjs-ng JavaScript engine if you have dependencies that need to be executed that way.
I’ve seen people want to publish TS libs but there are issues: TS will type check the libs as well as your project. You can’t tell it to stop just because it’s going inside node modules. And the app may have tighter settings than the library and you will get type errors if your configs were setup differently. It would be interesting to standardize publishing real typescript libs but I haven’t seen it. Maybe deno tried? I haven’t looked.
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...
Now people can have these ideas, slop together an awful solution that works at a surface level, maybe, but will never really go places because the foundation is slopped with no party involved actually capable of thinking thing through. But hey we launched something so let's make lots of noise! Oh look, a banana ... Sorry, what were we talking about?
There's an engineer on a team at work that I routinely engage with who slops together stuff so fast his team is basically exhausted all the time. They're stuck picking up a whole stream of pieces of crap because the engineer is incapable of actually doing the hard work of getting things to production because there's more "ohh, shiny" stuff they can spend tokens on, and their leadership aren't stepping in because it all looks terribly productive (it really isn't)
whats the use case for this , make it hard to reverse engineer my node projects?
other projects like claude code use something like `bun build --compile`[^1] for that, which instead of producing a small native binary just bundle the JS runtime into the executable.
[^1]: https://bun.com/docs/bundler/executables