It’s not uncommon to have complex forms with a large number of fields in the line of business applications. In one of the projects at work, we recently implemented such form with 60+ fields. Behind the scene, this application uses sophisticated business rules to determine whether the field is mandatory or optional based on user inputs. We wanted to give our users a visual feedback about the fields - whether it is required/mandatory, and the provided value passes validation.

Need for writing modular JavaScript code increases with the size of your code base. Namespaces would help you up to a certain extent. However, it has some limitations. As codebase grows, namespaces tend to go deeper, and it doesn’t help with managing dependencies. Module pattern leverages closure and function scope to create encapsulation to prevent unnecessary details leaking into global scope. Let’s create a module All variables and functions are wrapped in an immediately invoked function expression(IIFE) and only an object containing the members to be exposed as public is returned.

In the firs part of this post I listed options for implementing real-time web functionalities in ASP.Net MVC. In this section, we will implement the same application using the SignalR. What is SignalR - from their website SignalR will use WebSockets under the covers when it’s available, and gracefully fallback to other techniques and technologies when it isn’t, while your application code stays the same. The OS-level support for WebSocket was introduced only in Windows Server 2012/Windows 8.

Probably you have experienced tediousness of writing code for marshaling data in and out of web UI. There weren’t too many options to avoid it until the client-side MV* frameworks appeared on the horizons in last couple years. Two-way data binding eliminates the bulk of boilerplate code you would have to write otherwise. It simplifies development by raising the level of abstraction and frees you up to focus on more important aspects of your application.

Gone are the days where one could let JavaScript code grow like the weed on the global scope. Increasing size and complexity on the client side calls for the better organization of code. Namespaces allow to organize units of code into logical groups and reduces possibilities of name collisions. JavaScript doesn’t provide any built-in way to define namespaces like C# or Java. Variables declared outside of function or object scope is by default added to the window space, which you could think of as a global namespace.