pastelsky
Joined 9 years ago
Joined 9 years ago
I built pretty.fish with the belief that Mermaid diagrams don’t have to look like they’re from the 80s and to avoid squinting at Mermaid diagrams that coding agents create in tiny windows.
Having them on canvas also makes it easier to keep a track of, and even visualize agent steps as and when they are are being taken (if you connect an MCP you get a pretty nice view of agent building its knowledge graph for eg for a problem).
Didn’t expect it to take off like this—there are still rough edges (pan/zoom, mobile), but I’m working on smoothing those out soon.
It’s 2024 and it doesn’t really work!
Pointing to the canonical source can also limit the usefulness in a few cases (e.g. d3 is just a bunch of re-exports), and users may not care about internal package organization.
> 2. consider supporting the @packageDocumentation tag Organizing by @category and @packageDocumentation should already be supported. e.g. See the functions in — https://tsdocs.dev/docs/lodash-es/4.17.21/index.html
> 3. Relative links to things like CONTRIBUTING.md currently break Yeah, this is known, thanks! https://github.com/pastelsky/tsdocs/issues/9
I created this because I found myself peeping inside type declaration files too often, and the only way to do that was by installing the package first.
tsdocs.dev helps you check the API surface of a good number of JS libraries and their past versions — usually a quick search away.
There's something powerful about speed and being able to answer questions in seconds that usually take minutes.
edit: The server might be overloaded with requests as we prime up our caches, but do visit back after HN's done hugging us to death.
You can show your support and help cover a part of server costs if this (or bundlephobia.com) saved you time.
So you don't have to rely on library authors to provide upto date reference docs for different versions of their library
Couldn't you simply express useful problems as a function of problems that the quantum computer can already solve? Doing so might be extremely in-efficient, but give that there's so much performance leeway, it still might end up being similar to super computers of today?