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

21–30 of 165 posts

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

#21

Post by Tadpole9181 »

pizlonator wrote: post #16
bbor wrote: post #14

Earlier quoted context omitted.

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.

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…

So you don't actually have real criticisms of the architecture at all...?

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

#22

Post by panzi »

xiaodai wrote: post #15

how can you compile it if javascript is a valid subset of typescript? confused.

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.

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

#23

Post by pizlonator »

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?

They will have untyped dependencies. That’s how the TS/JS ecosystem works.

Note that “untyped dependency” means any code that says `any`.

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

#24

Post by simonw »

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

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.

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

#25

Post by anematode »

pizlonator wrote: post #16
bbor wrote: post #14

Earlier quoted context omitted.

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.

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…

> deferring int optimizations for later

This part made me laugh out loud

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

#26

Post by vips7L »

simonw wrote: post #24
pizlonator wrote: post #23

Earlier quoted context omitted.

They will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.

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.

So like less than 1% of the time? What part of the JS ecosystem doesn’t depend on a mountain of untyped dependencies?

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

#27

Post by pizlonator »

simonw wrote: post #24
pizlonator wrote: post #23

Earlier quoted context omitted.

They will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.

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.

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

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

#29

Post by slopinthebag »

pizlonator wrote: post #27
simonw wrote: post #24

Earlier quoted context omitted.

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.

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

I think more human effort is going into defending this project then what was put into the project itself haha.

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

#30

Post by skeledrew »

pizlonator wrote: post #27
simonw wrote: post #24

Earlier quoted context omitted.

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.

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

> if you don’t believe me, then at least believe Claude

I had to do a triple take on this.

Post reply on HN