Hover is a Chrome extension that gives you IDE style hover tooltips on any webpage: documentation sites, ChatGPT, Claude, etc.
How it works: - When a code block comes into view, the extension detects tokens and sends the code to an LLM (via OpenRouter or custom endpoint) - The LLM generates documentation for tokens worth documenting, which gets cached - On hover, the cached documentation is displayed instantly
A few things I wanted to get right: - Website permissions are granular and use Chrome's permission system, so the extension only runs where you allow it - Custom endpoints let you skip OpenRouter entirely – if you're at a company with its own infra, you can point it at AWS Bedrock, Google AI Studio, or whatever you have
Built with TypeScript, Vite, and the Chrome extension APIs. Coming to the Chrome Web Store soon.
Would love feedback on the onboarding experience and general UX – there were a lot of design decisions I wasn't sure about.
Happy to answer questions about the implementation.
ramon156•17h ago
> The LLM generates documentation
so, not documentation? Why not write your own engine and detect the official docs? e.g. docs.rs would do this wonderfully
sampsonj•16h ago
Looking up official documentation would require shipping sophisticated parsers for each language, plus a way to map tokens to their corresponding docs. I'd also need to maintain those mappings as libraries evolve and documentation moves. Some ecosystems make this easier (Rust with docs.rs), but others would be much harder (AWS documentation, for example).
I also want explanations visible directly in hover hints rather than linking out to external docs. So even with official documentation, I'd need to extract and present the relevant content anyway.
Beyond that, the LLM approach adapts to context in ways static docs can't. It generates explanations for code within the documentation you're reading, and it works on code that doesn't compile, like snippets with stubs or incomplete examples.
It could be interesting in the future to look into doing some type of hybrid approach where an LLM goes out and searches up the documentation, that way it's a little bit more flexible. But that would also be a bit slower and more costly.
nativeit•16h ago
For whom? The whole reason I want to consult docs is to get the official documentation on a given topic. How could I trust anything it says, and what’s to say any earned trust is durable over time?
almostgotcaught•16h ago
what is the name for this kind of pointless, lazy, selective, quoting that willfully misconstrues what's being quoted? the answer to this question is incredibly clear: for the developer that created this tool. if that makes you unhappy enough to malign them then maybe you should just not use it?
sampsonj•15h ago
jagged-chisel•11h ago
That said, people have built this without LLMs years, even decades, ago. But UX has fallen by the wayside for quite some time in the companies that used to build IDEs. Then some fresher devs come along and begin a project without the benefit of experience in a codebase with a given feature … and after some time someone writes a plugin for VSCode to provide documentation tooltips generated by LLM because “there is just no other way it can be done.”
We have language servers for most programming languages. Those language servers provide the tokens one needs to use when referencing the documentation. And it would be so much faster than waiting for an LLM to get back to you.
TBH, if anyone’s excuse is “an LLM is the only way to implement feature Q,” then they’re definitely in need of some experience in software creation.
freedomben•52m ago
In my opinion the shipped product is better than the unshipped product. While of course I would prefer the version that you have designed, I sure don't have time to build it, and I'm guessing you don't either.
If this was our day jobs and we were being paid for it, it would be a much different story, but this is a hobby project made open source for the world.
F3nd0•12h ago
They quoted the part they were replying to. The point was to show what they were asking about. If your question pertains to only a part of the text, it only makes sense to be selective. That's not wilfully misconstruing anything; that’s communicating in a clear, easy-to-follow way. The context is still right up there for reading, for anyone who needs to review it.
> the answer to this question is incredibly clear: for the developer that created this tool
Questions aren’t only ever asked out of pure curiosity; sometimes they’re asked to make the other person give them more consideration. The question you quote was accompanied by an explanation of how the commenter found the approach less simple for them as a user, suggesting that perhaps they think the developer would have done better to consider that a higher priority. (I might add that you, too, chose to selectively omit this context from your quoting—which I personally don’t see as problematic on its own, but the context does require consideration, too.)
> if that makes you unhappy enough to malign them then maybe you should just not use it?
The author of the extension chose to share what they made for others to use. They asked for feedback on user experience and expressed doubt about their design decisions. If someone finds they might not want to use it because of what they consider fundamentally flawed design, why couldn’t they tell the author? It’s not like they were rude or accused them of any wrong-doing (other than possibly making poor design choices).
ramon156•15h ago
You could just token match (use tree-sitter or something similar) and fetch the official docs. Keep it dead-simple so there's no way you can provide false positives (unlike what's happening rn where hallucinations will creep in).
> It generates explanation
Again, I don't want that. It's not a feature, it's a limitation that right now gives you fake information.
nativeit•16h ago
I could see getting actual docs being useful. Spitting out the delusions of an LLM is pretty well covered already, at least in my stack.
jagged-chisel•11h ago