Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

81–90 of 165 posts

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

#81

Post by yard2010 »

piterrro wrote: post #56
JoeDohn wrote: post #50

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's a one big hell of a contribution ;-) https://github.com/vercel-labs/scriptc/commit/725b931cf43ba7...

Do we have a name for such irony, remove the "honestly price" makes it less honest about what it is

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

#82

Post by torginus »

pizlonator wrote: post #23
simonw wrote: post #18

Earlier quoted context omitted.

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 will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.

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.

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

#83

Post by embedding-shape »

themgt wrote: post #80
JoeDohn wrote: post #50

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…

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

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.

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

#85

Post by piker »

simonw wrote: post #18
pizlonator wrote: post #16

Earlier quoted context omitted.

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

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?

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

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

#86

Post by piterrro »

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.

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

#87

Post by nkmnz »

jorisw wrote: post #52
isaachinman wrote: post #46

Earlier quoted context omitted.

This is a really important question. If true, it could end a lot of Electron wastefulness.

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

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.

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

#88

Post by iansmith_hn »

SkiFire13 wrote: post #40
aabhay wrote: post #2

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

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

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.

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

#89

Post by queenkjuul »

rixed wrote: post #43
acmnrs wrote: post #7

Earlier quoted context omitted.

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.

900k lines of code plus tons of deps for a compiler? Does that really make sense to you?

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)

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

#90

Post by daveidol »

skybrian wrote: post #77
sroussey wrote: post #33

Earlier quoted context omitted.

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…

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.

It’s too bad we didn’t start out with Deno
Post reply on HN