8 ms·
Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary
- luciana1u 2mo ago[flagged]
- deleted 2mo ago[deleted]
- aabhay 2mo ago178kb?! What are you putting in there, a JVM?
- SkiFire13 2mo agoYou're 2-3 orders of magnitude off for a JVM
- iansmith_hn 2mo agoAgreed. 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 2mo agosmallest i've been able to get hotspot is 30mb with jlinking. But even graal native will still give you a few megabytes.
- satvikpendem 2mo agoA lot of people are trying this now with AI, a native TypeScript compiler, for example https://github.com/PerryTS/pry 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.
- deleted 2mo ago[deleted]
- acmnrs 2mo agoPorforr<https://porffor.dev https://porffor.dev> has been working towards the same goal for a while. The creator, CanadaHonk<https://honk.foo 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 2mo ago> 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?selectedMetric=additions https://github.com/vercel-labs/scriptc/graphs/contributors?s...
- acmnrs 2mo agoThat 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 2mo ago900k lines of code plus tons of deps for a compiler? Does that really make sense to you?
- mi_lk 2mo agoIt's coming from Vercel, what do you expect?
- queenkjuul 2mo agoI 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 2mo ago
- casper14 2mo agoI like the idea.
- sheept 2mo agoOne 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.md#type-stripping-in-dependencies https://github.com/nodejs/node/blob/main/doc/api/typescript.... [2]: https://www.assemblyscript.org/ https://www.assemblyscript.org/
- simonw 2mo ago> 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.
- bbor 2mo agoThose 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 2mo agoPublishing 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.
- 2mo ago
- chilipepperhott 2mo agoIt's difficult to ignore how the README is filled with Claudisms.
- simonw 2mo agoLooks like PRs are actively accepted. I just got rid of one of them! https://github.com/vercel-labs/scriptc/commit/c4b68dc6d9c2591b53cebef8ead290a3b81b2731 https://github.com/vercel-labs/scriptc/commit/c4b68dc6d9c259...
- xiaodai 2mo agohow can you compile it if javascript is a valid subset of typescript? confused.
- panzi 2mo agoEither 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.
- queenkjuul 2mo agoBoth, basically. Default is the subset, but you can enable an interpreter
- lpribis 2mo agoNo idea about this project, but it is very possible to compile a dynamically typed language, without large VM/runtime. See Common Lisp, Julia
- panzi 2mo agoYes, and JavaScript itself is JITed. I used interpreted here as a shorthand for interpreted and/or JIT compiled at runtime.
- CarpeNecopinus 2mo agoWhat 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.
- deleted 2mo ago[deleted]
- deleted 2mo ago[deleted]
- localhoster 2mo agoFunny 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 :)
- pdantix 2mo agoanother 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 2mo agoThis 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)
- zuzululu 2mo agothis 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?
- isaachinman 2mo agoThis is a really important question. If true, it could end a lot of Electron wastefulness.
- jorisw 2mo agoDon’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 2mo agoNothing 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 2mo agoIm 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
- repeekad 2mo agoSome of us don’t like Spotify, Slack, Discord, and a simple notes app taking 1-2GB of RAM each..
- jonasdoesthings 2mo agoanother 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. [^1]: https://bun.com/docs/bundler/executables https://bun.com/docs/bundler/executables
- JoeDohn 2mo agoVercel 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.
- piterrro 2mo agoThat's a one big hell of a contribution ;-) https://github.com/vercel-labs/scriptc/commit/725b931cf43ba71ec154e378146fe274df0e8f65 https://github.com/vercel-labs/scriptc/commit/725b931cf43ba7...
- andytratt 2mo agotis
- yard2010 2mo agoDo we have a name for such irony, remove the "honestly price" makes it less honest about what it is
- bilalq 2mo agoI 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.
- vessenes 2mo agoIt'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.
- Fredkin 2mo agoI 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.
- elendilm 2mo agoThis 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 2mo agoDoes 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?
- elendilm 2mo agoNo the tool does not exist. Its medium to long term vision. Our backends are structured on isolated units - what we call "features". Features invoke another features via fully qualified names using a standard Features.send(...). in-process/inter-replica/inter-service and even seperate functions inside the same js files are all invoked likewise. Only a few specific helper functions for a feature exist for direct invocations. The complexity of ts2rust tool is thus greatly reduced because of the discipline of the architecture.
- MrDrMcCoy 2mo agoHasn'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...
- truth_seeker 2mo agoShameless 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. https://github.com/corporatepiyush/dynascript https://github.com/corporatepiyush/dynascript API reference : https://github.com/corporatepiyush/dynascript/blob/master/docs/dynajs-guide/API.md https://github.com/corporatepiyush/dynascript/blob/master/do...
- techpression 2mo agoWhatever happened with their new programming language for agents? I expect this will follow the same path.
- notsylver 2mo agoI 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
- weinzierl 2mo agoIt'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.
- pjmlp 2mo agoGCJ 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.
- vips7L 2mo agoI 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.
- relug 2mo agofinally someone did this
- anta40 2mo agoDoes this mean I can turn my JS-based backend into single executable and easily ship it, like in Go?
- queenkjuul 2mo agoRecent 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
- piterrro 2mo agothis 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.
- ianberdin 2mo agoI'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 2mo agoSometimes 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.
- khalic 2mo agoDoes it compiles to C? Wasm? I couldn’t find it the readme slop
- simonw 2mo agoIt compiles to C if you use "--backend c" Otherwise it looks like it compiles to LLVM.
- hnsmomdpvp 2mo ago[dead]
- jjice 2mo agoThis 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.
- gajus 2mo agoExcellent problem space. Related problem: Using AI to write compilers that optimize runtime code. I did this for Zod. https://github.com/gajus/zod-compiler 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.
- davexunit 2mo agoThis project is 5 days old going by the commit history and seems to be entirely vibecoded.
- h1fra 2mo agoVercel 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).
- mapcars 2mo agoInteresting, I wonder what does no-runtime option mean, no event loop and no async code then?
- bLorax 2mo agoIt 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?
- deleted 2mo ago[deleted]
- pmkary 2mo agoDespite 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?
- EliasWatson 2mo agoI had Claude run a benchmark on scriptc vs node: https://github.com/EliasWatson/Primes/tree/typescript-scriptc/PrimeTypeScript/solution_3 https://github.com/EliasWatson/Primes/tree/typescript-script... 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.
- hoppp 2mo agoIt has Comptime. Sweet. I can appreciate that as it seems zig has been successfully influencing things.
- _chall_ 2mo agoI think Vercel should either collaborate with the TypeScript team or hire one of the active external TypeScript contributors https://github.com/microsoft/TypeScript/graphs/contributors?all=1 https://github.com/microsoft/TypeScript/graphs/contributors?... to add another backend (make a fork of tsgo as an option), whether that's WebAssembly or LLVM IR... As it stands, the project's direction feels a bit odd.