The Practical Developer

Crystal Explained: Ruby's Syntax, Compiled Speed

Waqas Shahid — Tue, 27 Oct 2026 17:52:02 GMT

Introduction

Ruby is beloved for its readable syntax and developer happiness — and criticised for its speed. Crystal, released in 2014, asks a simple question: what if you kept Ruby's syntax and compiled it to native code? The result is a statically typed, compiled language that reads almost like Ruby, runs close to C speed, and needs no virtual machine. It is still young, but it is the most elegant answer yet to the dynamic-versus-compiled trade-off.

Ruby-like syntax, static types, and native compilation

Crystal's model rests on a few distinctive ideas:

Ruby-inspired syntax — blocks, symbols, and expressive method calls, so Ruby developers feel at home immediately.
Static typing with inference — types are checked at compile time, but usually inferred, so you get safety without annotating everything.
Macros — code that writes code at compile time, replacing Ruby's metaprogramming with a safer, checked version of the same power.
Native compilation — Crystal compiles to a single binary via LLVM, with no runtime to install, so deployment is a file, not a stack.

A tiny example shows the shape — it reads like Ruby, but the compiler checks it:

# A class with inferred types, compiled to native code
class Greeter
  def initialize(@name : String)
  end
  def greet
    "Hello, #{@name}!"
  end
end
puts Greeter.new("Ayesha").greet
# Hello, Ayesha!

@name : String is a typed instance variable; #{@name} is string interpolation, exactly as in Ruby. Same joy, checked by a compiler, running natively.

The honest trade

Crystal's trade is youth: a small ecosystem, fewer libraries and jobs than Ruby or Go, and tooling that is still maturing. Windows support has historically lagged, and the community is small. The rule of thumb: Crystal when you love Ruby's syntax but need compiled speed and single-binary deployment; Go when ecosystem and hiring dominate; Ruby when the existing ecosystem matters most.

Takeaway

Crystal is Ruby's syntax at compiled speed: inferred static types, macros, and native binaries, in code that reads like Ruby. It trades ecosystem maturity for elegance and performance — and for Rubyists who want speed without leaving home, that trade is tempting.

Originally published at https://practicaldevblog.blogspot.com/2026/10/crystal-explained-rubys-syntax-compiled.html

Clojure Explained: A Modern Lisp on the JVM

Waqas Shahid — Tue, 27 Oct 2026 17:50:18 GMT

Introduction

Lisp is the second-oldest programming language still in use, and most programmers have never written it — yet its ideas (code as data, functions as values, macros) shaped everything after it. Clojure, released in 2007, is Lisp rebuilt for the modern world: it runs on the JVM, uses every Java library, and replaces Lisp's mutable lists with immutable data structures. It is the language that convinced a generation of sceptics that parentheses are not a problem — they are the point.

Immutable data, code as data, and the REPL

Clojure's model rests on a few distinctive ideas:

Immutable data by default — maps, vectors, and sets never change in place; "updating" returns a new version, so concurrent code shares data safely and old versions stay available.
Code as data — Clojure code is itself a data structure (lists), so programs can manipulate programs: macros, the feature other languages fake with code generation, are native.
The REPL — develop interactively: evaluate expressions, inspect state, and reshape a running program without restarting it. The REPL is not a toy; it is the workflow.
JVM hosted — every Java library works, so Clojure programs deploy wherever Java does, with none of the ecosystem risk of a niche runtime.

A tiny example shows the shape — a function, a map, and immutable transformation:

;; A user, and a function that "ages" them — returning a new map
(def user {:name "Ayesha" :age 25})
(defn birthday [u]
  (update u :age inc))
(birthday user)
;; => {:name "Ayesha" :age 26}
;; user itself is unchanged — still 25

No mutation, no classes, just data and functions — and the original value is still there, untouched, for any other code that needs it.

The honest trade

Clojure's trade is familiarity and hiring: parentheses and prefix notation take adjustment, startup time is JVM-slow, and the talent pool is small. Error messages, from the JVM stack, can be cryptic. The rule of thumb: Clojure when immutable data and interactive development matter most, especially for data pipelines and backends; a mainstream JVM language when team familiarity dominates.

Takeaway

Clojure is a modern Lisp on the JVM: immutable data, code as data, and REPL-driven development, with every Java library available. It trades familiarity for simplicity that scales — and for programmers who learn it, parentheses stop looking strange and start looking honest.

Originally published at https://practicaldevblog.blogspot.com/2026/10/clojure-explained-modern-lisp-on-jvm.html

R Explained: The Language That Thinks in Data

Waqas Shahid — Tue, 27 Oct 2026 17:48:40 GMT

Introduction

Python does data science well, but R was born for it: created in 1993 by statisticians at the University of Auckland, it thinks in vectors, tables, and distributions the way other languages think in loops and objects. It powers academic research, clinical trials, and data journalism, and its superpower is that the things data people do all day — summarise, filter, plot — are one-liners, not library calls. If your work is data first and software second, R speaks your language natively.

Vectors, data frames, and the tidyverse

R's model rests on a few distinctive ideas:

Vectors everywhere — the basic unit is a vector, not a single value, so operations apply to whole columns at once: add 1 to a vector and every element grows, no loop needed.
Data frames — tables with named columns are a native type, not an add-on, so datasets feel like the language's home turf.
Vectorised statistics — means, models, and distributions are built in, from mean() to linear regression in one function call.
The tidyverse — a coherent family of packages (dplyr for manipulation, ggplot2 for plots) that turned R from a statistics tool into a full data workflow, with readable pipe-based code.

A tiny example shows the shape — filter, summarise, and plot-ready, in a few lines:

# A data frame of exam scores
scores <- data.frame(
  name  = c("Ayesha", "Bilal", "Chen"),
  score = c(88, 72, 95)
)
# Mean score, and the top scorer — no loops
mean(scores$score)              # 85
scores[scores$score > 80, ]     # Ayesha and Chen

$ reaches a column, [rows, ] filters it, and the whole dataset is one object. That is R's worldview: data first, code second.

The honest trade

R's trade is generality and speed: it is slower than Python for heavy computation, weaker for general-purpose software, and its syntax quirks (multiple assignment styles, inconsistent naming) confuse newcomers. The rule of thumb: R when statistics, analysis, and publication-quality plots are the job; Python when the job spans data, apps, and production systems.

Takeaway

R is the language that thinks in data: vectors, data frames, and vectorised statistics, with the tidyverse turning analysis into readable pipelines. It trades general-purpose power for data-native fluency — and for analysts, that fluency is everything.

Originally published at https://practicaldevblog.blogspot.com/2026/10/r-explained-language-that-thinks-in-data.html

Perl Explained: The Duct Tape That Held the Internet Together

Waqas Shahid — Tue, 27 Oct 2026 17:35:01 GMT

Introduction

Before Python was the default scripting language, there was Perl. Released in 1987, it powered the early dynamic web, system administration, and bioinformatics — and its motto, "there's more than one way to do it," made it the most expressive, and most notorious, language of its era. Perl is still running critical systems today, and its greatest gift to programming is one you use daily without thinking: regular expressions, which Perl made a first-class language feature.

Text processing, regex, and CPAN

Perl's model rests on a few distinctive ideas:

Text first — strings, files, and reports are Perl's home turf: slurp a file, transform it, print a report, in a handful of lines.
Regular expressions built in — pattern matching is not a library but syntax: =~ applies a regex directly, and Perl's regex engine set the standard others copied.
Context sensitivity — the same expression behaves differently in scalar and list context, which makes short scripts very short — and long programs harder to read.
CPAN — the Comprehensive Perl Archive Network, the original giant package repository, with a module for nearly everything, decades before npm or PyPI.

A tiny example shows the shape — read lines, keep the matching ones, print them transformed:

#!/usr/bin/perl
use strict;
use warnings;
while (my $line = <>) {
    if ($line =~ /error/i) {
        print uc $line;
    }
}

Feed it a log file and it prints every error line in uppercase: pattern matching, file handling, and transformation in six lines. That density is Perl's whole appeal — and, critics say, its whole problem.

The honest trade

Perl's trade is readability and fashion: dense, symbol-heavy code can be hard to read months later ("write-only" is the joke), and new projects rarely choose Perl over Python. The rule of thumb: Perl when maintaining or extending existing Perl systems, or for quick text-processing scripts; Python when starting fresh or working in a team that must read the code later.

Takeaway

Perl is the duct tape that held the internet together: text processing, built-in regex, and CPAN, in a language optimised for getting the job done fast. It trades readability for expressive density — and for the systems it still runs, that trade was worth making.

Originally published at https://practicaldevblog.blogspot.com/2026/10/perl-explained-duct-tape-that-held.html

Haskell Explained: Pure Functions, Serious Power

Waqas Shahid — Tue, 27 Oct 2026 17:33:40 GMT

Introduction

Most languages let functions do anything: change variables, print, read files, crash. Haskell, released in 1990, forbids most of that — and programmers who learn it often say it changed how they write every other language. It is a purely functional language: functions have no side effects, data never changes, and the type system catches whole classes of bugs before the program runs. It is less a tool for every job than a way of thinking that leaks, usefully, into everything else you write.

Purity, types, and laziness

Haskell's model rests on a few distinctive ideas:

Purity — a function, given the same inputs, always returns the same output and changes nothing. Testing becomes trivial, and reasoning about code becomes local: read the function, know what it does.
Strong static types with inference — the compiler knows every value's type and checks it, but you rarely write type annotations: it infers them, so safety does not cost verbosity.
Laziness — values are computed only when needed, so infinite lists are ordinary data and programs compose in ways strict languages cannot.
Type classes — interfaces defined by behaviour, not inheritance: a type joins a class by implementing its functions, and generic code works for any member.

A tiny example shows the shape — a function, a type, and no mutation anywhere:

-- Double every element of a list
doubleAll :: [Int] -> [Int]
doubleAll xs = map (* 2) xs
main :: IO ()
main = print (doubleAll [1, 2, 3])
-- [2,4,6]

map takes a function and a list; (* 2) is a function waiting for its argument. No loops, no mutation, no side effects in doubleAll — the IO type marks the one place effects are allowed: main.

The honest trade

Haskell's trade is learning curve and ecosystem: laziness and the type system take real adjustment, error messages can be cryptic, and the job market and library ecosystem are smaller than Python's or JavaScript's. The rule of thumb: Haskell when correctness, reasoning, and functional depth matter most — or when you want to level up as a programmer; a mainstream language when shipping speed or hiring dominates.

Takeaway

Haskell is pure functions, serious power: no side effects, inferred types, and laziness, in a language that makes correctness checkable. It trades mainstream ease for a way of thinking — and even programmers who never ship Haskell write better code for having learned it.

Originally published at https://practicaldevblog.blogspot.com/2026/10/haskell-explained-pure-functions.html

Phoenix Explained: Real-Time Web Apps That Never Stop

Waqas Shahid — Tue, 27 Oct 2026 17:31:45 GMT

Introduction

Most web frameworks treat real-time features — live updates, chat, collaborative editing — as an add-on: bolt on WebSockets, manage connections yourself, hope it scales. Phoenix, released in 2015 and built on Elixir (the batch 30 post), treats real-time as the default. It inherits the Erlang VM's fault tolerance, so a crashing connection affects one user, not the server, and it adds LiveView: server-rendered pages that update live over a persistent connection, without writing JavaScript. It is the framework that made "never stops" a web feature.

Channels, LiveView, and fault tolerance

Phoenix's model rests on a few distinctive ideas:

Channels — named topics over WebSockets, so a browser subscribes to a room, a feed, or a document, and the server pushes updates to exactly the right subscribers.
LiveView — server-side rendering with live updates: user events travel to the server, the server re-renders the changed part, and only the diff travels back. Interactive pages, almost no client JavaScript.
Presence — built-in tracking of who is online in a channel, so user lists and typing indicators come almost free.
Fault tolerance by inheritance — every connection is an Elixir process, supervised and isolated, so failures stay small and the system heals itself (see the Elixir post for the model).

A channel shows the shape — join a topic, broadcast to everyone in it:

defmodule MyAppWeb.RoomChannel do
  use MyAppWeb, :channel
  def join("room:lobby", _payload, socket) do
    {:ok, socket}
  end
  def handle_in("new_msg", %{"body" => body}, socket) do
    broadcast!(socket, "new_msg", %{body: body})
    {:noreply, socket}
  end
end

One process per connection, one broadcast to the whole room — and if a connection crashes, only that connection restarts.

The honest trade

Phoenix's trade is ecosystem and hiring: a smaller community and job market than Rails or Node, and Elixir's functional style takes adjustment. Its conventional structure is also opinionated — productive once learned, unfamiliar at first. The rule of thumb: Phoenix when real-time features and reliability matter most; Rails or Node when ecosystem depth or hiring dominates.

Takeaway

Phoenix is real-time web apps that never stop: channels, LiveView, and presence, on Elixir's fault-tolerant foundation. It trades mainstream ecosystem for live features that scale by default — and for apps where "live" is the product, that trade is the point.

Originally published at https://practicaldevblog.blogspot.com/2026/10/phoenix-explained-real-time-web-apps.html

Scala Explained: Objects and Functions on the JVM

Waqas Shahid — Tue, 27 Oct 2026 17:18:55 GMT

Introduction

Java gave the world a massive ecosystem and a verbose language; functional languages gave elegance and a smaller ecosystem. Scala, released in 2004, refused to choose: it runs on the Java Virtual Machine, uses every Java library, and blends object-oriented and functional programming in one language. It powers Twitter's backend, Apache Spark, and much of big data — and its lesson is that the two styles are not enemies, but tools for different parts of the same program.

Case classes, pattern matching, and immutability

Scala's model blends the familiar with the functional:

Everything is an object — like Java, but with type inference, so you write less boilerplate for the same safety.
Case classes — concise data holders with built-in equality and pattern matching, the natural way to model messages, events, and records.
Pattern matching — destructure data and branch on its shape in one readable expression, replacing chains of if and instanceof.
Immutability by default — prefer val over var and immutable collections, so concurrent code has fewer surprises; mutability is available, just not the default.

A tiny example shows the blend — a case class, a function, and pattern matching:

case class User(name: String, age: Int)
def describe(user: User): String = user match {
  case User(name, age) if age >= 18 => s"$name is an adult"
  case User(name, _)                => s"$name is a minor"
}
println(describe(User("Ayesha", 25)))
// Ayesha is an adult

Objects hold the data, functions transform it, and the compiler checks both — that blend is Scala's identity.

The honest trade

Scala's trade is complexity and hiring: it is a big language with many ways to do the same thing, compile times can be slow, and the talent pool is smaller than Java's or Kotlin's. The rule of thumb: Scala when you need JVM ecosystem plus functional power, especially for data pipelines; Kotlin when you want a simpler modern JVM language; Java when team familiarity dominates.

Takeaway

Scala is objects and functions on the JVM: case classes, pattern matching, and immutability by default, with every Java library available. It trades simplicity for expressive power — and for data-intensive systems, that power is why it endures.

Originally published at https://practicaldevblog.blogspot.com/2026/10/scala-explained-objects-and-functions.html

Julia Explained: The Language Built for Speed and Science

Waqas Shahid — Tue, 27 Oct 2026 17:17:05 GMT

Introduction

Scientific computing has long suffered a two-language problem: prototype in Python or MATLAB, then rewrite the slow parts in C or Fortran. Julia, released in 2012, was built to end that split — a language that reads like a scripting language and runs like a compiled one. It powers climate models, drug discovery, and the world's largest telescopes, and its secret is a design choice most languages never make: multiple dispatch, where the function that runs depends on the types of all its arguments.

Multiple dispatch and just-in-time compilation

Julia's model rests on a few distinctive ideas:

Multiple dispatch — define one function name with many methods, and Julia picks the right one based on every argument's type, not just the first. New types get new methods without touching old code.
Just-in-time compilation — Julia compiles each method the first time it runs, specialised for the actual argument types, so a loop over numbers compiles down to fast machine code.
Built for numbers — first-class arrays, linear algebra in the standard library, and a package ecosystem centred on science, statistics, and machine learning.
Interoperability — call Python, R, and C libraries directly, so Julia fits into existing scientific workflows instead of demanding a rewrite.

A tiny example shows the shape — one function, specialised by type:

# Generic version: works for any numbers
add(a, b) = a + b
# Specialised version: runs for matrices
add(A::Matrix, B::Matrix) = A .+ B
println(add(2, 3))          # 5
println(add([1 2], [3 4]))  # [4 6]

Same name, different behaviour, chosen by the compiler from the argument types — that is multiple dispatch, and it is how Julia stays both expressive and fast.

The honest trade

Julia's trade is ecosystem and startup time: a smaller general-purpose community than Python, fewer web and app libraries, and the famous "time to first plot" — the first compilation of a heavy package can take seconds. The rule of thumb: Julia when numerical performance and scientific expressiveness matter most; Python when ecosystem breadth and hiring dominate.

Takeaway

Julia is the language built for speed and science: multiple dispatch, just-in-time compilation, and first-class numerics, in syntax that reads like a scripting language. It trades mainstream ecosystem for an end to the two-language problem — and for scientists, that trade is the whole point.

Originally published at https://practicaldevblog.blogspot.com/2026/10/julia-explained-language-built-for.html

Stimulus Explained: Just Enough JavaScript for Server-Rendered Pages

Waqas Shahid — Tue, 27 Oct 2026 17:15:17 GMT

Introduction

Not every page needs a single-page app. If your server already renders good HTML — the Rails, Laravel, and Django way — bolting on React for a dropdown or a toggle is overkill, but writing jQuery spaghetti is no fun either. Stimulus, released in 2018 by the Rails team at 37signals, is the middle path: a modest JavaScript framework that attaches behaviour to HTML you already have, using conventions instead of a build step or a virtual DOM. It is JavaScript for the 90% of pages that are mostly server-rendered.

Controllers, targets, and values

Stimulus organises behaviour around three ideas, all declared in plain HTML:

Controllers — small JavaScript classes that connect to an element via a data-controller attribute and run when that element appears on the page.
Targets — named elements inside a controller's scope, declared with data-hello-target, so code reads this.nameTarget instead of querying the DOM by hand.
Values and actions — typed data passed through data-hello-name-value attributes, and behaviour wired with data-action="click->hello#greet", keeping the HTML readable and the JavaScript small.

A greeting controller shows the whole model — HTML declares the wiring, JavaScript supplies the behaviour:

// hello_controller.js
import { Controller } from "@hotwired/stimulus";
export default class extends Controller {
  static targets = ["name", "output"];
  greet() {
    this.outputTarget.textContent =
      `Hello, ${this.nameTarget.value}!`;
  }
}

No build step required, no state to synchronise, no virtual DOM: the HTML is the source of truth, and Stimulus just makes it interactive.

The honest trade

Stimulus's trade is scope: it deliberately does not do routing, global state, or complex client-side rendering, so a genuinely app-like interface will outgrow it. Its ecosystem is also smaller than React's or Vue's. The rule of thumb: Stimulus when your pages are mostly server-rendered and need sprinkles of interactivity; a full framework when the interface itself is the product.

Takeaway

Stimulus is just enough JavaScript for server-rendered pages: controllers, targets, and actions declared in HTML, with no build step and no virtual DOM. It trades app-framework power for simplicity — and for most pages, simplicity is exactly what you need.

Originally published at https://practicaldevblog.blogspot.com/2026/10/stimulus-explained-just-enough.html

Zig Explained: A Modern Systems Language Without the Magic

Waqas Shahid — Tue, 27 Oct 2026 17:00:18 GMT

Introduction

Systems programming — operating systems, embedded devices, game engines — has long meant C and C++, with their power and their footguns. Rust (the batch 5 post) added safety through its borrow checker. Zig, released in 2016, takes a different stance: keep C's simplicity and control, fix its worst problems, and add no hidden magic — no macros, no operator overloading, no implicit allocations, no hidden control flow. The result is a small language that is easy to read, explicit about costs, and increasingly used where C once ruled alone.

Comptime, explicit allocation, and no hidden control flow

Zig's design rests on a few distinctive ideas:

Comptime — code that runs at compile time, replacing C's preprocessor and much of generics: write one function that works for many types, evaluated by the compiler, with normal Zig syntax instead of macro magic.
Explicit allocators — every allocation names its allocator, so memory strategy is visible in the code: arena for short-lived work, general-purpose for the rest, no hidden malloc behind a library call.
No hidden control flow — no exceptions, no hidden function calls: errors return as values (! error unions), and every allocation, every fallible call, is visible at the call site.
C interop — Zig compiles C code and calls C libraries directly, so adopting it incrementally in a C codebase is practical, not a rewrite.

A hello-world shows the explicitness — errors handled, output written, nothing hidden:

const std = @import("std");
pub fn main() !void {
    const stdout = std.io.getStdOut().writer();
    try stdout.print("Hello, world!\n", .{});
}

!void says main can fail; try propagates the error explicitly. Read Zig code and you can see every cost — that visibility is the language's core promise.

The honest trade

Zig's trade is youth: a small ecosystem, a still-evolving standard library, and tooling that trails Rust's. Its manual memory model also demands more care than a garbage-collected language, and async support is still maturing. The rule of thumb: Zig when you want C-level control with modern ergonomics and explicit costs; Rust when you want maximum safety guarantees and ecosystem; C when you must stay in the existing codebase.

Takeaway

Zig is a modern systems language without the magic: comptime instead of macros, explicit allocators, visible errors, and direct C interop. It trades ecosystem maturity for readability and control — and for systems programmers tired of hidden costs, that trade is the appeal.

Originally published at https://practicaldevblog.blogspot.com/2026/10/zig-explained-modern-systems-language.html

Elixir Explained: Fault-Tolerant Code That Never Stops

Waqas Shahid — Tue, 27 Oct 2026 16:58:35 GMT

Introduction

Most languages crash when something goes wrong; a failed process takes down the request, or the server. Elixir, released in 2011 and built on the Erlang virtual machine (BEAM), was designed by telecom engineers who could not afford crashes: phone switches must run for years without stopping. Its answer is "let it crash" — isolate failures in tiny processes, supervise them, and restart only what failed. That philosophy now powers chat systems, real-time apps, and the Phoenix web framework, and it changes how you think about reliability.

Processes, messages, and supervision

Elixir's model is built on the actor model:

Processes — extremely lightweight (thousands per megabyte), isolated units of execution that communicate only by sending messages, never by sharing memory. A process crash affects nothing else.
Supervision trees — supervisors watch worker processes and restart them on failure, with strategies: restart one, restart all, or restart in order. Failures become routine events, not emergencies.
Let it crash — instead of defensive code everywhere, write the happy path and let supervisors handle the rest. The system heals itself.
Hot code upgrades — the BEAM can replace running code without stopping the system, the feature that kept phone switches running for decades.

A tiny example shows the shape — spawn a process, send it a message, receive a reply:

pid = spawn(fn ->
  receive do
    {:hello, from} -> send(from, :world)
  end
end)
send(pid, {:hello, self()})
receive do
  :world -> IO.puts("Got world!")
end

No shared state, no locks, no crash propagation — just messages between isolated processes, supervised from above.

The honest trade

Elixir's trade is ecosystem and hiring: a smaller community and job market than Python or JavaScript, and a functional style that takes adjustment for imperative programmers. Raw CPU-heavy computation is not its strength either (the BEAM optimises for concurrency, not number crunching). The rule of thumb: Elixir when fault tolerance, concurrency, and real-time features matter most; a mainstream language when ecosystem depth or raw compute dominates.

Takeaway

Elixir is fault-tolerant code that never stops: lightweight processes, message passing, and supervision trees that restart what fails. It trades mainstream ecosystem for reliability designed in from the start — and for systems that must not stop, that trade is everything.

Originally published at https://practicaldevblog.blogspot.com/2026/10/elixir-explained-fault-tolerant-code.html

Lit Explained: Web Components Without the Framework

Waqas Shahid — Tue, 27 Oct 2026 16:56:50 GMT

Introduction

Frameworks come and go, but web components — custom elements, shadow DOM, HTML templates — are browser standards, supported everywhere, with no framework to outgrow. The catch has always been boilerplate: raw web components need a lot of ceremony for reactivity and templating. Lit, released in 2019 by Google, removes that ceremony: a tiny library (about 5KB) that adds reactive properties and declarative templates to standard web components, so you build framework-free components that work in any page, with any framework, forever.

Reactive properties and declarative templates

Lit's model is small and standards-based:

LitElement — a base class extending HTMLElement, adding reactivity: declare a property, and Lit re-renders the component when it changes.
Reactive properties — decorated fields (or a static properties definition) that trigger updates on change, with attribute reflection for HTML attributes.
html templates — tagged template literals that describe the DOM declaratively, with expressions for dynamic values and event bindings, efficiently updated in place.
Shadow DOM — styles and markup encapsulated per component by the platform itself, so a component's CSS never leaks.

A counter shows the whole model — a custom element, reactive state, and a template, in a few lines:

import { LitElement, html } from "lit";
import { customElement, state } from "lit/decorators.js";
@customElement("my-counter")
class MyCounter extends LitElement {
  @state() count = 0;
  render() {
    return html`
      
    `;
  }
}

Use it anywhere with — in a React app, a Vue app, plain HTML, or another framework's page, with no adapter. That portability is Lit's whole argument.

The honest trade

Lit's trade is ecosystem and ergonomics: fewer ready-made component libraries than React, and shadow DOM styling has its own learning curve (theming across shadow boundaries needs CSS custom properties). Server rendering exists but is younger than React's. The rule of thumb: Lit when building shareable, framework-agnostic components or design systems; a full framework when building an entire app with routing, state management, and a large ecosystem.

Takeaway

Lit is web components without the framework: reactive properties, declarative templates, and shadow DOM encapsulation, on browser standards, in about 5KB. It trades framework ecosystem for components that outlive frameworks — and for design systems, that longevity is the point.

Originally published at https://practicaldevblog.blogspot.com/2026/10/lit-explained-web-components-without.html

Preact Explained: React, But 3 Kilobytes

Waqas Shahid — Tue, 27 Oct 2026 16:42:29 GMT

Introduction

React (covered earlier) is the default UI library — and, at around 40KB compressed plus its ecosystem, a heavy one for widgets, embeds, and performance-critical pages. Preact, released in 2015, asks a simple question: what if you kept React's API and dropped the weight? At about 3KB, Preact implements the same component model, hooks, and JSX, and most React code runs on it unchanged through a compatibility layer. It is the framework for places where every kilobyte counts.

The same API, a fraction of the size

Preact's compatibility is deliberate:

Same API — components, hooks (useState, useEffect), and JSX work as in React; preact/compat adds the remaining React APIs (like React.memo and synthetic events) for libraries that expect them.
Tiny core — 3KB means Preact loads fast on slow networks and embeds well in pages that are not primarily React apps: widgets, ads, and progressive enhancement.
Signals option — Preact Signals (like Solid's, batch 28) offer fine-grained reactivity as an alternative to re-rendering, for performance-critical components.
Drop-in migration — aliasing react to preact/compat in a bundler often migrates an app with no code changes, which is how teams adopt it incrementally.

A component shows the familiarity — if you know React, you already know this:

import { useState } from "preact/hooks";
export function Counter() {
  const [count, setCount] = useState(0);
  return (
    
  );
}

The only visible difference is the import path. That familiarity is Preact's whole pitch: React skills, a tenth of the size.

The honest trade

Preact's trade is edge-case compatibility: a few React libraries depend on React internals that preact/compat does not perfectly replicate, and its ecosystem and job market are far smaller. React's concurrent features and newest APIs also arrive later, if at all. The rule of thumb: Preact when size and load time dominate — widgets, embeds, slow networks; React when ecosystem depth, hiring, or cutting-edge features matter most.

Takeaway

Preact is React, but 3 kilobytes: the same components, hooks, and JSX, with a compat layer for most React code and signals for fine-grained updates. It trades ecosystem depth for size — and when every kilobyte counts, that trade wins.

Originally published at https://practicaldevblog.blogspot.com/2026/10/preact-explained-react-but-3-kilobytes.html

Neovim Explained: Vim Rebuilt for the Modern Era

Waqas Shahid — Tue, 27 Oct 2026 16:40:43 GMT

Introduction

Vim (the batch 24 post) is a legendary editor — and, by modern standards, a hard one to extend: its Vimscript configuration language and single-threaded design show their age. Neovim, forked from Vim in 2014, keeps Vim's modal editing and keybindings while rebuilding the internals for the modern era: Lua configuration, a built-in language server client, async plugins, and a first-class terminal. It is why a generation of Vim users moved — same muscle memory, modern capabilities.

What Neovim changes, and what it keeps

Neovim keeps everything Vim users rely on — modes, motions, the dw/ci" grammar — and upgrades the parts around it:

Lua configuration — init.lua replaces Vimscript for most users: a real programming language for config, with a huge plugin ecosystem built on it.
Built-in LSP client — language servers (the same protocol VS Code uses) plug in natively, giving autocomplete, go-to-definition, and diagnostics without a plugin framework.
Treesitter — incremental parsing gives accurate syntax highlighting and code-aware motions, replacing regex-based highlighting.
Async everything — plugins and jobs run without freezing the editor, and a built-in terminal (:terminal) runs shells inside editor splits.
Remote UI — Neovim's architecture separates the editor core from the UI, so GUIs and editor integrations can embed it.

A minimal Lua config shows the flavour — options set as Lua code, plugins managed by a plugin manager:

vim.opt.number = true
vim.opt.relativenumber = true
vim.keymap.set("n", "ff", ":Telescope find_files")

Same editor, same keys — but configured in a language developers already know, with IDE features built in rather than bolted on.

The honest trade

Neovim's trade is the same as Vim's, plus setup time: the learning curve is steep, and a good setup takes real configuration work (or a prebuilt distribution like LazyVim). GUI editors like VS Code still win on batteries-included convenience and debugging UI. The rule of thumb: Neovim when you want Vim's editing with modern IDE features and you enjoy configuring your tools; VS Code (with Vim keybindings) when you want the features without the setup.

Takeaway

Neovim is Vim rebuilt for the modern era: identical modal editing, plus Lua config, built-in LSP, Treesitter, and async plugins. It trades setup effort for an editor that is both legendary and current — which is why Vim's future wears its name.

Originally published at https://practicaldevblog.blogspot.com/2026/10/neovim-explained-vim-rebuilt-for-modern.html

HTMX Explained: Modern Interactivity From Plain HTML

Waqas Shahid — Tue, 27 Oct 2026 16:38:49 GMT

Introduction

The modern web taught developers that interactivity requires JavaScript frameworks, JSON APIs, and client-side state. HTMX, released in 2020, argues the opposite: most interactivity is just "click a thing, replace part of the page" — and HTML itself, extended with a few attributes, can do that directly. No build step, no JSON API, no client state: the server returns HTML fragments, and HTMX swaps them into the page. It is the hypermedia idea, updated for modern browsers, and it has quietly become one of the most talked-about tools in web development.

Attributes that make HTML dynamic

HTMX extends HTML with hx- attributes that describe behaviour declaratively:

hx-get / hx-post — issue an AJAX request when an event fires: a button with hx-get="/users" fetches that URL on click.
hx-target — choose where the response goes: a CSS selector for the element to replace, defaulting to the element itself.
hx-swap — choose how it goes in: replace the target's inner HTML, outer HTML, prepend, append, or swap with a CSS transition.
hx-trigger — choose when: on click by default, but also on load, on a timer, or on any event, including custom ones.
hx-boost — upgrade plain links and forms to AJAX automatically, turning a traditional multi-page site into a smooth single-page-feeling one.

A live-search example shows the whole model — an input that fetches results as you type, with no JavaScript written:

The server returns an HTML fragment of results; HTMX puts it in #results. The backend stays a normal server-rendered app (Django, Laravel, Flask — all covered earlier), and the frontend stays HTML.

The honest trade

HTMX's trade is the client-side ceiling: for highly interactive apps — collaborative editors, complex dashboards, offline-first tools — a JavaScript framework with local state still wins, and HTMX's server-round-trip model adds latency to every interaction. Debugging also means reading network responses, not component trees. The rule of thumb: HTMX when your app is mostly server-rendered with pockets of dynamic behaviour; a framework when the app itself lives in the browser.

Takeaway

HTMX is modern interactivity from plain HTML: attributes that fetch, target, and swap server-rendered fragments, with no build step or client state. It trades client-side power for server-side simplicity — and for most web apps, that trade is a revelation.

Originally published at https://practicaldevblog.blogspot.com/2026/10/htmx-explained-modern-interactivity.html

Tauri Explained: Tiny Desktop Apps From Web Code

Waqas Shahid — Tue, 27 Oct 2026 16:23:54 GMT

Introduction

Electron (the batch 23 post) put web developers on the desktop — at the cost of shipping a whole Chromium browser inside every app, with large downloads and heavy memory use. Tauri, released in 2020, offers the same promise with a fraction of the weight: build desktop apps from web frontend code, but use the operating system's own webview for rendering and a Rust backend for system access. The result is apps measured in megabytes, not hundreds of megabytes, with a security model designed around least privilege.

Webview frontend, Rust backend, and capabilities

Tauri splits the app like Electron does, but with different pieces:

Frontend — any web framework (React, Vue, Svelte, or plain HTML) running in the system's webview: WebKit on macOS, WebView2 on Windows, WebKitGTK on Linux. No bundled Chromium.
Backend — Rust code that handles system access: files, windows, menus, notifications, and shell commands, exposed to the frontend through a command API.
Capabilities — a permission system: the frontend can only call backend commands the app explicitly allows, in a config file, so a compromised frontend cannot freely access the system. This allowlist is Tauri's security headline versus Electron's broader default access.
Tiny output — because the webview is the system's, a Tauri app is typically a few megabytes, starts fast, and uses far less memory than the equivalent Electron app.

A frontend call to the backend shows the shape — invoke a Rust command by name from JavaScript:

import { invoke } from "@tauri-apps/api/core";
const greeting = await invoke("greet", { name: "Waqas" });
console.log(greeting);

The Rust side defines greet, Tauri wires it up, and the frontend treats it like any async function — with the capability config deciding what is allowed.

The honest trade

Tauri's trade is maturity and platform quirks: its ecosystem is younger than Electron's, webview differences across operating systems can bite (a feature working on one platform's webview, not another's), and Rust backend code is a learning curve for pure web teams. Some apps also need Chromium-specific features the system webview lacks. The rule of thumb: Tauri when app size, memory, and security matter and the frontend is standard web tech; Electron when you need Chromium guarantees, the largest plugin ecosystem, or a team with no Rust appetite.

Takeaway

Tauri is tiny desktop apps from web code: a system webview for the UI, a Rust backend for system access, and a capability allowlist guarding the boundary. It trades Electron's maturity for apps a fraction of the size — and for many desktop apps, that fraction is the whole argument.

Originally published at https://practicaldevblog.blogspot.com/2026/10/tauri-explained-tiny-desktop-apps-from.html

Qwik Explained: Instant Apps Through Resumability

Waqas Shahid — Tue, 27 Oct 2026 16:22:33 GMT

Introduction

Modern frameworks ship JavaScript, then spend time on page load "hydrating": re-running components in the browser to make server-rendered HTML interactive. That hydration cost is why many sites feel slow to become responsive even when they look loaded. Qwik, released in 2022, attacks the problem at its root with resumability: the server renders HTML and serialises the app's state, and the browser resumes where the server left off — without re-running component code or downloading the framework upfront. The result is near-instant interactivity, even for large apps.

Resumability, lazy loading, and dollar-sign syntax

Qwik's ideas build on each other:

Resumability, not hydration — server-rendered HTML carries serialised state and tiny event listeners; the browser does not re-execute components to attach interactivity, it resumes them.
Lazy loading by default — event handlers and component code download only when needed: clicking a button fetches that button's handler, not the whole app. Qwik's optimizer splits code automatically at the $ boundary.
Dollar-sign syntax — functions marked with $, like onClick$, tell the optimizer where code can be split and lazily loaded.
No hydration tax — initial JavaScript can be near zero regardless of app size, because code arrives on demand, not upfront.

A component shows the shape — familiar JSX, with $ marking the lazy boundary:

import { component$, useSignal } from "@builder.io/qwik";
export const Counter = component$(() => {
  const count = useSignal(0);
  return (
    
  );
});

The button renders on the server; its click handler downloads only when clicked. Scale that across an app and startup time stops growing with app size — Qwik's central claim, and the reason it wins startup benchmarks.

The honest trade

Qwik's trade is youth and ecosystem: a small community, fewer libraries, and a mental model (resumability, $ boundaries, serialisable state) that takes learning. Its tooling and job market trail React and Next.js by a wide margin. The rule of thumb: Qwik when startup performance is the top priority — marketing sites, e-commerce, content apps at scale; a mainstream framework when ecosystem and hiring matter more.

Takeaway

Qwik is instant apps through resumability: server-rendered HTML with serialised state, code split at $ boundaries and loaded on demand, no hydration re-run. It trades ecosystem maturity for startup time that does not grow with app size — and for user-facing sites, that is a superpower.

Originally published at https://practicaldevblog.blogspot.com/2026/10/qwik-explained-instant-apps-through.html

SolidJS Explained: React-Like Code, Svelte-Like Speed

Waqas Shahid — Tue, 27 Oct 2026 16:20:34 GMT

Introduction

React (covered earlier) re-renders components when state changes, diffing a virtual DOM to find what updated. Svelte (batch 8) compiles that work away at build time. SolidJS, released in 2021, takes a third path that feels familiar to React developers but performs like Svelte: write JSX that looks like React, and get updates through fine-grained reactivity — only the exact DOM nodes that depend on changed state update, with no virtual DOM at all. It is consistently among the fastest frameworks in benchmarks, and the reason is architectural, not a trick.

Signals and fine-grained updates

Solid's core is signals — reactive primitives that track dependencies automatically:

createSignal — holds a value and returns a getter and setter: const [count, setCount] = createSignal(0). Reading count() inside a component subscribes that exact text node to the signal.
Fine-grained updates — when setCount runs, only the DOM nodes that read count() update. No component re-renders, no diffing, no virtual DOM walk.
Effects — createEffect runs code whenever the signals it reads change, for side effects like logging or syncing.
JSX, familiar — components look like React, but they run once: the JSX compiles to real DOM creation, and signals do all the updating afterward.

A counter shows the shape — React-like syntax, fundamentally different update model:

import { createSignal } from "solid-js";
function Counter() {
  const [count, setCount] = createSignal(0);
  return (
    
  );
}

The component function runs once; the {count()} text node updates itself whenever the signal changes. That is why Solid benchmarks near vanilla JavaScript: there is almost nothing between a state change and the DOM update.

The honest trade

Solid's trade is ecosystem: far fewer libraries, jobs, and learning resources than React, and its "components run once" model surprises React developers (effects and lifecycles behave differently). Server rendering and routing exist but are younger than Next.js's. The rule of thumb: Solid when raw performance and React-like DX both matter, especially for interactive widgets; React when ecosystem depth and hiring matter most.

Takeaway

SolidJS is React-like code with Svelte-like speed: JSX components that run once, signals tracking dependencies, and only the exact DOM nodes updating — no virtual DOM. It trades ecosystem size for performance that comes from architecture, not optimisation tricks.

Originally published at https://practicaldevblog.blogspot.com/2026/10/solidjs-explained-react-like-code.html

CircleCI Explained: Cloud Pipelines Without Managing Servers

Waqas Shahid — Tue, 27 Oct 2026 16:08:23 GMT

Introduction

Jenkins (the batch 25 post) gives you full control — and full responsibility for the server. GitHub Actions (batch 13) gives you convenience — tied to GitHub. CircleCI, launched in 2011, carved out the middle: cloud-hosted CI/CD for any Git host, configured in a single YAML file, with no server to maintain and a generous free tier that made it a favourite of startups and open-source projects. It is the hosted-pipeline idea in its purest commercial form.

Jobs, workflows, and orbs

CircleCI's model mirrors the other pipeline tools, with its own vocabulary:

Jobs — units of work (build, test, deploy) that run in containers or virtual machines, each defined with steps.
Workflows — jobs chained with dependencies and filters: run tests on every push, deploy only on the main branch, run jobs in parallel.
Orbs — reusable packages of jobs and commands, shared by the community: an orb for Node, Docker, or AWS deployment replaces dozens of lines of config.
Config in the repo — a .circleci/config.yml file versions the pipeline with the code, like the other tools' config files.

A minimal config shows the shape — a job, its steps, and the workflow that runs it:

version: 2.1
jobs:
  test:
    docker:
      - image: node:20
    steps:
      - checkout
      - run: npm test
workflows:
  main:
    jobs:
      - test

Push code, CircleCI picks it up, the job runs in the cloud, and the team sees green or red — with caching and parallelism available when builds grow.

The honest trade

CircleCI's trade is cost and lock-in at scale: heavy usage gets expensive compared to self-hosted Jenkins, and its config dialect is specific to CircleCI. GitHub Actions has also eaten much of its market by being built into the platform most code already lives on. The rule of thumb: CircleCI when you want polished hosted CI independent of your Git host, with orbs doing the heavy lifting; GitHub Actions when your code is on GitHub; Jenkins when you must self-host.

Takeaway

CircleCI is cloud pipelines without managing servers: jobs in containers, workflows chaining them, and orbs packaging common setups, all from a config file in the repo. It trades self-hosting control for hosted convenience — and for teams that just want green builds, that convenience is the point.

Originally published at https://practicaldevblog.blogspot.com/2026/10/circleci-explained-cloud-pipelines.html

Elasticsearch Explained: Search That Actually Understands Your Data

Waqas Shahid — Tue, 27 Oct 2026 16:06:52 GMT

Introduction

A database can find exact matches — but type "runing shoes" into a store search and you expect results for "running shoes" anyway, ranked by relevance, with filters and facets. That is search, not lookup, and it needs a different engine. Elasticsearch, released in 2010 and built on Apache Lucene, is the most widely used search and analytics engine: it indexes JSON documents, answers full-text queries in milliseconds, and powers site search, log analysis, and observability at companies of every size.

Inverted indexes, documents, and relevance

Elasticsearch's model differs from a database in three ways:

Documents — data lives as JSON documents in indexes (like tables, but schemaless-friendly): a product, a log line, an article.
Inverted indexes — for each term, Elasticsearch stores which documents contain it, so finding "shoes" is a lookup, not a scan of every row. Analysis (lowercasing, stemming, tokenising) happens at index time, which is why "running" matches "run".
Relevance scoring — results rank by how well they match (term frequency, rarity, field boosts), not just whether they match, and queries combine full-text search with filters, aggregations (counts by category, price ranges), and sorting.

A search request shows the shape — a JSON query describing what to find and how to rank it:

{
  "query": {
    "match": {
      "title": "running shoes"
    }
  }
}

That query returns matching products ranked by relevance, in milliseconds, even across millions of documents — and the same engine aggregates logs for dashboards in tools like Kibana.

The honest trade

Elasticsearch's trade is operational weight and eventual consistency: clusters need sizing, sharding, and care (the same lesson as Kafka, batch 25), and it is not a primary database — it is a search index fed from one, so data can lag briefly. For small sites, a database's built-in full-text search or a hosted service often suffices. The rule of thumb: Elasticsearch when search quality, scale, or log analytics matter; a database when exact lookups are all you need.

Takeaway

Elasticsearch is search that understands your data: JSON documents, inverted indexes for instant term lookup, and relevance-ranked results with aggregations. It trades database simplicity for search power — and when users expect search to just work, that power is the product.

Originally published at https://practicaldevblog.blogspot.com/2026/10/elasticsearch-explained-search-that.html