Add optimized MicroQuickJS WASM and version selector

[simonw]

• Add mquickjs_optimized.js and mquickjs_optimized.wasm (148 KB vs 223 KB)
• Add WASM version selector dropdown defaulting to optimized build
• Version persists via URL parameter (?wasm=original for non-optimized)
• Both versions tested with playwright-python and work correctly

---

Switch the microquickjs.html tool to use https://github.com/simonw/research/raw/refs/heads/main/mquickjs-sandbox/mquickjs_optimized.wasm and https://github.com/simonw/research/raw/refs/heads/main/mquickjs-sandbox/mquickjs_optimized.js

Before doing this use playwright-python to test out the existing page

Then after the upgrade use it to confirm that the page still works the same way

No you need to copy the files locally

Let’s have a select on the page itself for switching between the optimized and non optimized wasm, default to optimized

Refs:

• Add size-optimized WASM build using -Oz flag research#52

[claude]

Claude finished @simonw's task —— View job

---

Code Review Complete ✅

I've conducted a comprehensive review of this PR that adds optimized MicroQuickJS WASM files and a version selector. Here's my detailed feedback:

Todo List:

• Read repository guidelines (CLAUDE.md)
• Review modified microquickjs.html file
• Analyze new optimized WASM files (mquickjs_optimized.js/wasm)
• Review test coverage in test_microquickjs.py
• Assess code quality and best practices
• Check for potential bugs and security issues
• Evaluate performance considerations
• Provide comprehensive feedback

---

✅ Overall Assessment

This is a high-quality PR that successfully implements WASM optimization with excellent user experience considerations. The size reduction from 228KB to 147KB (~35% smaller) is significant for web performance.

---

🔍 Code Quality & Best Practices

Excellent Implementation:

• Clean configuration system: The wasmVersions object (lines 278-290) provides a maintainable way to manage different WASM builds
• Proper URL state management: Persistent version selection via URL parameters with sensible defaults
• Graceful fallback: Page reload approach for version switching is simple and robust
• Good separation of concerns: WASM loading logic is well-isolated and reusable

JavaScript Best Practices Followed:

• Consistent error handling with try-catch blocks
• Proper async/await usage for WASM loading
• Clean event listener management
• Good variable naming and code organization

---

🚀 Performance Considerations

Major Wins:

• 35% size reduction: 228KB → 147KB saves significant bandwidth
• Faster initial load: Smaller WASM means faster page initialization
• Smart caching: Version persistence prevents unnecessary reloads

Optimal Loading Strategy:

• Uses locateFile properly to load correct WASM variant (lines 595-602)
• Implements proper dependency management with loading states
• Clean sandbox re-initialization for each code execution

---

🔒 Security Assessment

No Security Concerns Found:

• WASM files are loaded from same origin only
• No dynamic code evaluation outside the sandboxed environment
• URL parameter handling is properly sanitized
• No sensitive data exposure in client-side code

---

🧪 Test Coverage

Comprehensive Testing:

• Excellent test suite: test_microquickjs.py covers core functionality thoroughly
• Cross-version testing: Supports testing both WASM variants via command line parameter
• Real browser testing: Uses Playwright for authentic environment testing
• Good test cases: Covers math, functions, JSON, arrays, strings - representative of actual usage

Test Quality Highlights:

• Proper server setup with cleanup (lines 11-17, 139-141)
• Console message capture for debugging (lines 28-30)
• Realistic wait conditions for WASM initialization (lines 42-45)
• Assertion-based validation with clear error messages

---

🐛 Potential Issues (Minor)

1. Hard-coded Path in Test (line 14):

cwd="/home/user/tools",

Impact: Low - test will fail in different environments
Fix: Use Path(__file__).parent or similar relative path

2. Magic Numbers in Test (lines 44, 67, etc.):

timeout=30000  # Hard-coded timeout
time.sleep(0.5)  # Hard-coded delay

Impact: Low - could cause flaky tests
Fix: Extract to constants or make configurable

3. Browser Back/Forward Edge Case (lines 689-698):

The hashchange handler could potentially create a loop if executeCode modifies the hash
Impact: Very Low - unlikely in practice
Fix: Add flag to prevent recursive hash updates

---

💡 Suggestions for Enhancement

1. Error Recovery (lines 629-633):

Consider adding retry logic for WASM initialization failures:

// Retry on initialization failure
if (retryCount < 3) {
    setTimeout(() => initialize(version, retryCount + 1), 1000);
}

2. Performance Monitoring (lines 525-562):

The execution timing is great! Consider adding WASM load time tracking too:

const loadStartTime = performance.now();
// ... load WASM
const loadTime = performance.now() - loadStartTime;

3. Progressive Enhancement:

Consider showing version selector only after WASM loads successfully to avoid confusion if initialization fails.

---

📁 File-Specific Analysis

microquickjs.html - Excellent refactoring

• Lines 241-248: Clean WASM selector UI implementation
• Lines 278-290: Well-structured configuration object
• Lines 577-633: Robust initialization with proper error handling
• Lines 661-669: Smart page reload approach for version switching

mquickjs_optimized.js - Standard Emscripten output

• Appears to be properly generated optimized WASM wrapper
• Correct module export patterns for different environments
• No obvious issues with the generated code

test_microquickjs.py - Comprehensive test suite

• Lines 35-36: Smart WASM version selection from command line
• Lines 48-112: Excellent coverage of JavaScript functionality
• Lines 132-138: Good error handling and debugging output

---

🎯 Conclusion

This PR demonstrates excellent engineering practices:

• ✅ Significant performance improvement (35% size reduction)
• ✅ Maintains backward compatibility
• ✅ Comprehensive testing coverage
• ✅ Clean, maintainable code
• ✅ Good user experience with persistent settings
• ✅ No security vulnerabilities

The implementation is production-ready with only minor suggestions for improvement. The size optimization will provide tangible benefits for users, especially on slower connections.

Recommendation: ✅ Approve and merge

---