Oliver (the main developer) just announced that they’re going to work full time on Porffor: <a href="https://x.com/canadahonk/status/1818347311417938237" rel="nofollow">https://x.com/canadahonk/status/1818347311417938237</a>
I have thought about doing this and I just can't get around the fact that you can't get much better performance in JS. The best you could probably do is transpile the JS into V8 C++ calls.<p>The really cool optimizations come from compiling TypeScript, or something close to it. You could use types to get enormous gains. Anything without typing gets the default slow JS calls. Interfaces can get reduced to vtables or maybe even straight calls, possibly on structs instead of maps. You could have an Int and Float type that degrade into Number that just sit inside registers.<p>The main problem is that both TS and V8 are fast-moving, non-standard targets. You could only really do such a project with a big team. Maintaining compatibility would be a job by itself.
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.<p>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 straight native with a small binary.
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).<p>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?<p><pre><code> * They both aim for JS test262 conformance [1]
* Porffor supports both Native and Wasm outputs while Static Hermes is mainly focused on Native outputs for now
* Porffor is self-hosted (Porffor is written in pure JS and can compile itself), while Static Hermes relies on LLVM
* Porffor currently doesn't support async/promise/await while Static Hermes does (with some limitations)
* Static Hermes is written in C++ while Porffor is mainly JS
* They both support TypeScript (although Static Hermes does it through transpiling the TS AST to Flow, while Porffor supports it natively)
* Static Hermes has a fallback interpreter (to support `eval` and other hard-to-compile JS scenarios), while Porffor only supports AOT compiling (although, as I commented in other thread here, it maybe be possible to support `eval` in Porffor as well)
</code></pre>
In general, I'm excited to see if this project can gain some traction so we can speed-up Javascript engines one the Edge!
Context: I'm Syrus, from Wasmer [3]<p>[1] <a href="https://github.com/facebook/hermes/discussions/1137">https://github.com/facebook/hermes/discussions/1137</a><p>[2] <a href="https://github.com/tc39/test262">https://github.com/tc39/test262</a><p>[3] <a href="https://wasmer.io">https://wasmer.io</a>
There's a subset of JS that's trivially compilable, it's the long tail of other stuff that's hard. But cool to see research happening on where that boundary lies and how much benefit can be had for that subset
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.)
I'm a bit suspicious of the versioning scheme described here[0]<p>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<p>[0] <a href="https://github.com/CanadaHonk/porffor?tab=readme-ov-file#versioning">https://github.com/CanadaHonk/porffor?tab=readme-ov-file#ver...</a>
Its refreshing to see all the various JS engines that are out there for various usecases.<p>I have been working on providing quickjs with more node compatible API through llrt [1] for embedding into applications for plugins.<p>[1] <a href="https://github.com/awslabs/llrt">https://github.com/awslabs/llrt</a>
Promising, but a few rough edges.<p>> 1+1<p>2<p>> help<p>Uncaught ReferenceError: help is not defined
at exports.<computed> [as main] (file:///opt/homebrew/lib/node_modules/porffor/compiler/wrap.js:494:19)
at REPLServer.run (file:///opt/homebrew/lib/node_modules/porffor/runner/repl.js:98:27)
at bound (node:domain:432:15)
at REPLServer.runBound [as eval] (node:domain:443:12)
at REPLServer.onLine (node:repl:927:10)
at REPLServer.emit (node:events:532:35)
at REPLServer.emit (node:domain:488:12)
at [_onLine] [as _onLine] (node:internal/readline/interface:416:12)
at [_line] [as _line] (node:internal/readline/interface:887:18)
<i>Porffor can compile to real native binaries without just packaging a runtime like existing solutions.</i><p>Any language that allows generating and interpreting its own code at runtime will have the "eval problem". From some other comments here, it sounds like Porffor's solution is to simply ignore it.
Seems like the same idea that Facebook had with PHP which was to transpile PHP to C.<p>It was called hiphop-php, then they eventually gave up, before creating hhvm on a complete new concept.
I'd love to know if there's a way to compile NodeJS to native libraries with this! I have a process [0], but it's a bit hacky and error prone<p>[0] - <a href="https://github.com/ijustlovemath/jescx">https://github.com/ijustlovemath/jescx</a>
The most interesting bit about Porffor in my eyes is it lets JavaScript compete with something like Blazor (or allows JS to stand its ground), which kind of makes using any JS in your project redundant, since all your front-end logic can be done in C#. The reason I say this is, because obviously, there are JS devs, but if WASM tooling in other languages grows it will make JS redundant or feel incomplete / outcompeted.<p>I wont be surprised to see a SPA framework that uses Porffor once it is more mature, or even the major ones using it as part of their tooling.<p>WASM is the next step after SPA's essentially.<p>If you have never touched Blazor, I recommend you check it out via youtube video if you don't do any C#, it is impressive. Kudos to Microsoft for it. I have had 0 need or use for JavaScript since using it.
Just out of curiosity, how does the performance (compilation + runtime) compare to something like bun[0]?<p>[0] <a href="https://bun.sh/" rel="nofollow">https://bun.sh/</a>
I got "TodoError: no generation for ImportDeclaration!" for this script:<p>import * as squint_core from 'squint-cljs/core.js';
console.log("hello");