Hacker Newsnew | past | comments | ask | show | jobs | submit | henryhale's commentslogin

interesting


Nice


well done


great work over there.

allow users to pin or star tools for quick access - it would be nice to have.


You got it. Just pushed the change. Check it now.


interesting - i love it.


thank u man. would love your feedback.


give depgraph a try - https://github.com/henryhale/depgraph - i'd like to learn about how i could improve it.


I gave it a try on my current codebase out of curiosity. Definitely useful. It worked well and fast, but it has a lot of duplicates that get rendered as exports in the NodeJS modules based codebase. I think it can sometimes be caused by me just being haphazard about re-exporting them, but other times I'm not sure.

Eg authenticatedMenu() appears 4 times in authenticatedMenu.js, only one of them is imported by 2 different files and 3 are just there alone. There's a single export in the file and a number of other files import it through an index.js that re-exports several files other files too.

In my case I think it'd help, if I could disable the duplicates as they don't really provide any useful information when exploring the codebase.

Also, if there was optionally a way to ignore the files that re-export functions/classes and collapse those paths, it'd make the graph a lot smaller and more easy to understand. Maybe it's already something that depgraph does, but the duplicates confuse things, so I'm not sure.


> I think it can sometimes be caused by me just being haphazard about re-exporting them, but other times I'm not sure.

I think so too. I guess that's how your project is structured and duplicates maybe inevitable.

The graph shows exactly how the project is organized. Right - "duplicates confuse things" - this would suggest eliminating "files that re-export functions/classes" or passing an option (-i) for ignoring specific paths would help. Otherwise, this issue is noted for further analysis.

Thanks for trying depgraph.


I have been working on depgraph (https://github.com/henryhale/depgraph) for a while now. It is truly local with several output options(json, mermaid, jsoncanvas). Mutliple languages are supported (js, go, c) - expanding the list slowly but sure.


why not abstract that away so that `track()` can do it all? It would be alot easier to work with.


>I don't get how this would be more "ai friendly" than other frameworks, that kind of propositions should be backed by more concrete proof.

Most if not all llms are producing Markdown instead of HTML as the primary output. Markdown has a simpler syntax that basically uses fewer tokens compared to HTML Similarly, Ripple appears to express a complex structure in simple terms compared to React or HTML or whatever. No wonder most AI dev tools operate in React with web previews abstracting away the setup process.

Higher abstractions appear to be cost efficient(both training & inference time - output generation). All that is required is to provide the model with a document containing rules about ripplejs(in this case) and go from there...more like llms.txt or agent.md or simply documentation. Any DSL would fit in a single file and easily consumed by a model.


shorter syntax != higher level of abstraction


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: