DEV Community: James

Will WebAssembly (Wasm) replace JavaScript?

James — Mon, 07 Mar 2022 20:11:04 +0000

Ever since JavaScript was created in 1995 it has formed a key part of providing interactive experiences on websites. However, since WebAssembly (Wasm) support is now available in major browsers, will it be able to hold out against the competition, or will WebAssembly replace JavaScript as the essential tool for client-side development on the web?

I think there are several factors that will drive or slow developers to adopt WebAssembly as a JavaScript replacement. These are, the current level of language adoption by developers, the existing library support available, how comprehensive the browser support is, and the experiences they allow developers to deliver to users.

Language Adoption

At the moment, almost 98% of all websites use JavaScript for client-side development. This is primarily due to it being the only real option (especially since Flash support ended in 2020). JavaScript can also be used for server-side development, which enables developers to use the same language for the client-side and server-side parts of their web applications, through platforms such as Node.js. This makes JavaScript very flexible, since you can learn the language once, and apply it almost anywhere.

Making the case for WebAssembly is a little more complicated. WebAssembly can be compiled from multiple languages, each with their own positives and negatives. In the end, I imagine developers will use the language they are most familiar with already. This would seem to leave WebAssembly as an equal with JavaScript, since both could be used for client-side and server-side development.

Library Support

Due to JavaScript being the only viable option for client-side web development, a large number of libraries and packages have been developed with it. There are currently over 1.3 million packages hosted on npm, covering a wide variety of functionality for developers to leverage in their own applications. This makes JavaScript faster to build with, since developers are able to use these packages for common functionality.

In addition to this, there are also a number of frameworks available to support client-side development such as Angular or Vue. The breadth of support available makes using JavaScript a very safe option.

In the case of WebAssembly, the libraries available will vary between each language. But it would allow developers to leverage existing libraries for that language, so long as they are able to be compiled to WebAssembly. This opens up the possibility of using a range of performant features which would have previously been unavailable or difficult to achieve in JavaScript, such as image or video processing.

However, one of the notable drawbacks of WebAssembly, is that it cannot manipulate the HTML page directly. At the moment, a Wasm module must use JavaScript to update or modify page content in response to user interactions or data changes.

Browser Support

Browsers have extensive support for JavaScript, with major browsers implementing a wide variety of Web APIs. These APIs allow JavaScript code running in the browser to access a some of the features of the device, ranging from the device location to connected Bluetooth and USB peripherals.

WebAssembly is also supported by the major browsers. So applications which use it already have a pretty wide reach. It is worth being aware, that the Web APIs allowing access to features of the local device are only available to JavaScript code executing in the browser. As a result, WebAssembly code cannot access these features directly.

This would seem to indicate that browser vendors see JavaScript as a very flexible way to expose increasingly complex device features and functionality to developers. Meanwhile, WebAssembly has to rely upon JavaScript to access these APIs. To me, it certainly looks like JavaScript has the advantage in this case.

Experience Support

Both JavaScript and WebAssembly are capable of running complex client-side web applications. They will both handle functionality such as processing request routing information, responding to data changes and processing responses for user commands. However, JavaScript has very mature support for these use cases and is likely to remain the first choice for many.

WebAssembly performs best in specific use cases. This is usually when more intensive processing, such as in image or video editing, or rendering 3D graphics is required. While it would be possible to perform these tasks in JavaScript, the performance would be slower than a specially crafted Wasm module performing the same tasks. This is due to WebAssembly being compiled during the build process; speeding up browser execution.

Summary

To conclude, will Wasm replace JavaScript? No. Wasm is intended to compliment JavaScript in browsers, not provide a replacement. This is reinforced by Wasm modules needing to use JavaScript to interact with the HTML page.

The aim of Wasm is to support a variety of use cases that would be difficult or impossible to practically achieve through JavaScript alone. These could be rendering 3D graphics (such as in games), or other processing intensive operations (such as simulations). An example of this is Doom 3 running in a web browser, which uses Wasm to run the game and renders the graphical output to a HTML canvas.

While Wasm opens the door to many exciting new opportunities, in my opinion, JavaScript will remain the standard for client-side web development for a long time. Even the WebAssembly website indicates that JavaScript "will remain the single, privileged dynamic language of the Web".

AI Assistance for Software Developer Productivity – The Good, The Bad & The Ugly

James — Tue, 06 Jul 2021 19:17:13 +0000

Software Development can have moments of writing repetitive code. Following the DRY principle can help avoid this, but sometimes one block of code isn’t doing the same thing as another, although it is doing something similar (such as mapping objects in a collection). In these cases AI can be a helpful aid, but it does have drawbacks too!

The Good – AI Accelerated Development

Artificial Intelligence and Machine Learning have been applied to these kinds of problems for a while, and now they are being applied to improve developer productivity. AI-assisted developer tools can help to speed up the development process by making code suggestions, highlighting major changes as part of a code review or by detecting possible errors (such as providing method parameters in the wrong order).

Microsoft have been experimenting with adding AI assistance to software development since the release of Visual Studio IntelliCode in 2018. This Visual Studio extension aims to improve the developer experience by providing more “common sense” suggestions for the code being written. Some examples are, suggesting changes to ensure a consistent code style and changing the order of suggested methods and properties from IntelliSense to reflect how likely you are to use them.

GitHub (owned by Microsoft) has also recently released a technical preview of GitHub CoPilot, which is described as an “AI pair programmer”. This provides AI assistance to complete the writing of repetitive code (such as mapping between two objects), helping write tests, or even suggesting entire methods based upon the name you start typing or a comment describing the desired result.

These AI-based tools have the potential to make software development a faster and easier experience. They can reduce the repetitive elements of coding and potentially be used to assist individuals new to programming. This may be through suggesting improvements to code which has been written, such as ways to make it more efficient. However, there are some potential downsides to these tools at the moment.

The Bad – Undesirable Code

Applying artificial intelligence to solve problems isn’t a new concept, and it is important to acknowledge some of its limitations. AI systems can replicate unwanted bias which may exist in the machine learning training data.

In the case of AI-based development tools, they often use publicly available code for training data. As a result, they can replicate bad coding practices as well as the good ones. This can lead to them suggesting insecure code, code which contains bugs, or other undesirable consequences.

There has also been speculation that GitHub CoPilot (and similar tools) will reproduce secret or personal information if it is prompted in the right way. Although these secrets would have already been public, a tool such as CoPilot definitely improves the chances of it being discovered. In fact, it could be actively recommended to a developer.

The Ugly – The Legal (or Ethical) Side

There are also potential legal and ethical aspects to consider with how the model for the AI has been trained. GitHub says that CoPilot was trained using information available from publicly available sources. This would mainly consist of publicly available examples and public repositories hosted on GitHub.

The ugly part is, if the code which formed part of the training data is licensed to require any derivate work to also be freely released (such as under the GPL license), is the resulting AI model required to be open sourced?

There is also the possibility that code could have been leaked or released online without the original authors’ permission. In this case, would it be fair and reasonable for this to be used in the training of the AI model? Especially with the risk that the AI could suggest an exact reproduction of that leaked code?

Summary

AI-assisted software development is definitely an area that looks like it is here to stay. It has the potential to lower the barrier of entry to software development and increase automated code generation. This would certainly make developers more productive and make writing software easier.

However, there is also the possibility that AI tools can make bad recommendations. These could be minor bugs in functionality or security vulnerabilities which could then be exploited. This would be a risk for any developer, but could be especially risky to developers who are just starting out.

Software developers can certainly benefit from AI-based tools, however, I am sure there will be some interesting ethical debates over the data used to train them in the future.

What are your thoughts?

Using a Vue.js SPA with ASP.NET Core Web API

James — Fri, 02 Apr 2021 12:08:25 +0000

I recently started working on a new side project and decided to implement it as a single page application (SPA). For this, I chose to build an API powered by an ASP.NET Core Web API and a Vue.js powered front-end to consume the API.

I could find templates included in Visual Studio for AngularJS and React but nothing for Vue.js. Since I already have experience with Vue.js I decided to document the steps I used to create my starter project from a blank ASP.NET Core web app using ASP.NET Core 3.1 and Vue.js 2.

Install the required tools

We will need some command line tools installed to get started, these will be Node.js, the .NET CLI and the Vue CLI.

I have included links to the installation instructions for each tool below since these can vary a little depending on the platform. However, these are mostly running the appropriate installer or executing an NPM install command.

Now the tools are installed, we can move on to the next step! Getting your project setup.

Create a blank ASP.NET Core web app

I decided to start from a blank ASP.NET core web app. From here, I add the code required to support an ASP.NET Core Web API.

To start go to your root project folder (I am going to use ExampleApp for mine) and then run the following command.

dotnet new web

The .NET CLI will use the folder name as the name of the project. As a result, my project is also called ExampleApp.

At this point we have a pretty empty ASP.NET Core web app, so we will need to add the code to support an ASP.NET Core Web API.

Add support for ASP.NET Core Web API

The first thing you will notice missing if you are familiar with an ASP.NET Core MVC or ASP.NET Core Web API is the Controllers folder. This will need to be created as a place for us to put our controllers.

mkdir Controllers

Now that step is out of the way, we need to make some changes to the Startup.cs file.

The ConfigureServices method will need to be updated to register any controllers you create with the dependency injection container in ASP.NET Core. Thankfully, there is a useful extension method to make this simple. You just need to call the following method in ConfigureServices.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
}

The Configure method will need a little more work, but nothing too drastic. We need to map the endpoints of our API to the controllers and allow static files. We can make use of the provided extension methods to make this step easy too.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStaticFiles();

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

Finally we can create a controller for us to test our Vue.js app with. I decided on a HelloWorld controller which I have provided below (this should go in the Controllers folder). But you can use any example you like.

using Microsoft.AspNetCore.Mvc;

namespace ExampleApp
{
    [ApiController]
    [Route("api/[controller]")]
    public class HelloWorldController : ControllerBase
    {
        [HttpGet]
        public string Get()
        {
            return "Hello World from ASP.NET Core Web API!";
        }
    }
}

If you execute dotnet run you should now have a working ASP.NET Core Web API project. To test this you can open {your root URL}/api/HelloWorld in your web browser and you should see the message “Hello World from an ASP.NET Core Web API!” displayed.

Now we need to add our Vue.js client app to consume the API.

Create the Vue.js client app

We will use the Vue CLI is create the Vue.js client app. For the example I will use the default options but you can select whichever you need.

You need to run the following command in the root project folder.

vue create clientapp

This will create a new Vue.js app called clientapp and place all the files in an appropriately named folder. If you don’t want to initialise a git repository you can add the flag shown below.

vue create clientapp --no-git

If you execute npm run serve from inside the clientapp folder you should be able to view the Vue.js app on the URL provided.

Now we have our API and Vue.js app working individually, we can combine them so that the Vue.js SPA and ASP.Net Core Web API are served from the same URL.

Add SPA support to ASP.NET Core Web API for Vue.js

ASP.NET Core Web API includes support for bundling an SPA as part of the API deployment. This allows the client SPA and the web API to be served from the same URL and keeps development simple for small projects.

The first step in this process is to install the Microsoft.AspNetCore.SpaServices.Extensions package. We can do this by running the following command in the root project folder.

dotnet add package Microsoft.AspNetCore.SpaServices.Extensions

When this has finished, we need to add a few entries to the .csproj file for our project.

Open ExampleApp.csproj and under the <TargetFramework> element add the following elements as shown in the example below.

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
  <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
  <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
  <IsPackable>false</IsPackable>
  <SpaRoot>clientapp\</SpaRoot>
  <DefaultItemExcludes>$(DefaultItemExcludes);$(SpaRoot)node_modules\**</DefaultItemExcludes>
</PropertyGroup>

This above will let the .NET tools know where our SPA files are located and provide some additional details about how to treat the files during development.

Now we need to tell the .NET CLI how our SPA files should be handled during the publishing process. To do this we need to add the following <ItemGroup> and <Target> elements to the file.

<ItemGroup>
  <!-- Don't publish the SPA source files, but do show them in the project files list -->
  <Content Remove="$(SpaRoot)**" />
  <None Remove="$(SpaRoot)**" />
  <None Include="$(SpaRoot)**" Exclude="$(SpaRoot)node_modules\**" />
</ItemGroup>

<Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') ">
  <!-- Ensure Node.js is installed -->
  <Exec Command="node --version" ContinueOnError="true">
    <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
  </Exec>
  <Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
  <Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
  <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
</Target>

<Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
  <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
  <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
  <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build" />

  <!-- Include the newly-built files in the publish output -->
  <ItemGroup>
    <DistFiles Include="$(SpaRoot)dist\**" />
    <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
      <RelativePath>%(DistFiles.Identity)</RelativePath>
      <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
      <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
    </ResolvedFileToPublish>
  </ItemGroup>
</Target>

After all of the above steps have been completed your .csproj file should look similar to the file below.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
    <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
    <IsPackable>false</IsPackable>
    <SpaRoot>clientapp\</SpaRoot>
    <DefaultItemExcludes>$(DefaultItemExcludes);$(SpaRoot)node_modules\**</DefaultItemExcludes>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="3.1.9" />
  </ItemGroup>

  <ItemGroup>
    <!-- Don't publish the SPA source files, but do show them in the project files list -->
    <Content Remove="$(SpaRoot)**" />
    <None Remove="$(SpaRoot)**" />
    <None Include="$(SpaRoot)**" Exclude="$(SpaRoot)node_modules\**" />
  </ItemGroup>

  <Target Name="DebugEnsureNodeEnv" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Debug' And !Exists('$(SpaRoot)node_modules') ">
    <!-- Ensure Node.js is installed -->
    <Exec Command="node --version" ContinueOnError="true">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
    <Message Importance="high" Text="Restoring dependencies using 'npm'. This may take several minutes..." />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
  </Target>

  <Target Name="PublishRunWebpack" AfterTargets="ComputeFilesToPublish">
    <!-- As part of publishing, ensure the JS resources are freshly built in production mode -->
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm install" />
    <Exec WorkingDirectory="$(SpaRoot)" Command="npm run build" />

    <!-- Include the newly-built files in the publish output -->
    <ItemGroup>
      <DistFiles Include="$(SpaRoot)dist\**" />
      <ResolvedFileToPublish Include="@(DistFiles->'%(FullPath)')" Exclude="@(ResolvedFileToPublish)">
        <RelativePath>%(DistFiles.Identity)</RelativePath>
        <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
        <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
      </ResolvedFileToPublish>
    </ItemGroup>
  </Target>

</Project>

The final step is to let the ASP.NET Core Web API project know how load the SPA files when the project has been deployed. This can be done by using another helpful extension method in the Startup.cs file.

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    // In production, the Vue files will be served from this directory
    services.AddSpaStaticFiles(configuration =>
    {
        configuration.RootPath = "clientapp/dist";
    });
}

We will also need to add a few more lines to the Configure method so that the middleware for serving SPA files is also active when the project has been deployed. This can go below app.UseStaticFles() as shown below.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseStaticFiles();
    if (!env.IsDevelopment())
    {
        app.UseSpaStaticFiles();
    }

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
    });
}

When you execute npm run serve the Vue CLI development server is launched. This provides you with a local URL which you can use to access your Vue.js site. Since we want to use the URL for the ASP.NET Core Web API project for all requests, the API will need to act as a proxy for the server during development.

To achieve this, we just need add the following method calls to the Configure method in the Startup.cs file. You can change the localhost address and port to match yours if it is different.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseSpa(spa =>
    {
        spa.Options.SourcePath = "clientapp";

        if (env.IsDevelopment())
        {
            spa.UseProxyToSpaDevelopmentServer("http://localhost:8080");
        }
    });
}

After that is done, you need to make sure your Vue CLI development server is running (if it isn’t, go to your clientapp folder and execute npm run serve to start it).

Now when you run your ASP.NET Core Web API and go to its URL you should see your Vue SPA!

Consume the ASP.NET Core Web API in the Vue.js client SPA

The final step is to consume our ASP.NET Core Web API in our Vue.js client SPA. To do this we will add a button to the sample application which will make a request to our API and update the page.

The first step is to install Axios. This is a HTTP client which we will use to make the HTTP request to the API. We can install it using NPM by running the following command in the clientapp folder.

npm install axios

Next, we need to update the App.vue file to import Axios, add a method to call the API and add a button for us to click. The full example for the file is below.

<template>
  <div id="app">
    <img alt="Vue logo" src="./assets/logo.png" />
    <div>
      <button @click="fetch">Fetch from API</button>
    </div>
    <HelloWorld :msg="message" />
  </div>
</template>

<script>
import axios from "axios";
import HelloWorld from "./components/HelloWorld.vue";

export default {
  name: "App",
  data() {
    return {
      message: "Welcome to Your Vue.js App",
    };
  },
  methods: {
    async fetch() {
      try {
        const url = "http://localhost:5000/api/HelloWorld";
        const response = await axios.get(url);
        const data = response.data;

        this.message = data;
      } catch (error) {
        this.message = error;
      }
    },
  },
  components: {
    HelloWorld,
  },
};
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

You should now be able to run your ASP.NET Core Web API project (and make sure your Vue CLI development server is running too) and click the button to watch the heading be updated with the message from the API.

Summary

Your ASP.NET Core Web API project should be successfully proxying requests for the Vue CLI development server. In addition, the project should also be setup to publish your Vue.js client SPA files when you run dotnet publish.

This setup could be improved by adding a helper method for the Vue CLI development server, similar to the one built-in for Angular. I might take a look at implementing this in a future post.

You can find the complete example in this GitHub repository.

Hopefully this setup helps get your Vue.js and ASP.NET Core Web API projects off the ground!

Handling null values in C#

James — Sat, 27 Mar 2021 08:00:00 +0000

Handling null values in C# and .NET comes with the territory. Null values were introduced by Tony Hoare in mid-1960s to represent missing or unknown data. This is a useful capability but it has resulted in null reference exceptions becoming one of the most common causes of bugs which developers face. As a result, Tony Hoare now calls the null reference the ‘billion dollar mistake’.

C# has always allowed reference types to be nullable, and as a result, the NullReferenceException is something .NET or .NET Core developers see frequently. In C# it is common to see code guarding against null references, often looking similar to the following.

if (variable != null) {
    // code to execute
}

Over the last few years C# has been adding more ways to handle null references. These new C# features help to improve the reliability of code and remove some of the clutter from guarding against null references.

Below are some of the ways you can protect against receiving a NullReferenceException in C# 9.0.

Using the is operator

The is operator is a keyword in C# which is used for checking if a variable is compatible with a given type. When C# 7.0 was released, it added support for the constant pattern. This allows the is operator to compare values to a constant, such as null.

if (variable is null) {
    // code to execute
}

Using the is keyword to check for null values helps keep the code close to how it would be described in natural language. This can help to keep code easy to read and understand for developers.

Null-conditional operator

When C# 6.0 was released, the null-conditional operator was introduced into the language. This operator can be used to safely access members, ?., or an array index. ?[].

Person person = null;

if (person != null) {
    if (person.Address != null) {
        string city = person.Address.City;
    }
}

If any step in the chain is null the rest of the chain will not be executed and the chain will return null. This can help simplify your code by reducing the amount dedicated to guard conditions.

Person person = null;

string city = person?.Address?.City;

When there are nested properties the reduction of code can be substantial and make it much easier to read.

Null-coalescing operator

Prior to the null-coalescing operator being introduced, if you wanted to return an alternative value when a member was null, you would need to write a separate if statement.

Person person = null;

if (person?.Name is null) {
    return "Jane";
} else {
    return person.Name;
}

Today, you can open use the null-coalescing operator to simplify this and reduce the code you need to write to achieve the same result.

Person person = null;

return person?.Name ?? "Jane";

When the left-hand side of the operator is null, the result of right-hand operand will be executed and returned. If the left-hand operand is not null then the result of this will be returned.

Null-coalescing assignment operator

The null-coalescing assignment operator was brought into the lives of C# developers with the release of C# 8.0. This operator allows code guarding against null values to be reduced to a few characters.

Person person = null;

if (person is null) {
    person = new Person();
}

This example can be simplified to the following example through the use of the null-coalescing assignment operator.

Person person = null;

person ??= new Person();

This reduces the clutter generally produced, and if it is commonly used reduces the risk of a null check being missed when it is required.

Summary

When developing .NET and ASP.NET applications, null values are a common occurrence and can easily bring the execution of your code to a rapid halt.

Today there are a number of ways to reduce the amount of code needed to handle null values in C#. These new options help keep code readable and easy to understand, while helping to improve its resilience.