Hacker News new | ask | show | jobs
by toomim 16 days ago
It's compiled to wasm for "performance", but...

1. WASM FFI has a big overhead when interacting with the javascript DOM.

2. Any DOM UI has a big overhead compared to a canvas.

I would be curious to see an actual performance evaluation. This looks like it was built for the wrong tradeoff otherwise...
1 comments
tracker1 16 days ago
Depends on how much overhead and disconnect there is on the wasm bridge... For a terminal, I doubt it's going to be a noticeable issue compared to render time in the browser.

I have a similar project I haven't touched in a few months.. that said, mine is geared more towards rendering for ANSI-BBS output matching DOS EGA characteristics and correcting for proportion/scale. Mine's in Rust, targeting Canvas and comes in around 50kb (including EGA pixel font embedding), which is a bit larger than this project, which relies on DOM for rendering.

FWIW, I've been meaning to get started on the next part which is a door host that takes WSS connections then running a BBS door for the connection... I'll be taking some inspiration from GHost3 (majorbbs rebooted door host). For now, test renders of .ans files seem to be working very well allong with mouse driven scrollback support.

I'll probably followup with a similar wasm that will support RIPScrip/RIPTerm 1.54 .. not sure if I'll be able to reasonable support v2+, but that would be nice too.

link