Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Excellent problem space.

    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.

  • 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
  • It's difficult to ignore how the README is filled with Claudisms.
  • Looks like PRs are actively accepted. I just got rid of one of them! https://github.com/vercel-labs/scriptc/commit/c4b68dc6d9c259...
  • 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.

  • 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?
  • 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?
  • 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.
  • 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.

  • 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.
  • 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.

  • 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).
  • 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.

  • 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.

    [1]: https://github.com/nodejs/node/blob/main/doc/api/typescript....

    [2]: https://www.assemblyscript.org/

  • 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.
  • 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!
    by bbor
  • > 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.

  • 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...

  • Vercel sloping it's way to clout again, they do this every month or so, clearly they want to stay in the news and some how credible and relevant.

    I can't think of any serious company or project that would use this thing.

    P.S: I just checked the contributors list, I have the utmost respect to them (notably simonw), but clearly this code is claude'ish but it is not among the contributor which makes it even more suspect.

  • Claude-directed code by someone being conscientious and getting involved in the important decisions is going to be better than a whole swathe of existing open-source that was hand-written.
  • Edit: Removed.
  • Most SaaS products have Vercel as partner, with Next.js and React as the tier 1 SDK on their tooling.
  • 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

  • > 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=...

  • 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.

    https://github.com/vercel-labs/zerolang

    https://news.ycombinator.com/item?id=48193539

  • That's a one big hell of a contribution ;-) https://github.com/vercel-labs/scriptc/commit/725b931cf43ba7...