DEV Community: The Practical Developer

WebAssembly Explained: Near Native Speed Inside the Browser

The Practical Developer — Thu, 05 Nov 2026 03:24:09 +0000

WebAssembly, often shortened to Wasm, is a way to run code in the browser at near native speed, in a format that is not JavaScript. It was built for the parts of a web app where JavaScript is too slow or the wrong tool: image editing, games, video processing, and software originally written in another language. Instead of rewriting that software in JavaScript, developers compile it to WebAssembly and run it in the browser.

A WebAssembly module is a compact binary format that browsers can load and run safely. It runs in a sandbox, like JavaScript, so it cannot read your files or reach the network on its own. It can only do what the JavaScript around it allows, by calling functions JavaScript provides and by letting JavaScript call its exported functions. That boundary is deliberate. WebAssembly is a guest in the browser, powerful inside its sandbox and powerless outside it.

The smallest example is a function that adds two numbers, written in the text format for WebAssembly. This format is the human readable form of a module, and it shows the structure clearly.

(module
  (func (export "add") (param i32 i32) (result i32)
    local.get 0
    local.get 1
    i32.add))

Read it as a recipe. The module contains one function, exported under the name "add". It takes two parameters, both 32 bit integers (i32), and returns one 32 bit integer. local.get 0 and local.get 1 push the two parameters onto a stack, and i32.add pops them, adds them, and leaves the result on the stack, which becomes the return value. In a real project you would not write this by hand. You would write the function in C, C++, Rust, or another supported language and compile it to a .wasm file, but the module you get has this same shape underneath.

JavaScript loads the module and calls the exported function. Here is the loading code for a module built from the example above.

const { instance } = await WebAssembly.instantiateStreaming(fetch("add.wasm"));
console.log(instance.exports.add(2, 3));

The fetch call downloads add.wasm, instantiateStreaming compiles and creates an instance of it, and instance.exports.add calls the exported function with 2 and 3, printing 5. In practice, a real module exports more than one function, and JavaScript passes it memory and helper functions when it is created. The pattern stays the same: build in a compiled language, load in JavaScript, and call across the boundary only where speed or reuse justifies it.

WebAssembly is not a replacement for JavaScript. It has no direct access to the page, so it cannot change the DOM or handle a click on its own. JavaScript remains the language of the web page, while WebAssembly handles the heavy computation behind it. Used that way, the two complement each other: JavaScript for interaction, WebAssembly for number crunching, and a clear boundary between them.

The honest trade

WebAssembly trades simplicity for speed and reuse. Adding it to a project means adding a build step, a second language, and a boundary to debug across, which is real complexity for a small gain on an ordinary page. Where it pays off is clear: existing native code that would be expensive to rewrite, and workloads like codecs, simulations, and editors where JavaScript genuinely struggles. For most web pages, plain JavaScript is still the right answer, and WebAssembly should stay in the toolbox until the performance problem is real.

Try one small module first

The best introduction is one tiny module: a function written in a language you know, compiled to WebAssembly, and called from a small web page. Measure it against the JavaScript version, and keep WebAssembly only if the difference matters. That discipline, use it where it earns its place, is the whole skill.

Originally published at

https://practicaldevblog.blogspot.com/2026/11/webassembly-explained-near-native-speed.html

C++ Explained: C With Classes, Templates, and Real Power

The Practical Developer — Thu, 05 Nov 2026 03:23:25 +0000

C++ started as an extension of C, and it still compiles most C code. Over decades it grew into a much larger language, adding classes, templates, exceptions, and a standard library, while keeping C's promise of control over performance. That history explains both its power and its reputation: C++ can do almost anything, and it asks you to understand more before you can do it safely.

The core addition is the class, a way to bundle data with the functions that operate on it. A class lets you define a type of your own, with its own rules. A vector, a string, and a bank account can each be a class, with methods that keep their internal state consistent. Used well, classes turn a large program into a set of understandable parts instead of a pile of functions sharing global data.

Templates are the second big idea. A template lets you write one function or class that works for many types. The standard library uses templates everywhere, which is why one vector type can hold integers, strings, or objects you define yourself, without rewriting the container each time. Here is a complete C++ program that sums a vector of integers. It uses the standard library only, and it compiles with any modern C++ compiler.

#include <iostream>
#include <vector>

int main() {
    std::vector<int> numbers = {1, 2, 3};
    int total = 0;
    for (int n : numbers) {
        total += n;
    }
    std::cout << "Total: " << total << '\n';
    return 0;
}

Walk through it. The include lines bring in output and the vector container. std::vector is a vector holding integers, created with three values. The range based for loop reads each value in turn, without an index variable, and adds it to total. std::cout prints the result, and '\n' ends the line. The program prints "Total: 6". The std:: prefix means these names come from the standard library namespace, a container that keeps library names from clashing with your own.

Modern C++ looks different from the C++ of twenty years ago, and beginners should learn the modern subset first. Use std::vector instead of a raw array when the size can change. Use std::string instead of a character array. Prefer smart pointers, which free memory automatically, over raw new and delete. These habits remove whole classes of bugs that gave older C++ its fearsome reputation, while keeping the speed that makes the language worth learning.

C++ is everywhere performance matters: game engines, browsers, databases, trading systems, and desktop applications. It is also the language behind many tools developers use daily, even when they write in another language on top of it. Learning C++ will not make every project faster, but it will teach you what fast code costs and where that cost is worth paying.

The honest trade

C++ trades simplicity for range. It gives you low level control, high level abstractions, and everything in between, in one language, and that breadth makes it harder to learn than a language that picks one level and stays there. Compile errors from templates can be long and cryptic, and the language still lets you write unsafe code if you reach for the old tools. For systems software, games, and performance critical tools, that range is exactly the point. For a small script or a simple web service, a simpler language will get you there faster.

Learn the modern subset first

Start with the modern standard library: vector, string, and range based loops, as in the example above. Add one class of your own, then one template function. Resist the urge to learn every feature at once. C++ rewards a slow, deliberate path, and the modern subset is a genuinely pleasant language on its own.

Originally published at

https://practicaldevblog.blogspot.com/2026/11/c-explained-c-with-classes-templates.html

C Explained: The Language Still Underneath Almost Everything

The Practical Developer — Thu, 05 Nov 2026 03:22:38 +0000

C is over fifty years old, and it still runs much of the world. Operating systems, embedded devices, databases, and the runtimes of newer languages are often written in C, or in code that borrows heavily from it. When you learn C, you are not learning a museum piece. You are learning the layer that most software still stands on.

C is a small language with a direct relationship to the machine. There are few keywords, no built in objects, and no automatic memory management. A program is a set of functions, and data is stored in variables, arrays, and structs that you lay out yourself. That closeness is the point. C lets you say exactly how memory is used, which is why it fits systems programming, where performance and control matter more than convenience.

Here is a complete C program that adds three numbers in an array. It uses only the standard library, and it compiles with any standard C compiler.

#include <stdio.h>

int main(void) {
    int numbers[] = {1, 2, 3};
    int total = 0;
    for (int i = 0; i < 3; i++) {
        total += numbers[i];
    }
    printf("Total: %d\n", total);
    return 0;
}

Read it from the top. The include line brings in printf, the function that prints text. main is where every C program starts. numbers is an array of three integers, and total starts at zero. The loop runs with i equal to 0, 1, and 2, adding each element to total. printf then prints "Total: 6", because %d is replaced by the integer value of total, and \n starts a new line. Returning 0 tells the operating system the program finished successfully.

Pointers are the idea most beginners struggle with, and they are worth naming plainly. A pointer is a variable that holds a memory address, the location where another value lives. Passing a pointer to a function lets that function read or change the original value, instead of working on a copy. Used carefully, pointers make C fast and flexible. Used carelessly, they cause the classic C bugs: reading past the end of an array, using memory after it has been freed, and dereferencing a null pointer.

Memory management is manual in C. You request memory with malloc when you need it, and you release it with free when you are done. Forgetting to free memory leaks it. Freeing the same memory twice corrupts it. Modern languages hide this work, but hiding it does not remove it. Learning C teaches you what those languages are doing on your behalf, which makes their performance and their errors easier to understand.

The honest trade

C trades safety for control. It will let you write past an array, mix up types, and free memory too early, and it will often do so without complaint until the program crashes far from the mistake. Newer languages catch many of those errors at compile time or at run time. What C gives back is speed, predictability, and access to hardware with almost no abstraction in the way. For an operating system kernel, a device driver, or a tiny microcontroller with little memory, that trade is still the right one. For a typical web app, it usually is not.

Start small, then read real code

The best first C project is a small command line tool: read numbers from input, sort them, and print the result. Then open a small, well known C project and read how it organises files and functions. C rewards patience, and the habits it builds, careful memory use and respect for the machine, carry into every language you learn after it.

Originally published at

https://practicaldevblog.blogspot.com/2026/11/c-explained-language-still-underneath.html

WordPress Explained: The Software Running a Third of the Web

The Practical Developer — Wed, 04 Nov 2026 03:20:27 +0000

WordPress powers a remarkable share of the web, from personal blogs to news sites, company pages, and online shops. It started in 2003 as blogging software and grew into a full content management system: software that lets people publish pages and posts, upload media, and manage a site without writing HTML for every page. Its popularity is its own advantage, because almost every hosting company supports it and almost every web problem has already been solved for it somewhere.

A WordPress site has two sides. The public side is what visitors see. The admin dashboard is where owners write posts, approve comments, install themes that control appearance, and install plugins that add features, like contact forms, search optimisation, or a shop. That split is why non-developers can run a WordPress site: publishing content needs no code, while developers can still customise everything underneath.

Under the hood, WordPress is PHP with a MySQL database. Content lives in the database, themes and plugins are PHP files, and the theme decides how content is displayed. The feature that surprises newcomers most is how much can be done with a small piece of PHP. A shortcode, for example, lets an editor drop a reusable piece of output into any post by typing a bracketed tag.

function pdp_greeting_shortcode($atts) {
    $atts = shortcode_atts(
        array('name' => 'reader'),
        $atts,
        'greeting'
    );
    return '<p>Hello, ' . esc_html($atts['name']) . '! Welcome to this site.</p>';
}
add_shortcode('greeting', 'pdp_greeting_shortcode');

Put this in a theme's functions file or a small plugin, and typing [greeting name="Alex"] in a post prints "Hello, Alex! Welcome to this site." shortcode_atts fills in the default name when none is given, so [greeting] alone still works. esc_html escapes the name before it reaches the page, which stops a visitor-supplied value from injecting markup into the output, a small line that prevents a real class of security bug. add_shortcode registers the tag name with the function, connecting the editor's bracketed text to PHP code.

Themes and plugins are also WordPress's biggest risk, because they come from many authors of varying quality. A bloated theme or a dozen overlapping plugins can slow a site and open security holes, especially when updates are ignored. The discipline is simple: use well maintained themes and plugins with recent updates and many installs, delete what you do not use, and keep WordPress, themes, and plugins updated.

The honest trade

WordPress trades performance and fine control for speed and ease. A hand built site can be leaner and faster, and a custom app can do things WordPress was never designed for. But for content sites, blogs, and small shops, WordPress gets a working, editable site live in hours, with a huge ecosystem of themes, plugins, and people who know it. When a project outgrows it, that usually means it needed custom software all along, not that WordPress failed.

Publish first, perfect later

The fastest way to judge WordPress is to install it, pick a simple theme, and publish three real posts. You will learn more about themes, the editor, and plugins from one live site than from a week of reading comparisons, and you can always change the theme later without losing your content.

Originally published at https://practicaldevblog.blogspot.com/2026/11/wordpress-explained-software-running.html

Selenium Explained: Browser Tests That Click Like a Real User

The Practical Developer — Wed, 04 Nov 2026 03:19:40 +0000

Selenium is a tool for automating a real web browser. It opens Chrome, Firefox, or another browser, loads pages, clicks buttons, fills in forms, and checks what appears, exactly as a user would. That makes it the standard choice for end to end testing: tests that prove a whole web app works, from the login page to checkout, rather than testing one function in isolation.

The reason to drive a real browser is that many bugs only show up there. A button might look fine in code but be hidden behind another element on a small screen. A form might submit in a unit test but fail in the browser because a script loads late. Selenium catches those problems because it sees the page the way a user sees it, including layout, timing, and JavaScript behaviour.

Tests are usually written in Python, Java, C#, or JavaScript, using Selenium's WebDriver API. Here is a Python test that searches a site and checks the result. It uses an explicit wait, which is the single most important habit in Selenium testing.

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
try:
    driver.get("https://example.com")
    search_box = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.NAME, "q"))
    )
    search_box.send_keys("selenium testing")
    search_box.send_keys(Keys.RETURN)
    WebDriverWait(driver, 10).until(
        EC.title_contains("selenium")
    )
    print("Search results page loaded, title:", driver.title)
finally:
    driver.quit()

The structure matters more than the search itself. The driver starts a real browser. driver.get loads the page. WebDriverWait then waits up to 10 seconds for the search box to appear, instead of assuming it is there instantly, which is how flaky tests are born. send_keys types into the box, Keys.RETURN presses Enter, and a second wait checks the new page title before the test declares success. The finally block guarantees driver.quit() runs even if a step fails, so a failed test does not leave a browser window open forever.

Locators are how Selenium finds elements, and choosing well saves pain later. Prefer a stable id or name when one exists, fall back to a clear CSS selector, and avoid long, brittle paths copied from browser tools that break the moment a designer rearranges a page. When a test fails, the first question should always be whether the locator still matches the page, not whether Selenium is broken.

The honest trade

Selenium trades speed for realism. Browser tests are slower and more fragile than unit tests: pages load at network speed, animations take time, and a small layout change can break a locator. Teams that write only browser tests end up with a slow, flaky suite. The healthy mix is a pyramid: many fast unit tests, fewer integration tests, and a small set of Selenium tests covering the journeys that matter most, like signup, login, and checkout.

Start with one journey, not the whole site

If you are adding Selenium to a project, automate a single critical journey first, such as logging in and reaching the dashboard. Get that one test stable and running in your pipeline, then add the next journey. A small, trustworthy suite beats a large suite nobody believes.

Originally published at https://practicaldevblog.blogspot.com/2026/11/selenium-explained-browser-tests-that.html

Unity Explained: The Engine Behind Half the Games You Play

The Practical Developer — Wed, 04 Nov 2026 03:18:49 +0000

Unity is a game engine, which means it handles the hard, shared parts of making a game: drawing 3D and 2D graphics, playing sound, detecting collisions, and running physics, so developers can focus on the game itself. It is used for mobile games, indie titles, virtual reality experiences, and even non-game projects like architectural visualisations and training simulations. If you have played a game on a phone in the last decade, there is a good chance Unity was behind it.

A Unity project is built from scenes, and a scene is built from GameObjects. A GameObject is an empty container, and it only does something once you attach components to it. A sprite renderer draws it, a rigidbody gives it physics, a collider lets it bump into things, and a script tells it how to behave. This component approach keeps things flexible: the same GameObject can be a player, an enemy, or a moving platform, just by changing which components it carries.

Scripts in Unity are written in C#. Here is a simple movement script, the kind of first script almost every Unity beginner writes. Attach it to a player character and it will move with the arrow keys or WASD.

using UnityEngine;

public class PlayerMove : MonoBehaviour
{
    public float speed = 5f;

    void Update()
    {
        float horizontal = Input.GetAxis("Horizontal");
        float vertical = Input.GetAxis("Vertical");

        Vector3 movement = new Vector3(horizontal, 0f, vertical);
        transform.Translate(movement * speed * Time.deltaTime);
    }
}

Read it line by line. The script inherits from MonoBehaviour, which is Unity's base class for anything attached to a GameObject. The speed field is public, so it shows up in the Unity editor and a designer can tune it without touching code. Update runs once per frame. Input.GetAxis reads the player's input as a smooth value between -1 and 1, so holding right gives 1 and holding left gives -1. Those two values become a direction vector, and transform.Translate moves the object along it. Multiplying by Time.deltaTime is the detail beginners most often miss: it makes movement depend on real time, not on frame rate, so the character moves at the same speed on a fast computer and a slow phone.

That editor plus code combination is Unity's real strength. Artists can arrange a level visually, drag in models and sounds, and test the game by pressing Play, while programmers write scripts for behaviour. A small team can prototype an idea in a weekend, which is why Unity dominates game jams and indie development.

The honest trade

Unity trades deep control for speed of development. A custom engine gives a large studio exact control over performance and rendering, while Unity adds overhead and its own way of doing things, which can fight you on unusual projects. Its pricing and terms have also changed over the years, which made some studios nervous about building a business on it. For most small and mid-size teams, though, the trade is worth it: a huge asset store, tutorials for almost every problem, and one codebase that builds to phones, consoles, PCs, and the web.

Make something tiny, then finish it

The best way to learn Unity is not a huge dream project. Build one complete tiny game: a character that moves, something to collect, and a score that goes up. You will touch scenes, components, scripts, and builds in one sitting, and you will end up with a finished game instead of a half built epic.

Originally published at https://practicaldevblog.blogspot.com/2026/11/unity-explained-engine-behind-half.html

Godot Explained: Game Development Without the Price Tag

The Practical Developer — Tue, 03 Nov 2026 06:20:10 +0000

Godot is a free, open source game engine for building 2D and 3D games, and it costs nothing no matter how much money your game makes. There is no royalty, no revenue share, and no paid tier that unlocks features. That alone makes it worth a look, but the reason developers stay is that the engine is genuinely pleasant to use, especially for small teams and solo developers.

The core idea is the scene tree. Everything in a game is a node: a sprite, a sound, a timer, a physics body. Nodes are arranged in a tree, and a saved tree is called a scene. A player character might be a scene made of a physics body node, a sprite node, and a collision shape node. A level is a scene made of many such scenes. You build games by composing scenes from smaller scenes, which keeps even a large project understandable, because each piece can be opened and tested on its own.

Godot's own scripting language is GDScript, which looks like Python and is designed for the engine. Here is a complete 2D character movement script for Godot 4, the kind of code you write in your first hour with the engine.

extends CharacterBody2D

const SPEED = 300.0

func _physics_process(delta: float) -> void:
    var direction := Input.get_axis("ui_left", "ui_right")
    velocity.x = direction * SPEED
    move_and_slide()

Line by line: the script extends CharacterBody2D, the node type built for characters that move and collide. SPEED is a constant, 300 pixels per second. Every physics frame, _physics_process runs, Input.get_axis reads the left and right keys as a single value between -1 and 1, velocity.x is set from that direction times the speed, and move_and_slide moves the body while handling collisions. No boilerplate, no setup function, no separate update loop to wire up. Attach this script to a character node and it moves.

Godot also supports C# for developers who prefer it, and its 2D support is a first class citizen rather than a 3D engine with 2D bolted on. The editor itself is small, starts fast, and runs on modest hardware, which matters when your development machine is also your everyday laptop.

The honest trade

Godot trades the scale of the biggest commercial engines for freedom and simplicity. It does not yet match Unity or Unreal for high end 3D graphics, console tooling, or the size of the asset store, and finding experienced Godot developers to hire is harder than hiring Unity developers. What you get in return is an engine you fully own, a codebase you can read and modify, and a community that builds in the open. For 2D games, indie projects, and learning game development, that trade is easy to accept. For a large 3D title chasing the latest graphical features, the bigger engines still have the edge.

Build one small game first

The best introduction to Godot is a finished tiny game: a character that moves, something to collect, and a score. You will touch scenes, nodes, signals, and scripting in one sitting, and you will know by the end whether the engine's way of thinking suits you.

Originally published at https://practicaldevblog.blogspot.com/2026/11/godot-explained-game-development.html

NestJS Explained: Node Backends With Structure Built In

The Practical Developer — Tue, 03 Nov 2026 06:19:23 +0000

Node.js makes it easy to start a server and hard to keep one organised. A few routes become a few dozen, shared logic drifts into copy pasted handlers, and six months later nobody is sure where a feature lives. NestJS is a framework that gives a Node backend a deliberate shape from the first file, borrowing ideas from Angular and from enterprise frameworks in other languages.

The shape has three parts, and each has one job. Controllers receive HTTP requests and return responses, and they should do nothing else. Services hold the business logic, such as talking to a database or applying a rule. Modules group controllers and services that belong together, so a feature can be understood and tested as one unit. When you want to find where something happens, you already know which kind of file to open.

Here is the smallest complete example: a controller that answers a GET request by asking a service for a greeting.

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

import { Injectable } from '@nestjs/common';

@Injectable()
export class AppService {
  getHello(): string {
    return 'Hello World!';
  }
}

The decorators do the wiring. @Controller marks the class as a request handler, @get marks the method as the answer to a GET request, and @Injectable marks the service as something NestJS can create and hand to whoever needs it. The controller never builds the service itself; NestJS injects it through the constructor, which is the dependency injection pattern. That one habit is what makes NestJS code testable: in a test, you can hand the controller a fake service and check its behaviour without starting a server or touching a database.

NestJS also standardises the pieces every real backend needs. Guards handle authentication, pipes validate incoming data, interceptors transform responses, and exception filters turn errors into consistent responses. Because these are framework concepts rather than one off middleware, a new developer joining the project meets the same patterns in every module.

TypeScript is not optional decoration here. Types on controllers and services catch mismatched shapes at build time, and the decorators only make sense with the type metadata TypeScript provides. If you dislike TypeScript, NestJS will feel like friction from day one.

The honest trade

NestJS trades freedom for consistency. You write more files and more boilerplate than you would with a minimal framework like Express, and the decorator heavy style can feel like magic until you learn what each piece does. For a small API with three endpoints, that structure is overhead. For a backend that will grow to dozens of endpoints, several developers, and years of maintenance, the structure is exactly what keeps the project readable. The wrong time to adopt NestJS is a weekend prototype; the right time is the moment a prototype starts turning into a product.

Structure you can grow into

Start with one module, one controller, and one service, exactly like the example above, and add a second module only when a second feature arrives. If the shape still feels helpful at five modules, it will still feel helpful at fifty.

Originally published at https://practicaldevblog.blogspot.com/2026/11/nestjs-explained-node-backends-with.html

Blazor Explained: C# in the Browser, Without JavaScript

The Practical Developer — Tue, 03 Nov 2026 06:18:38 +0000

Blazor lets you build interactive web pages using C# instead of JavaScript. It runs on .NET, so if you already know C#, you can write both the front end and the back end of a web app in one language, sharing models and validation logic between them instead of maintaining two versions of the same idea.

Blazor comes in two hosting models, and the choice matters. Blazor WebAssembly runs your C# code in the browser itself, compiled to WebAssembly, so the app works as a single page application after the initial download. Blazor Server keeps the code on the server and sends only small UI updates to the browser over a live connection, which makes the first load fast but means every click round trips to the server. Many apps start with one model and switch later, because the component code stays mostly the same.

Components are the building block. A component is a Razor file that mixes HTML markup with C# code, and it re-renders itself when its state changes. Here is the classic counter, the smallest component that shows how state and events connect.

@page "/counter"

<h1>Counter</h1>
<p>Current count: @currentCount</p>
<button @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

Read it as two halves. The top half is markup: a heading, a paragraph that displays the current count, and a button. The @onclick attribute wires the button to a C# method instead of a JavaScript handler. The bottom half, inside @code, holds the state (currentCount, starting at 0) and the method that changes it. When the button is clicked, IncrementCount runs, currentCount grows by one, and Blazor re-renders the paragraph. There is no manual DOM update, no query selector, and no separate script file.

That model is why Blazor appeals to .NET teams. Forms, validation, and API calls can all use the same classes the server uses. A form can bind directly to a model object, validation attributes on that model work on both sides, and an HTTP call from a component looks like any other C# code.

The honest trade

Blazor trades the size of the JavaScript ecosystem for the comfort of one language. WebAssembly apps carry a larger first download than a plain JavaScript bundle, because the .NET runtime comes along with the app, and the pool of ready made Blazor component libraries is smaller than what React or Vue developers enjoy. Blazor Server avoids the download but adds a constant connection, so it fits internal tools and dashboards better than public pages on slow networks. When a team already lives in .NET, that trade is often worth it. When a team is hiring front end specialists, plain JavaScript frameworks usually have the deeper bench.

One language, end to end

The fastest way to judge Blazor is to build one small interactive page with it: a form, a list fetched from an API, and a button that changes state. If writing it all in C# feels like a relief rather than a constraint, Blazor has earned a place in your toolbox.

Originally published at https://practicaldevblog.blogspot.com/2026/11/blazor-explained-c-in-browser-without.html

F# Explained: Functional Code on .NET, Without the Ceremony

The Practical Developer — Mon, 02 Nov 2026 07:33:27 +0000

F# is a functional first language that runs on .NET, which means it can use the same libraries and tools as C#. Its pitch is simple: write less code, let the compiler infer more, and make incorrect states harder to express. For developers who like .NET but want a more concise style, it is a natural second language to learn.

The first thing you notice is type inference. You rarely write type annotations for local values, because the compiler works them out from how values are used. A function that adds two numbers does not need its types spelled out, and if you later pass it something that cannot be added, the compiler will say so before the program runs.

Pipelines are the second habit worth learning. The |> operator passes the value on its left as the final argument of the function on its right, so a chain of steps reads top to bottom in the order they happen.

let add x y = x + y
let result = 3 |> add 2
printfn "%d" result

Here add takes two numbers and returns their sum. The pipeline passes 3 as the final argument, so add 2 receives 3 as its second argument, and result is 5, which printfn prints. Read it as: take 3, add 2, print the result. Small functions composed this way stay easy to test, because each one does one thing and has no hidden state.

F# also leans on immutability by default. Values are not changed in place unless you explicitly ask for a mutable variable. That removes a whole class of bugs where a value changes unexpectedly between two uses, and it makes concurrent code safer, since shared data is not being rewritten under you.

None of this means F# is only for mathematics or research. It is used for web services, data processing, and tooling, and it interoperates with C# libraries directly, so adopting it does not mean abandoning the .NET ecosystem.

The honest trade

F# gives you conciseness and strong compile time checking, at the cost of a smaller community and fewer learning resources than C#. Finding answers, libraries, and jobs takes a little more effort, and teams used to object oriented C# may need time to adjust to a functional style. The language itself is not harder, but the ecosystem around it is smaller. That trade is worth it when correctness and clarity matter more than the size of the hiring pool, and less appealing for a team that needs to hire quickly in C# specifically.

Start with one small project

The best way into F# is a small, real project: a command line tool, a data script, or a tiny web API. Write it with pipelines and immutable values, let the compiler guide you, and notice how much code you did not need. That experience tells you more about the language than any feature list can.

Originally published at https://practicaldevblog.blogspot.com/2026/11/f-explained-functional-code-on-net.html

Erlang Explained: Processes That Fail and Restart

The Practical Developer — Mon, 02 Nov 2026 07:32:48 +0000

Erlang was built for telephone switches, systems that were expected to run for years without stopping. Its answer to failure was unusual: do not try to prevent every crash. Let a process fail, notice the failure, and start a fresh process in its place. The system as a whole keeps running because no single failure takes everything down.

The unit of work in Erlang is a process, and it is far lighter than an operating system process. A program can run thousands or millions of them. Processes do not share memory. They communicate by sending messages to each other, and each process handles its own mailbox in turn. That isolation is the point. A bug in one process cannot silently corrupt another process's state, because there is no shared state to corrupt.

Here is a small example. It spawns a new process that prints a greeting, while the calling function returns ok straight away.

-module(greet).
-export([hello/0]).

hello() ->
    spawn(fun() -> io:format("Hello from a process~n") end),
    ok.

The module and export lines declare a public function called hello, which takes no arguments. Inside, spawn starts a new process running the given function, and io:format prints text, with ~n as a newline. The original function does not wait for the new process. It returns ok immediately, and the greeting appears from the spawned process in its own time. That pattern, start work and carry on, is everywhere in Erlang code.

Supervisors take the idea further. A supervisor is a process whose job is to watch other processes and restart them according to a strategy when they crash. You write the normal case plainly, and you write the restart strategy separately, instead of scattering defensive checks through every function. The result is code that is easier to read and a system that recovers on its own.

Erlang is also the foundation of Elixir, which runs on the same virtual machine and keeps the same process model with a different syntax. If you know one, the other's concurrency ideas will feel familiar.

The honest trade

Erlang's strength is fault tolerance, not raw speed for a single computation. Message passing and process isolation add overhead, and the language itself is not the first choice for number crunching or for a user interface. Its syntax can also look unfamiliar at first, with pattern matching and recursion doing work that loops do in other languages. In return, you get a system that is designed to stay up, scale across cores and machines, and recover from failures without a restart of the whole service.

A system that expects trouble

The most useful idea to take from Erlang is not a syntax trick. It is the attitude: assume parts will fail, isolate them, and plan the restart. Even in another language, designing with that attitude, with small independent pieces and a clear recovery path, makes a system harder to break.

Originally published at https://practicaldevblog.blogspot.com/2026/11/erlang-explained-processes-that-fail.html

Assembly Explained: Code the Machine Actually Runs

The Practical Developer — Mon, 02 Nov 2026 07:32:16 +0000

Every program you write eventually becomes instructions for a processor. Assembly is the readable form of those instructions. It does not hide registers, memory addresses, or the order of operations behind abstractions. That is why it feels close to the metal, and why it is still worth learning even if you rarely write it by hand.

A processor works with a small set of registers, which are fast storage slots inside the chip itself. An instruction typically names an operation, a destination, and a source. Move a value into a register, add two registers, store the result in memory, jump to another instruction. Everything else, from loops to function calls, is built from those simple steps.

Here is a complete Linux program on x86-64 that prints Hello and exits. It uses system calls, which are requests to the operating system, identified by a number in the rax register.

section .data
    msg db "Hello", 10
    len equ $ - msg
section .text
    global _start
_start:
    mov rax, 1
    mov rdi, 1
    mov rsi, msg
    mov rdx, len
    syscall
    mov rax, 60
    xor rdi, rdi
    syscall

Read it line by line. The data section holds the text, with 10 as the newline character, and len is the length of that text. The first system call, number 1, is write: file descriptor 1 means standard output, rsi points to the text, rdx gives its length. The second system call, number 60, is exit, with an exit code of 0 produced by clearing rdi. Nothing is hidden. If a register is wrong, the program does something visibly different, and that is the lesson.

Assembly also explains why higher level languages behave the way they do. A function call is not magic: arguments go somewhere, a return address is saved, and control jumps back. A loop is a comparison followed by a conditional jump. Once you have seen those mechanics once, debuggers, performance surprises, and compiler output all make more sense.

The honest trade

Assembly gives you total control and total responsibility. You choose every register and every memory access, so you can write extremely tight code, and you can also corrupt memory with a single wrong address. There is no type checker to catch a mismatched size, no garbage collector to reclaim memory, and no runtime to give a friendly error. That trade is worth making when you are writing a bootloader, a device driver, or a hot inner loop that must be exact. For most application code, it is a poor trade, and a higher level language is the right tool.

Where this leaves you

Learn enough Assembly to read a short program and follow registers through a debugger. You do not need to write whole applications in it. That small amount of fluency pays off every time a program crashes at a low level and the stack trace is the only clue left.

Originally published at https://practicaldevblog.blogspot.com/2026/11/assembly-explained-code-machine.html