Typescript in HTML

The whole point of TS is to help the developer write less bad code. It has in fact taken web dev by storm - that’s why frameworks use TS.

Absolutely nobody has said or implied this.

Nobody has forgotten this. If you are working on a project written in TS, everything is written in TS, to include input validation. That TS gets transpiled to JS for the browser to understand, and that compilation process checks for errors in type agreement with the variables and functions the developer wrote.

The point would be that TS helps you ensure that the developer wrote code that uses types consistently. Developers write bugs. TS catches the type based bugs for you.

The question of user input has absolutely nothing to do with TS. You need to validate user input. Your app might be written in TS or JS. If your app is written in TS, then all you your code gets checked for type based bugs. If you write it is JS, then your code is not checked automatically in that way. In either language, input validation is mandatory if you want to prevent bugs introduced by the user.

“Would you as a developer be content if your app outputted “Louis Smit9” without warning the user? Maybe you would… Absolutely nobody has said or implied this.”

Nobody would make a fool of himself by explicitly stating that. But if you had taken the time to go through all the comments above, you’d have realized that no one acknowledged the role TS has in doing input validation.

“If you are working on a project written in TS, everything is written in TS, to include input validation. That TS gets transpiled to JS for the browser to understand, and that compilation process checks for errors in type agreement with the variables and functions the developer wrote.”

Is that news to anyone on this page?

  1. Would you say that there is any relevance in writing the TS code to catch bugs as the example below shows? If there is, show me where and explain why.

TS

function fullname(firstname: string, lastname: string) {
const regex = /{1, 15}$/;
if (regex.test(firstname) == false || regex.test(lastname) == false) {
try {
throw new Error(“Incorrect input.”);
} catch (e: unknown) {
if (e instanceof Error) {
alert(${firstname} ${lastname}. ${e.message});
}
}
} else if (regex.test(firstname) == true && regex.test(lastname) == true) {
alert(${firstname} ${lastname});
}
}

JS

function fullname(firstname, lastname) {
const regex = /{1, 15}$/;
if (regex.test(firstname) == false || regex.test(lastname) == false) {
try {
throw new Error(“Incorrect input.”);
}
catch (e) {
if (e instanceof Error) {
alert(${firstname} ${lastname}. ${e.message});
}
}
}
else if (regex.test(firstname) == true && regex.test(lastname) == true) {
alert(${firstname} ${lastname});
}
}

“The point would be that TS helps you ensure that the developer wrote code that uses types consistently. Developers write bugs. TS catches the type based bugs for you.”

  1. You keep stringing on the same harp. Can you then provide me with code that clearly shows how that type checking in TS influences the catching of bugs when it is its JS counterpart, stripped of all type checking, the one interacting with the browser or any other input medium?

Would you say the code below proves your point?

TS

interface Person {
name: string,
}

class Employee implements Person {
public name: string;
public id: number;

constructor(name: string, id: number){
this.name = name;
this.id = id;
}
}

In JS:

class Employee {
constructor(name, id) {
this.name = name;
this.id = id;
}
}

Show me the code…

“The question of user input has absolutely nothing to do with TS. You need to validate user input.”

  1. And how do we validate user input? Waving a magic wand? Of course you have to write the validation, either in TS or JS. How can you then say that it has nothing to do with TS when it is the very tool that allows us to write that code?

  2. Since you say that TS helps catching bugs, can you provide me with code that shows how that can be?

I am not here to disparage the role of TS. It wouldn’t have taken the developer community by storm if it hadn’t proven its power. My point is that no one here has as of yet shown me where that power lies.

I have numbered my questions to make sure you don’t miss any of them.

1 Like

Yes, and the reason I say that is that there are only two likely scenarios where that class in your example is going to be instantiated with an incorrect value:

  1. a malicious attempt to do something untoward, in which case the check isn’t really going to help because at that point the bad actor has to have direct access to the code, or
  2. user input, or more specifically unknown input (could be from an external API, for example)

If neither of those scenarios are in play, then the typecheck is simply there as a form of defensive programming, ie it’s being used to ensure the program works, logically. Which is what Typescript does, except TS does it before the code is compiled. This is a way of proving the logic works without running the code. So you develop using a statically typed language, which may provide a much more satisfactory level of confidence that the code will function as expected when it is actually ran.

It absolutely has, I would be extremely surprised IRL to be placed in a situation where a codebase does not use Typescript.

Obviously that is true, because types are stripped from the output code. That is not the point of using a statically typed language

On my Android phone, I can only type numbers in when I want to enter a phone number. Java is a statically typed language, yet it is not Java stopping me entering anything that isn’t a number due to the type system, it is stopping me entering them because there is some code a programmer has written (similar to your regex) that checks what the values entered into the input are.

A large % of the languages used IRL are statically typed and compiled. But when they are compiled, the output is just some bytecode or machine code instructions. All the statically typed stuff, all the semantics and syntax, that is just there as an abstraction for humans to be able to write instructions in a sane manner.

That’s what TS is. JavaScript is not statically typed, and not being statically typed has some benefits. As you say, TS is just a superset of JS and you can write everything in JS if you want. Yet TS is incredibly popular. Which should be a hint that people find the benefits of a statically typed layer on top of JS to be something that is extremely helpful.

It doesn’t magically cause your code to tell you if there is unexpected input at runtime. What you’re suggesting may seem simple and self-evident, but it isn’t at all. There are languages that can do this, that can include program state in the type system, they have been a research subject for at least 50 years. But afaik the only real existing usable implementations are either severely constrained (mathematical proof checkers like Coq, which are not turing-complete), or they involve dependent types, which are insanely complicated to work with (research languages like Idris or Agda).

Edit: is a given program correct? That is the question TS attempts to answer. And it can’t completely prove that, but it can go much further than JS can. This short talk is good:

https://www.destroyallsoftware.com/talks/ideology

1 Like

TS has zero role in input validation. That’s the role of the developer. We have said this repeatedly.

I read the conversation. I think you are not understanding what people are telling you.

Because this is the one and only purpose of TS - catching type mismatches in written code.

These are still utterly unrelated. Input checking has nothing to do with type checking the code the developer wrote.

Any language can do input validation. Language choice has nothing to do with the need for input validation.

The power is in type checking the code the developer writes. Its benefits have absolutely nothing to do with the need to validate user input. That is utterly unrelated to the purpose of strongly typed languages.

To make a simple toy, TS prevents bugs that look like

const result = iNeedAStringInput(5);
1 Like

When you’re working on a team, often times you need to be able to make changes to a part of a large code base, comprised of hundreds or thousands of files, and often times you were not the one who originally wrote that code, so you’re unfamiliar with it.

So let’s say you need to update the UI for the employee page, and there’s some function like this in JavaScript:

renderEmployeeDetails(employee) {
  // ...
}

In JavaScript, you have no idea what properties are on that employee object by just looking at this file. Do they have a name, or firstName, or first_name? The Employee class definition is not in this file so you can’t know. Even if there were an Employee class in some other file, you can’t yet be sure that the object this function is getting is an instance of that class. So you would need to do some debugging like logging the object to the console, running the dev server, then finding the log to confirm what properties are on the object. Or you might look for places calling this function and following the chain up until you find the place that instantiates the object. All in all, these sorts of things take time and can be frustratingly unclear depending on the project’s structure.

However in TypeScript, it’d likely look more like this:

import { Employee } from '@/types';

renderEmployeeDetails(employee: Employee) {
  // ...
}

In which case you right click on Employee in your IDE, select show definition which takes you to the interface, and then see bright as day what properties are on it. This makes you much more confident to make the necessary changes.

At least that’s why I much prefer to use TypeScript.

2 Likes

This conversation has become vitriolic and unproductive. I am closing this thread.