While at NDC 2012 in Oslo, Jon MC’d a Cage Match between Rob Conery (Node.js and socket.io) and Damian Edwards (ASP.NET and SignalR). Immediately after the cage match ended, Jon and K. Scott caught up with them to talk about the similarities and differences between these development stacks.
Download / Listen:
Herding Code 145 – NDC Cage Match with Rob Conery (node.js/socket.io) and Damian Edwards (SignalR) [audio:http://herdingcode.com/wp-content/uploads/HerdingCode-0145-NDC-Cage-Match-with-Rob-Conery-and-Damian-Edwards-update.mp3]
- Jon asks Rob about WebSocket support and fallback to older alternatives. Rob and Damian both discuss the fallback methods.
- Jon asks about the differences in development stacks.
- K. Scott asks about what was actually built during the presentation. Rob and Damian talk about what they built in the time available. Rob was wanting to use Backbone if time permitted. Damian says he generally uses simple HTML for many cases.
- Damian calls out a future feature they’re working on for SignalR that adds something like an Update Panel for Web Forms using SignalR.
- Rob talks about the synchronization feature Backbone uses with SignalR and tells Damian they should add something similar to
- Jon asks if Rob and Damian are "web scale." Rob talks about how he load tested using NodeLoad. Damian talks about how he tested using Flywheel and WCAT. Damian says they’ve been able to get great throughput out of SignalR and how they’re moving to some custom data structures to possibly double or triple capacity in SignalR 0.6.
- Rob thinks it’s interesting the SignalR can run outside of ASP.NET, and Damian talks about the hosting models for SignalR.
- Jon asks about some of the differences in development. Rob talks about the Node module ecosystem, Damian calls out some of the advantages of using .NET on the server.
- SignalR runs on Mono.
- K. Scott asks what the future holds for SignalR. Damian talks about 0.6, calling out future performance enhancements in the in-memory message store and standardizing on OWIN as the hosting layer. In version 1, they’re looking at the client story, low level transport, cross-domain support, and more.