[WIP] Begin moving towards invokable wire format

[wycats]

No description provided.

[github-actions]

	This PR	main
Dev	740K └─┬ . 233K ├── syntax 171K ├── runtime 161K ├── compiler 72K ├── opcode-compiler 27K ├── manager 24K ├── validator 13K ├── program 8.9K ├── reference 7.2K ├── destroyable 6.4K ├── util 4.3K ├── node 3.4K ├── global-context 2.6K ├── wire-format 1.0K ├── vm 969B ├── encoder 844B ├── vm-babel-plugins 606B └── owner	588K └─┬ . 169K ├── runtime 160K ├── syntax 100K ├── compiler 58K ├── opcode-compiler 27K ├── manager 24K ├── validator 11K ├── program 8.9K ├── reference 7.2K ├── destroyable 6.3K ├── util 4.3K ├── node 3.4K ├── global-context 2.5K ├── wire-format 1.0K ├── vm 969B ├── encoder 844B ├── vm-babel-plugins 606B └── owner
Prod	297K └─┬ . 103K ├── syntax 72K ├── compiler 64K ├── runtime 22K ├── opcode-compiler 7.9K ├── manager 5.6K ├── program 5.1K ├── validator 3.6K ├── reference 2.5K ├── util 2.1K ├── node 1.8K ├── wire-format 1.5K ├── destroyable 724B ├── vm 594B ├── global-context 516B ├── encoder 469B ├── vm-babel-plugins 155B └── owner	231K └─┬ . 70K ├── syntax 63K ├── runtime 48K ├── compiler 18K ├── opcode-compiler 7.9K ├── manager 5.1K ├── validator 4.8K ├── program 3.6K ├── reference 2.4K ├── util 2.1K ├── node 1.6K ├── wire-format 1.5K ├── destroyable 737B ├── vm 594B ├── global-context 516B ├── encoder 469B ├── vm-babel-plugins 155B └── owner

[Copilot]

Pull Request Overview

This PR begins transitioning towards an invokable wire format by updating integration test harnesses, refining event recording and cache behavior, and adding comprehensive documentation and pseudocode for the Glimmer reactivity system.

• Updated integration tests with new CSS and improved event recording handling.
• Refactored build configuration to adjust the typescript helper and updated the benchmark environment to reference layout compilation.
• Added extensive documentation and pseudocode for the reactive system, including tags, primitives, and composition.

Reviewed Changes

Copilot reviewed 171 out of 176 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
packages/@glimmer-workspace/integration-tests/lib/setup-harness.ts	Added import for new CSS tweaks.
packages/@glimmer-workspace/integration-tests/lib/render-test.ts	Extended test interfaces and recording event functionality.
packages/@glimmer-workspace/integration-tests/lib/modes/jit/delegate.ts	Minor whitespace adjustment.
packages/@glimmer-workspace/integration-tests/lib/compile.ts	Updated precompileJSON call with meta information.
packages/@glimmer-workspace/integration-tests/index.ts	Updated exports to include additional test helpers.
packages/@glimmer-workspace/build/lib/config.js	Refactored typescript function signature and adjusted SWC settings.
packages/@glimmer-workspace/benchmark-env/lib/benchmark/util.ts	Replaced reference to compilable with layout in entry compilation.
guides/reactivity/*	New and updated documentation and pseudocode for the reactivity system.

Files not reviewed (5)

• .prototools: Language not supported
• .vscode/settings.json: Language not supported
• package.json: Language not supported
• packages/@glimmer-workspace/build/package.json: Language not supported
• packages/@glimmer-workspace/integration-tests/lib/harness/tweaks.css: Language not supported

Comments suppressed due to low confidence (3)

packages/@glimmer-workspace/build/lib/config.js:410

• The typescript() function signature was changed by removing the package parameter. Please ensure all callers have been updated accordingly and update any related documentation or JSDoc to reflect this change.

              typescript(env),

packages/@glimmer-workspace/benchmark-env/lib/benchmark/util.ts:5

• The property reference was changed from 'compilable' to 'layout'. Verify that 'layout' exists on entry and that this change is consistent with the intended API to avoid compilation issues.

  return unwrapHandle(entry.layout!.compile(context));

packages/@glimmer-workspace/integration-tests/lib/render-test.ts:112

• [nitpick] This diff introduces private class fields (using the '#' syntax). Ensure that the target TypeScript/JavaScript environment fully supports private fields to avoid runtime errors.

  #events: RecordedEvent[] = [];

[reteps]

Any way that I can contribute? In the context of #1666, this would be very helpful.

[NullVoxPopuli]

idk, basically what's left here is that I need to add tests, and make sure CI goes green

[vlascik]

So I've been watching this PR in a hope ember will finally get its render performance act together, but I can't help myself but think this rewrite is going to miss the mark, again.

In my opinion, when it comes to the JS performance, two things are true:

1. You cannot get faster than vanillajs. vanillajs itself might get faster, but that's the JS engine authors' job, not the framework's.

2. The only way to be as fast as vanillajs, is to BE vanillajs.

I hope I'm wrong, but this PR doesn't seem to be headed into that direction (yet?).

If you profile say the simplest template, with just one <div>, flamegraphs show glimmer spends more time in JS execution of the VM than in the browser's createElement call - and that is what is causing the ember's 2x slowdown compared to every other framework. The code, that should have been just a simple createElement call, seems to be running up and down the VM stack, popping and allocating and doing JS work that it shouldn't be doing at all. The VM should only unpack the wire format once upon the first template use, the result should be something along the lines of templateRenderFunctionCache['my-template'] = new Function("document.createElement('div')") and from then on, the only thing executed should be the templateRenderFunctionCache['my-template']() and nothing else - no VM, no extra JS execution, no overhead to pay except for the first conversion from the wire format to vanilla JS.

Otherwise, you might shave off few milliseconds here and there, but this will never get fast enough to compete with frameworks executing vanillajs code or vanillajs itself.

I really hope I'm wrong and that is actually the plan, but upon (brief, I admit, don't have time to dig into this) look at this PR, it doesn't seem to be headed that way.

Thoughts?

[wycats]

I hope I'm wrong, but this PR doesn't seem to be headed into that direction (yet?).

@vlascik "(yet?)" is right. I'm trying to do this a little at a time, and even this incremental piece has been a somewhat significant project.

That said, the goal here is to get to a point where, first, the wire format itself is not needed. Next, we'd migrate more of the opcode compiler to vanilla-js (although I think you might be underestimating what's needed to make "vanilla js" support updating). If we can get to the end of this PR, I'll feel pretty optimistic about the direction you're suggesting.

And apologies for how long it's taken!