DSent

I had some experience with Flash before (Flex) and wasn't really that fond of it. Another reason is that Silverlight was new and exciting technology at the time, arguably better suited for complex games than Flash. But possibly the biggest reason is that with Silverlight you get .NET/C#, which I was much more familiar with and in my opinion so much better than ActionScript.

We use self-hosted SignalR for communication. It's super easy to set up (at least, initially) and is very powerful. With Silverlight we used WCF/SOAP, but it was definitely not as flexible and was constantly getting in a way. Server-side is all .NET as you've assumed, hosted on Windows Server 2012. For client-side we use frameworks like Fabric JS (all the graphics in game), Knockout (two-way binding), Bootstrap (for scalability) and jQuery (obviously), among a couple of others. Client code was partially ported from Silverlight with Saltarelle Compiler (C# to JS converter), which really helped us enormously, since we've already had a massive code base.

I would also like to add that the basis of our game idea is to keep it as simple as possible, while at the same time having a stable learning curve and infinite replayability.

I would say it's first and foremost lacking the consistency. With HTML you are required to use a mishmash or different technologies i.e. HTML, CSS, JS, then there's dozens of JS frameworks mounted on top of it all, then there's LESS/SASS and more that a half of all of our JavaScript code is actually compiled from C#, which we scavanged from the old Silverlight client.

I like the analogy! In hind sight, it does make perfect sense, but at the time when we started (2009), HTML5 was still in its infancy, and the devices weren't all that powerful for canvas graphics, the browsers' JavaScript engines weren't as optimized as they are nowadays.