Calling this a Lisp browser is like using Xmonad and calling Linux a Haskell Operating System.
Using that logic you can reduce a whole heap of things down to just "thin wrappers".
Yes, LispKit is a wrapper around a C++/C browser library. But would you really want someone writing yet another browser implementation in 2014? It's just not good engineering to rewrite things such as that. They're complicated, filled with security edge cases and would take a substantial amount of time compared to "just" writing a wrapper library.
In reality, LispKit exposes the WebKit API through Lisp using a bunch of relatively idiomatic (if I do say so myself!) functions and macros. For the most part it seems as if Lispkit was built from the ground up in Lisp. It does not feel like a "thin wrapper".
Wrapping WebKit is a great idea. I mean it generally hasn't worked well for other libraries that have tried it, none of them have managed to avoid lots and lots of bugs and quirky behavior, but maybe you do, so congratulations.
My only point is that this isn't a browser written in Lisp. It's not even remotely close to that! Yet that is what the title of the HN story implies. But it's not that, it's a wrapper, which is not what the title says, so I mentioned that. You are agreeing with me except you seem to think I'm implying something bad, which I'm not, beyond all the things implied by the facts, such as:
It does inevitably just feel like a thin wrapper. There is no way for a lisp hacker to get in there and play with it, or take this work and extend it using lisp. They can change how WebKit is wrapped, but changing or extending WebKit's behavior means digging into WebKit's millions of lines of C++.
(But the most beautiful software of them all, that arcane environment so many love, has a substantial lisp layer... so we got that going)
Well, you can browse Lisp sites with it, so there's that ...