Benchmark comparison

[garysassano]

How does this compare to selectolax (currently fastest HTML parser in Python)?

[taoqf]

This lib is getting slower while I was fixing issues. I wish I could rewrite this lib with rust.
It will be very appreciate if there is some ruster to help me with this.

[taoqf]

https://crates.io/crates/node-html-parser
Rust version will be faster, I did not test, but if you prefer faster way, try rust.

[samiurprapon]

For a Node project, I don't think a Rust rewrite would deliver much performance improvement here. I vibe-coded a package to Rust napi-rs. My findings:

• A synchronous napi-rs call typically adds around 0.01–0.05 ms of FFI overhead (V8 → N-API → Rust and back) before parsing starts. Async bindings add additional scheduling
  latency.

• On top of that floor, you pay a string marshaling cost: converting the JS UTF-16 string to a Rust UTF-8 String on the way in, and serializing the parsed result to JSON (or a napi object) on the way out. This scales with payload size, so for HTML-sized inputs it's usually the dominant cost, rather than the call overhead itself.

• Using Cloudflare's lol_html, the raw parser performance is excellent:

  • Small snippets: ~0.006 ms
  • Medium fragments: ~0.012 ms
  • Large documents: up to ~0.79 ms

• Realistically, the full round trip would be around 0.1–1 ms for a medium-sized document after including FFI and serialization overhead.

• Rust can be faster for very large HTML documents, but for typical usage, the improvement is not large enough to justify the added complexity of maintaining a Rust-based implementation.

This project can still be optimized significantly without a Rust rewrite. Other implementations like htmljs-parser have already shown that a JavaScript-based parser can achieve around ~0.2–7 ms parsing times. Focusing on optimizing the existing architecture would likely provide a better performance-to-complexity trade-off than introducing Rust + N-API.