Come on, this was about the language syntax, not some external massive util library. Ofc, this web engine would implement mostly its own utils, since dependency on external kludge like unistring or ICU or even worse harfbuzz(c++!)... would nullify the advantage to depend on a simple computer language.
I did not look that much into it but I can bet that 'lisp' browser is actually just a 'lisp front-end' to big tech web engines... namely a scam, please prove me wrong.
I would write a browser in RISC-V assembly with a small macro pre-processor, but the issue with the web is its infinite scope killing any non big tech, real-life, alternative attempt, and not for the good reasons.
I think it's an elegant design that sidesteps many issues, and since bindings aren't involved you are designing purely in the language of choice. You can't expect every project to reimplement every library down to the stdlib.
You always cherry-pick the code you want, and in the worse case scenario you port it or the part you want from it (open source powa). Often, performance critical code paths of significant size are assembly anyway or when small, they are built-in to maximize inlining to avoid a function call.
And like it was exposed below: in this end, this is sort of not very honnest, because this is just another Big Tech engine front-end.
I did not look that much into it but I can bet that 'lisp' browser is actually just a 'lisp front-end' to big tech web engines... namely a scam, please prove me wrong.
I would write a browser in RISC-V assembly with a small macro pre-processor, but the issue with the web is its infinite scope killing any non big tech, real-life, alternative attempt, and not for the good reasons.