February 2012's London Web Standards event at Forward London was an introduction to Node.js, the server-side javscript framework designed for high concurrency and real-time events. There were two sessions at the event, George Ornbo (@shapeshed) giving an introduction to Node, and a "Node & Tell" session, where four sets of developers came and told the gathered crowd how they'd been using Node in their work.
In my work, I'm parsing web services all of the time. Most of the time, they're XML, which does not make the best use of bandwidth/CPU time (compared to JSON), however, if it's all that you're given then you can certainly get by. I've been looking into ways to speed up the XML document traversal in with jQuery after the current best practice method was removed.
If you've developed for Microsoft's SharePoint before (I'm talking about 2007 here, but this applies to WSS2 and 2010 as well) , then you'll know that you can reach the limits of it's functionality very quickly. This is a big problem if you're making a zero-code solution, i.e. you have no access to Visual Studio and can't create web parts. This is more common than you'd think, especially in large organisations that use SharePoint extensively. For this, the only choice is to use SharePoint Designer 2007 (SPD), but it's not pleasant because, frankly, SPD sucks. I've not found a program that crashes as much as SPD, or that performs so poorly when presented with the most basic tasks. If you make a page that is too complex, has too many web parts, large data sources or lots of conditionals, connections and filters, it can take anywhere up to 20 minutes to perform a single action.
Web applications are the next big thing in the web. Being able to take web sites and make them run alongside native apps, having them work offline and perform just as well as their native counterparts is the next step along the road. As usual, with all new technology, there are some limitations.