DEV Community: henry messiah tmt

Solidity to Compact: Developer's Migration Guide

henry messiah tmt — Sat, 14 Feb 2026 09:45:42 +0000

Many developers entering the Midnight ecosystem bring valuable Solidity experience from Ethereum development. This guide bridges that knowledge gap by providing direct, side-by-side comparisons between Solidity and Compact code patterns.

Compact is Midnight Network's domain-specific language for building privacy-preserving smart contracts. Unlike Solidity's transparent-by-default model, Compact introduces explicit privacy controls through public ledger state and private witness functions. The language uses TypeScript-like syntax while introducing blockchain-specific concepts necessary for zero-knowledge proof generation.

This comparison guide covers ten fundamental patterns that Solidity developers use daily: contract structure, data types, loops, state management, events, access control, visibility modifiers, initialization, validation, and privacy features. Each pattern includes working code examples in both languages, highlighting key differences and migration considerations.

By mapping your existing Solidity knowledge to Compact equivalents, you will reduce the learning curve and start building privacy-preserving applications faster. The guide emphasizes not just syntax translation but conceptual differences in how privacy-first smart contracts operate.

The image below shows the architecture comparison between Solidity and Compact.

Before diving into detailed code comparisons, let's start with a high-level overview of how common Solidity patterns map to their Compact equivalents.

Quick reference table

This table provides an overview of how common Solidity patterns translate to Compact:

Pattern	Solidity Feature	Compact Equivalent	Key Difference
Structure	`contract MyContract { }`	`export ledger` + `export circuit`	No container; state declared globally
Data Types	Dynamic types, signed integers	`Field`, `Bytes<N>`, `Counter`, `Boolean`	Fixed-size types required for ZK proofs
Loops	`for (i < array.length)`	`for` with compile-time bounds	Iteration limits must be known at compile time
Privacy	All public (even `private` keyword)	`witness` functions for true privacy	Cryptographic privacy guarantees
Events	`emit Transfer(from, to, amount)`	Ledger state updates + return values	Track changes via ledger counters and return values
Modifiers	`modifier onlyOwner() { }`	Helper circuits with `assert`	No equivalent; use helper circuits instead
Visibility	`public`, `external`, `internal`, `private`	`export` vs non-exported	File-scoped functions
Constructor	`constructor(params) { }`	`constructor(params)` with direct assignment	Similar syntax, explicit state initialization
Validation	`require()`, `revert()`, `assert()`	`assert()` only	Aborts circuit execution on failure
State Reading	`function getValue() view`	Circuits read state directly	External apps query via TypeScript indexer

Now that you've seen the high-level mapping between Solidity and Compact, let's examine each pattern in detail with working code examples.

Pattern 1: Basic contract structure

This section explores how Solidity and Compact organize code differently. You'll learn how Solidity bundles everything into contract containers, while Compact separates state declarations from transaction logic using a global ledger model.

Solidity: Contract declaration

Solidity organizes code within contract containers that hold state variables and functions together:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleStorage {
    // State variables declared inside contract
    uint256 public storedValue;
    address public owner;

    // Constructor initializes state
    constructor(uint256 _initialValue) {
        storedValue = _initialValue;
        owner = msg.sender;  // Automatic caller context
    }

    // State-modifying function
    function setValue(uint256 _newValue) public {
        storedValue = _newValue;
    }

    // View function for reading state
    function getValue() public view returns (uint256) {
        return storedValue;  // Direct state access
    }
}

This familiar Solidity pattern organizes everything within a contract container. Now, let's see how Compact approaches the same functionality with a fundamentally different structure.

Compact: Ledger and circuit declaration

Compact separates state declarations from transaction logic, with no container pattern:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Public ledger state (declared globally, outside circuits)
export ledger stored_value: Field;
export ledger owner: Bytes<32>;

// Witness functions provide private off-chain data
witness get_caller(): Bytes<32>;

// Constructor initializes state with parameters
constructor(initial_value: Field, owner_address: Bytes<32>) {
    stored_value = initial_value;
    owner = owner_address;
}

// State-modifying circuit
export circuit set_value(new_value: Field): [] {
    stored_value = new_value;
}

// Circuits can read ledger state directly
export circuit get_and_update(increment: Field): Field {
    let current: Field = stored_value;  // Read state in circuit
    stored_value = current + increment;  // Update state
    return current;  // Return old value
}

You've seen how Compact declares state and circuits differently from Solidity. Circuits can read and modify ledger state directly during execution. For external applications (like frontends) that need to query state without executing a circuit, you'll use the TypeScript runtime.

Reading ledger state in compact

Compact circuits can read ledger state directly during execution. For external queries (like from a frontend), use TypeScript runtime:

// OPTION 1: Read state within a circuit (during execution)
export circuit check_value(): Field {
    let current: Field = stored_value;  // Direct state access
    return current;
}

// OPTION 2: Query state externally via TypeScript (for frontends)
import { indexerPublicDataProvider } from "@midnight-ntwrk/midnight-js-indexer-public-data-provider";

const state = await publicDataProvider.queryContractState(contractAddress);
if (state) {
    const ledger = ContractModule.ledger(state.data);
    const currentValue = ledger.stored_value;  // Read Field value
    const currentOwner = ledger.owner;
    console.log(`Value: ${currentValue}, Owner: ${currentOwner}`);
}

Now that you've seen both implementations, let's highlight the critical differences you need to remember.

Key differences

Constructor initialization: Both Solidity and Compact constructors accept parameters directly for initialization. In Compact, the constructor is called once during deployment with the initial state values.

Privacy by default: Solidity parameters are public. Compact circuit parameters can be provided as private witness data, enabling cryptographic privacy for sensitive inputs.

Structure: Solidity uses a contract container holding all code. Compact declares ledger state globally and defines individual circuits for transactions.

Language declaration: Solidity specifies version with pragma solidity ^0.8.0. Compact requires pragma language_version with version specification and mandatory import CompactStandardLibrary.

State access: Solidity allows state reads through view functions. Compact circuits can read ledger state directly during execution. External applications query state via TypeScript runtime SDK using the indexer.

Automatic context: Solidity provides msg.sender automatically. Compact requires explicit witness functions to access caller context.

Return types: Solidity uses explicit return type syntax returns (uint256). Compact uses [] (empty tuple) to indicate no return value, or specifies the return type like Field.

With a solid understanding of how Compact structures contracts differently from Solidity, you're ready to explore another fundamental difference: the type system.

Pattern 2: Data types and type system

This section examines the fundamental differences in how each language handles data types. You'll discover why Solidity's flexible runtime sizing doesn't work in Compact's zero-knowledge proof environment, which requires all sizes to be known at compile time.

Solidity: Flexible types with runtime sizing

Solidity supports various numeric types, signed integers, and dynamic data structures:

contract DataTypes {
    // Boolean (no type suffix needed)
    bool public flag = true;

    // Unsigned integers (various sizes)
    uint256 public largeNumber = 1000000;
    uint8 public smallNumber = 255;

    // Signed integers supported
    int256 public signedNumber = -100;

    // Address type
    address public userAddress;

    // Fixed-size bytes
    bytes32 public dataHash;

    // Dynamic string (no size limit)
    string public name = "Example";

    // Dynamic array (grows at runtime)
    uint256[] public dynamicArray;

    // Fixed-size array
    uint256[5] public fixedArray;

    // Mapping (key-value store)
    mapping(address => uint256) public balances;

    // Struct with dynamic fields
    struct User {
        string name;  // Dynamic
        uint256 age;
        bool active;
    }

    User public userData;
}

Solidity's flexible type system allows for dynamic sizing and various numeric types. Compact takes a stricter approach, requiring compile-time bounds for proof generation.

Compact: Fixed-Size, unsigned types

Compact requires compile-time sizing and primarily uses Field for general numeric operations:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Numeric values - Field type for general numeric operations
export ledger number: Field;

// Specific unsigned integer types
export ledger small_number: Uint<8>;
export ledger medium_number: Uint<16>;
export ledger large_number: Uint<64>;

// Boolean values are available
export ledger flag: Boolean;

// Address type - use Bytes<32>
export ledger user_address: Bytes<32>;

// Fixed-size bytes
export ledger data_hash: Bytes<32>;

// Opaque string type (for dynamic strings)
export ledger name: Opaque<"string">;

constructor() {
    number = 42;
    small_number = 255;
    medium_number = 1000;
    large_number = 1000000;
    flag = true;
    user_address = pad(32, "");
    data_hash = pad(32, "");
    name = "";
}

export circuit set_number(value: Field): [] {
    number = value;
}

export circuit set_flag(new_flag: Boolean): [] {
    flag = new_flag;
}

export circuit set_address(new_address: Bytes<32>): [] {
    user_address = new_address;
}

The contrast between these two approaches is stark. Let's break down what these differences mean for your migration.

Key differences

The chart below visualizes the fundamental type system differences between Solidity's flexible runtime sizing and Compact's fixed compile-time bounds.

Signed integers: Solidity supports both int and uint types. Compact only provides unsigned integers (Uint<8>, Uint<16>, Uint<32>, Uint<64>, Uint<128>, Uint<256>). No negative numbers. The Field type is commonly used for general numeric operations.

Type specification: Solidity infers types from literals (0, 255, true). Compact uses explicit type declarations in ledger fields and relies on type inference in circuit code.

Strings: Solidity allows dynamic string with unlimited length. Compact uses Opaque<"string"> for dynamic strings or fixed-size arrays for bounded strings.

Arrays: Solidity supports both dynamic arrays (uint[]) and fixed-size arrays (uint[5]). Compact primarily uses fixed-size collections with compile-time known bounds.

Mappings: Solidity provides key-value mappings with O(1) access. Compact has no direct mapping equivalent; use alternative data structures like MerkleTrees or Sets.

Structs: Both languages support structured data. Solidity uses struct keyword. Compact uses record types, and all fields must have fixed or opaque sizes.

Now that you understand Compact's strict type requirements, let's examine how these constraints extend to one of the most common programming patterns: loops and iteration.

Pattern 3: Loops and iteration

This section reveals how loop constraints differ between the two languages. You'll understand why Compact requires compile-time bounds on all loops for proof circuit generation, unlike Solidity's dynamic iteration patterns.

Solidity: Dynamic loop bounds

Solidity allows loops with runtime-determined iteration counts:

contract LoopExample {
    uint256[] public numbers;

    // For loop with dynamic bound (array.length)
    function sumArray() public view returns (uint256) {
        uint256 sum = 0;

        // Length determined at runtime
        for (uint256 i = 0; i < numbers.length; i++) {
            sum += numbers[i];
        }

        return sum;
    }

    // While loop with parameter-based bound
    function sumRange(uint256 max) public pure returns (uint256) {
        uint256 sum = 0;
        uint256 i = 0;

        // Max determined at runtime
        while (i < max) {
            sum += i;
            i++;  // Shorthand increment
        }

        return sum;
    }

    // Do-while loop
    function processUntilCondition(uint256 target) public pure returns (uint256) {
        uint256 value = 0;

        do {
            value += 10;
        } while (value < target);

        return value;
    }
}

Solidity's flexibility with loops makes iteration straightforward. Compact's zero-knowledge proof requirements demand a different approach.

Compact: Compile-time bounded loops

Compact requires all loops to have fixed maximum iteration counts known at compile time:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

export ledger sum: Field;
export ledger counter: Counter;

constructor() {
    sum = 0;
}

// Loop with compile-time bound
export circuit sum_range(max: Field): [] {
    let total: Field = 0;

    // Compile-time maximum bound (100) with runtime condition
    for (let i: Field = 0; i < max && i < 100; i = i + 1) {
        total = total + i;
    }

    sum = total;
}

// Counter operations for tracking
export circuit increment_counter(): [] {
    counter.increment(1);
}

export circuit increment_by_literal(): [] {
    // Counter.increment() requires literal integers
    counter.increment(5);  // Literal value
}

These examples reveal fundamental differences in how the two languages handle iteration. Let's examine what this means for your code.

Key differences

The diagram below illustrates how Solidity's dynamic loop bounds differ from Compact's compile-time bounded iteration requirements.

Loop bounds: Solidity permits dynamic bounds like i < array.length or parameter-based limits. Compact requires compile-time constant upper bounds (e.g., i < 100) combined with runtime conditions using && operator.

Increment syntax: Solidity supports shorthand operators i++ and i--. Compact requires explicit assignment: i = i + 1.

Loop types: Solidity supports for, while, and do-while loops. Compact supports for and while loops only. No do-while.

Zero-knowledge requirement: Loop bounds must be compile-time constants in Compact because zero-knowledge proof circuits require fixed, deterministic complexity. The proof system needs to know the maximum circuit size upfront.

Workaround pattern: When logical iteration count varies at runtime, use a compile-time maximum with conditional early exit using &&. The loop always iterates the maximum times for the proof circuit, but can exit early with conditional logic.

Having mastered bounded iteration, you're now ready to explore Compact's most powerful feature: true cryptographic privacy. This pattern reveals how Compact fundamentally differs from Solidity in handling sensitive data.

Pattern 4: State variables (public vs private)

This section uncovers the truth about blockchain privacy. You'll learn why Solidity's "private" keyword doesn't provide real privacy, and how Compact achieves genuine cryptographic privacy through witness functions.

Solidity: Visibility modifiers (all data on-chain)

Solidity uses visibility keywords, but all state exists on-chain regardless:

contract StateExample {
    // Public (auto-generates getter function)
    uint256 public totalSupply;
    address public owner;

    // Private (no auto-getter, but still readable from blockchain)
    // Anyone can read this by directly accessing blockchain state
    uint256 private secretValue;

    // Internal (accessible to derived contracts)
    uint256 internal sharedValue;

    // Constant (compile-time immutable)
    uint256 public constant MAX_SUPPLY = 1000000;

    // Immutable (set once in constructor)
    address public immutable deployer;

    constructor() {
        owner = msg.sender;
        deployer = msg.sender;
        totalSupply = 0;
        secretValue = 12345;  // Still visible on-chain to anyone!
    }

    function updateSecret(uint256 _new) public {
        require(msg.sender == owner, "Not authorized");
        secretValue = _new;  // Written to blockchain, publicly readable
    }
}

Despite Solidity's private keyword, all blockchain state is publicly readable. Compact offers true cryptographic privacy through a completely different mechanism.

Compact: Explicit privacy with witness functions

Compact provides true cryptographic privacy through witness functions that supply off-chain data:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Public ledger state (visible on-chain to everyone)
export ledger total_supply: Field;
export ledger owner: Bytes<32>;
export ledger deployer: Bytes<32>;
export ledger disclosed_secret: Field;

// Witness functions provide private off-chain data
witness get_secret_value(): Field;
witness get_caller(): Bytes<32>;

// Constants
const MAX_SUPPLY: Field = 1000000;

// Constructor with parameters for initialization
constructor(deployer_address: Bytes<32>, initial_supply: Field) {
    owner = deployer_address;
    deployer = deployer_address;
    total_supply = initial_supply;
    disclosed_secret = 0;
}

// Use private data without revealing it
export circuit use_secret_privately(): Field {
    let secret: Field = get_secret_value();
    let result: Field = secret + 100;
    return result;
}

// Selectively disclose private data (explicit opt-in)
export circuit update_secret(): [] {
    let caller: Bytes<32> = get_caller();
    let secret: Field = get_secret_value();
    assert(caller == owner, "Not authorized");
    disclosed_secret = secret;
}

The witness function declarations in the Compact code look simple, but you need to understand how to provide this private data from your TypeScript application.

Witness function implementation (typescript side)

import { WalletBuilder } from "@midnight-ntwrk/wallet";

// When calling circuits, provide witnesses
const witnesses = {
    get_secret_value: async () => {
        // Return private value (never goes on-chain)
        return 42n;  // BigInt value for Field
    },
    get_caller: async () => {
        // Return caller's address privately
        const state = await wallet.state();
        return state.address;
    }
};

// Call circuit with witnesses
const result = await contract.callTx.use_secret_privately(witnesses);

Now you've seen both the Compact circuit code and the TypeScript witness implementation. Let's examine the fundamental privacy differences between these approaches.

Key differences

The comparison below highlights the critical privacy differences between Solidity's publicly readable state and Compact's cryptographically private witness functions.

Privacy model: Solidity's private keyword only affects Solidity-level visibility; anyone can read blockchain state directly using tools like Etherscan. Compact's witness functions provide cryptographically private data that never appears on-chain.

Witness functions: Declared with witness keyword, these functions retrieve private off-chain data. The data participates in zero-knowledge proof generation but remains hidden from the blockchain and all observers.

Selective disclosure: Compact allows explicit disclosure of private data to the public ledger. Without explicit disclosure (storing to a ledger field), witness data remains private forever.

State reading: Solidity generates automatic getters for public variables. Compact circuits can read ledger state directly during execution. External applications query state through the TypeScript runtime SDK via the indexer.

Constants: Both languages support constants. Solidity uses constant and immutable keywords. Compact uses const for compile-time constants.

You've learned how Compact provides genuine privacy through witness functions. Next, let's address a common challenge developers face when migrating: how to track and monitor state changes without Solidity's event system.

Pattern 5: Events and logging

This section demonstrates how to track state changes without Solidity's event system. You'll learn Compact's alternative approach using ledger counters and return values for observable state transitions.

Solidity: Event declaration and emission

Solidity provides an explicit event system for off-chain logging:

contract EventExample {
    // Event declarations with indexed parameters
    event Transfer(address indexed from, address indexed to, uint256 amount);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    event StateChanged(uint256 indexed oldValue, uint256 indexed newValue);

    uint256 public value;
    address public owner;

    constructor() {
        owner = msg.sender;
        value = 0;
        // Emit event in constructor
        emit StateChanged(0, 0);
    }

    function updateValue(uint256 newValue) public {
        require(msg.sender == owner, "Not authorized");

        uint256 oldValue = value;
        value = newValue;

        // Explicitly emit event for off-chain tracking
        emit StateChanged(oldValue, newValue);
    }

    function transfer(address to, uint256 amount) public {
        // Transfer logic...

        // Event includes indexed and non-indexed data
        emit Transfer(msg.sender, to, amount);
    }
}

Solidity's dedicated event system makes off-chain tracking straightforward. Compact achieves similar observability through a different pattern.

Compact: Ledger state changes and return values

Compact has no event system; observable changes occur through ledger updates and circuit return values:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

export ledger value: Field;
export ledger owner: Bytes<32>;

// Counter fields for tracking changes (observable on ledger)
export ledger update_count: Counter;
export ledger transfer_count: Counter;

witness get_caller(): Bytes<32>;

constructor(initial_owner: Bytes<32>) {
    owner = initial_owner;
    value = 0;
}

// State changes are observable via ledger updates
export circuit update_value(new_value: Field): Field {
    let old_value: Field = value;  // Read current state
    value = new_value;              // Update state (observable)
    update_count.increment(1);      // Track change count

    // Return value provides event-like data
    return old_value;
}

export circuit transfer(to: Bytes<32>, amount: Field): [] {
    let from: Bytes<32> = get_caller();

    // Transfer logic...

    // Increment counter (observable on ledger)
    transfer_count.increment(1);
}

The ledger counters and return values provide observable data, but you need to know how to monitor these changes in your application.

Monitoring state changes (typescript side)

// TypeScript code for monitoring changes (not in .compact file)
import { indexerPublicDataProvider } from "@midnight-ntwrk/midnight-js-indexer-public-data-provider";

// Subscribe to contract state changes
const subscription = publicDataProvider
    .subscribeToContractState(contractAddress)
    .subscribe(async (state) => {
        if (state) {
            const ledger = ContractModule.ledger(state.data);

            // Monitor ledger changes
            console.log(`Value: ${ledger.value}`);
            console.log(`Update count: ${ledger.update_count}`);
            console.log(`Transfer count: ${ledger.transfer_count}`);

            // Build event-like timeline from state changes
        }
    });

With both patterns demonstrated, let's compare how each language handles state change tracking.

Key differences

The visualization below demonstrates how Compact's ledger-based state tracking replaces Solidity's dedicated event emission system.

Event system: Solidity has dedicated event keyword and emit statement for logging. Compact has no event system; changes are tracked through ledger state updates, counter increments, and circuit return values.

Indexing: Solidity allows indexed parameters for efficient event filtering via logs. Compact applications must monitor ledger state changes via the indexer GraphQL API and filter off-chain.

Observability: Solidity explicitly emits events with emit EventName(params). Compact circuit return values and ledger updates serve as observable outputs. Applications monitor these changes through the indexer.

Off-chain tracking: Solidity events are specifically designed for off-chain indexing with bloom filters and log queries. Compact applications monitor ledger state through the Midnight indexer and build event-like timelines from state changes.

Privacy: Solidity events are always public and visible to everyone. Compact can selectively reveal information by choosing what to return from circuits or update in the ledger, keeping witness data private.

Pattern recommendation: To track state changes in Compact, maintain counter fields on the ledger (like update_count) and return relevant data from circuits. Off-chain applications query the indexer to build event-like timelines from state transitions.

With state monitoring strategies in place, let's turn our attention to a critical aspect of smart contract security: access control.

Pattern 6: Access control and modifiers

This section compares authorization patterns between the languages. You'll discover that Solidity's modifier syntax has no equivalent in Compact; instead, you use explicit helper circuit calls for authorization checks.

Solidity: Function modifiers

Solidity uses modifiers to inject reusable authorization logic:

contract AccessControl {
    address public owner;
    mapping(address => bool) public admins;

    // Modifier for owner-only functions
    modifier onlyOwner() {
        require(msg.sender == owner, "Caller is not owner");
        _;  // Placeholder where function body executes
    }

    // Modifier for admin-only functions
    modifier onlyAdmin() {
        require(admins[msg.sender], "Caller is not admin");
        _;
    }

    // Modifier with parameters
    modifier hasMinBalance(uint256 minAmount) {
        require(address(this).balance >= minAmount, "Insufficient balance");
        _;
    }

    // Modifier for input validation
    modifier validAddress(address _addr) {
        require(_addr != address(0), "Invalid address");
        _;
    }

    constructor() {
        owner = msg.sender;
        admins[msg.sender] = true;
    }

    // Using modifiers (automatic injection before function)
    function transferOwnership(address newOwner) 
        public 
        onlyOwner           // Check 1: caller is owner
        validAddress(newOwner)  // Check 2: address is valid
    {
        owner = newOwner;
    }

    function addAdmin(address newAdmin) 
        public 
        onlyOwner 
        validAddress(newAdmin) 
    {
        admins[newAdmin] = true;
    }

    function adminAction() public onlyAdmin {
        // Admin-only logic
    }
}

Solidity's modifier syntax provides elegant code reuse for authorization. Compact achieves the same security with a more explicit pattern.

Compact: Helper functions and assertions

Compact has no modifier syntax; use helper functions with assert statements:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

export ledger owner: Bytes<32>;
export ledger admin_count: Counter;

witness get_caller(): Bytes<32>;

constructor(initial_owner: Bytes<32>) {
    owner = initial_owner;
}

// Helper function (replaces onlyOwner modifier)
// Call this at the start of circuits requiring owner access
circuit require_owner(caller: Bytes<32>): [] {
    assert(caller == owner, "Caller is not owner");
    // If assertion fails, circuit execution aborts
    // Transaction is never submitted to blockchain
}

// Helper function with parameters (replaces validAddress modifier)
circuit require_non_zero_address(addr: Bytes<32>): [] {
    const ZERO: Bytes<32> = pad(32, "");
    assert(addr != ZERO, "Invalid address");
}

// Using helper functions (manual calls replace modifiers)
export circuit transfer_ownership(new_owner: Bytes<32>): [] {
    let caller: Bytes<32> = get_caller();

    // Manually apply checks (like modifiers would)
    require_owner(caller);                    // Check 1
    require_non_zero_address(new_owner);      // Check 2

    // Function logic executes only if all checks pass
    owner = new_owner;
}

export circuit add_admin(): [] {
    let caller: Bytes<32> = get_caller();

    // Manual authorization checks
    require_owner(caller);

    // Simplified admin addition (just tracks count)
    admin_count.increment(1);
}

export circuit admin_action(): [] {
    let caller: Bytes<32> = get_caller();

    // Check owner status
    require_owner(caller);

    // Admin-only logic here
}

Both approaches secure your functions, but Compact has no modifier equivalent. All authorization checks must be done explicitly through helper circuit calls.

Key differences

The diagram below compares Solidity's automatic modifier injection with Compact's explicit helper function approach for authorization.

Syntax: Solidity has dedicated modifier keyword with _ placeholder for automatic function body injection. Compact has no equivalent to modifiers; use explicit helper circuit calls at the start of circuits instead.

Reusability: Solidity modifiers automatically inject code before function execution with clean syntax. Compact has no modifier equivalent; you must manually call helper circuits in each circuit that needs authorization, giving explicit control but requiring more verbose code.

Execution order: Solidity modifiers execute in the order listed in function declaration. Compact has no modifiers; helper circuits execute in the exact order you call them, providing explicit control flow.

Caller context: Solidity provides msg.sender automatically in all functions. Compact requires witness functions like get_caller() to retrieve the caller's address.

Authorization logic: Solidity uses require() for authorization checks that revert on failure. Compact uses assert() (similar to Solidity's require) which aborts circuit execution if the condition fails, preventing the transaction from being submitted.

Authorization privacy: Solidity authorization checks are publicly visible in transaction data. Compact can verify authorization privately through witness proofs without revealing the caller on-chain (unless explicitly disclosed to ledger state).

Pattern recommendation: Create a library of reusable helper circuits for common authorization checks (owner, admin, balance, etc.) and call them consistently at the start of circuits requiring access control.

Having established secure access control patterns, let's examine how Compact handles function visibility and scope.

Pattern 7: Function visibility

This section clarifies how function visibility works in each language. You'll learn how Compact's simple export model replaces Solidity's four-level visibility system.

Solidity: Visibility modifiers

Solidity provides four visibility levels and state access modifiers:

contract VisibilityExample {
    uint256 private internalState;

    // Public: callable externally and internally
    function publicFunction() public view returns (uint256) {
        return internalState;
    }

    // External: only callable from outside (more gas efficient)
    function externalFunction(uint256 value) external {
        internalState = value;
    }

    // Internal: callable within contract and derived contracts
    function internalFunction() internal view returns (uint256) {
        return internalState * 2;
    }

    // Private: only callable within this contract
    function privateFunction() private pure returns (uint256) {
        return 42;
    }

    // Pure: doesn't read or modify state
    function pureMath(uint256 a, uint256 b) public pure returns (uint256) {
        return a + b;
    }

    // View: reads but doesn't modify state
    function viewState() public view returns (uint256) {
        return internalState;
    }

    // Payable: can receive Ether
    function deposit() public payable {
        internalState += msg.value;
    }
}

// Inheritance example
contract DerivedExample is VisibilityExample {
    function callInternal() public view returns (uint256) {
        // Can call internal function from parent
        return internalFunction();
    }

    // Cannot call privateFunction() from parent
}

Solidity offers four distinct visibility levels with specific gas and inheritance implications. Compact simplifies this with a binary exported/non-exported model.

Compact: Export keyword and circuit Scope

Compact uses export for public circuits; non-exported functions are internal:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

export ledger internal_state: Field;

constructor() {
    internal_state = 0;
}

// Exported circuit: callable from outside
// Like Solidity's public/external
export circuit public_function(): Field {
    return internal_state;
}

// Exported circuit with state modification
export circuit external_function(value: Field): [] {
    internal_state = value;
}

// Non-exported function: internal to this file only
// Like Solidity's internal/private (no inheritance distinction)
circuit internal_helper(): Field {
    return internal_state * 2;
}

// Non-exported helper (private to file)
circuit private_helper(): Field {
    return 42;
}

// Pure computation (no state access)
// Like Solidity's pure functions
circuit pure_math(a: Field, b: Field): Field {
    return a + b;
}

// Exported circuit using helpers
export circuit complex_calculation(): Field {
    let internal_result: Field = internal_helper();
    let private_result: Field = private_helper();

    // Non-exported functions can be called within file
    return pure_math(internal_result, private_result);
}

// Circuit with state modification and return value
// No explicit "view" or "pure" keyword
export circuit update_and_return(new_value: Field): Field {
    let old_value: Field = internal_state;
    internal_state = new_value;
    return old_value;
}

The visibility systems reveal different design philosophies. Here's what you need to know for migration.

Key differences

The chart below maps Solidity's four-level visibility system to Compact's simplified export-based model.

Visibility keywords: Solidity has public, external, internal, private. Compact has export for public circuits; non-exported functions are internal to the file.

External vs public: Solidity distinguishes external (more gas-efficient, calldata) from public (can call internally, memory). Compact treats all exported circuits similarly without optimization difference.

State access modifiers: Solidity has view (read-only) and pure (no state access). Compact has no explicit modifiers; circuits can both read and modify state directly. External applications also read state via TypeScript runtime SDK.

Inheritance: Solidity supports full inheritance with internal functions accessible to derived contracts and private functions not accessible. Compact has no inheritance model; use composition by importing circuits from other files.

Payable functions: Solidity uses payable for functions that receive Ether. Compact has no native token handling within circuits; token operations are managed at the protocol level by the Midnight runtime.

Understanding function visibility prepares you for the next essential pattern: contract initialization.

Pattern 8: Contract initialization (constructors)

This section explains contract initialization patterns in both languages. You'll understand how Compact's constructor works similarly to Solidity's but requires explicit parameter passing for context.

Solidity: Constructor pattern

Solidity uses the constructor keyword for one-time initialization:

// Simple constructor with automatic context
contract SimpleConstructor {
    address public owner;
    uint256 public createdAt;

    constructor() {
        owner = msg.sender;          // Automatic
        createdAt = block.timestamp;  // Automatic
    }
}

// Constructor with parameters
contract ParameterizedConstructor {
    string public name;
    uint256 public totalSupply;
    address public admin;

    constructor(string memory _name, uint256 _supply) {
        name = _name;
        totalSupply = _supply;
        admin = msg.sender;  // Still automatic
    }
}

// Constructor with validation
contract ValidatedConstructor {
    address public owner;
    uint256 public initialSupply;

    uint256 public constant MAX_SUPPLY = 1000000;

    constructor(uint256 _supply) {
        // Validation with require
        require(_supply > 0, "Supply must be positive");
        require(_supply <= MAX_SUPPLY, "Supply exceeds maximum");

        owner = msg.sender;
        initialSupply = _supply;
    }
}

// Immutable variables (set once in constructor)
contract ImmutableExample {
    address public immutable deployer;
    uint256 public immutable deployTime;

    constructor() {
        deployer = msg.sender;
        deployTime = block.timestamp;
    }
}

Solidity's constructor has special syntax and automatic context variables. Compact treats constructors similarly but requires explicit parameters.

Compact: Constructor circuit

Compact uses a constructor that works similarly to Solidity, accepting parameters directly:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Simple constructor with parameters
export ledger owner: Bytes<32>;
export ledger created_at: Field;
export ledger total_supply: Field;

const MAX_SUPPLY: Field = 1000000;

constructor(
    initial_owner: Bytes<32>,
    timestamp: Field,
    supply: Field
) {
    // Validation using assert
    assert(supply > 0, "Supply must be positive");
    assert(supply <= MAX_SUPPLY, "Supply exceeds maximum");

    // Address validation
    const ZERO_BYTES: Bytes<32> = pad(32, "");
    assert(initial_owner != ZERO_BYTES, "Invalid owner");

    // Initialize state
    owner = initial_owner;
    created_at = timestamp;
    total_supply = supply;
}

// State-modifying circuits work with initialized state
export circuit update_supply(additional: Field): [] {
    assert(total_supply + additional <= MAX_SUPPLY, "Exceeds max supply");
    total_supply = total_supply + additional;
}

// Immutable fields (set once in constructor, never changed)
export ledger deployer: Bytes<32>; 
export ledger deploy_time: Field;

constructor(deployer_address: Bytes<32>, timestamp: Field) {
    deployer = deployer_address;
    deploy_time = timestamp;
    // Application logic should prevent further changes to these fields
}

The constructor looks straightforward, but you need to understand how to call it correctly during deployment.

Constructor call in deployment script

// TypeScript deployment code
import { deployContract } from "@midnight-ntwrk/midnight-js-contracts";

// Get wallet state for address
const state = await wallet.state();

// Deploy with constructor parameters
const deployed = await deployContract(providers, {
    contract: contractInstance,
    // Pass constructor arguments directly
    initialState: {
        initial_owner: state.address,
        timestamp: BigInt(Date.now()),
        supply: 1000000n
    },
    privateStateId: "contractState",
    initialPrivateState: {}
});

console.log(`Deployed: ${deployed.deployTxData.public.contractAddress}`);

Now that you've seen both the contract code and deployment script, let's examine the key differences in initialization patterns.

Key differences

The illustration below shows how constructor patterns differ between Solidity's special syntax and Compact's regular circuit approach.

Constructor pattern: Both Solidity and Compact use constructors that accept parameters directly. The syntax and initialization approach are similar.

Caller Context: Solidity provides msg.sender and block.timestamp automatically in constructors. Compact requires these values as explicit constructor parameters, passed from the deployment script.

Validation: Solidity uses require() for constructor validation that reverts deployment if failed. Compact uses assert(), which aborts circuit execution if validation fails.

Inheritance: Solidity constructors can call parent constructors with special syntax. Compact has no inheritance; cannot chain constructor calls. Use composition patterns instead.

Immutability: Solidity uses immutable keyword for values set once in constructor. Compact has no built-in immutability enforcement for ledger fields; implement "set-once" patterns in your application logic if needed.

With initialization patterns covered, let's address a critical aspect of robust smart contract development: input validation and error handling.

Pattern 9: Input validation and error handling

This section compares validation mechanisms between the languages. You'll learn why Compact uses only assert() statements that prevent proof generation.

Solidity: Require, revert, and assert

Solidity provides three mechanisms for validation and error handling:

contract ValidationExample {
    address public owner;
    uint256 public balance;

    constructor() {
        owner = msg.sender;
    }

    // Using require for input validation (common pattern)
    function deposit(uint256 amount) public {
        require(amount > 0, "Amount must be positive");
        require(amount <= 1000000, "Amount exceeds maximum");

        balance += amount;
        // If requires fail, transaction reverts and gas refunded
    }

    // Multiple require statements
    function withdraw(uint256 amount) public {
        require(msg.sender == owner, "Not authorized");
        require(amount > 0, "Invalid amount");
        require(balance >= amount, "Insufficient balance");

        balance -= amount;
        // State changes only persist if all requires pass
    }

    // Using revert for complex conditions
    function complexValidation(address user, uint256 value) public {
        if (user == address(0)) {
            revert("Invalid user address");
        }

        if (value < 100 || value > 10000) {
            revert("Value out of range");
        }

        // Process transaction only if validations pass
    }

    // Assert for invariants (should never fail in correct code)
    function criticalOperation(uint256 a, uint256 b) public pure returns (uint256) {
        uint256 result = a + b;
        assert(result >= a);  // Check overflow
        return result;
    }
}

The diagram below illustrates Solidity's three validation mechanisms (require, revert, assert) and their different behaviors.

Solidity provides three validation mechanisms with different behaviors. Compact simplifies this to a single assertion pattern.

Compact: Assert statements only

Compact uses assert() statements that abort circuit execution when validation fails:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

export ledger owner: Bytes<32>;
export ledger balance: Field;

witness get_caller(): Bytes<32>;

constructor(initial_owner: Bytes<32>) {
    owner = initial_owner;
    balance = 0;
}

// Using assert for input validation
export circuit deposit(amount: Field): [] {
    assert(amount > 0, "Amount must be positive");
    assert(amount <= 1000000, "Amount exceeds maximum");

    balance = balance + amount;
    // If assertions fail, circuit execution aborts
}

// Multiple assert statements
export circuit withdraw(amount: Field): [] {
    let caller: Bytes<32> = get_caller();

    assert(caller == owner, "Not authorized");
    assert(amount > 0, "Invalid amount");
    assert(balance >= amount, "Insufficient balance");

    balance = balance - amount;
    // State changes only persist if all assertions pass
}

// Complex validation with conditional logic
export circuit complex_validation(user: Bytes<32>, value: Field): [] {
    const ZERO: Bytes<32> = pad(32, "");
    assert(user != ZERO, "Invalid user address");

    assert(value >= 100 && value <= 10000, "Value out of range");

    // Process transaction only if validations pass
}

// Return status codes for recoverable errors
// (alternative pattern when you don't want to abort)
export circuit withdraw_with_status(amount: Field): Field {
    let caller: Bytes<32> = get_caller();

    // Check conditions and return status codes
    if (caller != owner) {
        return 1;  // Error code: unauthorized
    }

    if (balance < amount) {
        return 2;  // Error code: insufficient balance
    }

    balance = balance - amount;
    return 0;  // Success code
}

// Compact has no try-catch
// Design with status codes or boolean returns for error cases
export circuit safe_operation(): Boolean {
    // Return true for success, false for failure
    // instead of throwing errors

    // Perform operation
    return true;  // Success
}

The visualization below demonstrates how Compact's single assert mechanism prevents proof generation when validation fails.

The single assertion mechanism requires a different approach to error handling. Here are the critical differences.

Key differences

Validation mechanism: Solidity has require(), revert(), and assert() with different gas behaviors and use cases. Compact only has assert() for validation.

Error handling: Solidity's failed validations revert transactions and return error messages to callers. Compact's failed assertions abort circuit execution, preventing the transaction from being created and submitted to the blockchain.

Transaction costs: Solidity failed validations consume gas up to the failure point, then refund remaining. Compact failed assertions prevent transaction submission entirely, so no on-chain cost occurs for validation failures.

Error messages: Solidity error messages are returned to callers and visible on explorers. Compact error messages are for developers during testing; assertions either pass or fail without revealing error details on-chain.

Recovery: Solidity exceptions can be caught with try-catch for error recovery patterns. Compact has no exception handling; design with status codes or boolean returns for scenarios where you want to handle failures gracefully.

Best practice: Use assert() for critical validations that must never fail in correct usage (invariants, authorization). For recoverable errors (like insufficient balance), return status codes or boolean success flags instead of asserting, allowing applications to handle errors gracefully.

You've now mastered nine fundamental patterns that have direct Solidity equivalents. For our final pattern, we'll explore Compact's unique privacy features.

Pattern 10: Privacy-specific features (compact-only)

This section showcases Compact's unique privacy capabilities that have no Solidity equivalent. You'll explore zero-knowledge proof patterns that enable genuinely private computation.

The diagram below illustrates the zero-knowledge proof flow that enables Compact's privacy features, showing how witness data participates in proof generation without appearing on-chain.

Important note: The examples in this pattern demonstrate privacy concepts. Specific cryptographic functions may vary based on the CompactStandardLibrary version. Always refer to the official Compact documentation for exact API details.

Private state with witness functions

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Public ledger (visible on-chain to everyone)
export ledger public_counter: Field;
export ledger disclosed_value: Field;
export ledger computation_result: Field;

// Witness functions (private off-chain data)
// These provide private inputs that never appear on-chain
witness get_secret_value(): Field;

constructor() {
    public_counter = 0;
    disclosed_value = 0;
    computation_result = 0;
}

// Example 1: Private computation with public result
export circuit compute_privately(): [] {
    // get_secret_value() retrieves private input
    let secret: Field = get_secret_value();  // Private

    // Compute with private data
    // The computation happens in the proof, but secret never goes on-chain
    let result: Field = secret * 2 + 100;

    // Store result publicly (secret remains hidden)
    computation_result = result;
}

// Example 2: Selective disclosure
export circuit reveal_secret(): [] {
    let secret: Field = get_secret_value();  // Private

    // Explicitly choose to disclose private data
    // This is the only way to make witness data public
    disclosed_value = secret;
    public_counter = public_counter + 1;
}

These examples showcase powerful privacy patterns. Let's summarize the key concepts that make them possible.

Key privacy concepts

Witness functions: Declared with witness keyword, these provide private off-chain data that participates in zero-knowledge proof generation but never appears on-chain. The blockchain only sees the proof, not the data.

Selective disclosure: Private data remains hidden unless explicitly written to a ledger field. You control what becomes public and what stays private, enabling granular privacy controls.

Commitments and Merkle Trees: Compact provides MerkleTree and HistoricMerkleTree types for storing commitments to private data. These allow proving membership without revealing which specific item is being proven.

Privacy patterns:

Prove properties without revealing data: Prove you're over 18 without showing birthdate
Commit to values without disclosure: Sealed-bid auctions where bids are hidden until reveal phase
Selective disclosure timing: Keep data private during sensitive periods, reveal later
Anonymous actions: Private operations where identity stays hidden

No Solidity equivalent: These patterns are impossible in Solidity because all transaction data, inputs, and state changes are public and visible on-chain. Compact's zero-knowledge proof architecture enables genuinely private computation where only the proof of correct execution is public.

Zero-knowledge proofs: When a circuit executes, it generates a zero-knowledge proof that proves "I executed this code correctly with some private inputs" without revealing what those inputs were. The blockchain verifies the proof but never sees the private data.

Key conceptual differences

This section moves beyond syntax to explore the architectural differences that drive language design choices.

Privacy model

Solidity: Everything is public by default. The private keyword only affects Solidity-level visibility; anyone can read blockchain state directly using block explorers or archive nodes.

Compact: Explicit public/private separation. Ledger state is public and visible to everyone. Witness functions provide truly private data through zero-knowledge proofs that cryptographically guarantee privacy.

The comparison below visualizes how Solidity's transparent-by-default model differs fundamentally from Compact's explicit public/private separation.

Execution model

Solidity: Code executes directly on-chain in the Ethereum Virtual Machine. Every node re-executes transactions. Gas costs are proportional to computational complexity.

Compact: Code compiles to zero-knowledge circuits. Proofs generate off-chain using private data. Only the proof is submitted on-chain. On-chain validation has constant cost regardless of computation complexity.

The diagram below illustrates the architectural difference between Solidity's on-chain execution and Compact's off-chain proof generation with on-chain verification.

State management

Solidity: State variables declared inside contracts. Functions directly read and write state using simple assignment and access.

Compact: Ledger state declared globally with export ledger. Circuits can both read and modify state through direct assignments. External applications query state via TypeScript runtime SDK using the indexer.

Data constraints

Solidity: Supports dynamic arrays that grow at runtime, unbounded loops based on array length, runtime-sized strings, and signed integers for negative numbers.

Compact: Requires compile-time bounds on most data structures. Only unsigned integers supported (no negative numbers). All sizes must be known at compile time for proof circuit generation. Uses Opaque<"string"> for dynamic strings.

The chart below summarizes the fundamental data constraint differences between Solidity's dynamic runtime flexibility and Compact's fixed compile-time requirements.

Caller context

Solidity: msg.sender automatically provides transaction sender. block.timestamp, block.number, msg.value etc. automatically available in all functions.

Compact: Caller address retrieved via witness functions for privacy. Block data passed as circuit parameters from deployment/interaction scripts. Nothing is automatic; everything is explicit.

Migration mindset

When migrating from Solidity to Compact, shift your thinking:

From transparent to privacy-first: Default to keeping data private, explicitly disclose only when necessary.
From dynamic to bounded: Determine maximum sizes for data structures upfront, or use Opaque types for dynamic data.
From runtime to compile-time: Most constraints must be expressible at compile time for circuit generation.
From automatic to explicit: Explicitly handle caller context, timestamps, and authorization.
From gas optimization to proof optimization: Minimize proof complexity rather than gas costs.

Common pitfalls and solutions

This section identifies the seven most common mistakes developers make during migration. You'll learn practical solutions to avoid these pitfalls and accelerate your Compact development.

The diagram below highlights the six most common migration pitfalls developers encounter when converting Solidity contracts to Compact.

Pitfall 1: Incorrect return type syntax

Wrong:

export circuit increment(): Void {  // Outdated syntax
    counter.increment(1);
}

Correct:

export circuit increment(): [] {  // Modern syntax
    counter.increment(1);
}

Solution: Use [] (empty tuple) for circuits that don't return values. This is the modern Compact syntax.

Pitfall 2: Using dynamic sizes without Opaque

Wrong:

export ledger name: String;  // No size specified

Correct:

export ledger name: Opaque<"string">;  // Dynamic string using Opaque
// OR
export ledger name: Bytes<100>;  // Fixed maximum size

Solution: Use Opaque<"string"> for dynamic strings or specify fixed sizes with Bytes<N>.

Pitfall 3: Unbounded loops

Wrong:

export circuit process_all(count: Field): [] {
    for (let i: Field = 0; i < count; i = i + 1) {
        // Loop bound depends on runtime parameter
    }
}

Correct:

export circuit process_all(count: Field): [] {
    // Add compile-time maximum bound
    for (let i: Field = 0; i < count && i < 1000; i = i + 1) {
        // Now compiler knows maximum 1000 iterations
    }
}

Solution: Always add compile-time upper bounds to loops using && operator.

Pitfall 4: Forgetting CompactStandardLibrary import

Wrong:

pragma language_version >= 0.18.0;
// Missing import
export ledger value: Field;

Correct:

pragma language_version >= 0.18.0;
import CompactStandardLibrary;  // Required
export ledger value: Field;

Solution: Always include import CompactStandardLibrary; after the pragma.

Pitfall 5: Using signed integers

Wrong:

export ledger temperature: Int32;  // No signed types

Correct:

export ledger temperature: Field;  // Use Field for general numeric values
// Handle negative logic differently using conditional checks

Solution: Compact only has unsigned integers and Field. Redesign logic to avoid negative numbers.

Pitfall 6: Expecting automatic msg.sender

Wrong:

export circuit restricted_action(): [] {
    assert(msg.sender == owner, "Not authorized");  // Doesn't exist
}

Correct:

witness get_caller(): Bytes<32>;

export circuit restricted_action(): [] {
    let caller: Bytes<32> = get_caller();  // Explicit witness
    assert(caller == owner, "Not authorized");
}

Solution: Use witness functions to get caller address. Provide the address from TypeScript when calling the circuit.

Pitfall 7: Using disclose() incorrectly

Wrong (for regular types):

export circuit update_value(new_value: Field): [] {
    stored_value = disclose(new_value);  // Not needed for regular types
}

Correct (for regular types):

export circuit update_value(new_value: Field): [] {
    stored_value = new_value;  // Direct assignment
}

Correct (for Opaque types):

export circuit store_message(msg: Opaque<"string">): [] {
    message = disclose(msg);  // Required for Opaque types
}

Solution: Regular types (Field, Bytes, Boolean, Uint) can be assigned directly to ledger fields. Opaque types like Opaque<"string"> require disclose() to make the data public on the ledger, as Compact treats user inputs as private by default.

Complete migration Example

Let's migrate a simple ERC20-like token contract from Solidity to Compact, applying all the patterns you've learned.

Solidity token contract

The diagram below provides a visual overview of the Solidity ERC20-like token contract structure before migration.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SimpleToken {
    string public name = "SimpleToken";
    string public symbol = "STK";
    uint256 public totalSupply;
    address public owner;

    mapping(address => uint256) public balances;

    event Transfer(address indexed from, address indexed to, uint256 amount);
    event Mint(address indexed to, uint256 amount);

    constructor(uint256 _initialSupply) {
        owner = msg.sender;
        totalSupply = _initialSupply;
        balances[owner] = _initialSupply;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "Not owner");
        _;
    }

    function transfer(address to, uint256 amount) public returns (bool) {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        require(to != address(0), "Invalid recipient");

        balances[msg.sender] -= amount;
        balances[to] += amount;

        emit Transfer(msg.sender, to, amount);
        return true;
    }

    function mint(address to, uint256 amount) public onlyOwner {
        require(to != address(0), "Invalid recipient");

        totalSupply += amount;
        balances[to] += amount;

        emit Mint(to, amount);
    }

    function balanceOf(address account) public view returns (uint256) {
        return balances[account];
    }
}

This standard ERC20-like contract uses familiar Solidity patterns. Now let's see the Compact equivalent.

Compact token contract

The visualization below shows the migrated Compact token contract structure with ledger state, circuits, and witness functions.

pragma language_version >= 0.18.0;
import CompactStandardLibrary;

// Public ledger state
export ledger total_supply: Field;
export ledger owner: Bytes<32>;
export ledger owner_balance: Field;
export ledger transfer_count: Counter;
export ledger mint_count: Counter;

witness get_caller(): Bytes<32>;

constructor(initial_supply: Field, owner_address: Bytes<32>) {
    total_supply = initial_supply;
    owner = owner_address;
    owner_balance = initial_supply;
}

// Helper function (replaces onlyOwner modifier)
circuit require_owner(caller: Bytes<32>): [] {
    assert(caller == owner, "Not owner");
}

// Helper function for address validation
circuit require_valid_address(addr: Bytes<32>): [] {
    const ZERO: Bytes<32> = pad(32, "");
    assert(addr != ZERO, "Invalid recipient");
}

// Transfer circuit
export circuit transfer(to: Bytes<32>, amount: Field): [] {
    let caller: Bytes<32> = get_caller();

    // Validation
    require_valid_address(to);
    assert(owner_balance >= amount, "Insufficient balance");

    // Update balances (simplified - only tracks owner balance)
    owner_balance = owner_balance - amount;

    // Increment counter (replaces event)
    transfer_count.increment(1);
}

// Mint circuit
export circuit mint(amount: Field): [] {
    let caller: Bytes<32> = get_caller();

    // Authorization and validation
    require_owner(caller);

    // Update state
    total_supply = total_supply + amount;
    owner_balance = owner_balance + amount;

    // Increment counter (replaces event)
    mint_count.increment(1);
}

// Read balance through circuit
export circuit get_balance(): Field {
    return owner_balance;
}

Typescript deployment script

import { deployContract } from "@midnight-ntwrk/midnight-js-contracts";
import { WalletBuilder } from "@midnight-ntwrk/wallet";

// Build wallet
const wallet = await WalletBuilder.buildFromSeed(
    indexerUrl,
    indexerWsUrl,
    proofServerUrl,
    nodeUrl,
    walletSeed,
    networkId,
    "info"
);

wallet.start();

// Wait for sync
await firstValueFrom(
    wallet.state().pipe(filter(s => s.syncProgress?.synced === true))
);

// Get wallet address
const state = await firstValueFrom(wallet.state());

// Deploy contract
const deployed = await deployContract(providers, {
    contract: contractInstance,
    privateStateId: "tokenState",
    initialPrivateState: {},
    initialState: {
        initial_supply: 1000000n,
        owner_address: state.address
    }
});

console.log(`Deployed: ${deployed.deployTxData.public.contractAddress}`);

Typescript interaction script

import { findDeployedContract } from "@midnight-ntwrk/midnight-js-contracts";
import { indexerPublicDataProvider } from "@midnight-ntwrk/midnight-js-indexer-public-data-provider";

// Connect to deployed contract
const deployed = await findDeployedContract(providers, {
    contractAddress: deploymentAddress,
    contract: contractInstance,
    privateStateId: "tokenState",
    initialPrivateState: {}
});

// Read balance
const state = await publicDataProvider.queryContractState(contractAddress);
if (state) {
    const ledger = TokenModule.ledger(state.data);
    console.log(`Owner balance: ${ledger.owner_balance}`);
    console.log(`Total supply: ${ledger.total_supply}`);
}

// Call transfer
const witnesses = {
    get_caller: async () => walletState.address
};

const tx = await deployed.callTx.transfer(
    recipientAddress,
    100n,
    witnesses
);

console.log(`Transfer completed: ${tx.public.txId}`);

// Call mint (owner only)
const mintTx = await deployed.callTx.mint(
    500n,
    { get_caller: async () => walletState.address }
);

console.log(`Minted: ${mintTx.public.txId}`);

The diagram below summarizes the eight critical migration decisions made during the ERC20 conversion from Solidity to Compact.

You've now seen the complete migration including contract code, deployment, and interaction. Let's highlight the critical migration decisions.

Key migration points

No mapping: Compact has no mapping type. This example uses simplified single-balance tracking. Production code needs alternative patterns like MerkleTrees for managing multiple balances.
No events: Use counters on the ledger and return values. Applications monitor state changes via indexer.
Explicit context: No msg.sender. Use witness functions to provide caller address.
Constructor parameters: Compact constructors accept parameters directly, similar to Solidity.
Return types: Use [] for circuits with no return value (modern Compact syntax).
Balance reading: Circuits can read state directly. External applications also read state via TypeScript using indexer queries.
Modifiers: Use helper circuits with assert() instead of modifiers, called explicitly.
Witness providers: TypeScript provides witness data when calling circuits.
Validation: Use assert() for validation. Failed assertions abort circuit execution.
State access: Circuits can read and write ledger state directly during execution.

When to use each language

This section provides strategic guidance for choosing the right language for your project. You'll learn when Compact's privacy features are essential, when Solidity's mature ecosystem is better, and when a hybrid approach makes sense.

Understanding the strengths of each language helps you choose appropriately.

Let's start by examining scenarios where Compact's privacy features make it the superior choice.

Choose compact when

Privacy is essential: Applications requiring confidential data processing, private transactions, or selective information disclosure.

Use cases:

Healthcare records with HIPAA compliance requirements
Confidential voting systems
Private financial transactions
Sealed-bid auctions where bid amounts must stay hidden
Identity verification without revealing personal information
KYC compliance with data protection regulations
Private supply chain tracking
Confidential credit scoring

Regulatory compliance: Industries with strict data privacy regulations that prohibit public data storage or require selective disclosure controls.

Selective disclosure: Scenarios requiring proof of properties without revealing underlying data.

The chart below illustrates use cases where Compact's privacy features provide essential value that Solidity cannot match.

Choose solidity when

Full transparency required: Applications benefiting from complete auditability and public verification where privacy is not needed.

Use cases:

Public treasuries and transparent fund management
Open governance systems and DAO voting
Transparent token distributions
Decentralized exchanges with public order books
Community-funded projects requiring full accountability
Public records and registries

Complex DeFi composability: Applications requiring integration with existing Ethereum protocols.

Dynamic structures essential: Applications needing runtime-determined data structures or signed integers.

Mature ecosystem critical: Projects requiring extensive battle-tested libraries and established auditing processes.

The visualization below shows scenarios where Solidity's transparency and mature ecosystem make it the superior choice.

Hybrid approach

Consider using both languages in a single application architecture:

Pattern: Use Solidity for public coordination and Compact for private operations, connected via cross-chain bridges.

Example: Private NFT marketplace

Solidity contracts manage public NFT ownership records
Compact contracts handle private bid amounts and confidential buyer identities
Public can verify ownership, but bid details stay private

The diagram below demonstrates how hybrid architectures can combine Solidity's public coordination with Compact's private operations for optimal results.

Additional resources

Conclusion

Your Solidity expertise provides a strong foundation for Compact development. The core concepts of state management, transactions, and contract logic transfer directly. What's new is the explicit privacy model and the constraints of zero-knowledge proof systems.

With the patterns, differences, and examples outlined in this guide, you are ready to build the next generation of privacy-preserving decentralized applications on Midnight Network. Start with simple contracts, gradually add privacy features, and explore the unique capabilities that zero-knowledge proofs enable.

Privacy is not just a feature, it's a fundamental design principle. Compact gives you the tools to build applications where users control their data, sensitive information stays confidential, and trust is established through cryptographic proofs rather than transparency.

Key Takeaways:

Privacy Architecture: Ledger for public state, witness functions for truly private data with cryptographic guarantees
Compile-Time Constraints: Fixed sizes for most structures, bounded loops, unsigned integers - all determined before execution
No Direct Equivalents: Mappings, inheritance, events require alternative patterns
Explicit Context: Manual handling of caller context and timestamps through witness functions
Proof-Aware Design: Optimize for proof complexity and generation time rather than gas costs

Welcome to privacy-first smart contract development.

The Pharmacist's Guide to Becoming a Developer: Skills That Transfer

henry messiah tmt — Fri, 31 Oct 2025 13:40:54 +0000

I remember staring at my first for loop error at 2 AM, feeling completely lost. Six months earlier, I had been confidently counseling patients on complex drug interactions, calculating pediatric doses, and navigating the intricacies of pharmaceutical care. Now, I couldn't figure out why my JavaScript code kept returning undefined. Had I made a terrible mistake transitioning to programming?

That moment of doubt was transformative. As I methodically worked through the problem, isolating variables, checking each line, testing different inputs, something clicked. This process felt remarkably familiar. I was troubleshooting code the same way I had troubleshooted medication errors: systematically, carefully, with attention to detail.

Two years later, I work as a software developer and technical writer, and I've come to realize something crucial: my pharmacy background didn't hold me back from programming. It made me better at it.

If you're a healthcare professional considering a transition to tech, this article is for you. I'm not going to tell you what you need to learn; there are thousands of tutorials for that. Instead, I want to show you what you already have: a sophisticated set of problem-solving skills that translate directly into programming excellence. You're not starting from scratch. You're building on years of expertise.

The Myth of "Starting From Scratch"

When I first decided to learn programming, I was bombarded with discouraging narratives. "You're too old to learn coding." "You don't have a computer science degree." "You need to think like a programmer, which means forgetting everything you know."

These misconceptions are not just wrong, they're harmful. They create unnecessary barriers and fuel imposter syndrome before you even write your first line of code.

Here's the reality: programming is fundamentally about problem-solving, not memorizing syntax. While computer science degrees teach valuable theory, the tech industry increasingly recognizes that diverse backgrounds bring unique perspectives and strengths. According to Course Report's 2023 Bootcamp Graduate Survey, career changers make up over 70% of coding bootcamp students, and they perform just as well as, if not better than traditional CS graduates in many roles.

Healthcare professionals, in particular, bring something invaluable to software development: experience solving high-stakes problems in complex systems. When I build applications now, I draw on years of clinical decision-making, risk assessment, and systematic thinking. These aren't skills you can pick up in a weekend tutorial. They take years to develop, and you've already done that work.

The question isn't whether you can learn to code. It's how you'll leverage your existing expertise to become an exceptional developer.

The Seven Skills That Transfer

1. Systematic Problem-Solving

In Pharmacy:

As a pharmacist, I approached every medication-related problem with a structured methodology. When a patient experienced adverse effects, I didn't guess randomly, I followed a systematic process:

Gather complete information (medication history, timeline, symptoms)
Identify potential causes using differential diagnosis
Prioritize possibilities based on likelihood and severity
Test hypotheses by checking drug interactions, dosages, and patient factors
Implement solutions and monitor outcomes

This is algorithmic thinking in its purest form. We used clinical algorithms for antibiotic selection, dosage calculations based on renal function, and decision trees for managing drug interactions. SOAP notes (Subjective, Objective, Assessment, Plan) provided a framework for documenting this process.

In Programming:

Debugging code follows an identical pattern:

Gather information (error messages, console logs, input values)
Identify potential causes (logic errors, syntax issues, incorrect data types)
Prioritize based on error messages and code flow
Test hypotheses by isolating code sections and using debugging tools
Implement fixes and verify the solution

Consider this parallel:

Pharmacy Scenario: A patient on warfarin presents with unexpected bleeding. I check their medication list and discover they recently started taking a new supplement containing high-dose vitamin E, which increases bleeding risk when combined with warfarin. Solution: discontinue the supplement and adjust warfarin dosing.

Programming Scenario: A React application crashes with a "Cannot read property of undefined" error. I check the code flow and discover that an API call sometimes returns null, and the component tries to access properties of that null value before checking if data exists. Solution: add conditional rendering and proper null checks.

The cognitive process is identical: systematic investigation, pattern recognition, and logical solution implementation.

Personal Example:

Early in my coding journey, I spent hours trying to debug an authentication issue. Users could log in, but their session data wasn't persisting. I was ready to blame the entire authentication library when I remembered my pharmaceutical training: always check the obvious first, like you'd verify a patient's adherence before adjusting medication.

I went back to basics, checked environment variables, reviewed configuration files, and examined database connections. The culprit? A typo in the session secret key in my production environment. Five minutes of systematic checking solved what I'd been randomly poking at for hours. My pharmacy training had taught me to follow the evidence, not my assumptions.

2. Attention to Detail

In Pharmacy:

In pharmaceutical care, attention to detail isn't just important; it's literally life or death. A misplaced decimal point means the difference between 1.0 mg and 10 mg, between therapeutic effect and toxicity. I reviewed hundreds of prescriptions, checking for:

Correct drug names (many drugs have similar names: Hydralazine vs. Hydroxyzine)
Appropriate dosages for patient age, weight, and condition
Drug allergies and contraindications
Potential drug-drug, drug-food, and drug-disease interactions
Subtle discrepancies in patient records

This vigilance becomes second nature. You learn to catch the pharmacist's equivalent of syntax errors, such as an order for metformin in a patient with severe renal impairment, or a dose of acetaminophen that exceeds maximum daily limits when combined with other medications.

In Programming:

Code demands similar precision. A missing semicolon, a typo in a variable name, or an off-by-one error can break an entire application. But beyond syntax errors, attention to detail manifests in:

Code review practices: Catching logic errors before they reach production
Input validation: Anticipating edge cases and invalid data
Testing thoroughness: Writing test cases that cover boundary conditions
Security considerations: Recognizing potential vulnerabilities in authentication, data handling, and API endpoints

The pharmacy mindset of "measure twice, cut once" translates perfectly to writing production code. I'm meticulous about testing edge cases because I understand that small oversights can cascade into major failures. When I write a function that processes user data, I don't just test the happy path; I test what happens with null values, empty strings, unexpected data types, and malicious inputs.

Real-World Connection:

Just as I would never dispense medication without triple-checking the label, patient name, and dosage, I never deploy code without thorough testing and review. This might seem tedious to some developers, but to me, it's a professional responsibility. In pharmacy, we had a saying: "You're only as good as your last error." In software development, especially in production environments, this principle holds equally true.

My attention to detail has made me particularly effective in QA testing and technical writing, where catching inconsistencies and edge cases is crucial.

3. Documentation & Record-Keeping

In Pharmacy:

Documentation was a cornerstone of pharmaceutical care. Every patient interaction required clear, comprehensive records:

SOAP notes: Structured documentation of clinical reasoning
Medication counseling records: What was explained, patient understanding, concerns addressed
Intervention documentation: What problem was identified, action taken, outcome
Handoff notes: Critical information for the next pharmacist on duty

Good documentation served multiple purposes: continuity of care, legal protection, quality assurance, and communication with other healthcare providers. I learned to write notes that were clear, concise, and comprehensive, balancing detail with readability.

In Programming:

These documentation skills transfer seamlessly to software development:

Code comments: Explaining complex logic or non-obvious design decisions
README files: Project setup, usage instructions, and architectural overview
API documentation: Endpoints, parameters, response formats, and example usage
Commit messages: Clear descriptions of what changed and why
Technical documentation: User guides, troubleshooting resources, and system architecture

The key principle is the same: your documentation should allow someone else to understand and continue your work without you present. In pharmacy, I documented so the next pharmacist could pick up seamlessly. In programming, I document so future developers (including future me) can understand the codebase.

Actionable Tip:

Many companies desperately need technical writers who understand both the subject matter and how to communicate clearly. Pharmacists excel at translating complex information into plain language—we spent years explaining medications to patients with varying health literacy levels. This skill makes healthcare-background developers particularly valuable for:

Creating user-facing documentation
Writing API guides for external developers
Building internal knowledge bases
Contributing to open-source documentation
Transitioning into developer advocacy roles

Technical writing can also be a lucrative side income or even a full career pivot. I currently earn additional income writing technical tutorials and documentation for SaaS companies, directly leveraging the documentation skills I developed in pharmacy.

4. Continuous Learning

In Pharmacy:

Pharmacy requires lifelong learning. New drugs receive FDA approval regularly, clinical guidelines are updated constantly, and evidence-based practice evolves with new research. As a pharmacist, I:

Completed continuing education (CE) requirements annually
Read clinical studies and drug information updates
Attended seminars on new therapeutic approaches
Learned new pharmacy software systems and technologies
Stayed current on insurance formulary changes and regulations

This wasn't optional; it was integral to maintaining competence and licensure. I became comfortable with being a perpetual student, knowing that my education would never be "complete."

In Programming:

The tech industry moves even faster than healthcare. JavaScript frameworks rise and fall in popularity within years. Libraries update with breaking changes. Best practices evolve. New languages emerge. The parallel to pharmacy is striking:

Learning new frameworks and libraries as projects require
Following industry blogs, documentation updates, and release notes
Adapting to rapidly changing best practices
Self-directed learning through courses, tutorials, and documentation
Staying current on security vulnerabilities and patches

Mindset Shift:

Many career changers feel overwhelmed by how much there is to learn in programming. But here's the reframe that transformed my perspective: I don't need to learn to learn, I already know how to learn complex systems quickly.

In pharmacy school, I memorized thousands of drug names, mechanisms, interactions, and dosing protocols. I learned to interpret lab values, understand disease pathophysiology, and apply clinical guidelines. If I could learn that the cytochrome P450 3A4 enzyme metabolizes over 50% of marketed drugs and understand the clinical implications of enzyme induction and inhibition, I could learn React hooks.

The skills that helped me pass pharmacy board exams, breaking complex topics into manageable chunks, using spaced repetition, teaching concepts to solidify understanding, and applying knowledge through practice problems, work just as well for mastering programming.

When I approach a new technology now, I use the same strategies I used for learning new drug classes:

Start with fundamentals: Understand core concepts before diving into advanced features
Build mental models: Create analogies and frameworks for how things work
Learn by doing: Theory matters, but hands-on practice solidifies understanding
Teach others: Explaining concepts reveals gaps in my knowledge
Review regularly: Spaced repetition prevents knowledge decay

The difference between pharmacy and programming isn't the volume of learning required; it's that in programming, the information is more accessible, the feedback is immediate, and you can experiment without risking patient safety.

5. Working with Complex Systems

In Pharmacy:

Pharmaceutical care involves navigating incredibly complex, interconnected systems:

Pharmacokinetics and pharmacodynamics: How drugs move through the body (absorption, distribution, metabolism, excretion) and how they produce therapeutic effects
Drug interactions: Understanding how multiple medications interact, sometimes enhancing effects, sometimes causing dangerous combinations
Multi-system thinking: Recognizing how cardiovascular medications affect renal function, or how diabetes impacts wound healing
Insurance formularies: Navigating Byzantine rules about what medications are covered under different plans
Healthcare coordination: Interfacing between patients, physicians, insurance companies, and other healthcare providers

Every decision required systems thinking. Prescribing an antibiotic isn't just about killing bacteria; it's about considering renal function (affects dosing), drug allergies (contraindications), current medications (interactions), patient adherence patterns (complexity of regimen), and insurance coverage (accessibility).

In Programming:

Software systems share this complexity:

Architecture: Understanding how frontend, backend, database, and external services interact
Dependencies: Managing libraries that depend on other libraries, and how updates cascade
Data flow: Tracing how information moves through an application, from user input to database storage to API responses
Debugging across systems: Identifying whether an issue originates in the frontend code, backend logic, database queries, or network communication
Integration: Making different services work together, each with its own requirements and constraints

Visual Comparison:

Consider how similar these flows are:

Drug Pathway Through the Body:

Oral medication → GI absorption → Liver metabolism → Systemic circulation → 
Target tissue → Therapeutic effect → Renal/hepatic elimination

Data Flow Through an Application:

User input → Frontend validation → API request → Backend processing → 
Database query → Data transformation → API response → UI update

Both require understanding:

Entry points and validation
Transformation processes
Target destinations
Expected outputs
Error handling at each stage
Feedback mechanisms

Personal Example:

When I built my first full-stack application, a medication tracking app. I instinctively approached the architecture the same way I approached patient care plans. I mapped out:

Input layer (frontend): Like taking a patient history
Validation layer (backend): Like checking for contraindications
Processing layer (business logic): Like applying clinical guidelines
Storage layer (database): Like maintaining medical records
Monitoring layer (logging/alerts): Like follow-up appointments

This systems thinking, honed through years of pharmaceutical care, made architectural concepts intuitive rather than abstract. I understood that changing one part of the system could have cascading effects elsewhere, just like adjusting one medication in a patient's regimen might require adjusting others.

6. Communication with Non-Technical Stakeholders

In Pharmacy:

One of the most underappreciated pharmacy skills is the ability to translate complex medical information into language that patients understand. Every day, I explained:

How medications work, without overwhelming patients with biochemistry
Potential side effects, balancing information with avoiding unnecessary anxiety
Why drug interactions matter, in concrete rather than abstract terms
Insurance denials and prior authorization processes, helping patients navigate bureaucracy
Treatment alternatives when first-line options weren't suitable

I also communicated regularly with other healthcare professionals, physicians who needed pharmacokinetic consultation, nurses implementing medication orders, and insurance companies requiring clinical justification. Each audience required a different language, detail level, and framing.

In Programming:

These same communication skills are invaluable in software development:

Explaining technical concepts to non-technical team members: Product managers, designers, marketers, executives
Writing user-friendly error messages: Not "Error 422: Unprocessable Entity" but "Please enter a valid email address"
Presenting technical solutions to business stakeholders: Translating implementation details into business value
Creating end-user documentation: Guides that users can actually follow
Collaborating across disciplines: Working with designers who think visually, product managers who think strategically, and clients who think about outcomes

Career Advantage:

This skill set makes healthcare-background developers particularly valuable in:

Client-facing roles: Many developers struggle to communicate technical concepts to clients. I can discuss database architecture with engineers in the morning and explain the same system's benefits to a non-technical client in the afternoon.
Technical writing: As mentioned earlier, clear communication is scarce in tech. Good documentation is often the difference between a product's success and failure.
Developer advocacy: Companies need people who can represent their products to developer communities, explain features, create tutorials, and gather feedback. Communication skills are essential.
Product management: Understanding both technical constraints and user needs allows for better product decisions. Many healthcare professionals transition successfully into product management roles.
Team leadership: Senior developers and tech leads spend more time communicating than coding. The ability to explain technical decisions, mentor junior developers, and interface with stakeholders becomes crucial.

Personal Story:

During a project meeting, our team was debating whether to implement a complex caching strategy. The engineers understood the technical benefits, but the project manager worried about the timeline impact, and the client didn't understand why it mattered.

I drew on my pharmacy communication skills. To the project manager, I explained it like medication adherence: "Just like how pre-packaging medications in blister packs saves time during administration, this caching strategy takes extra setup time now but makes every subsequent operation faster." To the client, I framed it in business terms: "This will reduce your server costs by approximately 40% and improve page load times, which directly impacts user retention."

Both analogies worked because I understood the principle (caching) and could translate it into language that resonated with each audience. This skill was developed through years of counseling patients and has become one of my most valuable professional assets.

7. Quality Assurance & Risk Management

In Pharmacy:

Pharmacy is fundamentally about risk management. Every medication has potential benefits and potential harms, and pharmacists constantly evaluate risk-benefit ratios:

Double-checking calculations: Especially for high-risk populations like pediatrics and neonates, where dosing errors are most dangerous
Implementing safety checks: Multiple verification points before dispensing medication
Anticipating adverse effects: "What could go wrong?" thinking before problems occur
High-alert medications: Extra safeguards for drugs with narrow therapeutic indices or high risk of harm
Root cause analysis: When errors occurred, a systematic investigation to prevent recurrence

We learned to think defensively. What if the patient forgets to take this medication? What if they take it with food when they shouldn't? What if they're taking an unreported supplement that interacts? This anticipatory thinking prevented problems before they arose.

In Programming:

Software development requires identical risk management:

Unit testing: Verifying that individual functions work correctly
Integration testing: Ensuring different parts of the application work together
Error handling: Anticipating and gracefully managing failures
Input validation: Defending against invalid or malicious data
Edge case testing: What happens with empty arrays, null values, or unexpected data types?
Security considerations: Protecting against SQL injection, XSS attacks, and authentication bypasses
Code review: Multiple sets of eyes catching potential issues

Personal Story:

My pharmacy background naturally led me to emphasize testing in my code. When I built a feature for calculating medication dosages based on patient weight, I didn't just test that it worked with typical values. I tested:

What happens with zero or negative weight values?
What happens with extremely high weights (data entry errors)?
What happens if weight units aren't specified?
What happens if the calculation produces a dose exceeding maximum limits?
What happens if database queries fail?

This might seem excessive, but in pharmacy, I learned that edge cases aren't theoretical; they're inevitable. Real users will input invalid data, networks will fail at inopportune moments, and assumptions about "this will never happen" are dangerous.

My colleagues sometimes joke about my "paranoid" testing approach, but it's caught critical bugs before they reached production. When your professional training emphasizes that mistakes can harm people, you develop a healthy respect for thorough quality assurance.

This mindset has made me particularly effective in QA roles and has prevented numerous production incidents. I approach code reviews with the same scrutiny I applied to prescription verification: assume nothing, verify everything, and protect the end user.

Overcoming Imposter Syndrome

Despite these transferable skills, I still struggled with imposter syndrome during my transition. Scrolling through tech Twitter, I'd see developers who'd been coding since age twelve, had computer science degrees from prestigious universities, and could whiteboard complex algorithms effortlessly. How could I compete?

The turning point came when I reframed the narrative.

The Challenge:

Imposter syndrome tells you:

"You're not a real developer without a CS degree"
"Everyone else started coding as children; you're so far behind."
"You're just faking it until someone realizes you don't belong."

These feelings are amplified in tech, where there's a pervasive myth that great programmers are born, not made, and that you need to start young to succeed.

The Reframe:

Here's what I eventually realized:

Your healthcare background is a differentiator, not a deficit. When I applied for roles at health-tech companies, my pharmacy background wasn't a curiosity; it was a competitive advantage. I understood the problems our users faced because I'd lived them. I could speak clinically with our medical advisory board and technically with our engineering team.
Diversity of thought improves software teams. Homogeneous teams produce limited solutions. Teams with varied backgrounds: different industries, different educational paths, different life experiences, build better products. Your perspective matters.
You bring domain expertise that's incredibly valuable. There's an explosion of health-tech companies that desperately need people who understand both healthcare and technology. Your dual expertise is rare and valuable.
Your problem-solving skills are already advanced. You spent years developing systematic thinking, attention to detail, and risk management. These cognitive skills transfer directly to programming. Learning syntax is the easy part.

Practical Strategies:

Keep a "wins" journal. Document every problem you solve using your transferred skills. When imposter syndrome strikes, review this journal. You'll see concrete evidence of your capabilities.
Find community. Connect with other career-changers through communities like CodeNewbie, career-change Discord servers, or local meetups. Realizing you're not alone makes a tremendous difference.
Embrace beginner's mind. Being new to syntax doesn't mean being new to thinking. I may not have known JavaScript's prototype chain initially, but I understood complex systems, logical reasoning, and methodical troubleshooting.
Contribute to health-tech. Your dual expertise is invaluable in medical software projects. Contributing to open-source health applications or volunteering your skills for health-tech nonprofits reinforces that your background is an asset.
Reframe your narrative. Instead of "I'm a pharmacist trying to become a developer," try "I'm a problem-solver expanding my toolkit." Your identity isn't about your title, it's about your capabilities.

I still sometimes feel like an imposter. But I've learned that imposter syndrome often signals growth; you're pushing beyond your comfort zone. The key is recognizing that feeling inadequate doesn't mean you are inadequate. It often means you're learning.

Practical Steps to Leverage Your Skills

Understanding that your skills transfer is valuable, but how do you actually leverage them? Here's a concrete roadmap:

Step 1: Identify Your Strengths

Take fifteen minutes and complete this exercise:

List five things you excelled at in your healthcare role:

Example from my experience:

Identifying drug interactions before they cause patient harm
Explaining complex medical concepts to patients with limited health literacy
Troubleshooting medication-related problems systematically
Maintaining meticulous documentation for legal and clinical purposes
Learning new drugs and clinical guidelines quickly

Now match each to a programming parallel:

Identifying drug interactions → Debugging code and catching edge cases before production
Explaining to patients → Writing clear documentation and user-friendly error messages
Systematic troubleshooting → Methodical debugging and problem-solving approach
Meticulous documentation → Writing clear code comments, README files, and technical docs
Learning new drugs quickly → Rapidly learning new frameworks, libraries, and languages

This exercise isn't just motivational, it's strategic. These become talking points for interviews, content for your portfolio, and focus areas for skill development.

Step 2: Choose Your Learning Path Strategically

Not all learning paths are equal for healthcare professionals. Consider:

Health-tech focused bootcamps or courses:
Some bootcamps (like Springboard's Health Tech track) specifically cater to healthcare professionals transitioning to tech. These programs understand your background and help you leverage it.

Project-based learning:
Build projects that combine your interests. When you're learning React, don't build a generic todo app, build a medication tracker. When learning databases, create a drug interaction database. This serves two purposes: you stay motivated by working on relevant problems, and you build a portfolio that showcases your unique expertise.

Open-source health software:
Contributing to projects like OpenMRS, OpenEMR, or health-tech libraries gives you real-world coding experience while building connections in health-tech communities.

Step 3: Build a Bridge Portfolio

Your portfolio should showcase both skill sets. Instead of generic beginner projects, create applications that demonstrate your domain expertise:

Project Ideas:

Drug Interaction Checker: An application that checks medication combinations for interactions, using public APIs like OpenFDA or RxNorm. Demonstrates API integration, data processing, and healthcare knowledge.
Medication Reminder App: Mobile or web app for medication adherence, with features like custom schedules, refill reminders, and interaction warnings. Shows frontend skills, local storage/database management, and understanding of patient needs.
Clinical Calculator Collection: Web app with common pharmacy calculations (creatinine clearance, ideal body weight, medication dosing adjustments). Demonstrates mathematical logic, input validation, and clinical application.
Pharmacy Inventory Management System: Full-stack application for tracking medication stock, expiration dates, and reorder points. Shows database design, CRUD operations, and real-world business logic.
Patient Education Content Management: Platform for creating, organizing, and sharing medication information sheets. Highlights content management, user authentication, and understanding of healthcare communication needs.

Each project should have:

Clean, well-documented code on GitHub
A deployed demo users can interact with
A detailed README explaining the clinical problem it solves
Screenshots or a demo video
Notes on what you learned technically and how your healthcare background informed design decisions

Step 4: Network Strategically

Don't just attend generic tech meetups, focus on health-tech communities:

Online:

Join health-tech LinkedIn groups
Participate in r/healthIT and r/HealthTech on Reddit
Follow health-tech companies and their engineering blogs
Connect with other healthcare professionals who've made the transition

In-person:

Attend health-tech meetups and conferences (HIMSS, Health 2.0)
Healthcare hackathons (often focused on solving clinical problems)
Local tech meetups, but emphasize health-tech interests
Alumni networks from your healthcare program

Why this matters:
Health-tech companies specifically seek candidates with clinical backgrounds. When you network in these spaces, your healthcare experience is an advantage, not something you need to explain or apologize for.

Step 5: Tell Your Story

Your career transition is a compelling narrative. Use it:

Update your LinkedIn:

Don't hide your pharmacy background, highlight it
Frame skills in terms of transferable capabilities: "problem-solving," "systematic analysis," "technical documentation," "risk management"
Add a summary that explicitly addresses the transition: "Pharmacist transitioning to software development, combining clinical expertise with technical skills to build health-tech solutions"

Write about your journey:

Blog posts on Medium or dev.to about lessons learned
Twitter threads about "Today I learned" moments
LinkedIn posts about challenges and insights
Technical tutorials that incorporate healthcare examples

Prepare your narrative for interviews:
Practice explaining your transition concisely and positively:

"I spent five years in pharmacy, where I developed strong problem-solving skills and a deep understanding of healthcare workflows. I became interested in the technology we used daily and realized I could have more impact by building tools that improve healthcare delivery. I've spent the past year learning full-stack development, focusing on health-tech applications. My clinical background helps me understand user needs and design solutions that actually work in healthcare settings."

This narrative reframes your transition as purposeful and strategic, not desperate or uncertain.

Real-World Success Stories

You're not alone in making this transition. Here are three professionals who successfully moved from healthcare to tech:

Story 1: Sarah - Pharmacist to Software Engineer

Background: Sarah worked five years in hospital pharmacy before transitioning to software development.

Skills that transferred most easily: "My systematic approach to problem-solving and attention to detail made debugging feel natural. I was already used to double checking everything and thinking through edge cases."

Biggest challenge: "Overcoming the feeling that I was 'too late' since I didn't start coding as a teenager. I had to remind myself that my maturity and professional experience were assets."

Current role: Software engineer at a health-tech startup building clinical decision support tools.

Advice: "Don't just learn to code, learn to solve problems with code. Your healthcare background gives you problems worth solving. Build projects that address real clinical needs, and you'll stand out."

Story 2: James - Nurse to QA Engineer

Background: James worked six years as an ICU nurse before transitioning to quality assurance engineering.

Skills that transferred most easily: "Nursing taught me to anticipate what could go wrong and implement safeguards. That's exactly what QA is about, thinking through failure scenarios and preventing them."

Biggest challenge: "Learning to advocate for quality without coming across as negative. In healthcare, we're trained to speak up about safety concerns, but in tech, I had to learn how to frame issues constructively."

Current role: QA engineer specializing in medical device software testing.

Advice: "Your healthcare safety mindset is valuable, don't lose it when you transition to tech. But learn to communicate in terms of business risk and user impact, not just technical correctness."

Story 3: Aisha - Medical Lab Scientist to Data Engineer

Background: Aisha worked four years in clinical laboratory science before moving into data engineering.

Skills that transferred most easily: "Lab work is all about protocols, documentation, and quality control. Data engineering requires the same rigor—ensuring data quality, documenting processes, and validating results."

Biggest challenge: "The pace of change in tech was jarring after working in a highly regulated environment. I had to become comfortable with iteration and accepting that code doesn't need to be perfect before deployment."

Current role: Data engineer at a clinical research organization, building data pipelines for medical studies.

Advice: "Look for roles that bridge healthcare and tech. Clinical research, health-tech companies, and medical device firms all need people who understand both domains."

Common Themes

Across all three stories:

Problem-solving skills transferred first and most easily
The biggest challenges were often mindset shifts, not technical skills
Their healthcare backgrounds became differentiators in health-tech roles
They all wish they'd made the transition sooner

Addressing Common Concerns

Let's tackle the questions that might be holding you back:

"Am I too old?"

No. Full stop.

Age diversity benefits tech teams by bringing varied perspectives, life experience, and professional maturity. Many successful developers started later in life:

According to Stack Overflow's 2023 Developer Survey, 40% of developers learned to code after age 25
Bootcamp graduate data shows students in their 30s and 40s often outperform younger counterparts due to better time management and clearer goals
Major tech companies increasingly value diverse age ranges—experience with professional environments, communication skills, and project management are assets

Your "late start" often means you're more focused, more motivated, and more mature than someone coding fresh out of high school. You understand professional responsibility, workplace dynamics, and career strategy. These are advantages.

"Will I have to take a huge pay cut?"

It depends on your path, but it's often temporary:

Initial considerations:

Entry-level developer salaries may be lower than experienced pharmacist salaries initially
However, tech salary trajectories often outpace healthcare over time
Remote work opportunities can offset costs (no commute, broader job market)
Freelancing and consulting in health-tech can command premium rates due to your dual expertise

Long-term potential:

Senior developers often earn significantly more than pharmacists
Technical leadership roles, specialized positions (like QA automation or technical writing), and health-tech product management can be highly lucrative
Your healthcare background can command premium rates in health-tech consulting

Strategies to minimize financial impact:

Start with freelance projects or part-time work while maintaining your current role
Look for hybrid roles (like pharmacy informatics or clinical systems analyst) that value both backgrounds
Build skills through evening courses while employed
Target health-tech companies that value clinical backgrounds and may offer competitive salaries

"What about my pharmacy license/degree?"

It's not wasted, it's your differentiator:

Your education and license are assets:

Health-tech companies specifically seek clinical expertise
You can consult on health projects while working as a developer
Clinical informatics roles require both healthcare and technical knowledge
You understand regulatory requirements (HIPAA, FDA regulations) that many developers don't

Maintaining your license:

Some states have inactive or non-practicing license status with reduced CE requirements
You can maintain your license while working in tech
This keeps doors open for hybrid roles or consulting

Opportunities that value both skills:

Pharmacy informatics specialist
Clinical systems analyst
Health-tech product manager
Medical software consultant
Healthcare data analyst
Clinical decision support developer
Digital health entrepreneur

The rise of clinical informatics, telehealth, and digital therapeutics means demand for professionally trained healthcare workers with technical skills is growing rapidly.

"How long will it take?"

Honest answer: It varies, but probably less time than you think:

Different paths:

Full-time bootcamp (3-6 months):

Intensive, structured learning
Career services and networking
Fastest path to job-ready skills
Best for those who can afford to not work during training

Part-time bootcamp or courses (6-12 months):

Balance learning with current job
Less financial risk
Slower pace but more sustainable
Common for career changers with responsibilities

Self-taught (6-18 months):

Most flexible but requires discipline
Lower cost but less structure
Timeline varies significantly based on time commitment
Works well for self-motivated learners with technical aptitude

The advantage you have:
You're not starting from zero. Your problem-solving skills, attention to detail, and ability to learn complex systems quickly mean you'll likely progress faster than you expect. The learning curve isn't learning to think, it's learning syntax and tools.

Realistic expectations:

3-6 months: Basic competency, can build simple applications
6-12 months: Job-ready skills, portfolio projects, entry-level positions
12-18 months: Comfortable with multiple technologies, strong portfolio, competitive for mid-level positions
18+ months: Specialized skills, potential for senior positions, especially in health-tech niches

Conclusion

Two years after that frustrating night debugging my first for loop, I work as a software developer and technical writer. I build applications, write technical documentation, and consult on health-tech projects. But more importantly, I've realized that the skills I developed in pharmacy—the systematic problem-solving, meticulous attention to detail, clear documentation, continuous learning, systems thinking, stakeholder communication, and risk management—weren't left behind. They were the foundation.

Learning to code didn't mean abandoning my healthcare identity. It meant expanding my toolkit to solve problems in new ways. When I debug complex issues, I use the same methodical approach I used for identifying drug interactions. When I write documentation, I draw on years of explaining medications to patients. When I test code, I apply the same defensive thinking that prevented medication errors.

You already possess the hard skills: problem-solving, attention to detail, systematic thinking. Learning syntax is the easy part. Your healthcare background isn't baggage; it's your competitive advantage, especially in the rapidly growing health-tech sector.

If you're a healthcare professional considering this path, remember: you're not starting from scratch. You're building on years of expertise. The question isn't whether you can learn to code, it's what problems you'll solve once you do.

Your Action Plan

This week:
Make a list of three transferable skills you used in your healthcare role this week. Write one sentence for each describing how that skill applies to programming.

This month:
Complete one beginner coding tutorial. I recommend:

freeCodeCamp's Responsive Web Design Certification (free, project-based)
The Odin Project's Foundations Course (free, comprehensive)
Codecademy's Introduction to JavaScript (free tier available)

This quarter:
Build one small project that combines your healthcare knowledge with code. It doesn't need to be complex, a simple medication reminder, a dosage calculator, or a drug information lookup tool. The goal is to prove to yourself that you can create something functional.

Resources to Get Started

Free Learning Platforms:

freeCodeCamp (web development)
The Odin Project (full-stack development)
Codecademy (multiple languages)
CS50 (Harvard's intro to computer science)

Health-Tech Communities:

Healthcare IT Professionals on LinkedIn
r/HealthIT and r/healthtech on Reddit
HIMSS (Healthcare Information and Management Systems Society)
Health 2.0 Developer Community

Books for Career Changers:

"The Self-Taught Programmer" by Cory Althoff
"Cracking the Coding Interview" by Gayle Laakmann McDowell
"The Pragmatic Programmer" by David Thomas and Andrew Hunt

Podcasts:

CodeNewbie (features career changers)
Learn to Code With Me
The Changelog (tech industry insights)

The same brain that calculates pediatric doses can debug complex code. The same attention to detail that catches prescription errors catches software bugs. The same communication skills that counsel patients write clear documentation.

You're not too old. You're not too late. You're not starting from scratch.

You're a problem-solver learning a new language.

And that changes everything.

Top 10 Test Automation Frameworks for JavaScript Developers (2025 Edition)

henry messiah tmt — Thu, 30 Oct 2025 13:37:23 +0000

Introduction

JavaScript has evolved from a simple scripting language to the backbone of modern web development. Today's applications are complex, user-facing systems where bugs can cost businesses thousands of dollars and damage user trust. Manual testing alone can't keep pace with rapid deployment cycles and continuous integration demands.

Test automation solves this challenge by catching regressions early, validating functionality across browsers, and enabling developers to refactor with confidence. But choosing the right testing framework isn't straightforward. Developers face a crowded landscape where each tool promises speed, simplicity, or comprehensive coverage, yet delivers different trade-offs in practice.

Should you prioritize lightning-fast unit tests? Cross-browser compatibility? A gentle learning curve for your team? The answer depends on your project's unique needs.

This article breaks down the top 10 JavaScript test automation frameworks for 2025, examining what each does best and where it falls short. Whether you're testing React components, building end-to-end workflows, or validating APIs, you'll find a framework that fits.

What Makes a Great JavaScript Testing Framework?

Before diving into specific tools, let's establish the criteria that separate exceptional frameworks from mediocre ones:

Ease of Setup and Use: The best frameworks get you writing tests quickly without wrestling with configuration files. Zero-config solutions win points here, though flexibility matters for complex projects.

Type of Testing Supported: Different tools excel at different layers. Unit testing frameworks validate individual functions, integration tests verify how modules work together, and end-to-end (E2E) frameworks simulate real user interactions across entire applications.

Ecosystem and Community Support: Popular frameworks benefit from extensive documentation, active maintainers, and rich plugin ecosystems. When you hit a roadblock, community support can make or break your experience.

CI/CD Integration: Modern development demands seamless integration with Jenkins, GitHub Actions, GitLab CI, and other automation platforms. Look for frameworks with built-in reporters and parallel execution support.

Browser and Device Coverage: If you're testing web UIs, cross-browser compatibility is non-negotiable. The best E2E frameworks handle Chrome, Firefox, Safari, and Edge without manual driver management.

Reporting and Debugging Tools: Clear error messages, visual diffs, and actionable stack traces accelerate debugging. Time-travel debugging and automatic screenshots raise the bar even higher.

With these benchmarks in mind, let's explore the frameworks that dominate JavaScript testing in 2025.

Top 10 Test Automation Frameworks for JavaScript Developers

(A) Jest

Overview: Jest is Facebook's testing framework designed for simplicity and speed. It's the default choice for React applications but works equally well with Vue, Angular, and Node.js backends.

Key Features:

Zero configuration for most JavaScript projects
Built-in code coverage reports with no additional setup
Snapshot testing for UI components and data structures
Powerful mocking capabilities for dependencies and modules
Parallel test execution for faster feedback

Ideal Use Case: Jest shines in component-driven development. If you're building a React app or need quick unit tests with minimal setup, Jest delivers exceptional developer experience out of the box.

Getting Started:

npm install -D jest
npx jest --init

Example test file (sum.test.js):

// sum.js
function sum(a, b) {
  return a + b;
}
module.exports = sum;

// sum.test.js
const sum = require('./sum');

describe('sum function', () => {
  test('adds 1 + 2 to equal 3', () => {
    expect(sum(1, 2)).toBe(3);
  });

  test('adds negative numbers correctly', () => {
    expect(sum(-1, -2)).toBe(-3);
  });
});

Pros:

Extremely beginner-friendly
Excellent documentation and a massive community
Fast watch mode for test-driven development

Cons:

Not designed for E2E browser testing
Snapshot tests can become brittle if overused
Less flexible than Mocha for custom configurations

(B) Mocha + Chai

Overview: Mocha is a veteran testing framework known for flexibility. Paired with Chai (an assertion library), it forms a powerful, customizable testing stack popular in backend development.

Key Features:

Highly flexible: use any assertion library, spy library, or mocking tool
Supports multiple interfaces (BDD, TDD, exports)
Runs in both Node.js and browsers
Extensive plugin ecosystem
Asynchronous testing with promises, callbacks, or async/await

Ideal Use Case: Choose Mocha when you need full control over your testing stack. It's perfect for Node.js APIs, microservices, and teams with specific tooling requirements.

Getting Started:

npm install -D mocha chai
npx mocha

Example test file (test/api.test.js):

const chai = require('chai');
const expect = chai.expect;

describe('Array operations', () => {
  it('should return -1 when value is not present', () => {
    expect([1, 2, 3].indexOf(4)).to.equal(-1);
  });

  it('should handle async operations', async () => {
    const fetchData = () => Promise.resolve('data');
    const result = await fetchData();
    expect(result).to.equal('data');
  });
});

Pros:

Maximum flexibility and customization
Mature ecosystem with years of battle-testing
Works seamlessly with TypeScript

Cons:

Requires manual setup of assertions and other utilities
Steeper learning curve than opinionated frameworks
No built-in mocking or code coverage

(C) Jasmine

Overview: Jasmine is a behavior-driven development (BDD) framework that requires zero external dependencies. Its straightforward syntax makes it accessible to developers new to testing.

Key Features:

Zero dependencies—everything included out of the box
Clean, readable BDD syntax
Built-in assertions, spies, and mocks
Can run in Node.js or browser environments
Standalone test runner included

Ideal Use Case: Jasmine fits projects where simplicity and low overhead matter more than bleeding-edge features. It's ideal for small to medium applications and teams learning test automation.

Getting Started:

npm install -D jasmine
npx jasmine init

Example test file (spec/calculator.spec.js):

describe('Calculator', () => {
  let calculator;

  beforeEach(() => {
    calculator = {
      add: (a, b) => a + b,
      multiply: (a, b) => a * b
    };
  });

  it('should add two numbers', () => {
    expect(calculator.add(5, 3)).toBe(8);
  });

  it('should multiply two numbers', () => {
    expect(calculator.multiply(4, 3)).toBe(12);
  });
});

Pros:

No configuration needed
Easy for beginners to understand
Stable and mature

Cons:

Slower than modern alternatives like Vitest
Smaller community compared to Jest
Limited built-in tools for complex scenarios

(D) Cypress

Overview: Cypress revolutionized E2E testing with its developer-first approach. It runs directly in the browser, providing real-time reloads, automatic waiting, and powerful debugging tools.

Key Features:

Time-travel debugging with snapshots at every step
Automatic waiting eliminates flaky tests from timing issues
Real-time test reloading during development
Network traffic control and API mocking
Screenshots and videos on test failures

Ideal Use Case: Cypress is the gold standard for web application E2E testing. Use it when you need reliable, maintainable tests for critical user workflows like authentication, checkout processes, or form submissions.

Getting Started:

npm install -D cypress
npx cypress open

Example test file (cypress/e2e/login.cy.js):

describe('Login Flow', () => {
  beforeEach(() => {
    cy.visit('https://example.com/login');
  });

  it('should login successfully with valid credentials', () => {
    cy.get('[data-testid="email"]').type('user@example.com');
    cy.get('[data-testid="password"]').type('password123');
    cy.get('[data-testid="submit-btn"]').click();

    cy.url().should('include', '/dashboard');
    cy.contains('Welcome back').should('be.visible');
  });

  it('should show error with invalid credentials', () => {
    cy.get('[data-testid="email"]').type('wrong@example.com');
    cy.get('[data-testid="password"]').type('wrongpass');
    cy.get('[data-testid="submit-btn"]').click();

    cy.contains('Invalid credentials').should('be.visible');
  });
});

Pros:

Outstanding developer experience
Excellent documentation and community
Intuitive API for writing readable tests

Cons:

Limited to Chromium-based browsers by default (Firefox support in beta)
Can't test multiple tabs or origins easily
Slower execution compared to Playwright for large suites

(E) Playwright

Overview: Microsoft's Playwright is a next-generation browser automation framework supporting Chromium, Firefox, and WebKit. It's built for modern web apps requiring cross-browser coverage and parallel execution.

Key Features:

True cross-browser testing with a single API
Auto-waiting for elements to be ready
Parallel test execution across multiple browsers
Network interception and mocking
Mobile device emulation with touch and geolocation

Ideal Use Case: When cross-browser compatibility is critical and you need speed, Playwright delivers. It's perfect for enterprise applications, Progressive Web Apps (PWAs), and mobile-responsive testing.

Getting Started:

npm install -D @playwright/test
npx playwright install
npx playwright test

Example test file (tests/example.spec.js):

import { test, expect } from '@playwright/test';

test('basic navigation test', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveTitle(/Example Domain/);
});

test('form submission test', async ({ page }) => {
  await page.goto('https://example.com/contact');

  await page.fill('#name', 'John Doe');
  await page.fill('#email', 'john@example.com');
  await page.selectOption('#country', 'US');
  await page.click('button[type="submit"]');

  await expect(page.locator('.success-message')).toBeVisible();
});

Pros:

Fastest E2E framework for large test suites
Excellent browser coverage, including WebKit
Powerful auto-wait mechanism reduces flakiness

Cons:

Steeper learning curve than Cypress
Less polished developer tools (though improving rapidly)
Smaller community and fewer third-party plugins

(F) Puppeteer

Overview: Puppeteer is Google's Node.js library for controlling headless Chrome. While not a full testing framework, it excels at browser automation, scraping, and UI regression testing.

Key Features:

Direct control over Chrome DevTools Protocol
Generate screenshots and PDFs programmatically
Automate form submissions and keyboard input
Intercept network requests
Integrates with Jest or Mocha for assertions

Ideal Use Case: Puppeteer fits niche scenarios like generating PDF reports, testing Chrome extensions, or automating tasks that don't require full framework features.

Getting Started:

npm install -D puppeteer

Example test file (test/screenshot.js):

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  await page.goto('https://example.com');

  // Take screenshot
  await page.screenshot({ path: 'example.png' });

  // Generate PDF
  await page.pdf({ path: 'page.pdf', format: 'A4' });

  // Test interactions
  await page.click('a[href="/about"]');
  await page.waitForSelector('h1');

  const title = await page.$eval('h1', el => el.textContent);
  console.log('Page title:', title);

  await browser.close();
})();

Pros:

Lightweight and fast
Great for web scraping and automation
Excellent Chrome/Chromium integration

Cons:

Chrome-only (no Firefox or Safari)
Requires pairing with testing frameworks for assertions
Not designed for comprehensive E2E suites

(G) WebdriverIO

Overview: WebdriverIO is a full-featured test automation framework supporting web, mobile (React Native, Appium), and desktop applications. It's built on the WebDriver protocol with modern async/await syntax.

Key Features:

Supports web, iOS, and Android testing
Built-in test runner with parallel execution
Smart element selectors with automatic retries
Extensive plugin ecosystem
Integrates with Selenium Grid and cloud services

Ideal Use Case: WebdriverIO is ideal for teams needing comprehensive test coverage across platforms. If you're testing web and mobile apps with a unified framework, this is your best bet.

Getting Started:

npm install -D @wdio/cli
npx wdio config
npx wdio run wdio.conf.js

Example test file (test/specs/example.e2e.js):

describe('WebdriverIO example', () => {
  it('should verify page title', async () => {
    await browser.url('https://example.com');

    await expect(browser).toHaveTitle('Example Domain');
  });

  it('should interact with elements', async () => {
    await browser.url('https://example.com/search');

    const searchInput = await $('#search');
    await searchInput.setValue('WebdriverIO');

    const submitBtn = await $('button[type="submit"]');
    await submitBtn.click();

    const results = await $('.results');
    await expect(results).toBeDisplayed();
  });
});

Pros:

Unmatched platform coverage
Mature and actively maintained
Strong Sauce Labs and BrowserStack integration

Cons:

Complex setup for beginners
Heavier than modern alternatives
Configuration can be overwhelming

(H) TestCafe

Overview: TestCafe is a Node.js E2E testing tool that doesn't require WebDriver or browser plugins. It injects scripts directly into pages, making setup remarkably simple.

Key Features:

Zero browser plugin or WebDriver setup
Concurrent test execution
Automatic waiting for elements
Built-in support for CI/CD systems
Live mode for debugging tests in real-time

Ideal Use Case: TestCafe suits teams wanting E2E testing without infrastructure complexity. It's great for startups and small teams prioritizing quick wins over advanced features.

Getting Started:

npm install -D testcafe
npx testcafe chrome tests/

Example test file (tests/basic.test.js):

import { Selector } from 'testcafe';

fixture('Getting Started')
  .page('https://example.com');

test('Basic navigation', async t => {
  await t
    .expect(Selector('h1').innerText).eql('Example Domain')
    .click(Selector('a').withText('More information'))
    .expect(Selector('h1').exists).ok();
});

test('Form interaction', async t => {
  await t
    .typeText('#username', 'testuser')
    .typeText('#password', 'password123')
    .click('#submit')
    .expect(Selector('.welcome-message').visible).ok();
});

Pros:

Easiest E2E framework to set up
No external dependencies
Cross-browser support out of the box

Cons:

Slower than Playwright and Cypress
Smaller ecosystem and community
Debugging tools are less sophisticated than competitors

(I) Vitest

Overview: Vitest is the newest entrant, designed specifically for Vite-powered applications. It's blazingly fast and shares configuration with Vite, eliminating setup friction.

Key Features:

Lightning-fast execution with native ESM support
Compatible with Jest API (easy migration)
Hot Module Replacement (HMR) for instant feedback
Built-in TypeScript support
Component testing for Vue, React, and Svelte

Ideal Use Case: If you're building with Vite, Vitest is a no-brainer. It's also excellent for projects prioritizing speed and modern JavaScript features.

Getting Started:

npm install -D vitest
npx vitest

Example test file (src/utils.test.js):

import { describe, it, expect } from 'vitest';

function formatCurrency(amount) {
  return `$${amount.toFixed(2)}`;
}

describe('formatCurrency', () => {
  it('formats numbers with two decimals', () => {
    expect(formatCurrency(10)).toBe('$10.00');
    expect(formatCurrency(10.5)).toBe('$10.50');
  });

  it('rounds to two decimal places', () => {
    expect(formatCurrency(10.126)).toBe('$10.13');
  });
});

// Async testing
describe('API utilities', () => {
  it('fetches user data', async () => {
    const fetchUser = async (id) => ({ id, name: 'John' });
    const user = await fetchUser(1);

    expect(user).toEqual({ id: 1, name: 'John' });
  });
});

Pros:

Fastest unit testing framework available
Seamless Vite integration
Modern, future-proof architecture

Cons:

Still maturing (less stable than Jest)
Smaller community and fewer resources
Not suitable for E2E testing

(J) Nightwatch.js

Overview: Nightwatch is an all-in-one E2E testing solution with built-in support for Selenium WebDriver and Appium. It emphasizes simplicity with a clean, readable syntax.

Key Features:

Built-in test runner and assertion library
Page Object Model support out of the box
Native mobile testing via Appium
Parallel execution with workers
Cloud testing service integration

Ideal Use Case: Nightwatch fits teams already invested in Selenium infrastructure or needing mobile testing without adding tools like WebdriverIO.

Getting Started:

npm install -D nightwatch
npx nightwatch

Example test file (tests/github.js):

module.exports = {
  'GitHub Test': function(browser) {
    browser
      .url('https://github.com')
      .waitForElementVisible('body')
      .assert.titleContains('GitHub')
      .assert.visible('input[name="q"]')
      .setValue('input[name="q"]', 'nightwatch')
      .click('button[type="submit"]')
      .pause(1000)
      .assert.containsText('.repo-list', 'nightwatch')
      .end();
  },

  'Navigation Test': function(browser) {
    browser
      .url('https://nightwatchjs.org')
      .waitForElementVisible('.hero')
      .click('a[href="/guide"]')
      .assert.urlContains('/guide')
      .assert.visible('h1')
      .end();
  }
};

Pros:

Complete solution requiring minimal plugins
Good documentation and examples
Active development and updates

Cons:

Slower than Playwright/Cypress
Smaller community than leading frameworks
Less intuitive API compared to modern alternatives

Comparison Table: Choosing the Right Framework

Framework	Type	Speed	Learning Curve	Ideal For	CI/CD Ready
Jest	Unit	⚡⚡⚡⚡	Easy	React apps	✅
Mocha + Chai	Unit	⚡⚡⚡	Moderate	Backend testing	✅
Jasmine	Unit	⚡⚡⚡	Easy	Beginners	✅
Cypress	E2E	⚡⚡⚡⚡	Moderate	Web UI testing	✅
Playwright	E2E	⚡⚡⚡⚡⚡	Moderate	Cross-browser tests	✅
Puppeteer	Automation	⚡⚡⚡⚡	Moderate	Chrome automation	✅
WebdriverIO	E2E/Mobile	⚡⚡⚡	Difficult	Full-stack teams	✅
TestCafe	E2E	⚡⚡⚡	Easy	Simple E2E needs	✅
Vitest	Unit	⚡⚡⚡⚡⚡	Easy	Vite projects	✅
Nightwatch.js	E2E	⚡⚡⚡	Moderate	Selenium users	✅

Best Frameworks by Use Case

Fastest for Unit Testing: Vitest takes the crown with its native ESM support and Vite integration. Jest remains a close second with excellent caching mechanisms.

Best for Cross-Browser E2E Testing: Playwright leads with comprehensive browser support and parallel execution. TestCafe offers a simpler alternative for teams avoiding complex setup.

Best for Full-Stack Teams: WebdriverIO provides unified testing across web, iOS, and Android platforms. Combine it with Jest for complete coverage from unit to E2E.

Beginner-Friendly Options: Jest and Cypress offer the smoothest onboarding experiences. Jasmine is great for those learning testing fundamentals without framework complexity.

Most Scalable for CI/CD: Playwright and Cypress both integrate seamlessly with modern CI/CD pipelines, offering parallelization, retries, and detailed reporting out of the box.

How to Pick the Right Framework for Your Project

Choosing wisely requires matching frameworks to your specific context:

Step 1: Define Your Testing Needs
Start by categorizing what you need to test. Are you validating individual functions (unit tests), checking how modules integrate (integration tests), or simulating user journeys (E2E tests)? Most projects need multiple layers.

Step 2: Check Project Stack Compatibility
If you're using React with Vite, Vitest is the natural choice for unit tests. Angular projects often pair well with Jasmine or Jest. For frameworks like Next.js or Nuxt, Jest handles server and client testing elegantly.

Step 3: Evaluate CI/CD Integration
Review your deployment pipeline. GitHub Actions, GitLab CI, and Jenkins all have excellent support for major frameworks. Playwright and Cypress offer official Docker images and parallel execution strategies that scale with your needs.

Step 4: Consider Team Experience
New to testing? Jest and Cypress provide the gentlest learning curves with extensive tutorials. Experienced teams might prefer Mocha's flexibility or Playwright's power features.

Step 5: Assess Documentation Quality
Poor documentation kills productivity. Check official docs, community tutorials, and Stack Overflow activity. Jest, Cypress, and Playwright all excel here with comprehensive guides and active communities.

Final Thoughts

Test automation isn't optional in modern JavaScript development—it's the foundation of sustainable, high-quality software. The frameworks covered here represent the best tools available in 2025, each solving distinct problems.

For most teams, a combination approach works best: Jest or Vitest for fast unit tests, plus Cypress or Playwright for critical E2E workflows. This layered strategy catches bugs early while validating real user experiences.

Don't get paralyzed by choice. Pick one framework aligned with your immediate needs and start writing tests today. You can always add complementary tools as your project grows. The key is building the testing habit; the specific framework matters less than consistent coverage.

Experiment with a couple of options from this list. Set up a small proof-of-concept, run a few tests, and decide which tool fits your workflow. The best framework is the one your team will actually use.

Start small, test often, and let automation amplify your team's ability to ship confidently.

Designing Accessible Dark Mode Interfaces: A Step-by-Step Guide for Modern Web Designers

henry messiah tmt — Wed, 29 Oct 2025 20:01:14 +0000

Introduction

Dark mode is everywhere, from mobile apps to developer tools and websites. It’s sleek, power-efficient, and easier on the eyes for many users.

But there’s a catch: most dark mode designs aren’t accessible. Poor contrast, harsh text, and invisible icons make them difficult to use for people with visual impairments, and tiring for everyone else.

In this guide, you’ll build your own accessible dark mode layout from scratch, learning best practices as you go. By the end, you’ll know how to design, test, and implement dark mode that’s both stylish and inclusive. You will be able to build interchangable theme as seen bellow:

Prerequisites

Before you begin, ensure you meet a few basic requirements to follow this guide smoothly. These will help you understand each step and build your own accessible dark mode interface without issues.

You’ll need:

Basic web development knowledge: comfortable with HTML, CSS, and a bit of JavaScript.
A code editor: such as Visual Studio Code, Sublime Text, or Atom.
A modern browser: Chrome, Firefox, or Edge for previewing and testing your design.
Basic understanding of accessibility principles: like color contrast and readability.

Optional but helpful:

Familiarity with design tools such as Figma or Adobe XD (for visual testing).
Access to accessibility tools like Stark or WebAIM Contrast Checker.

If you’re missing any of these, take a moment to set them up first, so that we can flow together effortlessly.
Once these prerequisites are in place, you’re ready to start building your own inclusive dark mode layout from scratch.

Setting Up Your Project

With your tools ready, it’s time to create your workspace. In this step, you’ll build the structure that will hold your dark mode interface.

Let’s start by creating a simple HTML + CSS + JavaScript project that you’ll use throughout this tutorial.

Create Your Project Folder

On your computer, create a new folder called dark-mode-tutorial.

If you’re using Windows, right-click on your desktop → New → Folder → name it dark-mode-tutorial.

Alternatively, open your terminal or command prompt and run:

mkdir dark-mode-tutorial
cd dark-mode-tutorial

Open the folder in your code editor (for example, Visual Studio Code).

In VS Code, go to File → Open Folder → dark-mode-tutorial. Or from your terminal, run:

code .

This opens the current folder directly in VS Code. Now, you’re inside your project, the creative canvas where everything will unfold.

Create Three Files

Inside your dark-mode-tutorial folder, create these three files:

dark-mode-tutorial/
├── index.html
├── style.css
└── script.js

You can do this by:
Right-clicking in VS Code’s file explorer → New File, or Running these commands in your terminal:

touch index.html style.css script.js

This trio forms the backbone of your dark mode project: HTML for structure, CSS for design, and JavaScript for interactivity.

Before we style and script, let’s fill your HTML file with a clean, accessible layout.

Add the Starter `HTML` Code

Every great interface begins with solid structure. Let’s add your starter HTML code that is simple, semantic, and screen-reader friendly.

Now, open the index.html file in your editor.
To do that:
In VS Code, click index.html in the left panel. Paste in the following code:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Accessible Dark Mode Demo</title>
  <link rel="stylesheet" href="style.css" />
</head>
<body>
  <header>
    <h1>Accessible Dark Mode Demo</h1>
    <button id="theme-toggle">Toggle Theme</button>
  </header>

  <main>
    <section>
      <h2>Welcome</h2>
      <p>This page demonstrates how to build an accessible dark mode interface.</p>
    </section>
  </main>

  <script src="script.js"></script>
</body>
</html>

Save your file (Ctrl + S or Cmd + S).
Now that your basic structure is ready, let’s make it both beautiful and accessible.

Understanding Accessibility in Dark Mode

Now that your structure is set, let’s talk about why accessibility matters in dark mode.
Even the most elegant design fails if users can’t comfortably read or interact with it.

Accessibility ensures inclusivity and dark mode introduces unique visual challenges that we must address.

Accessibility means designing for everyone, including users with low vision or color blindness. In dark mode, even small mistakes in color contrast can make text unreadable.

Apply a Comfortable Dark Background

Open your style.css file:
In VS Code, click on style.css in the left sidebar. Then paste in the following CSScode:

body {
  background-color: #121212; /* softer than pure black */
  color: #E0E0E0; /* light gray text */
  font-family: Arial, Helvetica, sans-serif;
  line-height: 1.6;
  padding: 2rem;
}

Why not use pure black (#000000)?
Because white text on a pure black background causes glare, especially for users with astigmatism or light sensitivity (I am a pharmacist, you can believe me on this).
A dark gray background is easier on the eyes and improves readability.

Now that you’ve created a comfortable visual base, let’s refine your color palette for clarity and balance.

Choosing the Right Color Palette

Colors define how users perceive your interface, so good color contrast makes dark mode usable.

A good dark mode color palette is calm, readable, and adheres to WCAG 2.1 contrast standards (at least 4.5:1 for normal text).

Let us now bring the colors to life in our next step.

Add Color Variables

Now that we understand what a good dark mode color palette is, let’s define reusable color variables in your CSS for consistency.

Still in your style.css file, scroll to the top and add these color variables:

:root {
  --background-dark: #121212;
  --text-light: #E0E0E0;
  --accent-color: #BB86FC; /* soft purple */
}

body {
  background-color: var(--background-dark);
  color: var(--text-light);
}

button {
  background-color: var(--accent-color);
  color: #000;
  border: none;
  padding: 0.6rem 1rem;
  border-radius: 8px;
  cursor: pointer;
  font-weight: bold;
}

Tip: Use tools like Contrast Checker by WebAIM
to test your color combinations.

## Typography and Readability
Typography is where accessibility meets design.
Readable type keeps users engaged and reduces visual fatigue, especially in dark mode.

Readable typography is essential in dark mode.
Text should be slightly larger, well-spaced, and never pure white.

Update Your style.css File
Scroll down and add these new styles:

h1, h2 {
  font-weight: 600;
  margin-bottom: 0.5em;
}

p {
  font-size: 1.1rem;
  color: #E0E0E0; /* not pure white */
}

main {
  max-width: 700px;
  margin: 2rem auto;
}

Avoid ultra-thin fonts. They can fade or disappear against dark backgrounds. Stick to medium or bold weights for headings.

Now that your text is legible, it’s time to enhance your visual elements like icons and images.

Icons, Illustrations, and Imagery

Dark mode affects visuals too. Bright icons or images that look great in light mode may disappear in dark mode.

Add an Image

In your index.html, go to the section and add this line under the

tag:

<img src="light-logo.png" alt="Company logo" class="logo" />

Adjust the Image in CSS

Visuals add personality, but they can break dark mode if not optimized.
Icons may fade, and bright images can overpower the background.
To prevent this, balance brightness and contrast:
Open yourstyle.css again and add the following code:

.logo {
  filter: brightness(0.9) contrast(1.1);
  width: 50px;
}

For the best results, prepare two logo versions, one for light mode and one for dark mode, and switch them dynamically in JavaScript (we’ll cover that next).

Adding a Dark Mode Toggle (with JavaScript)

Let’s make your design interactive by allowing users to toggle between light and dark themes. We are empowering users to switch between light and dark modes with a simple button.

Add a Data Attribute

In your index.html, locate the <body> tag and modify it like this:

<body data-theme="light">

Add JavaScript to Toggle Themes

Now, open your script.js file (click on it in your editor) and paste this code:

const toggleBtn = document.getElementById("theme-toggle");
const body = document.body;

toggleBtn.addEventListener("click", () => {
  const currentTheme = body.getAttribute("data-theme");
  const newTheme = currentTheme === "dark" ? "light" : "dark";
  body.setAttribute("data-theme", newTheme);
});

Define Light and Dark Themes in CSS

Back in your style.css, scroll to the bottom and add:

[data-theme="light"] {
  --background-dark: #FFFFFF;
  --text-light: #111111;
  --accent-color: #6200EE;
}

[data-theme="dark"] {
  --background-dark: #121212;
  --text-light: #E0E0E0;
  --accent-color: #BB86FC;
}

Test it:

Save all files (Ctrl + S or Cmd + S).

Open index.html in your browser (double-click the file or run open index.html).

Click the Toggle Theme button, your dark mode should now switch dynamically like you see bellow.

Testing Accessibility

Never assume your design is accessible, always test it. Accessibility testing ensures your dark mode works for everyone, including users with visual impairments or those viewing your site under different lighting conditions.

Start by opening your project in a browser. Locate your index.html file inside the dark-mode-tutorial folder and double-click it to open. You can also right-click and choose Open With → Chrome, Firefox, or Edge. Try toggling between light and dark themes using the “Toggle Theme” button.

As you switch modes, check if your text remains readable and whether icons, buttons, and accents are still visible. The goal is for both themes to look balanced, comfortable, and easy on the eyes.

Next, test your color contrast ratio using WebAIM’s Contrast Checker. Copy your text and background colors from your CSS file (for example, #121212 and #E0E0E0) and paste them into the tool. Aim for a ratio of 4.5:1 or higher for normal text and 3:1 for larger text.

If your contrast ratio falls below the standard, adjust the colors slightly. Lighten the text or darken the background until the ratio improves. This small tweak makes a big difference for users with low vision or color sensitivity.

You can also use accessibility tools for deeper testing. The Stark Plugin in Figma or Adobe XD simulates color blindness and checks contrast instantly. In Chrome, open DevTools → Lighthouse → Accessibility and click Analyze page load to get a detailed accessibility score. Firefox users can check the Accessibility Tab under Ctrl + Shift + I.

Finally, perform a manual test. Turn on your room lights and review your page, is everything still clear? Then dim the lights or use your device’s dark mode and check again. If your page feels comfortable in both conditions, you’ve achieved true accessibility balance.

Case Studies & Best Practices

Many popular platforms have already mastered dark mode accessibility. Studying their design choices helps you create your own high-quality, inclusive themes.

GitHub, for example, uses dark gray backgrounds (#0D1117) instead of pure black. Its text (#C9D1D9) maintains strong contrast and consistency, ensuring comfort during long coding sessions. The key takeaway: readability always comes before aesthetics.

Slack takes a different approach by offering multiple dark themes. Users can choose what feels best for their eyes, proving that customization enhances accessibility. Choice empowers users with diverse vision needs.

Notion uses layered contrasts and soft shadows to separate elements clearly. Its design demonstrates how visual hierarchy, not just color contrast improves readability in dark environments.

When designing your own dark mode, avoid common mistakes. Don’t use pure black backgrounds with bright white text; they create harsh glare and eye strain. Steer clear of overly saturated accent colors or gray-on-gray combinations with poor contrast.

Instead, use subtle elevation effects such as shadows or slightly lighter backgrounds to separate elements. This creates depth and readability without overwhelming the user’s eyes.

Next Steps

Take your design further by adding smooth CSStransitions when switching between light and dark modes. You can also detect user preferences automatically using the prefers-color-scheme media query.

If possible, test your design with users who have color vision deficiencies or rely on assistive technologies like screen readers. Their feedback will help you refine your design for real-world use.

Conclusion

You’ve successfully created and tested an accessible dark mode interface. You learned how to balance colors, ensure readability, and test for inclusivity. Now your design doesn’t just look modern, it works beautifully for everyone.

Designing an accessible dark mode interface isn’t just about trendy visuals, it’s about empathy and inclusion. A well-crafted dark theme supports users who are light-sensitive, work at night, or simply prefer darker interfaces, ensuring comfort and usability for everyone.

Useful Resources

Getting Started with LambdaTest: A Comprehensive Beginner’s Guide

henry messiah tmt — Fri, 24 Oct 2025 23:11:35 +0000

Introduction

Today’s users expect flawless digital experiences, no matter which device, browser, or operating system they use. For developers and QA teams, ensuring that consistency across thousands of environments is no small feat.

LambdaTest makes that challenge simple. It’s a powerful cloud based testing platform that enables effortless manual and automated cross browser testing on more than 3,000 real browsers and devices, all without the need for local setups or physical labs.

Built for speed, scalability, and collaboration, LambdaTest integrates seamlessly with your existing CI/CD pipelines and popular tools like GitHub, Jenkins, and Jira. It supports leading automation frameworks such as Selenium, Cypress, Playwright, and Appium, empowering teams to test faster and release with confidence.

From real time debugging and visual regression testing to comprehensive analytics, screenshots, and video logs, LambdaTest gives you everything you need to ensure your application looks and performs perfectly everywhere.

In this Getting Started Guide, you’ll learn how to set up your account, navigate the dashboard, run your first manual and automated tests, and take your first steps toward a more efficient and reliable testing workflow.

Prerequisites

Before you begin, ensure you meet a few basic requirements to follow this guide smoothly. These will help you understand each step and execute your first test without issues.

You’ll need:

Node.js (v16+) and npm installed on your system
Basic JavaScript knowledge: comfortable with functions and syntax
Command line basics: you’ll be running npm commands and navigating folders
A modern browser: Chrome, Firefox, or Edge for accessing the LambdaTest dashboard
A stable internet connection: required for all cloud based testing

Optional but helpful:

Familiarity with manual or automated testing concepts
Experience using any testing framework like Selenium or Cypress

If you’re missing any of these, take a moment to set them up first, so that we can flow together seamlessly. Once these prerequisites are in place, you’re ready to create your LambdaTest account and start your first testing session.

Create a LambdaTest Account

Now that you’ve set up all the prerequisites, it’s time to step into the LambdaTest ecosystem by creating your personal account.

Before you can start testing, you’ll need to set up your LambdaTest account which is your entry point to the cloud testing ecosystem.

Steps to Get Started:

Visit LambdaTest.com
Click Sign Up for Free.
Create an account using your email, Google, or GitHub credentials.
Verify your email and log in to access your LambdaTest Dashboard.

LambdaTest’s free plan includes limited testing minutes and parallel sessions, enough to explore its key features before deciding to upgrade.

Once you’ve created your LambdaTest account, you’ll gain access to your personal dashboard, the command center where all your testing activities begin.

Next, you’ll learn how to explore and navigate the dashboard to understand where key tools and settings are located.

Explore the Dashboard

Once logged in, the Dashboard serves as your central hub for all testing activities. It provides easy access to real time tests, automation suites, visual regression tools, and detailed analytics, all from a single, user friendly interface.

From the Dashboard, You Can:

Launch Real Time Tests on live browsers
Run Automated Tests using your favorite framework
Access Visual Regression Testing tools to track UI changes
Review Test Logs & Analytics for detailed insights
Integrate tools like GitHub, Jenkins, Jira, and Slack
Use the left hand navigation panel to switch between features and manage your projects efficiently.

This is what the dashboard looks like

Run Your First Manual Test

Now that you’re familiar with the dashboard layout and its core features, you’re ready to take action.

In this step, you’ll learn how to run your first manual test, helping you see exactly how your website behaves across different browsers and operating systems in real time.

Manual testing on LambdaTest allows you to visually verify your website’s appearance and performance across multiple browsers, operating systems, and screen resolutions, without local setups.

Steps to Run a Manual Test:
From the Dashboard, navigate to Real Time > Browser Testing.

Enter your website’s URL (e.g., https://example.com) in the URL input space provided.

Select:

Operating System: Windows, macOS, or Linux
Browser & Version: Chrome, Firefox, Safari, Edge, etc.
Screen Resolution

Click Start to launch a live browser session.

Within seconds, LambdaTest opens your website in the selected environment. You can interact, inspect, and debug in real time, just like you would locally.

Use the built in developer tools, capture screenshots, and record sessions to streamline debugging. The developer tools are shown in the image bellow

The next image shows how you can screenshot and record sessions.

After successfully performing your first manual test, you’ll understand how LambdaTest helps you verify the visual and functional consistency of your site.

Next, you’ll take things a step further by learning how to automate your tests, saving time and improving efficiency across multiple test scenarios.

Run Your First Automated Test (Selenium Example)

Having experienced manual testing, it’s time to take things to the next level with automation.

Automated testing saves time and ensures reliability, especially for larger projects. LambdaTest supports major automation frameworks like Selenium, Cypress, Playwright, and Appium through its secure cloud grid.

In this section, you’ll learn how to set up and run your first automated Selenium test on LambdaTest using Node.js.

Set Up Your Environment

First, make sure Node.js (v16 or later) and npm are installed on your system.
If you have not installed Node.js then follow these steps to install it.

For Windows users
Open PowerShell or Command Prompt and run the following command:

winget install OpenJS.NodeJS.LTS

This installs the latest Long Term Support (LTS) version of Node.js using the Windows Package Manager.

For macOS Users
If you already have Homebrew installed, run the following command:

brew install node

If you don’t have Homebrew yet, install it first by running this command in your terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once Homebrew finishes installing, use it to install Node.js by running this command:

brew install node

For Both Windows and MacOS users
After installation we need to be sure that it was succefull. To verify that the installation was successful, open your terminal or command prompt and run the following commands:

node -v
npm -v

If both commands return version numbers, you’re ready to proceed.
If not, download and installNode.js from nodejs.org

Create a Project Folder
After verifying that the Node.js installation was successful you can now create a project folder. You’ll need a folder to keep all your test files organized.

In your terminal, run the following commands to creat a new folder called lambdatest-automation :

mkdir lambdatest-automation

Now, use the following command to navigate into the new folder we have called lambdatest-automation:

cd lambdatest-automation

With the above command we are now inside the new folder we created.

Initialize a Node.js Project

Now, initialize your project with npm (Node Package Manager).
This creates a package.json file that tracks your project dependencies.
To achieve that run the following command inside the project folder:

npm init -y

The -y flag automatically accepts all default options.

Install Selenium WebDriver
Next, install the Selenium library for JavaScript. To achieve that run the following command inside the project folder:

npm install selenium-webdriver

This command downloads and installs Selenium into your project folder, allowing you to write and execute browser automation scripts.

Add Your LambdaTest Credentials

Before running tests, you need to provide your LambdaTest Username and Access Key.
You can find them in your LambdaTest Dashboard under Profile → Account Settings → Access Key.

The image below shows where to locate your credentials:

Once you have them, add them as environment variables in your terminal.

For Windows (PowerShell)run the following command in your project folder:

setx LT_USERNAME "your_username"
setx LT_ACCESS_KEY "your_access_key"

For macOS/Linux run the following command in your project folder:

export LT_USERNAME="your_username"
export LT_ACCESS_KEY="your_access_key"

This securely stores your credentials on your system so your test script can access them.

Create the Test File

Now, create a new file named lambdatest.jsinside your project folder.

If you’re using the terminal, run the following command:

touch lambdatest.js

You can now navigate into the test file using the following command:

cd lambdatest.js

(If you’re on Windows and touch doesn’t work, you can manually create the file in your folder using File Explorer.)

Then, open the file in your preferred code editor (e.g., VS Code).

Write Your Selenium Test Code

Copy and paste the following code into lambdatest.js:

const { Builder } = require('selenium-webdriver');

(async function runTest() {
  const capabilities = {
    browserName: "Chrome",
    browserVersion: "latest",
    "LT:Options": {
      platformName: "Windows 10",
      build: "Getting Started Sample Build",
      name: "My First LambdaTest",
      user: process.env.LT_USERNAME,
      accessKey: process.env.LT_ACCESS_KEY,
    },
  };

  const driver = await new Builder()
    .usingServer("https://hub.lambdatest.com/wd/hub")
    .withCapabilities(capabilities)
    .build();

  await driver.get("https://www.lambdatest.com");
  console.log(await driver.getTitle());
  await driver.quit();
})();

This simple script launches Chrome on Windows 10 in the LambdaTest cloud, opens the LambdaTest homepage, prints its title, and closes the session.

Run the Test
You’re now ready to execute your first automated test!
From your project folder, run the following command:

node lambdatest.js

This command tells Node.js to execute your Selenium script.

Once the test starts, LambdaTest will automatically open a cloud browser session and run your test.

View Your Test Session
After running the test, go to your LambdaTest Dashboard → Automation → Test Logs.
You’ll see your session appear under “Recent Tests.”

Click the session to view:

Logs: Console and network logs
Screenshots & Video Recordings: To review test execution
Session Details: Browser, OS, build name, and duration

Use Smart UI for Visual Testing

LambdaTest’s Smart UI feature helps detect pixel level visual differences between builds.
You can enable it from the Automation Dashboard to ensure your design remains consistent across updates.

By reviewing your test data, you’ll learn how to identify bugs, confirm design accuracy, and maintain UI consistency across multiple browsers.

Use the Smart UI feature to perform visual regression testing, detecting pixel level UI discrepancies between builds for consistent design validation.

After reviewing your results, you’ll know how to analyze test data, identify issues, and confirm visual accuracy using Smart UI.

Next, you’ll learn how to troubleshoot common issues, ensuring that any challenges you encounter can be quickly resolved.

Troubleshooting Common Issues

When using LambdaTest, you might occasionally run into problems while running your tests. Here’s a breakdown of some common issues, their likely causes, and how you can fix them effectively.

1. Session Not Starting
If your test session fails to start, the most common reason is invalid credentials. LambdaTest requires your correct username and access key to authenticate with its servers. Double check these details under Profile → Account Settings on your dashboard, and ensure that your environment variables (LT_USERNAME and LT_ACCESS_KEY) are properly set in your system before running any test.

2. Browser Not Launching
Sometimes, the browser you select may not open during testing. This often happens when you’ve chosen an unsupported browser version. To resolve this, verify that the browser and version combination you’re using is supported by LambdaTest. You can find a complete list of supported browsers and OS combinations on their platform documentation or within the test configuration panel.

3. Test Timeout
If your tests are failing due to timeouts, it’s likely a result of network latency or slow website responses. To fix this, consider increasing the timeout duration in your test script. You can adjust Selenium’s implicit or explicit wait times to give your pages more time to load. It’s also worth ensuring your internet connection is stable before initiating long test runs.

4. Localhost Not Loading
When testing locally hosted websites or staging environments, you might encounter problems accessing your localhost URL. This usually means the LambdaTest Tunnel isn’t configured correctly. The tunnel acts as a secure bridge between your local system and LambdaTest’s cloud grid. To solve this, install and run the LambdaTest Tunnel binary, then verify that it’s connected successfully before starting your tests.

If you continue to experience issues after trying these fixes, visit the LambdaTest Support Center
for detailed documentation, community discussions, and real-time help from their support team.

By learning to troubleshoot common testing challenges, you’ll become more confident in managing and optimizing your testing sessions.

Next, you’ll explore advanced LambdaTest features and integrations, empowering you to streamline testing workflows and enhance team collaboration.

Next Steps

Congratulations, you’ve run your first manual and automated tests! To take your skills further, explore these advanced capabilities:

Parallel Testing: Execute multiple tests simultaneously to speed up your testing cycle.
CI/CD Integrations: Connect LambdaTest with Jenkins, GitHub Actions, or Azure DevOps.
Visual Regression Testing: Automatically detect UI inconsistencies between builds.
Local App Testing: Use LambdaTest Tunnel to test staging or internal environments securely.

With a solid foundation in manual and automated testing, you’re ready to expand your testing strategy.

Conclusion

By following this guide, you’ve learned how to create and set up your LambdaTest account. You now know how to configure your workspace and testing environment. This ensures a smooth start as you begin running tests across browsers and devices.

You’ve also explored how to navigate the LambdaTest dashboard efficiently. Its clean layout makes it easy to access real-time tests, automation tools, and analytics. With this, managing sessions and reviewing results becomes quick and intuitive.

Lastly, you’ve mastered running both manual and automated tests while learning to analyze logs and troubleshoot issues. These skills prepare you to integrate LambdaTest into your CI/CD workflow. Now you can deliver faster, more reliable, and consistent digital experiences.

For more detailed information and advanced configurations, you can visit the official LambdaTest Documentation page to explore further.

Automating Jasmine Tests with GitHub Actions for Continuous Integration

henry messiah tmt — Sat, 18 Oct 2025 16:19:19 +0000

Introduction

Manual testing can quickly become a problem in your development workflow. Every time you need to remember to run tests. This process would not only waste valuable time but also increase the risk of human error; it's quite very common to forget a test or accidentally merge faulty code when you're in a hurry.

That's why this article is important because it introduces how you integrate Jasmine tests with GitHub Actions to create a fully automated testing pipeline, and walks through how to write sample tests and automate them to run on every push or pull request made in your future projects. So you no longer manually run your test, you push with a crossed finger, hoping you pass.

Prerequisites

Before diving into this tutorial, you'll need:

Node.js (v16+) and npm installed on your machine
Basic JavaScript knowledge - You should be comfortable writing functions and understanding basic syntax
Git fundamentals - Know how to commit, push, and work with branches
A GitHub account - Required for setting up GitHub Actions
Command line basics - You'll be running npm commands and navigating directories

Optional but helpful:

Familiarity with testing concepts (though we'll cover the basics)
Previous experience with any testing framework

If you're missing any of these, take some time to set them up first. Everything else we'll build together from scratch.

Setting up your project

First, we need to set up a new Node.js project. This will create a package.json file, which keeps track of all dependencies and scripts for our project.
Open your terminal (or command prompt) and follow these steps:
Create a new folder for the project using the following command

    mkdir project

Navigate into the project folder using the following command

    cd project

Initialize a new Node.js project inside the folder using the following command

    npm init -y

This command initializes a Node.js project with default settings and automatically generates a package.json file inside your project directory.

Next, we will need to install Jasmine as a development dependency. To do that, run this command in the project folder.

    npm install jasmine --save-dev

To initialize Jasmine, you will need to run this command in the project folder.

    npx jasmine init

When you do, you will see a default configuration file named jasmine.json.

Now that we have successfully installed and initialized Jasmine, we need to create a simple test to confirm that Jasmine is working correctly in our project. To do that, follow these steps:

Create a new folder called spec inside your project directory. This is where Jasmine expects your test files to be stored. Use this command to create the spec folder

    mkdir spec

Navigate into the spec folder using the following command

    cd spec

Inside the spec folder, create a new test file named sampleSpec.js using this command

    touch sampleSpec.js

If you’re on Windows and touch doesn’t work, use:

    echo > sampleSpec.js

Open the sampleSpec.js file in your code editor and add the following test code:

    describe("Sample Test", function() {
      it("adds numbers correctly", function() {
        expect(1 + 1).toBe(2);
      });
    });

This simple test checks if 1 + 1 equals 2. If Jasmine is set up correctly, this test will pass when you run it.

Finally, run your test locally. This verifies that Jasmine is correctly installed and configured. Let’s run the following command in our terminal:

    npx jasmine

A passing test confirms that your setup is complete and ready for CI integration. When your tests run successfully, Jasmine will display green indicators showing that all checks have passed, just like in the image below.

However, not all tests are meant to pass immediately. Sometimes, developers intentionally write failing tests to verify that Jasmine correctly detects errors or to test incomplete features under development. These failing tests serve as a guide, reminding you of areas that still need attention or improvement. Once the issue is resolved or the feature is implemented, those tests should then pass, confirming that your fix or new functionality works as expected.
This balance between passing and expected failing tests is a key part of effective test-driven development, ensuring your project grows with confidence and precision.

Example folder structure
Now that you’ve successfully set up and tested your Jasmine environment, it’s important to organize your files for better clarity and maintainability.
Use this structure as a reference:

    project/
    │
    ├── spec/
    │   └── sampleSpec.js
    ├── src/
    │   └── app.js
    ├── package.json
    ├── jasmine.json
    └── .github/
        └── workflows/
            └── test.yml

This layout separates your test files, source code, and CI configurations clearly. It helps you and your team maintain order as your project grows.
Now that we have neatly organized files, you can proceed to automate the testing process using GitHub Actions.

Add GitHub Actions workflow

With your project structure in place, the next step is to automate your testing process. By using GitHub Actions, you can ensure your Jasmine tests run automatically whenever you push new code or open a pull request.

Create a workflow file at .github/workflows/test.yml. This file tells GitHub Actions what to do during each run.

    name: Run Jasmine Tests

    on:
      push:
      pull_request:

    jobs:
      test:
        runs-on: ubuntu-latest

        steps:
          - name: Checkout code
            uses: actions/checkout@v4

          - name: Set up Node.js
            uses: actions/setup-node@v4
            with:
              node-version: '20'

          - name: Install dependencies
            run: npm install

          - name: Run tests
            run: npx jasmine

Each step performs a key task:

Checkout code downloads your repository to the workflow runner.
Set up Node.js ensure the correct runtime version.
Install dependencies gets all required packages.
Run tests executes Jasmine to validate your code.

This setup guarantees that your code is tested automatically on every commit.
Now that the automation workflow is ready, the next step is to push your code to GitHub and trigger the workflow in action.

Trigger the workflow

You’ve defined your CI workflow, now it’s time to see it work. Committing and pushing your files to GitHub connects your project to the automated testing pipeline.

Commit your files and push them to the main branch:

    git add .
    git commit -m "Set up Jasmine CI workflow"
    git push origin main

Each push triggers the workflow defined in test.yml. GitHub Actions installs dependencies and runs your tests automatically. Now that your workflow has been triggered, let’s verify that it runs successfully and that your tests pass as expected.

Verify the workflow

At this point, your tests should be running automatically in GitHub Actions. It’s important to confirm that everything executes correctly and that your CI pipeline is stable.
Follow these steps to verify:

Open your repository on GitHub.
Click the Actions tab.
Select your workflow from the list.
Check the log to confirm that all steps completed and tests passed.

The image below shows what it will look like:

If any step fails, review the logs to identify configuration or test issues. Fixing them early prevents broken code from merging.

Once you’ve confirmed that your workflow works, you can optionally add a visual indicator to your repository, a status badge that shows whether your tests are passing or failing.

Add test status badges (optional)

Now that your CI pipeline is up and running, adding a status badge provides instant visibility into your project’s health. Badges are especially useful for open-source projects and team collaboration.
Add this line to your README.md file: https://github.com/your-username/your-repo/actions/workflows/test.yml/badge.svg. This will show the status of the test if passed or failed:

The badge updates automatically after every workflow run. This adds visibility and helps collaborators monitor build status at a glance. With your automated workflow complete, let’s look at a few best practices to make your testing process more reliable and efficient.

Tips for reliable testing

Now that your Jasmine tests run automatically with each commit, maintaining consistency and reliability becomes crucial. Following these best practices ensures that your CI pipeline stays fast, dependable, and easy to maintain over time.

1. Keep tests small and independent
Write focused tests that check one specific functionality at a time. This makes it easier to identify which part of your code is failing when an error occurs. Independent tests can run in any order without affecting each other, which improves accuracy and speeds up debugging.

2. Avoid relying on external data sources
Tests should not depend on external APIs, databases, or network connections. These can introduce delays or failures unrelated to your actual code. Instead, use mock data or stubs to simulate external responses, ensuring that your tests remain stable even when you’re offline.

3. Run tests locally before committing
Always run your Jasmine tests locally before pushing code to your repository. This helps you catch issues early, saving time and preventing unnecessary CI failures. A quick local test run ensures that only clean, working code reaches your remote branch.

4. Cache dependencies in CI for faster execution
Most CI systems (like GitHub Actions) allow you to cache dependencies such as node_modules. Caching means that repeated builds won’t reinstall all packages from scratch, significantly reducing test run times and improving overall pipeline efficiency.

By applying these practices, your automated testing workflow becomes more reliable, efficient, and scalable. You’ll spend less time fixing broken builds and more time focusing on writing high-quality, maintainable code.

Conclusion

You now understand how to install essential dependencies, configure Jasmine for your project, and create a workflow that runs tests automatically with every push or pull request. More importantly, you’ve seen how continuous integration helps detect bugs early, keeps your code clean, and verifies every change before merging all without manual intervention.

Applying what you’ve learned will greatly improve your workflow. Automated testing reduces errors, accelerates feedback, and boosts confidence in your codebase. With Jasmine and GitHub Actions working together, you’ve built a strong foundation for reliability and efficiency in every update.

From Pills to Programming: My Journey from Pharmacy to Software Development

henry messiah tmt — Sun, 05 Oct 2025 20:31:20 +0000

My journey began in the structured halls of pharmacy school, where science met service, and every formula represented a step toward saving lives. As a young student, I was driven by a passion for health care and a desire to make meaningful contributions to society. I poured my energy into learning and service, graduating as the second-best student in my class with honors, a recognition that did not just reward academic excellence, but also my discipline, resilience, and vision for the future.
After pharmacy school, I channeled my passion into entrepreneurship, founding Mexicare Pharmacy and Co. Ltd. As CEO, I was not just responsible for medicines and prescriptions, but for building a brand rooted in trust, innovation, and excellence. Managing a business required me to go beyond clinical knowledge. I had to understand people, logistics, technology, and leadership. That experience taught me how to balance precision with empathy and structure with adaptability.
Yet, my thirst for knowledge did not stop at the pharmacy counter. I pursued a Master’s degree in Clinical Pharmacy, deepening my expertise in pharmacotherapy and patient-centered care. To complement this, I ventured into the field of health informatics, an intersection of health and computer science. This was my first formal step into the world of data and algorithms, and it opened my eyes to the power of computation in solving real-world health problems.
It was during my graduate studies that I developed a keen interest in data analysis. I trained in tools like Excel, SPSS, and GraphPad, learning to translate complex datasets into meaningful insights. I discovered how numbers can tell stories, predict outcomes, and shape decisions. This phase sharpened my analytical thinking and laid a strong foundation for the next chapter of my journey.
Now, I am stepping boldly into the world of software development, equipped with foundational and intermediate skills in HTML, CSS, JavaScript, and React.js. What began as curiosity has evolved into a new passion, a desire to build, create, and innovate in the digital space. Software development excites me because it offers limitless possibilities. Just as I once compounded formulas for healing, I now write code that solves problems, connects people, and enhances lives.
As part of my transition into tech, I have built several projects that demonstrate my growing expertise and creativity. These include a personal portfolio website that showcases my work and skills; a weather app that provides real-time weather conditions for any city; a digital stopwatch; an interactive rock-paper-scissors game; a digital clock; and an Amazon clone website built with React and modern web development principles. Each of these projects taught me how to think like a software developer, focusing on functionality, user experience, and scalability.
Alongside coding, I have developed a strong interest in technical writing, which is the art of explaining complex technical concepts with clarity and precision. Through my articles and documentation, I aim to make technology more accessible to beginners while maintaining the accuracy professionals expect. I’ve written step-by-step guides on building JavaScript projects and creating responsive interfaces, honing my ability to communicate effectively across both technical and non-technical audiences. Example of such an article published in dev. to is How to build a digital clock using JavaScript.
My path may seem unconventional, from clinical pharmacy to entrepreneurship, from health informatics to programming, but at the heart of it all is a commitment to growth and impact. Each stage has equipped me with unique tools: precision from pharmacy, leadership from business, analysis from research, and creativity from coding.
I do not see this as a career change, but rather a career evolution. Today, as I continue learning and building in tech, I carry with me the discipline of a pharmacist, the vision of a CEO, the curiosity of a researcher, the clarity of a technical writer, and the innovation of a software engineer.
This is my story, and it is only just beginning.

How To Create A Digital Clock Using JavaScript

henry messiah tmt — Sun, 05 Oct 2025 16:49:09 +0000

Introduction

Time is everywhere, on our phones, computers, and even our microwaves. But have you ever wondered how a digital clock actually works behind the scenes? Building a digital clock with JavaScript is not only a fun, beginner-friendly project but also an excellent way to strengthen your understanding of real-time updates, DOM manipulation, and event-driven programming.

In this guide, you’ll learn how to create a fully functional digital clock from scratch using just HTML, CSS, and JavaScript. By the end, you’ll have a sleek clock that updates automatically every second, perfect for embedding in a webpage, dashboard, or even as a standalone utility.

Whether you are just starting your coding journey or looking to sharpen your JavaScript skills, this project will help you achieve the following:

Master working with Date objects.
Practice dynamic content updates using the DOM.
Enhance your styling and layout skills with CSS.

Let’s get started and bring your own digital clock to life.

Project Setup

Before we dive into writing the code, we need to set up a simple working environment for our digital clock. This project is lightweight and doesn’t require any special frameworks or tools; all you need is your browser and a text editor.

Create a Project Folder

Create a new folder on your computer and name it digital-clock. This will keep all your project files organized.

Create the Essential Files
After creating the folder that will keep all our files together, we can now create the different files we need.

Inside your project folder, which we have named digital-clock, create the following files:

index.htmlThis will contain the structure of the clock.
clock.cssThis will handle the visual design of the clock.
clock.js This will contain the JavaScript logic that makes the clock work.

Your project folder should now look like this:

digital-clock/
  ├── index.html
  ├── clock.css
  └── clock.js

When we are done with the project, this is what the digital clock will look like.

Don't forget to link the clock.css and the clock.js files to the index.htmlfile properly.
Link the clock.css inside the HTML

with then Link the clock.jsbefore the closing tag with .

Build The HTML Structure

Now that our project setup is complete and we have all the necessary files ready, it’s time to start building the foundation of our digital clock, the HTML structure.

This step focuses on creating the basic layout that will display the time on the webpage. It defines what elements appear on the page and how they are organized.

We’ll be adding simple elements that represent the digital clock display, which we’ll later style using CSS and make interactive with JavaScript.

Let’s dive into the HTML part of our project and bring the structure of our digital clock to life.

Open the index.html file and write the following code.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=0.5">
  <title>digital clock</title>
  <link rel="stylesheet" href="clock.css">
</head>
<body>
  <div id="clock-container">
    <div id="clock">00:00:00</div>
  </div>
  <script src="clock.js"></script>
</body>
</html>

Add The CSS Code

Now that we’ve built the structure of our digital clock using HTML, it’s time to make it visually appealing with CSS.

While HTML gives our project its form, CSS adds style, color, and aesthetics, turning a plain layout into an attractive digital display. In this step, we’ll design the clock to look clean, centered, easy to read, and add a background image.

We’ll focus on aligning the clock at the center of the screen, choosing the right font, and giving it a glowing digital feel.

Let’s move on and make the clock beautiful with some sleek and responsive styling using CSS.

Open the clock.css file and add the following code

  body{
  background-image: url(premium_photo-1661954654458-c673671d4a08.avif);
  background-position: center;
  background-repeat: no-repeat;
  background-size: cover;
  background-attachment: fixed;
  margin: 0;
}
#clock-container{
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
}
#clock{
  font-family: monospace;
  font-size: 6.5rem;
  font-weight: bold;
  text-align: center;
  color: white;
  backdrop-filter: blur(5px);
  background-color: hsl(0, 0%, 100%, 0.1);
  width: 100%;

}

At this stage, the digital clock looks exactly as our final product above, but it is not functional.

Add The JavaScript Logic

With the structure and styling in place, our digital clock now looks great, but it doesn’t tick yet. To make it come alive and update in real time, we need to add the JavaScript logic.

JavaScript is the brain of our project. It’s what allows the clock to fetch the current time, update the numbers every second, and display the hours, minutes, and seconds dynamically.

In this section, we’ll write the code that powers the functionality behind the clock, ensuring it runs smoothly and reflects the exact time on your device, just like a real digital clock.

Let’s dive in and give our clock its heartbeat with JavaScript.

Open the clock.js file and add the following code.

function updateClock() {
  const now = new Date();
  let hours = now.getHours();
  const meridien = hours >= 12 ? "PM": "AM";
  hours = hours % 12 || 12;
  hours = hours.toString().padStart(2, 0);
  const minutes = now.getMinutes().toString().padStart(2, 0);
  const seconds = now.getSeconds().toString().padStart(2, 0);
  const timeString = `${hours}:${minutes}:${seconds} ${meridien}`;
  document.getElementById("clock").textContent = timeString;
}

updateClock();
setInterval(updateClock, 1000);

A link to the fully functional clock is available here

User Interface Overview

The user interface of our digital clock is designed to be clean, elegant, and easy to read. The background image fills the entire screen, creating a modern and visually appealing environment, while the clock itself is centered perfectly on the page using CSS Flexbox. This ensures the layout remains balanced and responsive across all screen sizes from desktops to mobile devices.

At the center of the screen, the clock displays bold white digits in a monospace font, giving it a classic digital appearance. The large font size and even spacing make the time clearly visible at a glance. A subtle blur and semi-transparent background sit behind the clock, creating a smooth, glasslike effect that highlights the numbers and enhances readability regardless of the background image.

When the JavaScript logic runs, the clock updates automatically every second, bringing the interface to life with real-time motion. The result is a simple yet sophisticated digital clock that combines functionality with a sleek, modern design, perfect for embedding in any webpage or dashboard.

Conclusion

Building a digital clock with HTML, CSS, and JavaScript is a simple yet powerful project that brings together the core principles of front-end development, which include structure, style, and interactivity. Through this project, you’ve learned how to use JavaScript’s Date object to track real-time updates, manipulate the DOM to display dynamic content, and apply CSS to craft a clean, responsive design.

Beyond just displaying time, this project demonstrates how a few lines of code can transform basic concepts into a visually engaging and functional application. You can now take what you’ve learned and expand it, add new features, experiment with different designs, or even integrate it into a larger web project. With every enhancement, you’ll continue sharpening your coding skills and developing a stronger understanding of how JavaScript brings web pages to life.

Although the digital clock works perfectly, it can be enhanced with features like a date display, theme customization, and options to switch between 12-hour and 24-hour formats. Adding smooth animations, time zone selection, or dynamic greetings such as “Good Morning” or “Good Night” would make it more interactive, while expanding it with a countdown timer or stopwatch could turn it into a versatile time utility, all great ways to strengthen your JavaScript and front-end development skills further.

How To Build A Note Taking Application With JavaScript

henry messiah tmt — Sun, 28 Sep 2025 13:28:50 +0000

Building software often starts with solving everyday problems. One common problem is how to keep track of important information. People take notes during meetings, while studying, or when planning personal tasks. Paper notes get lost, and static files are hard to update. A digital note taking app offers a practical solution.

A note taking app allows you to create, edit, organize, and store notes in one place. It helps you keep information structured and easy to access. With simple features, you can add a title, write your content, assign tags, and search through your notes later. Storing notes in local storage ensures that your data remains available even after closing the browser.

This tutorial will guide you through the process of building a note taking app using JavaScript, HTML, and CSS. You will learn how to:
• Create a user interface for writing and displaying notes
• Add functionality to create, edit, and delete notes
• Build a search feature to filter notes by keywords or tags
• Store and retrieve notes using local storage
• Add a web clipping feature to save selected webpage text into your notes
By following these steps, you will complete a working note taking application that runs directly in the browser and supports practical features for managing your notes efficiently.

System Requirements

Browser Compatibility

• Google Chrome (recommended).
• Mozilla Firefox.
• Microsoft Edge.
• Safari.

Dependencies
• None. The app uses pure HTML, CSS, and JavaScript (no frameworks required).

Technologies Used: An outline of the foundational web technologies needed.

HTML5 (for structuring the app)
CSS3 (for styling)
JavaScript (for functionality)
Browser Local Storage (for data persistence)

Project Setup

Now that we have installed all basic requirements, we can now proceed to set up the project structure in our code editor.

At this stage we will learn how to open folder and arrange the file structure of the project. To do that, follow the steps bellow:

Folder structure

This is how the folder structure will look like.

note-taking-app/
  index.html
  style.css
  script.js

Steps
Let us follow these steps to create the folder and the files to structure our project.

Create a folder named note-taking-app.
Inside it, add three files: index.html, style.css, and script.js
Link style.css inside the HTML <head> with <link rel="stylesheet" href="style.css">.
Link script.js before the closing </body> tag with <script src="script.js"></script>.

At the end of the project, if you follow the exact codes bellow, this is what the product would look like.

Step 1: Build the HTML Structure

Now that we have created the folder and the files required for the project, we will now start to write the codes for the project.

In this step, we will write the HTML codes for the project, the html codes will determine the physical appearance of the project. Follow the steps bellow and write the codes to achieve the desired result.

Open theindex.html file and add the following code.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>Notes</title>
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <header>
    <h1>Notes</h1>
    <div class="controls">
      <input id="search" placeholder="Search notes">
      <button id="newNote">New Note</button>
    </div>
  </header>

  <main>
    <aside id="list"></aside>

    <section id="editor" class="hidden">
      <input id="title" placeholder="Title">
      <textarea id="content" placeholder="Write your note here"></textarea>
      <div class="editor-actions">
        <input id="tags" placeholder="Tags separated by commas">
        <button id="save">Save</button>
        <button id="delete">Delete</button>
        <button id="close">Close</button>
      </div>
    </section>
  </main>

  <script src="script.js"></script>
</body>
</html>

Navigation Bar (header): Contains the app title, a search box, and a button to create new notes.
Notes List Panel (aside): Displays all saved notes.
Editor Panel (section): Provides fields for writing, tagging, saving, or deleting notes. Hidden by default until a note is opened or created.

Step 2: Add CSS Styling

Now that we have written the HTML codes for the project, we can now write the CSS codes for the project that would be responsible for the beautification and positioning of the elements in the project.

Open the style.css file and add the following codes.

html, body {
  height: 100%;
  margin: 0;
  font-family: system-ui, Arial, Helvetica;
}

header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 12px;
  border-bottom: 1px solid #ddd;
}

.controls input {
  padding: 8px;
  margin-right: 8px;
  width: 220px;
}

main {
  display: flex;
  height: calc(100% - 64px);
}

aside#list {
  width: 320px;
  border-right: 1px solid #eee;
  overflow: auto;
  padding: 12px;
  box-sizing: border-box;
}

.note-item {
  padding: 10px;
  border: 1px solid #f0f0f0;
  margin-bottom: 8px;
  cursor: pointer;
}

.note-item .meta {
  font-size: 12px;
  color: #666;
}

section#editor {
  flex: 1;
  padding: 12px;
  box-sizing: border-box;
}

section.hidden {
  display: none;
}

input, textarea, button {
  font-size: 14px;
  box-sizing: border-box;
}

#title {
  width: 100%;
  padding: 8px;
  margin-bottom: 8px;
}

#content {
  width: 100%;
  height: 60vh;
  padding: 8px;
  margin-bottom: 8px;
}

.editor-actions {
  display: flex;
  gap: 8px;
  align-items: center;
}

.app-note-tag {
  display: inline-block;
  padding: 2px 6px;
  margin-right: 6px;
  margin-top: 6px;
  border-radius: 4px;
  background: #f3f3f3;
  font-size: 12px;
}

Header Styling: Creates a top navigation bar with search and button.
Sidebar Styling: Sets width and scroll behavior for the notes list.
Editor Styling: Expands the editor panel and makes it flexible.
Note Item Styling: Adds borders, spacing, and hover-friendly design.
Responsive Layout: Flexbox ensures panels resize correctly.

Step 3: Add JavaScript Functionality

After we have written the CSS codes for the beautification of the project, we can now write the javaScript code to make the project interactive and functional.

Open the script.js file and add the following codes:

Setup and Local Storage (Initialization): This aspect of the code handles data persistence, making sure notes survive page reloads.

const storageKey = 'notes-v1'
let notes = []
let activeId = null

// Shortcut for selecting elements
const el = id => document.getElementById(id)

// Save notes to local storage
const saveToStorage = () => {
  localStorage.setItem(storageKey, JSON.stringify(notes))
}

// Load notes from local storage
const loadFromStorage = () => {
  const raw = localStorage.getItem(storageKey)
  if (!raw) return
  try {
    notes = JSON.parse(raw)
  } catch {
    notes = []
  }
}

Rendering and Displaying Notes:

This aspect of the code ensures users can see and search through their notes.

// Format timestamp into a readable string
const formatDate = ts => {
  const d = new Date(ts)
  return d.toLocaleString()
}

// Render list of notes in the sidebar
const renderList = filter => {
  const list = el('list')
  list.innerHTML = ''

  // Filter and sort notes
  const items = notes
    .filter(n => {
      if (!filter) return true
      const s = filter.toLowerCase()
      return n.title.toLowerCase().includes(s)
        || n.content.toLowerCase().includes(s)
        || (n.tags || []).join(' ').toLowerCase().includes(s)
    })
    .sort((a, b) => b.updated - a.updated)

  // Show message if no notes found
  if (items.length === 0) {
    const p = document.createElement('div')
    p.textContent = 'No notes found'
    list.appendChild(p)
    return
  }

  // Render each note as a card in the list
  items.forEach(n => {
    const item = document.createElement('div')
    item.className = 'note-item'
    item.dataset.id = n.id

    const h = document.createElement('div')
    h.textContent = n.title || 'Untitled'
    item.appendChild(h)

    const meta = document.createElement('div')
    meta.className = 'meta'
    meta.textContent = formatDate(n.updated)
    item.appendChild(meta)

    // Add tags (if any)
    if (n.tags && n.tags.length) {
      const tagWrap = document.createElement('div')
      n.tags.slice(0, 3).forEach(t => {
        const tspan = document.createElement('span')
        tspan.className = 'app-note-tag'
        tspan.textContent = t
        tagWrap.appendChild(tspan)
      })
      item.appendChild(tagWrap)
    }

    // Click event to open note in editor
    item.addEventListener('click', () => openEditor(n.id))
    list.appendChild(item)
  })
}

Editor Functions (Open, Close, Create, Save, Delete):

This aspect of the code provides the core functionality of the app, that is for the user to be able to create, read, update, and delete notes.

// Open editor for a specific note
const openEditor = id => {
  activeId = id
  const note = notes.find(x => x.id === id)
  el('editor').classList.remove('hidden')
  el('title').value = note.title || ''
  el('content').value = note.content || ''
  el('tags').value = (note.tags || []).join(',')
}

// Close editor and reset inputs
const closeEditor = () => {
  activeId = null
  el('editor').classList.add('hidden')
  el('title').value = ''
  el('content').value = ''
  el('tags').value = ''
}

// Create a new note
const createNote = () => {
  const id = 'n_' + Date.now()
  const now = Date.now()
  const note = {
    id,
    title: '',
    content: '',
    tags: [],
    created: now,
    updated: now
  }
  notes.push(note)
  saveToStorage()
  renderList(el('search').value)
  openEditor(id)
}

// Save current note
const saveNote = () => {
  if (!activeId) return
  const note = notes.find(x => x.id === activeId)
  if (!note) return
  note.title = el('title').value.trim()
  note.content = el('content').value.trim()
  note.tags = el('tags').value.split(',').map(s => s.trim()).filter(Boolean)
  note.updated = Date.now()
  saveToStorage()
  renderList(el('search').value)
  closeEditor()
}

// Delete current note
const deleteNote = () => {
  if (!activeId) return
  notes = notes.filter(x => x.id !== activeId)
  saveToStorage()
  renderList(el('search').value)
  closeEditor()
}

Event Binding and App Initialization:
This aspect of the code handles user interactions and the application startup.

// Bind user events
const bind = () => {
  el('newNote').addEventListener('click', createNote)
  el('save').addEventListener('click', saveNote)
  el('delete').addEventListener('click', deleteNote)
  el('close').addEventListener('click', closeEditor)
  el('search').addEventListener('input', e => renderList(e.target.value))

  // Keyboard shortcut: Ctrl + N creates a new note
  document.addEventListener('keydown', e => {
    if (e.ctrlKey && e.key === 'n') {
      e.preventDefault()
      createNote()
    }
  })
}

// Initialize app
const init = () => {
  loadFromStorage()
  bind()
  renderList()
}

init()

User Interface Overview

The user interface shows what the user will see when the user wants to use the product. The user will see Navigation Bar that includes title, search bar, and New Note button. A Notes List Panel that displays all saved notes. An Editor Panel that includes Text area with title, tags, and action buttons. Search and Filter that can filter notes by keywords or tags.
This is the exact image the user will see.

Future Enhancements

Possible future enhancements that can be added to the project includes the following:

Cloud sync across devices
User authentication and login
Rich text editing with formatting options

Conclusion

This tutorial showed how to build a complete note-taking app with HTML, CSS, and JavaScript. You learned how to manage data with local storage, render a dynamic interface, and handle user interactions. This is a foundation you can extend with more advanced features like categories, cloud sync, or authentication.

Understanding Object-Oriented Programming (OOP) in JavaScript

henry messiah tmt — Sat, 13 Sep 2025 10:29:14 +0000

Introduction

Programming is much like building a city. You don’t throw bricks, cement, and metal randomly together, instead you carefully organize them into structures like houses, schools, and hospitals. In the same way, coding requires structure and organization to make programs easy to build, extend, and maintain.

This is where Object-Oriented Programming (OOP) comes in. OOP is a programming paradigm that allows developers to model real-world entities as objects with properties (data) and behaviors (functions). In JavaScript, OOP is extremely powerful because it makes your code reusable, scalable, and easier to understand.

Understanding OOP in JavaScript is important because it gives you the foundation to work on complex projects, collaborate with teams, and write clean, modular code that mirrors real-life situations.

In this tutorial, we aim to simplify the concept of Object-Oriented Programming (OOP) and make it easy to understand for learners at all levels. By the end of this guide, readers will not only grasp the fundamental principles of OOP but will also be able to confidently apply them in building both simple and complex projects.

What is Object-Oriented Programming (OOP)?

Object-Oriented Programming (OOP) is a way of writing code where you structure it around objects. An object is a collection of properties (attributes) and methods (functions) that describe and control a specific thing.
JavaScript, unlike some traditional OOP languages like Java or C++, is prototype-based, but with the introduction of ES6, we now have the class syntax that makes OOP in JavaScript more familiar and readable.

Core Principles of OOP in JavaScript

There are four main pillars of OOP. Let’s break them down:

Encapsulation: Bundling related data and methods together inside a single object while restricting direct access to certain parts.
Abstraction: Hiding complex details and exposing only the essentials.
Inheritance: Allowing one class (child) to acquire properties and methods of another (parent).
Polymorphism: The ability for the same method or function to behave differently depending on the context.

Real-World Analogy of OOP

Imagine you’re designing a Car System:
• Encapsulation: The car has properties like color, brand, and engineType, and methods like startEngine() or applyBrakes(). You don’t directly control how the engine works internally, you just start it.
• Abstraction: You turn the steering wheel to change direction but you don’t need to know the complex physics behind it.
• Inheritance: A SportsCar can inherit features of a general Car but have additional features like turboBoost().
• Polymorphism: The method drive() can mean different things depending on whether it’s a Car, a Bike, or a Truck.
This structure makes the car system easier to understand, expand, and maintain. The same applies to code.

OOP in JavaScript with Examples

Encapsulation (Creating a Class) Encapsulation means bundling data (properties) and methods (functions) into one unit (class).

// Encapsulation example with a Car class
class Car {
  // The constructor is used to initialize object properties
  constructor(brand, color) {
    this.brand = brand; // property to store the car brand
    this.color = color; // property to store the car color
  }

  // Method to start the car engine
  startEngine() {
    // Access the car's brand property
    console.log(`${this.brand} engine started!`);
  }
}

// Create a new object (instance) of the Car class
const myCar = new Car("Toyota", "Red");

// Call the method to start the engine
myCar.startEngine(); // Output: Toyota engine started!

2. Abstraction
Abstraction hides unnecessary details and exposes only the essential methods.

// Abstraction example with a BankAccount class
class BankAccount {
  constructor(owner, balance) {
    this.owner = owner; // account owner's name

    // Private variable to hold the balance
    // It cannot be accessed directly outside the class
    let _balance = balance;

    // Method to check current balance (controlled access)
    this.getBalance = function() {
      return _balance;
    };

    // Method to deposit money (changes balance internally)
    this.deposit = function(amount) {
      _balance += amount;
      console.log(`Deposited ${amount}. New balance: ${_balance}`);
    };
  }
}

// Create a new bank account with an initial balance of 1000
const account = new BankAccount("Peace", 1000);

// Deposit money using the provided method
account.deposit(500); // Output: Deposited 500. New balance: 1500

// Access the balance safely through the method
console.log(account.getBalance()); // Output: 1500

// Direct access like account._balance is not possible (hidden!)

3. Inheritance
Inheritance allows one class to acquire the properties and methods of another.

// Parent class Vehicle
class Vehicle {
  constructor(type) {
    this.type = type; // type of vehicle (e.g., Car, Bike, Truck)
  }

  // Method for movement
  move() {
    console.log(`${this.type} is moving...`);
  }
}

// Child class Bike extends Vehicle
class Bike extends Vehicle {
  constructor(type, brand) {
    // super() calls the parent class constructor
    super(type);
    this.brand = brand; // brand of the bike
  }

  // Override the parent move() method with custom behavior
  move() {
    console.log(`${this.brand} ${this.type} is speeding away!`);
  }
}

// Create an instance of Bike
const myBike = new Bike("Motorbike", "Yamaha");

// Call the overridden method
myBike.move(); // Output: Yamaha Motorbike is speeding away!

4. Polymorphism
Polymorphism allows the same method name to behave differently depending on the object.

// Parent class Animal
class Animal {
  // Default method for speaking
  speak() {
    console.log("This animal makes a sound.");
  }
}

// Child class Dog overrides speak()
class Dog extends Animal {
  speak() {
    console.log("Woof! Woof!");
  }
}

// Child class Cat overrides speak()
class Cat extends Animal {
  speak() {
    console.log("Meow!");
  }
}

// Create an array of different animals
const animals = [new Dog(), new Cat(), new Animal()];

// Each object responds differently to the same method call
animals.forEach(animal => animal.speak());

/* Output:
Woof! Woof!
Meow!
This animal makes a sound.
*/

Importance Of OOP Matters in JavaScript

1. Code Reusability
• With OOP, you can create reusable classes or objects that can be used across different parts of your application.
• Example: A User class with login/logout methods can be reused in multiple projects.
2. Modularity (Better Organization)
• OOP helps break down complex code into smaller, manageable pieces (classes/objects).
• Each object focuses on one specific task, making the codebase easier to navigate and maintain.
3. Encapsulation (Data Hiding & Security)
• OOP allows you to hide the internal implementation of an object and expose only what’s necessary.
• Example: Instead of directly changing a bank account’s balance, you might only allow deposits/withdrawals through specific methods.
4. Inheritance (Avoiding Duplication)
• You can create a parent class with common properties and methods, and let child classes inherit them.
• This reduces duplication of code and enforces consistency.
• Example: A Vehicle class → extended by Car, Bike, Bus.
5. Polymorphism (Flexibility & Extensibility)
• Objects can share the same interface but behave differently based on the context.
• Example: A draw() method might render a circle, square, or triangle differently depending on the object.
6. Improved Maintainability
• Since OOP structures your code in clear, self-contained objects, it becomes easier to fix bugs, add features, or make changes without breaking other parts.

7. Scalability (Good for Large Applications)
• Large projects (like web apps, games, and enterprise software) benefit from OOP because it makes it easier to manage growing codebases.
8. Real-World Modeling
• OOP mirrors real-world entities (users, products, orders, etc.), making the design more intuitive.
• Example: In an e-commerce app, you can have classes for Product, Cart, and Order that closely resemble real-world objects.

Conclusion

Object-Oriented Programming (OOP) in JavaScript is not just a concept — it’s a powerful way to think about code. By understanding encapsulation, abstraction, inheritance, and polymorphism, you can write cleaner, smarter, and more professional programs.
OOP is like building blocks — once you master them, you can create applications as small as a calculator or as big as a social media platform.

Understanding Encapsulation in JavaScript

henry messiah tmt — Thu, 04 Sep 2025 02:44:51 +0000

Introduction

Have you ever wondered why an ATM never shows you its inner workings, yet always gives you just the right amount of money when you press a button? Or why your favorite apps protect your passwords without ever exposing them? Behind these everyday experiences lies a powerful programming principle called Encapsulation.

In JavaScript, encapsulation is the art of hiding the messy details of how something works and exposing only what you need to use. It’s like driving a car, you don’t have to know how the engine combusts fuel, you just press the accelerator and the car moves. Encapsulation makes our code safer, cleaner, and easier to work with, while giving us full control over how data is accessed and modified.

Documenting encapsulation is important because it helps developers understand how to properly structure applications, protect data, and avoid coding mistakes that lead to bugs and security flaws. With the guide from this documentation, you and your team can build reliable software that scales well and remains easy to maintain.

What is Encapsulation?

Encapsulation in JavaScript is one of the core principles of Object-Oriented Programming (OOP).

It means bundling related data (properties/variables) and behavior (methods/functions) into a single unit (object or class) while restricting direct access to some parts of that object.

Encapsulation in simple terms means keeping data and methods together in one unit while restricting direct access to some details. You show only what is needed. You hide the rest.

Why Use Encapsulation?

Protects data from unsafe changes.
Gives controlled access through getters and setters.
Keeps code organized and reusable.
Provides better security for sensitive logic.

Examples of encapsulation in JavaScript

Using Objects

const user = {
  name: "Henry",
  age: 36,

  getAge() {
    return this.age;
  },

  setAge(newAge) {
    if (newAge > 0) {
      this.age = newAge;
    } else {
      console.log("Invalid age");
    }
  }
};

console.log(user.getAge()); // 36
user.setAge(40);
console.log(user.getAge()); // 40

Here, age is managed only through getAge and setAge.

Using Classes with Private Fields

class BankAccount {
  #balance = 0;

  deposit(amount) {
    if (amount > 0) {
      this.#balance += amount;
    }
  }

  withdraw(amount) {
    if (amount > 0 && amount <= this.#balance) {
      this.#balance -= amount;
    } else {
      console.log("Insufficient funds");
    }
  }

  getBalance() {
    return this.#balance;
  }
}

const account = new BankAccount();
account.deposit(1000);
account.withdraw(300);
console.log(account.getBalance()); // 700

The field #balance is private and cannot be accessed from outside.

Using Closures

function Car() {
  let engineOn = false;

  return {
    startEngine: () => {
      engineOn = true;
      console.log("Engine started");
    },
    stopEngine: () => {
      engineOn = false;
      console.log("Engine stopped");
    },
    drive: () => {
      if (engineOn) {
        console.log("Car is moving");
      } else {
        console.log("Start the engine first");
      }
    }
  };
}

const myCar = Car();
myCar.drive();       // Start the engine first
myCar.startEngine(); // Engine started
myCar.drive();       // Car is moving

The variable engineOn is private to the function.

Real World Examples

ATM Machine

class ATM {
  #balance;

  constructor(initialBalance) {
    this.#balance = initialBalance;
  }

  deposit(amount) {
    if (amount > 0) {
      this.#balance += amount;
      console.log(`Deposited: ₦${amount}`);
    }
  }

  withdraw(amount) {
    if (amount > 0 && amount <= this.#balance) {
      this.#balance -= amount;
      console.log(`Withdrawn: ₦${amount}`);
    } else {
      console.log("Insufficient funds");
    }
  }

  getBalance() {
    return this.#balance;
  }
}

const myATM = new ATM(1000);
myATM.deposit(500);
myATM.withdraw(300);
console.log("Balance:", myATM.getBalance()); // 1200

The balance is private. You only interact through deposit, withdraw, and getBalance.

Password Manager

function PasswordManager() {
  let passwords = {};

  return {
    addPassword: (site, pwd) => {
      passwords[site] = pwd;
    },
    getPassword: (site) => {
      return passwords[site] ? "****" : "No password saved";
    },
    verifyPassword: (site, pwd) => {
      return passwords[site] === pwd;
    }
  };
}

const manager = PasswordManager();
manager.addPassword("gmail", "mySecret123");
console.log(manager.getPassword("gmail")); // ****
console.log(manager.verifyPassword("gmail", "mySecret123")); // true

The stored passwords are hidden and safe from direct access.

Car

class Car {
  #engineStatus = false;

  startEngine() {
    this.#engineStatus = true;
    console.log("Engine started");
  }

  stopEngine() {
    this.#engineStatus = false;
    console.log("Engine stopped");
  }

  drive() {
    if (this.#engineStatus) {
      console.log("Car is moving");
    } else {
      console.log("Start the engine first");
    }
  }
}

const myCar = new Car();
myCar.drive();       
myCar.startEngine(); 
myCar.drive();

The engine status is hidden. The driver interacts only with exposed methods.

Conclusions

Encapsulation means hiding internal details.

It gives controlled access through methods.

It keeps data safe and code maintainable.

Real-world parallels include ATMs, password managers, and cars.

Understanding Polymorphism in JavaScript

henry messiah tmt — Fri, 29 Aug 2025 00:59:57 +0000

Introduction

Polymorphism is one of the hardest concepts for new programmers to understand. The word itself looks complex and can confuse beginners. Many learners struggle because the explanations they find are filled with theory and technical terms. This makes the topic feel harder than it is.

The aim of this document is to explain polymorphism in simple terms. You will see how it works through clear examples from everyday life. The goal is to help you understand what polymorphism means and how you can apply it in JavaScript. Real life comparisons, like a house lamp, phone charger, vehicles, and remote control, will make the concept practical and easy to remember.

What is Polymorphism

Polymorphism means one name with many forms. A single method or function behaves differently depending on the object or context. This is part of object-oriented programming.

Example: House Lamp
You buy one lamp for your house. You use it in the room, parlor, and kitchen. The same lamp behaves differently in each location.

JavaScript Example

  turnOn(location) {
    if (location === "room") {
      console.log("Lamp gives soft light in the room.");
    } else if (location === "parlor") {
      console.log("Lamp gives bright light in the parlor.");
    } else if (location === "kitchen") {
      console.log("Lamp gives white light in the kitchen.");
    } else {
      console.log("Lamp gives default light.");
    }
  }
}

const lamp = new HouseLamp();
lamp.turnOn("room");
lamp.turnOn("parlor");
lamp.turnOn("kitchen");

### Other Examples

Phone Charger

One charger works for different devices.

class Charger {
  charge(device) {
    console.log(`Charging ${device}`);
  }
}

const charger = new Charger();
charger.charge("phone");
charger.charge("tablet");
charger.charge("power bank");
Vehicles
All vehicles move but each in its own way.

class Vehicle {
  move() {
    console.log("This vehicle moves.");
  }
}

class Car extends Vehicle {
  move() {
    console.log("The car drives.");
  }
}

class Boat extends Vehicle {
  move() {
    console.log("The boat sails.");
  }
}

class Plane extends Vehicle {
  move() {
    console.log("The plane flies.");
  }
}

const vehicles = [new Car(), new Boat(), new Plane()];
vehicles.forEach(v => v.move());

Remote Control

One remote operates different devices.

Switch on TV,

Play music on speaker,

Control a fan.

Why Polymorphism Matters?

Reuse methods in different contexts,

Keep your code flexible,

Make updates easier.

Discriminator Properties in Polymorphism

In JavaScript, polymorphism often needs a way to decide how a method should behave. This is where discriminator properties help. A discriminator property is a special value inside an object that tells the program which form of behavior to use.

Think of it as a label. The label helps the program pick the right action.

Example with House Lamp

class HouseLamp {
  constructor(location) {
    this.location = location; // discriminator property
  }

  turnOn() {
    if (this.location === "room") {
      console.log("Lamp gives soft light in the room.");
    } else if (this.location === "parlor") {
      console.log("Lamp gives bright light in the parlor.");
    } else if (this.location === "kitchen") {
      console.log("Lamp gives white light in the kitchen.");
    } else {
      console.log("Lamp gives default light.");
    }
  }
}

const roomLamp = new HouseLamp("room");
const parlorLamp = new HouseLamp("parlor");
const kitchenLamp = new HouseLamp("kitchen");

roomLamp.turnOn();
parlorLamp.turnOn();
kitchenLamp.turnOn();

Here, the property location is the discriminator. It changes how the method turnOn behaves.

Example with Vehicles

class Vehicle {
  constructor(type) {
    this.type = type; // discriminator property
  }

  move() {
    if (this.type === "car") {
      console.log("The car drives.");
    } else if (this.type === "boat") {
      console.log("The boat sails.");
    } else if (this.type === "plane") {
      console.log("The plane flies.");
    } else {
      console.log("Unknown vehicle type.");
    }
  }
}

const car = new Vehicle("car");
const boat = new Vehicle("boat");
const plane = new Vehicle("plane");

car.move();
boat.move();
plane.move();

Here, the property type acts as the discriminator. It decides how the vehicle moves.

Why Discriminator Properties Help?

They give objects a clear identity,
They make code easier to extend,
Add a new type, define its behavior, and the same method works.
They keep your methods reusable but context-aware.

conclusions

Polymorphism lets you use one function or method name in many forms. The context decides the behavior.

A discriminator property is like a switch inside an object. It tells the method how to behave. This makes polymorphism more practical and easier to control in real projects.

DEV Community: henry messiah tmt

Solidity to Compact: Developer's Migration Guide

Quick reference table

Pattern 1: Basic contract structure

Solidity: Contract declaration

Compact: Ledger and circuit declaration

Reading ledger state in compact

Key differences

Pattern 2: Data types and type system

Solidity: Flexible types with runtime sizing

Compact: Fixed-Size, unsigned types

Key differences

Pattern 3: Loops and iteration

Solidity: Dynamic loop bounds

Compact: Compile-time bounded loops

Key differences

Pattern 4: State variables (public vs private)

Solidity: Visibility modifiers (all data on-chain)

Compact: Explicit privacy with witness functions

Witness function implementation (typescript side)

Key differences

Pattern 5: Events and logging

Solidity: Event declaration and emission

Compact: Ledger state changes and return values

Monitoring state changes (typescript side)

Key differences

Pattern 6: Access control and modifiers

Solidity: Function modifiers

Compact: Helper functions and assertions

Key differences

Pattern 7: Function visibility

Solidity: Visibility modifiers

Compact: Export keyword and circuit Scope

Key differences

Pattern 8: Contract initialization (constructors)

Solidity: Constructor pattern

Compact: Constructor circuit

Constructor call in deployment script

Key differences

Pattern 9: Input validation and error handling

Solidity: Require, revert, and assert

Compact: Assert statements only

Key differences

Pattern 10: Privacy-specific features (compact-only)

Private state with witness functions

Key privacy concepts

Key conceptual differences

Privacy model

Execution model

State management

Data constraints

Caller context

Migration mindset

Common pitfalls and solutions

Pitfall 1: Incorrect return type syntax

Pitfall 2: Using dynamic sizes without Opaque

Pitfall 3: Unbounded loops

Pitfall 4: Forgetting CompactStandardLibrary import

Pitfall 5: Using signed integers

Pitfall 6: Expecting automatic msg.sender

Pitfall 7: Using disclose() incorrectly

Complete migration Example

Solidity token contract

Compact token contract

Typescript deployment script

Typescript interaction script

Key migration points

When to use each language

Choose compact when

Choose solidity when

Hybrid approach

Additional resources

Official documentation

Tools and platforms

Community

Conclusion

The Pharmacist's Guide to Becoming a Developer: Skills That Transfer

The Myth of "Starting From Scratch"

The Seven Skills That Transfer

1. Systematic Problem-Solving

Add the Starter `HTML` Code