🕵️ SicherheitslückenHak5: Hackers Just Poisoned the Rust Supply Chain | Threat Wire(01.09.2026 um 14:00 Uhr)
🕵️ SicherheitslückenHak5: Hackers Found a Way Into Humanoid Robots | Threat Wire(04.09.2026 um 15:04 Uhr)
🔧 AI Nachrichten Bits und so #1021 (Passwort für Laufwerk)(31.08.2026 um 22:15 Uhr)
🔧 AI Nachrichten Bits und so #1022 (Wie Weißbier)(06.09.2026 um 20:39 Uhr)
🍏 iOS / Mac OSHue-App 6.0 ist da: das sind die Neuerungen(07.09.2026 um 17:21 Uhr)
🕵️ SicherheitslückenHak5: Hackers Just Poisoned the Rust Supply Chain | Threat Wire(01.09.2026 um 14:00 Uhr)
🕵️ SicherheitslückenHak5: Hackers Found a Way Into Humanoid Robots | Threat Wire(04.09.2026 um 15:04 Uhr)
🔧 AI Nachrichten Bits und so #1021 (Passwort für Laufwerk)(31.08.2026 um 22:15 Uhr)
🔧 AI Nachrichten Bits und so #1022 (Wie Weißbier)(06.09.2026 um 20:39 Uhr)
🍏 iOS / Mac OSHue-App 6.0 ist da: das sind die Neuerungen(07.09.2026 um 17:21 Uhr)

🔧 Programmierung 🕛 kürzlich 3 Min Lesezeit
0

Don't type in typescript. (At least most of the time)

↗ Quelle (dev.to)
🗣️ Stimme:
📑 Inhaltsübersicht

I apologise in advance for the clickbait title.



Many people use typescript the wrong way, blame it for their bad use and turn back to javascript. You don't have to type everything explicitly in typescript. Actually, I would argue in most cases you should let typescript do it for you via type inference. That's the best way to do it. Makes the code more readable while preserving the benefits of using it.






Not bloated, not hard to read



Take a look at this bit of JavaScript code:



Let's write a basic function that prints whether a person can vote along with their first name which I broke into multiple variables to prove a point.




CODE
function canIVote(name, age) {
const nameParts = name.split('');
const firstName = nameParts.shift();
const canVote = age > 18;
const message = canVote
? `Congrats ${firstName}, you can vote!`
: `Sorry ${firstName}, you can't vote.`;
console.log(message);
}






Here's an example of incorrect use of typescript:




CODE
function canIVote(name:string, age:string) {
const nameParts:string[] = name.split(' ');
const firstName:string = nameParts.shift() as string; // as string to ignore the error from it being string | undefined
const canVote:boolean = age > 18;
const message:string = canVote
? `Congrats ${firstName}, you can vote!`
: `Sorry ${firstName}, you can't vote.`;
console.log(message);
}






While this might not look bad, this approach does not scale well. You will spend more time writing out the types of things than actually coding the things. When the project becomes bigger and more complex, the code is going to look messier and unmaintainable.



This is where few developers run into the issue of typescript being less readable and complain about writing a lot more lines of code to achieve the same result. They would be right, if the above code was the norm and if the project was big enough.



Another thing to note in this approach is the as keyword. Use it wisely. Don't use it to squash warnings but properly handle the value type and perform actions accordingly. as should only be used when you are certain what the type of a variable is going to be.



Here's an example of correct use of typescript:




CODE
function canIVote(name:string, age:string) {
const nameParts = name.split(' ');
const firstName = nameParts.shift(); // -> string | undefined
if (!firstName)
throw new Error("How do you not have a first name?");
// now if you hover over firstName the type will have changed
// to `string` because we have handled `undefined` above and
// removed that case.
const canVote = age > 18;
const message = canVote
? `Congrats ${firstName}, you can vote!`
: `Sorry ${firstName}, you can't vote.`;
console.log(message);
}









any



Don't use any just anywhere.

Sorry, couldn't resist. Avoid using any. If you are using any everywhere, you are just using javascript with more steps. any can be used if you are migrating the code from a javascript codebase gradually typing things out but don't let it stay that way.






Typing



There are definitely cases where you have to explicitly mention a type for a variable because the inference was vague and you are certain it is of one type. You do have to define your own types for interfaces, objects, etc for the best experience.

Only in very rare scenarios will you have to write types like this:





I am trying to build a twitter profile.

Vollständiger Original-Bericht
Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.
↗ Original-Artikel auf dev.to lesen
Wie bewertest du diesen Beitrag?
1 Klick Feedback
Teilen mit Netzwerk & Team:

Community-Analysen & Experten-Meinungen 0

Verfasse deine eigene Analyse, teile Workarounds oder diskutiere diesen Vorfall im Blog.
Noch keine Community-Analyse verfasst. Markiere einen Textabschnitt oder klicke oben auf Eigene Analyse verfassen“!
Community Pulse: Relevanz-Einschätzung
1 Klick Experten-Votum
🔴 Akute Relevanz 0%
🟡 In Evaluierung 0%
🟢 Keine Auswirkung 0%
Spannende Innovation 0%
Verwandte Story-Cluster & Quellen (Vektor-KI)
Port 8095 Engine
1 Quelle
Hackers Just Poisoned the Rust Supply Chain | Threat Wire
1 Quelle
Hackers Found a Way Into Humanoid Robots | Threat Wire
1 Quelle
Bits und so #1021 (Passwort für Laufwerk)
Ähnliche Beiträge
🔍 Verwandte News

Auch interessante Nachrichten Don't type in typescript. (At least most of the time)

Thematisch verwandte Begriffe: Dont, type, typescript, least · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...