Live data from Hacker News

Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

github.com

151–160 of 165 posts

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#151
post #116

Earlier quoted context omitted.

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

I get so irritated every time Claude says "honest". Anthropic talks about how they specifically engineer for it to be "honest". I'm convinced they're just measuring how many times it says the word honest instead.

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.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#152

Earlier quoted context omitted.

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.

Back in the days we used to call this R&D.

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.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#153
post #2

178kb?! What are you putting in there, a JVM?

You're 2-3 orders of magnitude off for a JVM

smallest i've been able to get hotspot is 30mb with jlinking. But even graal native will still give you a few megabytes.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#154

Earlier quoted context omitted.

Oh no, we do, because the software world has been abusing what engineering means for decades, in order to inflate job titles. Most people are programmers, not software engineers, and that's OK.

What we do is absolutely engineering, there’s just a lot less credentialing upfront and rigor before something is released, because usually people’s lives do not depend on it and it’s easy to release updates. But it is indeed engineering, and that’s OK.

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.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#155

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 fr…

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.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#156

Earlier quoted context omitted.

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.

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.

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

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#157
I had Claude run a benchmark on scriptc vs node: 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.

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#159

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?

Im 99℅ certain this could not handle an Electron project.

The use case, imo, is to be able to write server side code in familiar TypeScript, then deploy it as a small single native binary (vs Node and Bun which embed the entire 100MB+ runtime when you build a native binary.) Electron for the record ships their own modified Node runtime (not ABI compatible) on top of the whole Chromium renderer

Re: Scriptc by Vercel: TypeScript-to-Native compiler, no JavaScript engine in binary

#160
I 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?... 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.
Post reply on HN