What we are going to learn in this article?
- We are going to see how normal Web development happens and what is new with Web Assembly.
- We are going to see the history of different ASP.NET Frameworks.
Let's check quickly how communication between client & server happens and what happens on the client-side specifically.
- Browser understands and processes HTML, CSS & JavaScript.
- When we open a link in a browser or submit a form on-page, browser sends HTTP requests to the Server.
- The server does some processing and returns the response which contains HTML, CSS, and JavaScript irrespective of what technology or database we are using on the server-side.
- In the case of RESTful Services, the response may contain data in the form of JSON or XML normally.
- The response may contain static resources; for example - image, text file.
- The browser provides a very limited form of control. For complex controls, we’ve to use custom scripts.
What was unique about ASP.NET Web Forms?
Microsoft introduced Web Forms in 2001 with Visual Studio.NET. WebForms came with event drive development like Windows Forms. Web forms got popular because of ease & quick productivity. It came with Server controls. The server control compiles into a normal browser control but with the extra script. For example, we didn't have built-in calendar control in the browser at that time. WebForms provides us with a calendar control (server control). We bind events with it; write code in C# and start using it. But how does the browser treat it? When Request goes to the server, it does the processing and returns the "required" HTML/CSS/JavaScript to render that "calendar" control in browser hence there is nothing new in the browser. When any event happens in the calendar on the client-side, the request is sent to the server to execute the event handler written in C#. Another example: Browser doesn't provide any complex grid component but web forms do. You can do programming in C# to handle different actions (e.g. sorting). In browser, it is rendered as a table tag for example. When some event (e.g. sort) happens on the client-side, it sends a request to the server to trigger some C# code. The developer doesn't need to know what is happening behind the scene but this makes a developer's life easier.
The era of jQuery Popularity (2008 onwards)
jQuery made client-side development very easy. It opened a new era of client-side plugins & development. JavaScript started getting great popularity. Developers started using JavaScript as a Programming language, not just only for client-side form validation. Web 2.0 got popularity. It was the start of creating "Thick" Clients & "Thin" Servers. The main purpose of the server side was to send data to the client. The client became responsible for getting data from the server through AJAX calls and updating DOM. Eventually, RESTful Services got popular. A lot of JS was being written. Many JS frameworks (e.g. backbone, angular) were introduced to solve different issues that came from thick client development.
ASP.NET MVC (2008 onwards)
Considering different issues with Web Forms & to cope with the latest trends (e.g. Unit Testing, Separation of concern), ASP.NET MVC was introduced. Later ASP.NET Web APIs were introduced to go with the "RESTFul Services" boom. Still Web Development model was the same as explained in the first part of this article.
ASP.NET Core
It was just an evolved (re-written) version of ASP.NET which solves many other issues of server side development but it still doesn't change the way Browser-Server works.
What are Rich clients?
What if we want some complex/rich functionality on the Client-side? What if I've developed a component written in C# or Java and want to use that in the browser? There has been a workaround for this since the start. Java Introduced Applets which are downloadable in the browser & run in its own environment (which require Java Runtime installed on client machine). Flash worked in the same way. Microsoft Introduced Plugins' support for IE. Then Microsoft Introduced Silverlight. You install its runtime on your machine; Silverlight application (written in C# for example) is downloaded in browser & runs in its own environment. One thing was common in all these; they can't access or play with DOM of the page.
What can help us to improve things in Web Development?
- Can we write do client side coding in programming languages other than JavaScript. For example, what if I want to play with DOM in C#?
- And can we write such code which can execute faster than JavaScript?
Question - What can we do to achieve above objectives without changing how browser basically works (understands only HTML, CSS & JavaScript)?
JavaScript is not pre-compiled but interpreted and compiled at run time. Pre-Run process takes extra time. What if we have compiled code and give it to the browser instead of plain JS and the browser just runs it? WebAssembly is the answer.
What is Web Assembly?
Around 2016, Web Assembly buzzword came. It is actually an open standard and not for a specific language.
[Ref: WikiPedia]
WebAssembly is an open standard that defines a portable binary code format for executable programs, and a corresponding textual assembly language, as well as interfaces for facilitating interactions between such programs and their host environment.
We'll not go into the depth of web assembly but will try to have enough detail so we can understand what is special about it. WebAssembly standard allows us to write code in any language and then compile that code into a (binary) "format" which can run in browser as JavaScript runs after compilation. Currently WebAssembly v1.0 is available. Browsers & different vendors are implementing this standard. If we want to use it, we need to write a translator that converts our code (e.g. C#) into format defined by WebAssembly. As this is pre-compiled (no compilation in browser), it may (or will eventually) run faster than current approach (i.e. plain JavaScript which is compiled at run time).
What is ASP.NET Core Blazor now?
"---Blazor lets you build interactive web UIs using C# instead of JavaScript.
Blazor can run your client-side C# code directly in the browser, using WebAssembly. Because it's real .NET running on WebAssembly, you can re-use code and libraries from server-side parts of your application. Alternatively, Blazor can run your client logic on the server. Client UI events are sent back to the server using SignalR - a real-time messaging framework. Once execution completes, the required UI changes are sent to the client and merged into the DOM.--- [Ref: Microsoft site]
With Blazor, you can write your code in C# (for example). It is compiled to WASM (a binary format that can run in the browser as JS runs in a browser). Then WASM is downloaded on the browser side. It runs in JavaScript runtime context and can access different components of runtime. So your code is running as you would have written JS code. Now imagine if you want to create a Grid component and want to handle its event in C#, you will do things like you used to do in Web Forms. But now C# code (compiled to WASM) will run in the browser and not doing any trick behind the scene as Web Forms used to do. But if you want to behave it like web forms (trigger event & do processing on the server and then get the result from server) you can do that too.
Many Platforms are providing support to compile their code to Web Assembly. So you will just write your code in your favorite language (e.g. C#, Python, Java, Typescript) and it will be compiled to WASM and WASM will be run in the browser. And as it is pre-compiled, it will eventually become faster than plain JavaScript. And there may a time come when JavaScript might be compiling to WASM too.
Summary
WebAssembly is going to change how we develop things. In one way, we are going back to Web Forms like development but with an enhanced approach. With time, JavaScript language for browser may die (or might be compiling to WebAssembly too).