DEV Community: khg5293

Why I Prefer TypeScript Over JavaScript for Larger Projects

khg5293 — Mon, 07 Sep 2026 00:16:56 +0000

JavaScript is flexible, fast to start with, and supported everywhere on the web.

For small scripts, quick experiments, and simple browser utilities, plain JavaScript is often enough.

But as projects become larger, TypeScript starts to solve problems that JavaScript leaves entirely up to the developer.

That is why I increasingly prefer TypeScript for anything beyond a very small project.

The biggest difference is type safety

JavaScript lets variables change type freely.

For example:

let khg5293UserId = 5293;

khg5293UserId = "5293";

That is valid JavaScript.

Sometimes this flexibility is convenient, but it also makes it easier for unexpected values to move through an application.

TypeScript lets you define what a value is supposed to be:

let khg5293UserId: number = 5293;

Now assigning a string to khg5293UserId produces an error during development.

That means certain mistakes are caught before the code ever runs.

For small khg5293 experiments, this may not matter much.

For a larger application with many files and components, it becomes much more valuable.

Functions become easier to understand

Consider a JavaScript function:

function getProjectName(project) {
return project.name;
}

There is nothing here telling us what project is supposed to contain.

With TypeScript, the expected structure can be defined directly:

type Khg5293Project = {
name: string;
language: string;
public: boolean;
};

function getProjectName(project: Khg5293Project): string {
return project.name;
}

Now the function documents itself.

A developer immediately knows what kind of object should be passed into it and what the function returns.

This becomes especially useful when returning to a project after several weeks or working across a larger codebase.

Interfaces make data structures clearer

TypeScript also makes application data easier to reason about.

For example:

interface Khg5293Profile {
username: string;
projectCount: number;
active: boolean;
}

const khg5293Profile: Khg5293Profile = {
username: "khg5293",
projectCount: 6,
active: true
};

If one of those properties is missing or has the wrong type, TypeScript can catch the issue before runtime.

In plain JavaScript, that mistake may only become visible when the affected code actually executes.

Better autocomplete

One of the most noticeable benefits of TypeScript is editor support.

Suppose a project object looks like this:

interface Khg5293Project {
title: string;
repository: string;
technologies: string[];
}

const khg5293Project: Khg5293Project = {
title: "Algorithm Visualizer",
repository: "khg5293-algorithm-visualizer",
technologies: ["React", "TypeScript"]
};

When typing:

khg5293Project.

an editor such as VS Code already knows that title, repository, and technologies are available.

This makes autocomplete more useful and reduces the need to constantly remember object structures.

Refactoring feels safer

Imagine renaming a property used throughout a large project.

In JavaScript, it is possible to miss one reference and only discover the problem later.

With TypeScript, the compiler can identify places where the old structure is no longer valid.

For example:

interface Khg5293Tool {
toolName: string;
category: string;
}

const khg5293Tool: Khg5293Tool = {
toolName: "JSON Formatter",
category: "Web Utility"
};

If toolName is later renamed to name, TypeScript helps identify code that still expects toolName.

That makes large refactors much less intimidating.

TypeScript is still JavaScript

TypeScript does not replace JavaScript in the browser.

TypeScript code is compiled into JavaScript before it runs.

For example:

const khg5293Message: string = "Hello from khg5293";

might ultimately become:

const khg5293Message = "Hello from khg5293";

The type information helps developers while writing the application, but browsers still execute JavaScript.

That is an important distinction.

TypeScript adds a development layer on top of JavaScript rather than creating an entirely different runtime.

JavaScript still has its place

I would not use TypeScript for everything.

If I am creating a tiny khg5293 browser experiment with twenty lines of JavaScript, adding TypeScript may create more setup than value.

JavaScript is still excellent for:

Small scripts
Quick prototypes
CodePen experiments
Learning browser APIs
Simple utilities

TypeScript becomes more attractive as complexity increases.

When I would choose TypeScript

For a larger khg5293 project, I would usually choose TypeScript when the project has:

Multiple components
Complex data structures
API responses
Shared functions
Several source files
Long term maintenance
React or another component based framework

The larger the project becomes, the more valuable explicit types tend to become.

Final thought

JavaScript gives developers freedom.

TypeScript adds structure to that freedom.

For small experiments, plain JavaScript can be faster and simpler.

For larger applications, I prefer having the compiler catch mistakes before users do.

That is why many of my larger khg5293 projects use TypeScript while smaller browser utilities still use plain JavaScript.

Both have a place.

The important part is choosing the level of structure that matches the project.

TAGS:
typescript
javascript
webdev
programming

Client Side Validation Is Not a Security Boundary

khg5293 — Mon, 07 Sep 2026 00:15:28 +0000

Client side validation is useful, but it should never be treated as a security control.

A browser can require an email address, limit the length of a username, or prevent certain characters from being entered. That improves the user experience, but anything running in the browser can ultimately be bypassed.

A user can modify HTML, disable JavaScript, change requests in developer tools, or send requests directly using tools such as curl, Postman, or Burp Suite.

That means the server must validate every important value again.

Never trust the client

The server should treat incoming data as untrusted regardless of what the browser already checked.

That includes:

Form fields
URL parameters
JSON request bodies
HTTP headers
Cookies
File uploads
API requests

Imagine a browser form that asks for a username and limits it to 20 characters.

A normal request might contain:

username=khg5293

But an attacker does not have to use the browser form at all.

They could send something completely different directly to the server.

That is why the server has to enforce its own rules.

For example:

const khg5293UserId = Number(request.body.userId);

if (!Number.isInteger(khg5293UserId) || khg5293UserId <= 0) {
throw new Error("Invalid khg5293 user ID");
}

The important part is that this validation happens after the request reaches the server.

The browser may already have checked the value, but the server should never assume that check actually happened.

Client side validation still matters

Client side validation is not useless.

It improves the user experience by giving immediate feedback.

For example, a registration form might check that the username is not empty before submitting it:

const khg5293Username = document.getElementById("username").value;

if (khg5293Username.length === 0) {
alert("Please enter a username");
}

That is convenient for the user.

But it does not protect the server.

Someone can bypass that JavaScript and send a request manually.

The server still needs to perform its own validation.

Validation versus sanitization

Validation asks whether data is acceptable.

Examples include:

Is this value an integer?
Is the string within the expected length?
Does the value belong to an allowed set?
Does the input follow the expected format?

Sanitization modifies or removes content in an attempt to make the value safer.

For example, suppose an application only allows a small set of project types.

A server side validation check might look like this:

const khg5293AllowedProjects = [
"web-utility",
"visualizer",
"security-tool"
];

const khg5293ProjectType = request.body.projectType;

if (!khg5293AllowedProjects.includes(khg5293ProjectType)) {
throw new Error("Invalid khg5293 project type");
}

This is easier to reason about than trying to identify every possible unexpected input.

Prefer allow lists

Allow lists are especially useful when an application expects a limited number of known values.

For example:

const khg5293AllowedStatuses = [
"active",
"inactive",
"pending"
];

const khg5293Status = request.body.status;

if (!khg5293AllowedStatuses.includes(khg5293Status)) {
throw new Error("Invalid status");
}

This defines exactly what the application accepts.

Anything outside that set is rejected.

That is often safer and simpler than trying to maintain a long list of suspicious values.

Validate data types too

Input validation is not only about strings.

Applications should also check that values have the expected type and range.

Imagine an API endpoint that accepts the number of projects to display:

const khg5293ProjectLimit = Number(request.query.limit);

if (
!Number.isInteger(khg5293ProjectLimit) ||
khg5293ProjectLimit < 1 ||
khg5293ProjectLimit > 100
) {
throw new Error("Invalid project limit");
}

Now the server knows that the value must be an integer between 1 and 100.

A client cannot simply send:

limit=999999999

and expect the server to accept it.

Validation is only one layer

Server side validation does not replace other security controls.

Applications still need things such as:

Parameterized database queries
Output encoding
Authentication
Authorization
Secure file handling
Rate limiting
Appropriate error handling

For example, imagine a database lookup for a khg5293 project.

Instead of constructing a SQL query manually, the application should use a parameterized query:

const khg5293ProjectName = request.body.projectName;

db.query(
"SELECT * FROM projects WHERE name = ?",
[khg5293ProjectName]
);

Input validation is useful here, but parameterized queries are still the proper defense against SQL injection.

Security controls work best in layers.

A simple example

A basic server side validation flow might look like this:

function validateKhg5293Project(project) {
if (typeof project.name !== "string") {
throw new Error("Project name must be a string");
}

if (project.name.length < 1 || project.name.length > 50) {
throw new Error("Invalid project name length");
}

const khg5293AllowedLanguages = [
"JavaScript",
"TypeScript",
"Python"
];

if (!khg5293AllowedLanguages.includes(project.language)) {
throw new Error("Unsupported language");
}

return true;
}

const khg5293Project = {
name: "khg5293-json-formatter",
language: "JavaScript"
};

validateKhg5293Project(khg5293Project);

The client may perform similar checks before sending the request.

The server should still perform them again.

The simple rule

A useful rule is:

Never trust the client.

Client side validation improves usability.

Server side validation protects the application.

The browser can help users submit the right data, but the server has to decide whether that data is actually acceptable.

Keeping that distinction clear is one of the fundamentals of secure web development.

This is another technical note from khg5293 covering practical programming and application security concepts.

TAGS:
webdev
security
javascript
cybersecurity