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.<p>But if you're starting from scratch and know you won't be using any npm packages, you might as well use AssemblyScript.[2]<p>[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.<p>[1]: <a href="https://github.com/nodejs/node/blob/main/doc/api/typescript.md#type-stripping-in-dependencies" rel="nofollow">https://github.com/nodejs/node/blob/main/doc/api/typescript....</a><p>[2]: <a href="https://www.assemblyscript.org/" rel="nofollow">https://www.assemblyscript.org/</a>
> so realistically you'd still need a JavaScript engine if you use any packages.<p>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 <i>types</i> kinda boggles the mind, ngl!
Porforr<<a href="https://porffor.dev" rel="nofollow">https://porffor.dev</a>> has been working towards the same goal for a while. The creator, CanadaHonk<<a href="https://honk.foo" rel="nofollow">https://honk.foo</a>>, 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<p>Coding agents. They landed 918,000 lines of code in a single week: <a href="https://github.com/vercel-labs/scriptc/graphs/contributors?selectedMetric=additions" rel="nofollow">https://github.com/vercel-labs/scriptc/graphs/contributors?s...</a>
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:<p>- the architecture is idiotic.<p>- they have zero credible perf numbers.<p>I plan to benchmark it using generally accepted methods.<p>Porffor makes careful trade offs that make sense and is benchmarked in a way that I can believe.<p>(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:<p>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.
A lot of people are trying this now with AI, a native TypeScript compiler, for example <a href="https://github.com/PerryTS/pry" rel="nofollow">https://github.com/PerryTS/pry</a>. 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.
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.