Forem: Ben Lue

Reclaim the Fun of Coding: How to Avoid Manual Input Checks

Ben Lue — Thu, 27 Nov 2025 08:38:57 +0000

We all know the feeling. You’ve just architected a brilliant feature. The logic is sound, the data flow is elegant, and you’re ready to dive into the "fun part"—building the core functionality that actually does something cool.

But wait. First, you have to build the gatekeeper.

You have to check if userId exists. You have to check if age is actually a number. You have to make sure quantity isn't negative, and that email actually looks like an email. Before you know it, the top 20 lines of your function are a messy soup of if statements, typeof checks, and manual error throwing.

Input verification is critical for security and stability, but it's probably also the most boring part of web development. It could break your flow, clutter your code, and turn a creative process into a tedious chore. Most importantly, it takes the fun out of programming.

Is There A Better Way?

Over the years, I've found there's a better way to do input verification. The suggestion is to move from imperative checking to declarative contracts.

In the traditional imperative approach, we write code that tells the computer how to check the data step-by-step. Below is a typical example:

// The "Chore" Section - Hard to read, hard to maintain
if (!input.username || typeof input.username !== 'string') {
    throw new Error("Username is required");
}
if (input.age && (typeof input.age !== 'number' || input.age < 18)) {
    throw new Error("Must be 18+");
}
if (input.role && !['admin', 'user', 'guest'].includes(input.role)) {
    throw new Error("Invalid role");
}
// Finally... the actual logic starts here

This is quite mechanical and tedious. Even the most patient developers can hardly enjoy reading code like that. What if we could simply declare what valid data looks like and let a utility handle the rest?

Let Inputs Declare Themselves

Instead of writing step-by-step checks, we define a schema — a contract that describes the shape of valid input. We put our effort into a reusable utility that does all the validation for us. Build once, use all the time.

An example can better illustrate this declarative pattern:

{
    username: { 
        '@type': 'string(50)', 
        '@required': true 
    },
    age: { 
        '@type': 'integer[18..]', // Must be integer, 18 or greater
        '@required': false 
    },
    role: { 
        '@type': 'string{admin, user, guest}', // Enum constraint
        '@default': 'user'
    }
}

A descriptor for each input parameter is defined as a JSON object with @type to describe the data type and additional control properties such as @required and @default to further refine the input contracts. The @type property can be quite versatile. As shown in the example, you can limit the string length, put a range on an integer or even enumerate the possible values of an input. This declarative approach offers immediate, tangible benefits over manual checks:

Readability: You can understand the requirements in seconds.
Compactness: It handles type checking, length limits, ranges ([18..]), and allowed values ({...}) in a single line.
Sanitization: A good declarative system (like this one) will also automatically convert inputs (e.g., transforming "20" into the integer 20) and apply defaults.

When input data reaches the core logic, you are guaranteed that input is valid. You never have to write an if statement for validation again.

You Don't Really Need A Framework For This

You might be thinking, "The syntax is nice but my framework does not support that."

The good news is you don't need a specific framework to adopt this philosophy. You can write simple utilities to mimic this behavior. It might not be as powerful as the checkIn example above, but it can still alleviate the pain of manual checks to a certain extend. If your utility only implements part of the features demonstrated above, it will still save you lots of time and make your code more readable.

Let's try to implement a "checkIn-lite" (simplified version) in different languages:

1. JavaScript / Node.js

You can create a helper function that takes a schema object and validates your input against it.

Note: These code examples are for reference only. There may be more efficient or elegant ways to achieve the same result.

// 1. Define your Contract (Declarative)
const userSchema = {
    username: { '@type': 'string', '@required': true },
    age: { '@type': 'integer', '@required': true }
};

function  verifyInput(input, userSchema)  {
    const  errors = [],
           verified = {}

    Object.keys(userSchema).forEach(key => {
        let  spec = userSchema[key],
             value = input[key];

        // deal with '@required'  and '@default'
        if (spec['@required'])  {
            if (value === undefined)  {
                errors.push(`${key} is required`);
                return;
            }
        } else  {
            if (value === undefined && spec['@default'] !== undefined)
                value = spec['@default']
        }

        // type checking
        if (value !== null && value !== undefined)  {
            switch (spec['@type'])  {
                case  'integer':
                    if (!Number.isInteger(value))
                        errors.push(`${key} should be an integer`);
                    esle
                        verified[key] = value;          
                    break;

                case  'string':
                    if (typeof value !== 'string')
                        errors.push(`${key} should be a string`);
                    esle
                        verified[key] = value;
                    break;

                default:
                    verified[key] = value;
                    break;
            }
        }
    })

    return  {input: verified, errors: errors};
}

2. PHP

In PHP, we can create a similar utility using an associative array as the schema.

$userSchema = [
    'username' => ['@type' => 'string', '@required' => true],
    'age'      => ['@type' => 'integer', '@required' => true]
];

function verifyInput(array $input, array $schema): array {
    $errors = [];
    $verified = [];

    foreach ($schema as $key => $spec) {
        $value = $input[$key] ?? null;

        // 1. Handle @required and @default
        if (!empty($spec['@required'])) {
            if ($value === null) {
                $errors[] = "$key is required";
                continue;
            }
        } else {
            if ($value === null && isset($spec['@default'])) {
                $value = $spec['@default'];
            }
        }

        // 2. Check Data Type
        if ($value !== null) {
            switch ($spec['@type']) {
                case 'integer':
                    if (!is_int($value))
                        $errors[] = "$key should be an integer";
                    else
                        $verified[$key] = $value;
                    break;
                case 'string':
                    if (!is_string($value))
                        $errors[] = "$key should be a string";
                    else
                        $verified[$key] = $value;
                    break;
                default:
                    $verified[$key] = $value;
                    break;
            }
        }
    }

    return ['input' => $verified, 'errors' => $errors];
}

3. Python

Python dictionaries are perfect for this. We can write a function that accepts the input dictionary and the schema.

# 1. Define your Contract
user_schema = {
    'username': {'@type': str, '@required': True},
    'age':      {'@type': int, '@required': True}
}

def verify_input(input_data, schema):
    errors = []
    verified = {}  # Initialize the verified dictionary

    for key, spec in schema.items():
        value = input_data.get(key)

        # 1. Handle @required and @default first
        if spec.get('@required'):
            if value is None:
                errors.append(f"{key} is required")
                continue  # Skip further checks for this field
        else:
            if value is None and '@default' in spec:
                value = spec['@default']

        # 2. Check Data Type (only if value exists)
        if value is not None:
            expected_type = spec.get('@type')
            if expected_type == int and (not isinstance(value, int) or isinstance(value, bool)):
                errors.append(f"{key} should be an integer")
            elif expected_type == str and not isinstance(value, str):
                errors.append(f"{key} should be a string")
            else:
                verified[key] = value  # Only add when validation passes

    return {'input': verified, 'errors': errors}

The "Full Blown" Experience with WNode

While the DIY solutions above are helpful, writing your own validation engine can be a project in itself. If you really want to experience the full power of declarative validation without sinking in your own energy too much, you can look for WNode for the full power of the checkIn coding pattern.

In WNode, you can declare compound data types such as arrays, objects, even array of objects or objects of arrays. If you're interested in the full feature of checkIn, you can check out the WNode CheckIn Documentation. The checkIn gatekeeper is designed in WNode to make sure a web component has a clear, well-specified input contract. With a clear input contract, WNode further asserts that input is the state for every web component to simplify state management. That design decision eventually allows WNode to avoid the client hydration issues in modern web frameworks.

I think it's important to note that you don't have to rely on frameworks (including WNode) to make declarative input contracts possible. Developers are good at building things. You can create your own version of checkIn-lite to fit your own needs.

Why I favor the fundamentals over the "Framework of the Month" for Web Development

Ben Lue — Sat, 22 Nov 2025 08:54:49 +0000

I’ve been doing web development for roughly 15 years. I remember the days before npm, the rise of jQuery, Bootstrap, the explosion of SPAs, and things in between.

I’ve seen exciting trends and helpful tools, but lately, I’ve also seen frameworks that are increasingly confusing. Today's web development seems to be heading in an uneasy direction.

We have normalized a level of complexity that pulls developers away from the basics of the web and into a walled garden framed by build tools, transpilers, and packers.

I’m lucky to be self-employed, which gives me a unique perspective. I don't have a boss or a job description forcing me to use a specific framework, and that gives me the freedom to build my own way.

Here is why I favor the fundamentals (HTML, CSS, JS) over the "Framework of the Month."

The "Necessity" Trap

The biggest question I ask myself when I look at a modern package.json is: "Why would I need these dependencies?"

Is this complexity required by the Platform (the browser)? Or is it required by the Framework?

Browsers today are incredibly powerful. They support ES Modules, they handle complex DOM manipulation, and they render CSS beautifully. Yet, we often spend hours configuring Webpack, Vite, or Turbopack. We aren't setting up these tools because the user's browser demands them; we are setting them up because our framework can't run without them.

We have created a world where "Hello World" requires a build step. That feels wrong.

Dependency Hell vs. Application Logic

When you install a modern framework, you often pull in hundreds or thousands of node_modules. If you look at those dependencies critically:

Are those modules helping you write your specific application logic? Or are they just the scaffolding required to hold the framework together?

If 80% of your dependencies are there just to make your build tool talk to your transpiler so your framework can render a button, we have lost the plot. I prefer to keep my dependencies limited to what the application actually needs to function.

How I Build (The "No-Build" Approach)

Because I don't have to be restricted to work with a specific framework, I prioritize simplicity and stability for my tool choice. Here is what the "Alternative" looks like for me:

1. Server-Side Rendering (SSR) + Standard Scripts

I don't need a complex client-side hydrator. Standard SSR (generating HTML on the server) coupled with standard <script> libraries works just fine. It is fast, the browser loves it, and SEO becomes easier.

2. ES Modules

I sometimes use ES Modules (import / export) directly. Browsers support this natively now. I don't need a bundler to merge files together during development.

3. CSS Utilities

Going "back to basics" doesn't mean writing every line of CSS from scratch. I like using Bootstrap, especially for the utility classes. It provides a clean grid and consistent styling which can keep CSS manageable (I can minimize my customized CSS code).

4. Components without Complexity

You don't need a framework to think in "Components." Whether you use web components or just structure your backend code to render reusable HTML snippets, the concept of a component is logical, not technological.

The Takeaway for Junior Developers

If I could offer one piece of advice to developers just starting their journey: Immerse yourself directly with the web fundamentals (HTML/CSS/JS).

If your job does not offer that chance, try to do it when you're self-practicing.

Try not to let a framework abstract the world away from you. The native WebAPI, modern HTML, and JavaScript are well-designed and powerful enough to do almost everything you need.

A Zero-Build Web Framework with Pure JavaScript

Ben Lue — Thu, 20 Nov 2025 09:05:02 +0000

Over the past year we’ve been working on WNode Cloud, an experiment in simplifying the modern web stack.

The idea is to see whether a web app can be developed and deployed without a build system — no Webpack, no Babel, no bundlers — just standard JavaScript executed as-is.

Some core design choices:

True component architecture (model, view, controller, and styling encapsulated and colocated in one file)
Views written in plain JavaScript (no template language)
Zero-config cloud deployment tied directly to your codebase

Demo

We recorded a 45-second demo showing a functional app deployed in under 15 seconds: Watch demo

Technical Trade-Offs

Dependency Management: Client-side code works with native ES modules or classic <script>-based libraries.
Production Optimization: No minification or tree-shaking is performed. Instead, WNode only delivers the components required for the current page, rather than sending the entire application bundle.
Browser Support: modern browsers only; no IE/legacy support.
Performance for Large Apps: For each page, WNode maintains a context window containing only the components required for that page, rather than the entire application. This approach helps improve performance for large apps by keeping dependency graphs small and focused.

I’d love to hear thoughts from the community.