You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal: Compressing DevDocs with a Low-Level C Core #2669
I’ve been using DevDocs for years—it’s a lifesaver when AI fails on niche cases. I have a lot of respect for the work done so far, but the current Ruby/JS stack feels like it’s holding the project back from being as fast and straight-forward as it could be
What i am asking is if I can rewrite the core server and processing logic in C? Specifically:
The Search Engine: Moving the indexing and fuzzy matching from JS to a C codebase that is compiled to a wasm module to kill the memory lag
The HTML Pipeline: Replacing the Ruby/Nokogiri filters with a fast C-based parser for cleaning docsets
The Local Server: Swapping the Ruby/Sinatra backend for a lightweight C static server to remove the heavy runtime requirements for local hosting
Due to such changes around 30% of the project may be reduced including the definite removal of something as useless as docker, which will be replaced with simple statically-compiled servers for each OS that people can just download (or build themselves since C is available on all platforms) and launch the server without any unnecessary dependencies
I'm happy to handle the heavy lifting and resolve any issues that pop up with this new setup. Are you guys open to adding this C-based paradigm to the official repo? I truly believe this would make the project much leaner and easier to maintain long-term
I truly hope that you will accept this crazy request to rebuild the core of the project in a language that most of your contributors probably dont use and I hope I get the chance to work with you on this
Something like Go or Rust would be more maintainable, while still giving the same benefits as C (smaller binary size, less dependencies, faster execution, quicker to develop).
I do believe that some of the scraping logic can stay/should stay in Ruby, but I would be happy to see it also ported to Go/Rust or even Python/Node.
@tsengia
Something like Go or Rust would be more maintainable, while still giving the same benefits as C (smaller binary size, less dependencies, faster execution, quicker to develop).
I dont know who hit you in the head and said rust is a maintainable language because it isnt, but i can see the case for go, but even so the zero-overhead perks of C are unbeatable so i would still prefer to work in a proper language like that
But even so, if the maintainers of devdocs want a more modern language, using D wouldnt be too bad, its still not as good as C but its decent enough
Activity
tsengia commentedon Mar 30, 2026
I've had similar thoughts.
However I disagree with your choice of C.
Something like Go or Rust would be more maintainable, while still giving the same benefits as C (smaller binary size, less dependencies, faster execution, quicker to develop).
I do believe that some of the scraping logic can stay/should stay in Ruby, but I would be happy to see it also ported to Go/Rust or even Python/Node.
CyberReaper00 commentedon Mar 31, 2026
I dont know who hit you in the head and said rust is a maintainable language because it isnt, but i can see the case for go, but even so the zero-overhead perks of C are unbeatable so i would still prefer to work in a proper language like that
But even so, if the maintainers of devdocs want a more modern language, using D wouldnt be too bad, its still not as good as C but its decent enough
simon04 commentedon Jul 15, 2026
See #2710 for an attempt to serve devdocs only from static assets. Would love to hear your feedback.