No it doesn't, I just never use it because it's not integrated into Node-RED itself. Just as I don't like copying flow json titbits from the forum to Node-RED just to look at the flow. This is just me, I don't like the extra steps when everything could be done better directly inside Node-RED.
If I could search flows on flows.nodered.org via an interface in Node-RED then I'd be happy. If I could then upload my flows to flows.nodered.org using a single button inside of Node-RED, I would be even more happy. If I could then visually compare versions of flow code inside Node-RED well then I would have FlowHub. Because that's what FlowHub does.
I know flows.nodered.org doesn't do these things and I know I could have made these changes over at flows.nodered.org but flows.nodered.org isn't coded in Node-RED and that was part of the exercise: create extensions for Node-RED in Node-RED.
But that's not what I'm looking for, I'm looking for Node-RED integration. Not a searchable website. Just as the node packages are beautifully integrated into Node-RED - in fact the inspiration for better flow integration - why not the same for libraries of shared flows?
I don't understand why a better integration of flows and flow libraries into Node-RED is such an uphill discussion. And besides, I don't care about what the other kids across the street are playing, I want to play Node-RED and I want to play it efficiently. No switching between my Emacs and Node-RED when I'm developing nodes for Node-RED. No switch browser tabs to copy code from GitHub or wherever, all my flow code is integrated in Node-RED as a list and checked in on GitHub - version control and visual code. And all coded in Node-RED.
Sorry, but this discussion started back about two years ago when I asked whether there was a way to visual flow json files in a browser without Node-RED. The answer was: no and if it was easy, then it would have been done already. It took me all of a week to have an initial version of the flowviewer completed. Which, after those two years, is now integrated here (btw thanks again for doing that :)).
Only two years. So I assume that FlowHub will also take another two years before it catches on. So what. In the meantime, I'll just keep working on Erlang-Red, which has already created a certain resonates within the Erlang/BEAM community.
Plus because all the coding I did with FlowHub, I can seamlessly transfer flow code between Erlang-Red and Node-RED to create a library of tests to verify that I'm matching Node-RED functionality in Erlang-Red.
Here's another idea: lets create suite of visual unit tests that ensure that node functionality is maintained between versions? The test suite above is a start.