Porffor: A from-scratch ahead-of-time JS engine

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.

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.

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.

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 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)

[1] https://github.com/facebook/hermes/discussions/1137

[2] https://github.com/tc39/test262

[3] https://wasmer.io

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-file#ver...

I have been working on providing quickjs with more node compatible API through llrt [1] for embedding into applications for plugins.

[1] https://github.com/awslabs/llrt

> 1+1

2

> help

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)

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.

It was called hiphop-php, then they eventually gave up, before creating hhvm on a complete new concept.

[0] - https://github.com/ijustlovemath/jescx

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.

WASM is the next step after SPA's essentially.

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.

[0] https://bun.sh/

import * as squint_core from 'squint-cljs/core.js'; console.log("hello");