I used juantar's excellent plugin (based off Zack0Wack0's) to create my prototype, and also followed juantar's tutorial to make my node.js server.
It was very disappointing because I was getting huge lag spikes and desyncs in localhost, with only two players in separate windows, and it's not an issue with my server code or my logic, since I redid the prototype in MMF2 (while keeping the server written in node.js). The lag issues there were still present, although a lot less due to it being raw TCP sockets instead of websockets. I was able to compensate for lag with some dead reckoning in MMF, and the game appeared to be completely playable even with ~300 ms latency once I put in UDP.
Construct is a lot more enjoyable to work with, especially since you can hook up debuggers and inspect traffic flow without having to resort to wireshark, and the fact that you can jump straight into the code (thanks to the SDK) if you need something more complex.
The issues don't appear to be construct's fault, though I have a slight feeling that socket.io "message received" events either aren't triggers (I haven't checked) or triggers are affected by chrome's policy of slowing down inactive tabs.
In any case, multiplayer of any kind seems like a no-go in HTML5, since even having a window pop-up in front of chrome causes it to suspend your thread and make the player lose sync.Artillery
claims to have made a playable air-hockey game, which would be ideal, however they seem to have ran into the same issues
regarding the lack of UDP support. Researching the web I've found some people who claim to have solved the problem by round-robing two, three or more instances of web-socket objects to prevent the entire game from choking on a lost packet, but so far I've seen no working examples.
If anyone has any comments on the issue such as success stories, links to further resources, research papers, prototypes or even wild ideas, I'd be happy to hear them.