At windmill.dev, when users deploy their code, we use Bun build (which is similar to esbuild) to bundle their scripts and all their dependencies into a single js file to load which improve cold start and memory usage. We store the bundle on s3 because of the size of the bundles. If we could bundle everything to native that would completely change the game since as good as bun's cold start is, you can't beat running s…
Hey, dev here, I agree that is an interesting application which Porffor could potentially help with! Happy to chat sometime :)
I'm a bit suspicious of the versioning scheme described here[0] If some change were required which introduced a regression on some Test262 tests, it could cause the version number to regress as well. This means Porffor cannot have both a version number which increases monotonically and the ability to introduce necessary changes which cause Test262 regressions [0] https://github.com/CanadaHonk/porffor?tab=readme-ov-fi…
Presumably the idea is that any work that causes Test262 regressions is temporary, takes place in a separate branch, and is only merged to main once the branch also contains all the necessary fixes to make the regressions go away again. A new version number would only be used once that merge happens.
Exactly. The versioning system is definitely unique and controversial, but I think it fits for a fast moving project like this, so I don't have to really consider versioning which could slow development. When it becomes more stable, I'll likely move to a more traditional semver scheme from 1.0.
It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android). I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor? * They both aim for JS test26…
You make it sound bad to rely on LLVM.
Yeah... It is unclear to me how not using LLVM is a good thing. You'd inherit millions of man-hours of optimization work, code gen, and general thought process.
Yeah... It is unclear to me how not using LLVM is a good thing. You'd inherit millions of man-hours of optimization work, code gen, and general thought process. Is there a technical reason why?
In this case, being self contained will help implementing things like `eval()` and `Function()` since Porffor can self-host. That would be much harder with a LLVM based solution.
Outside of really funky code, especially code originally written in TS, you can assume the interface is the actual underlying object. You could easily flag non-recognized-member accesses to interfaces and then degrade them back to object accesses.
You’re misunderstanding me, I think. Suppose you have some interface with fields a and c. If your function takes in an object with that interface and operates on the c field, what you want is to be able to do is compile that function to access c at “the address pointed to by the pointer to the object, plus 8” (assuming 64-bit fields). Your CPU supports such addressing directly. Because of structural subtyping, you ca…
> Because of structural subtyping, you can’t do that
In practice v8 does exactly what you're saying can't be done, virtually all the time for any hot function. What you mean to say is that typescript type declarations alone don't give you enough information to safely do it during a static compile step. But modern JS engines, that track object maps and dynamically recompile, do what you described.
What subtleties am I missing that makes "ahead-of-time JS engine" a better description than "JS-to-Wasm compiler"? (If it's mostly a framing strategy, that's cool too.)
There are already projects that does JS-to-WASM by bundling a JS interpreter. So, it's likely to make the difference to those clearer.
At least without additional extensions, TypeScript would help less than you think. It just wasn’t designed for the job. As a simple example - TypeScript doesn’t distinguish between integers and floats; they’re all just numbers. So all array accesses need casting. A TypeScript designed to aid static compilation likely would have that distinction. But the big elephant in the room is TypeScript’s structural subtyping. T…
I think the even bigger elephant in the room is that TypeScript's type system is unsound. You can have a function whose parameter type is annotated to be String and there's absolutely no guarantee that every call to that function will pass it a string. This isn't because of `any` either. The type system itself deliberately has holes in it. So any language that uses TypeScript type annotations to generate faster/small…
> I think the even bigger elephant in the room is that TypeScript's type system is unsound.
Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.