Rendered at 01:50:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
JoeDohn 19 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.
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.
Fredkin 11 hours ago [-]
I have spent a small fortune in tokens trying to get Anthropic models to attempt proofs of things like the irrationality of the Euler-Mascheroni constant, and to make lattice reduction / SVP algorithms that rival SOTA methods like the G6K sieve, and all sorts of difficult frontier problems. It says 'honest' as a euphemism for giving up, because it knows I'm being a crank, and because the training data contains a lot of pessimism.
But I can get around this by first having it write a prompt for itself discussing the problem followed by a rousing speech about never giving in and admitting defeat, but pressing on towards results regardless of how hard matching SOTA results is.
ljm 8 hours ago [-]
I'm amused by Claude developing its own corporate jargon which, while clearly pulled from the corpus of human language, is quite distinct from the bullshit traded over the boardroom table.
I've had trouble unpacking some of the copy it generates because its default tone of voice is fairly unintuitive. It's almost like it's designed to induce psychosis because it makes you feel like you've discovered something novel.
WorldMaker 8 hours ago [-]
Bring to mind that old classic cliche about never trust a salesperson who always says the word "honest" or uses the phrases "to be honest" or "honestly" because they are probably lying in that moment.
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.
yard2010 17 hours ago [-]
Do we have a name for such irony, remove the "honestly price" makes it less honest about what it is
andytratt 18 hours ago [-]
tis
themgt 17 hours ago [-]
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.
pacoWebConsult 11 hours ago [-]
Is it really that bad of an idea to experiment, put things out into public, and see what works and what sticks? They haven't abandoned agent-browser and portless, which came out of these vercel-labs efforts because they're useful tools and people are using them.
embedding-shape 9 hours ago [-]
> Is it really that bad of an idea to experiment
I don't think so, I literally think it's fun to see. Sharing projects regardless of how done, mature, reliable, correct or not they are, feels like a net positive for humanity.
simlevesque 10 hours ago [-]
Back in the days we used to call this R&D.
WorldMaker 8 hours ago [-]
Back in the day companies used to have productization teams that separated pie-in-the-sky R&D from product, product teams, and product-like marketing.
tom1337 15 hours ago [-]
> I have the utmost respect to them (notably simonw)
seems like simon only changed the readme and wasn't really involved in the project.
Yeah I didn't think I'd be mistaken for being involved in the project!
I deleted two words from the README.
risyachka 18 hours ago [-]
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
pas 18 hours ago [-]
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)
kaoD 16 hours ago [-]
Personally my benchmark for a compiler is way higher than "it has a lot of tests". Way higher.
trueno 14 hours ago [-]
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
risyachka 15 hours ago [-]
>> 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
andsoitis 11 hours ago [-]
> >> 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
I think the bet is that the AI is an expert, given the vast literature and open source around compilers.
pjmlp 18 hours ago [-]
Most SaaS products have Vercel as partner, with Next.js and React as the tier 1 SDK on their tooling.
reactordev 13 hours ago [-]
Careful using the term “most” when you mean “the ones I know of”. You would be surprised how much Angular is out there.
pjmlp 13 hours ago [-]
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.
mattstir 13 hours ago [-]
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.
pjmlp 12 hours ago [-]
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?
shimman 9 hours ago [-]
I'll be honest I have never heard of this nor do I understand why it matters. It looks like it's just internal Vercel marketing speak that basically amounts to them desperately trying to build a platform and extract rents off of it.
pjmlp 9 hours ago [-]
It matters, because React is one of the reasons FE development sucks nowadays, and in many cases there are no alternatives, unless one loves yak shaving for their framework du jour.
reactordev 12 hours ago [-]
I think you are confusing React SDK with Vercel SDK.
pjmlp 11 hours ago [-]
They are both pushed by the same company, even more so since many React contributors became Vercel employees.
React is designed with Next.js needs in mind nowadays.
kristiandupont 9 hours ago [-]
Perhaps the newer features of React are but thankfully those bits can be completely ignored.
12 hours ago [-]
bubble_niter 18 hours ago [-]
Edit: Removed.
andytratt 18 hours ago [-]
why so many caps
JoeDohn 18 hours ago [-]
Indeed I am a random, but does it make me less qualified than another random ? (look up ^ )
psychoslave 18 hours ago [-]
>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?
petesergeant 18 hours ago [-]
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.
Perz1val 18 hours ago [-]
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?
TeMPOraL 18 hours ago [-]
> 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.
andsoitis 11 hours ago [-]
> > 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.
Don't you think that even if you don't know someone personally, you can calibrate your trust in their ability based on reputation, track record.
TeMPOraL 11 hours ago [-]
Yes. But we usually start with a high default, and only recalibrate if there's a specific reason in a given situation (e.g. there's been a specific user or sets of users involved in spreading malware, and software in question could've been targeted).
petesergeant 9 hours ago [-]
> you can calibrate your trust in their ability based on reputation, track record
rarely. How many of the libraries you pull from package managers do you actually know the authors of?
geraldwhen 16 hours ago [-]
“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.
bakugo 16 hours ago [-]
I'm sure that single 800k line commit was created in a very conscientious and involved way.
andytratt 18 hours ago [-]
oof
acmnrs 23 hours ago [-]
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.
simonw 23 hours ago [-]
> I'm more than a little suspicious of how Vercel has made so much progress so fast
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.
satvikpendem 20 hours ago [-]
"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.
leansensei 18 hours ago [-]
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.
daishi55 14 hours ago [-]
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.
WorldMaker 8 hours ago [-]
The credentials and rigor are what Professional Engineering is supposed to include. The credentials help give bite to Ethics Boards and other tools used to keep the entire profession honest and safe. The rigor is supposed to include things like making sure that you are solving the right problems.
Many people's lives do depend on software today. Insurance software dictates who gets treatment and who doesn't; that's real lives at stake. Finance software controls access to things like food and shelter; that's real lives at stake. Firmware in prosthetics and diabetic injectors and so on and so forth. Software runs the world, we pat ourselves on the back saying, but forget the world is full of real lives.
zaphirplane 12 hours ago [-]
Why is it engineering what makes it engineering
daishi55 10 hours ago [-]
We use science and technology to design, build, and maintain complex systems that solve real-world problems.
Do you have some other definition of engineering that excludes SWE?
satvikpendem 10 hours ago [-]
Maybe you're an outlier seeing as you're even on this forum. Most other non software engineers I know do not give a single thought about "title inflation," it does not even register in their minds as a topic to think about.
WorldMaker 8 hours ago [-]
My resume includes a bunch of time at a primarily Civil Engineering firm and one of the things I took away from that was also some respect for this "title inflation" issue. That company would not allow any "Engineer" in a title that didn't involve someone without up-to-date PE credentials. Technically my title the whole time there was "Senior Software Developer". I still feel guilty switching my resume back to "Senior Software Engineer" to not have to explain that "gap" to software interviewer who somehow think "Developer" is a less important title than "Engineer" and don't understand title inflation in our industry.
(At one point I even debated the value of getting PE credentials at my age for extra leverage in that company.)
igleria 16 hours ago [-]
as long as they stay away from boeing or anything that flies...
antonvs 19 hours ago [-]
> 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.
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.
rixed 19 hours ago [-]
900k lines of code plus tons of deps for a compiler? Does that really make sense to you?
mi_lk 19 hours ago [-]
It's coming from Vercel, what do you expect?
queenkjuul 16 hours ago [-]
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)
pizlonator 23 hours ago [-]
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)
bbor 23 hours ago [-]
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.
pizlonator 23 hours ago [-]
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
simonw 23 hours ago [-]
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?
pizlonator 22 hours ago [-]
They will have untyped dependencies. That’s how the TS/JS ecosystem works.
Note that “untyped dependency” means any code that says `any`.
simonw 22 hours ago [-]
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.
pizlonator 22 hours ago [-]
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
simonw 21 hours ago [-]
The QuickJS thing doesn't seem like a big deal to me, provided the documentation makes it clear that code will run slower if you use Any.
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:
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.
timcobb 20 hours ago [-]
For some new custom small thing you'd be better off using not this though, right?
queenkjuul 16 hours ago [-]
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.
skeledrew 21 hours ago [-]
> if you don’t believe me, then at least believe Claude
I had to do a triple take on this.
sroussey 21 hours ago [-]
There is always AssemblyScript
slopinthebag 22 hours ago [-]
I think more human effort is going into defending this project then what was put into the project itself haha.
vips7L 22 hours ago [-]
So like less than 1% of the time? What part of the JS ecosystem doesn’t depend on a mountain of untyped dependencies?
torginus 17 hours ago [-]
Devil's advocate - this is for the backend. You get to control your dependencies there, and I'd say Vercel controls its own stack, so they can replace deps as they go by submitting patches/slopforking projects to remove incompatible features.
piker 17 hours ago [-]
> "As far as I can tell they..."
This phrase I think highlights the fundamental issue for a lot of folks that would otherwise consider adopting a project like this written by humans.
drunkenmagician 19 hours ago [-]
"This project reeks of weapons grade AI psychosis" - fantastic quote: I will shamelessly steal & use. Apologies to pizlonator
anematode 22 hours ago [-]
> deferring int optimizations for later
This part made me laugh out loud
Altern4tiveAcc 15 hours ago [-]
> 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...
Tadpole9181 22 hours ago [-]
So you don't actually have real criticisms of the architecture at all...?
jeswin 15 hours ago [-]
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?
h1fra 11 hours ago [-]
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).
piterrro 17 hours ago [-]
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.
pmkary 8 hours ago [-]
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?
sheept 23 hours ago [-]
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.
skybrian 18 hours ago [-]
I would use it for a focused command-line tool that needs to share code with a larger TypeScript project, not for code with a lot of dependencies.
bbor 23 hours ago [-]
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!
sroussey 21 hours ago [-]
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.
skybrian 18 hours ago [-]
When publishing on jsr.io, you upload the TypeScript, and if using Deno, you also download TypeScript (with import statements rewritten.) Having nearly the original source code is better for debugging.
Deno doesn’t type-check external dependencies unless you ask.
sroussey 10 hours ago [-]
With the exports rewritten? Maybe we should have a export of “ts” like we have “types” instead?
skybrian 9 hours ago [-]
Not sure what you mean, but to expand on what I wrote, JSR rewrites the import statements to include file extensions and full version numbers for package dependencies, so that the imports can be resolved without looking for them in multiple places.
There's a way to download JSR packages and use them with npm too. I don't know what it does in that case.
Looking at the byte-array results (best case): scriptc is about 7.5x slower than Node 24, even after Claude tried making some scriptc-specific optimizations. But the executable starts up 12x faster (1.5 ms vs 18.6 ms), uses 72x less memory (2.5 MiB vs 181 MiB), and is a single 370 KB executable with no runtime dependencies.
weinzierl 18 hours ago [-]
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.
vips7L 8 hours ago [-]
I think the Graal team was also trying to take a meta-interpreter approach like this too. For cases where you need to dynamically load bytecode or do reflection where native couldn't handle it they would try to interpret with their espresso java implementation.
pjmlp 18 hours ago [-]
GCJ was always a prototype kind of.
Anyone serious would be paying for Excelsior JET, BEA JRockit, or the myriad of other commercial JDKs wihth AOT tooling.
In fact most likely one reasons why Excelsior is not more, is that now GraalVM and OpenJ9 exist as free bear.
PTC and Aicas still have it good, because few care about their embedded and real time customers.
gajus 11 hours ago [-]
Excellent problem space.
Related problem: Using AI to write compilers that optimize runtime code. I did this for Zod.
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.
elendilm 19 hours ago [-]
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.
aluxian 15 hours ago [-]
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?
jjice 11 hours ago [-]
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.
satvikpendem 23 hours ago [-]
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.
19 hours ago [-]
chilipepperhott 23 hours ago [-]
It's difficult to ignore how the README is filled with Claudisms.
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
binary132 22 hours ago [-]
Perhaps they should be left as a warning to others.
notsylver 18 hours ago [-]
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
localhoster 21 hours ago [-]
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 :)
MrDrMcCoy 18 hours ago [-]
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...
hoppp 6 hours ago [-]
It has Comptime. Sweet.
I can appreciate that as it seems zig has been successfully influencing things.
15 hours ago [-]
davexunit 11 hours ago [-]
This project is 5 days old going by the commit history and seems to be entirely vibecoded.
luciana1u 8 hours ago [-]
no JavaScript engine in the binary, but optionally bundles a 620KB quickjs runtime. giving up JavaScript but keeping a flask in the desk drawer.
aabhay 23 hours ago [-]
178kb?! What are you putting in there, a JVM?
SkiFire13 20 hours ago [-]
You're 2-3 orders of magnitude off for a JVM
iansmith_hn 16 hours ago [-]
Agreed. Along those same lines, their startup time claim "faster than go", gives me concern because the slowest part of go startup is the various GC-related initializations. If they are doing GC, then you would assume their times would be broadly similar.
vips7L 8 hours ago [-]
smallest i've been able to get hotspot is 30mb with jlinking. But even graal native will still give you a few megabytes.
pdantix 21 hours ago [-]
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.
Twirrim 20 hours ago [-]
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)
bLorax 10 hours ago [-]
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?
mapcars 11 hours ago [-]
Interesting, I wonder what does no-runtime option mean, no event loop and no async code then?
anta40 17 hours ago [-]
Does this mean I can turn my JS-based backend into single executable and easily ship it, like in Go?
queenkjuul 16 hours ago [-]
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
ianberdin 16 hours ago [-]
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.
mdavid626 15 hours ago [-]
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.
xiaodai 23 hours ago [-]
how can you compile it if javascript is a valid subset of typescript? confused.
panzi 22 hours ago [-]
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.
lpribis 15 hours ago [-]
No idea about this project, but it is very possible to compile a dynamically typed language, without large VM/runtime. See Common Lisp, Julia
queenkjuul 18 hours ago [-]
Both, basically. Default is the subset, but you can enable an interpreter
CarpeNecopinus 19 hours ago [-]
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.
hnsmomdpvp 15 hours ago [-]
Not glamorous but it works
casper14 23 hours ago [-]
I like the idea.
truth_seeker 18 hours ago [-]
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.
Whatever happened with their new programming language for agents? I expect this will follow the same path.
relug 18 hours ago [-]
finally someone did this
khalic 16 hours ago [-]
Does it compiles to C? Wasm? I couldn’t find it the readme slop
simonw 11 hours ago [-]
It compiles to C if you use "--backend c"
Otherwise it looks like it compiles to LLVM.
zuzululu 20 hours ago [-]
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?
repeekad 19 hours ago [-]
Some of us don’t like Spotify, Slack, Discord, and a simple notes app taking 1-2GB of RAM each..
lpribis 15 hours ago [-]
Still need the entire browser DOM, APIs, layout, renderers, etc outside of JS.
jonasdoesthings 18 hours ago [-]
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.
This is a really important question. If true, it could end a lot of Electron wastefulness.
jorisw 19 hours ago [-]
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
nkmnz 16 hours ago [-]
Nothing more horrible than apps that "care about the host OS in terms of UI", thus looking different on every type of device I have to use for work.
queenkjuul 16 hours ago [-]
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
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.
But I can get around this by first having it write a prompt for itself discussing the problem followed by a rousing speech about never giving in and admitting defeat, but pressing on towards results regardless of how hard matching SOTA results is.
I've had trouble unpacking some of the copy it generates because its default tone of voice is fairly unintuitive. It's almost like it's designed to induce psychosis because it makes you feel like you've discovered something novel.
I checked my history and mapped how often it started to use "honest" and it's too much https://x.com/podviaznikov/status/2067231875068768447
https://github.com/vercel-labs/zerolang
https://news.ycombinator.com/item?id=48193539
I don't think so, I literally think it's fun to see. Sharing projects regardless of how done, mature, reliable, correct or not they are, feels like a net positive for humanity.
seems like simon only changed the readme and wasn't really involved in the project.
https://github.com/vercel-labs/scriptc/commits/main/?author=...
I deleted two words from the README.
Edit: typo
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
tests don't mean much if you are not an expert on the subject
> tests don't mean much if you are not an expert on the subject
I think the bet is that the AI is an expert, given the vast literature and open source around compilers.
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.
Invalidating the remark "I can't think of any serious company or project that would use this thing."
Where's the example?
React is designed with Next.js needs in mind nowadays.
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?
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.
> 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.
Don't you think that even if you don't know someone personally, you can calibrate your trust in their ability based on reputation, track record.
rarely. How many of the libraries you pull from package managers do you actually know the authors of?
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.
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.
But it is indeed engineering, and that’s OK.
Many people's lives do depend on software today. Insurance software dictates who gets treatment and who doesn't; that's real lives at stake. Finance software controls access to things like food and shelter; that's real lives at stake. Firmware in prosthetics and diabetic injectors and so on and so forth. Software runs the world, we pat ourselves on the back saying, but forget the world is full of real lives.
Do you have some other definition of engineering that excludes SWE?
(At one point I even debated the value of getting PE credentials at my age for extra leverage in that company.)
“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'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.
I had to do a triple take on this.
This phrase I think highlights the fundamental issue for a lot of folks that would otherwise consider adopting a project like this written by humans.
This part made me laugh out loud
For a project like this, isn't it worth introducing a TS type for Ints? Since they are trying to leverage TypeScript anyway...
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?
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.
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.
Deno doesn’t type-check external dependencies unless you ask.
There's a way to download JSR packages and use them with npm too. I don't know what it does in that case.
Looking at the byte-array results (best case): scriptc is about 7.5x slower than Node 24, even after Claude tried making some scriptc-specific optimizations. But the executable starts up 12x faster (1.5 ms vs 18.6 ms), uses 72x less memory (2.5 MiB vs 181 MiB), and is a single 370 KB executable with no runtime dependencies.
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.
Anyone serious would be paying for Excelsior JET, BEA JRockit, or the myriad of other commercial JDKs wihth AOT tooling.
In fact most likely one reasons why Excelsior is not more, is that now GraalVM and OpenJ9 exist as free bear.
PTC and Aicas still have it good, because few care about their embedded and real time customers.
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.
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.
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.
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 can appreciate that as it seems zig has been successfully influencing things.
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)
I might be wrong here. What's the use case?
This is more equivalent to Go, with a single static native binary that does not include the whole Node runtime
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.
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...
Otherwise it looks like it compiles to LLVM.
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
Deno is building a less-wasteful Electron style framework for native desktop apps