At a bare minimum, counterparty-server’s reliance on a fork of Bitcoin Core with addrindex is problematic. Even if we were on good terms with Bitcoin Core, they’ve failed to merge addrindex functionality for years. The patch we’re relying on as a workaround is practically unmaintained.
btcd, bcoin and libbitcoin all feature native address indexing, so switching to any one of these altnodes on the backend would be a major step in the right direction for Counterparty. It would also be simple enough to not require a rewrite. To that end, would be interesting to discuss e.g. funding a Venezuelan full time dev team for Counterparty, paid in digital currency, but that is getting off-topic here.
It’d be crazy not to use bcoin/btcd/libbitcoin. We must break the dependency on our patched version of Bitcoin Core.
Something to consider about BCoin, however; BCoin includes native C code for performance reasons. Hence, BCoin is going to ship a mixed JS/C codebase forever and ever. Not that I don’t trust JJ to write C, but impurity creates complications.
Conversely, btcsuite is pure Go, and Go has very nice deployment properties. Nicer than JS and much nicer than C++. I also see @rubensayshi is contributing some code to btcsuite.
JS makes a lot of sense when writing consumer facing software that is intended to run inside a web browser. Also, the immensity of the JS ecosystem makes it a stronger contendor than Python for a wide range of uses IMO; but I’m biased there, I’m not a fan of Python whatsoever so JS being better than Python doesn’t mean much.
Enterprise server deployments are in a different category, and for what we’re doing with indexing the blockchain, and parsing the blocks for Counterparty data, I think you pretty much have to favor C++ and Go over JS.