I have just begun studying Typescript and I’m afraid I’m missing something basic. Since TS is compiled into JavaScript and HTML files only recognize the latter, what is the point of worrying about type safety? For instance, how can I make sure that the second function below, transpiled from the first one and embedded in a HTML file, will only accept numerical arguments?
function sum( a: number, b: number ):void {
return a + b;
}
function sum(a, b){return a + b};
TypeScript gets transpiled into JavaScript, allowing for compile-time errors if type safety is violated (meaning your app won’t build and will give you an error). The server will still send JavaScript files to the browser.
Hi there!
Since Javascript is not a typed language, it can get pretty messy when you have a certain logic made to handle a certain type of data, for example its meant to handle a particular object and receives a completely different one. Typescript ensures type safety and will warn you during compilation, which is awesome to prevent bugs in production.
For small and “simple” projects, you’ll probably won’t feel big difference, but when working in big projects you’ll definitely feel the pain of not having types defined, its much more chaotic. Also you can check what object type you’re working on, rather than console.log() every time.
I am aware of all that and I don’t feel that you have answered my question.
Why should the user bother to do type checking when that defeats the purpose of TS providing for type safety? Why doesn’t the TS compiler instead generate JS code like, for example, the one below?
function sum (a, b) {
if ( type a != “number” && type b != “number” ) {
console.error(“Your input types are incrrect.”);
} else {
return a + b;
}
}
I am aware of what you said. If you re-read the post, it mentions an embedded file, not one provided by the server.
Who is the console.log message for? The developer or the user?
A developer might want a more specific message about what is wrong with the types. A user might need a different message too. The point is, what messages get displayed to the console occur in the compiled version at run time. TypeScript is to aid the developer in the development process. Any messages that should be generated for the user or after-the-fact console messages has to be created by the developer.
That was only an example. It could be an alert message shown to the user who entered input with the wrong type when using a web page.
When you say “user” you’re referring to the programmer? Either way the purpose of TS is to ensure good code quality practices during development, almost like a es-lint, not like a JS compiler like babel. The final bundled code is meant for running, not for enforcing good practices to the programmer, thats on us. Does this answers your question?
All files are provided by the server. If you’re talking about embedded scripts in HTML files (which are still served files fwiw) via script tags, then that’s a really bad practice anyway so I’ve never researched whether there are any tools to allow you to use TypeScript there. If so, those files would still get transpiled via a build process into JavaScript.
Anyone navigating the web who accesses the HTML page. If he or she is required to enter input and it is wrongly typed, how will the user get feedback from that unless the programmer implements type checking in your JS code like I sad in my previous comment? Should that not be the job of TS?
No. Any interaction with a page visitor is the job of the developer. Why? For the very reasons I stated above. There is no one-size-fits all message or way of showing a page user the “correct” message. Every application is different in regards of the best way to inform users of incorrectly submitted data.
Why bad practice when I am talking from the front-end developer’s perspective and not from the back-end one?
And how does that answer the question the post proposes?
I think you’re confusing the type checking of TypeScript with input validation. TypeScript helps you make sure that your code is correctly written to minimize logical errors.
Making sure that a user gives you a number when you ask for a number is something that you need to write code for. It’s not a language feature (except in that there are some built-in validation methods in some languages).
Agree, it’s 2 different things that you’re talking about.
It’s much harder to maintain. Separation of concerns makes code that is easier to read, easier to extend and update, and less error-prone. It also makes it harder to take advantages of tools like TypeScript.
I can’t see how I’m mixing things up.
Back to the example of the post, why doesn’t the TS compiler generates the JS code below instead of leaving the type-checking task to the programmer?
function sum (a, b) {
if ( typeof a != “number” && typeof b != “number” ) {
warning message;
} else {
return a + b;
}
}
The bottom line is TypeScript does not do what you think it should be doing for all the reasons that have been given to you. There is no point in debating about what it should or shouldn’t do because it is what it is.
Input validation is strictly the job of the developer. A developer could create a library with features like you are wanting. In fact, there are many JavaScript form validation libraries out there. You can search “JavaScript form validation libraries” and find many of them and incorporate them into your own app.
A front-end developer can use both script tags, though with caution to avoid code bloating, or import statements . Anyway I think we’re deviating from the topic the post is addressing.
As I said, input validation was just one scenario. Obviously, I am not trying to reinvent the wheel but looking for a reasonable answer.
Back to the example of the post, why doesn’t the TS compiler generates the JS code below instead of leaving the type-checking task to the programmer?
function sum (a, b) {
if ( typeof a != “number” && typeof b != “number” ) {
warning message;
} else {
return a + b;
}
}