For debugging server-side code, Visual Studio hooks into the IIS server, letting programmers set breakpoints and step through the server-side code. Such breakpoints typically occur as a result of the user interacting with the Web page; during this time, the browser will be waiting for the server, unaware that the server is being debugged. (In that case, Visual Studio must either be on the same machine as IIS, or set up to remotely debug.)
But to debug client-side, developers need to set breakpoints that cause the browser itself to pause and wait for the debugger. Given that, the browser must be aware of the debugger and be on the same computer as the debugger.
That means if a developer has a single instance of Visual Studio running, then it needs to be aware that it's potentially debugging two separate processes: the server-side (through IIS) and the client-side (through the browser).
Instead, a good way is to set a breakpoint in the code (by right-clicking and clicking Insert Breakpoint in the context menu). Then set the HTML page you want to test out as the startup page (by right-clicking the page name in Solution Explorer and clicking Set As Start Page). Make sure the project is set up to use IE as the default browser (by right-clicking on the HTML file in Solution Explorer, and clicking Browse With. In the window that opens, click Internet Explorer, and then Set As Default. Close the window by clicking the upper-right button; don't click Browse, as you don't want to open the page from here, because it won't be set for debugging.) Finally, press F5 to start up the debugger in Visual Studio.
At this point, things worked really well. I set a breakpoint on the first line inside my function. When I typed something into the Web page and clicked the button, the page waited as Visual Studio activated with the code waiting at my breakpoint's line.
All is cool so far. Now let's try out the jQuery support.