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.
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.
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.
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?
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.
> 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.
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!
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.
This is like putting lipstick on a pig. Give me an AI written README or tests but actually thoughtful codebase over human written readme but aislop code any day of the month
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...
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.
That explains why:
- the architecture is idiotic.
- they have zero credible perf numbers.
I plan to benchmark it using generally accepted methods.
Porffor makes careful trade offs that make sense and is benchmarked in a way that I can believe.
(Source: I make dynamic languages fast for a living)
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 that languages that are even slightly dynamic need dynamic JIT opts is very old; folks figured that out in the 80s.
This project reeks of weapons grade AI psychosis
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?
So you don't actually have real criticisms of the architecture at all...?
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/
> 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.
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!
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 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 is like putting lipstick on a pig. Give me an AI written README or tests but actually thoughtful codebase over human written readme but aislop code any day of the month
Perhaps they should be left as a warning to others.
how can you compile it if javascript is a valid subset of typescript? confused.
178kb?! What are you putting in there, a JVM?
I like the idea.