The Power of Pissing Code, and its Place in Answering the Age-Old Question: “TypeScript, or JavaScript?”

New developers often ask whether they should use JavaScript or TypeScript, and while the answer will almost always be TypeScript, writing JavaScript has its place.

TypeError: Cannot read property 'typeScriptOrJavaScript' of undefined

A classic error. Some might say a rite of passage even.

Every developer has experienced it, and most developers are now equipped with both the experience and tools to avoid silly little errors like it. One of those tools? TypeScript.

For the unwitting beginner, this error stems from accidentally (or purposefully, if you’re a masochist) assuming an undefined variable is an object, and trying to access a property of that undefined value.

const undefinedVariable = undefined;
undefinedVariable.nonExistentProperty;
// TypeError: Cannot read property 'nonExistentProperty' of undefined

TypeScript to the Rescue

With TypeScript, small issues like this can be caught during development, meaning they’ll never see the light of day in runtime. With no changes to the above snippet, TypeScript would have warned the developer that the code is invalid outlining exactly what needs to be changed, in this case: ensuring undefinedVariable had a property called nonExistentProperty, or removing the invalid property access attempt.

type ActuallyDefinedVariable = {
    nonExistentProperty: string;
};

const undefinedVariable: ActuallyDefinedVariable = {
    nonExistentProperty: "I'm defined!",
};

undefinedVariable.nonExistentProperty; // ✅ TypeScript Approves

The Forbidden Keyword

Any language has its own set of bad practices, and TypeScript isn’t immune. I’ve seen both beginners and experienced developers alike resort to the keyword any, which is a catch-all type in TypeScript. It allows you to essentially bring JavaScript to TypeScript by removing static typing for a variable.

let numberVariable: number = 5;
numberVariable = "string"; // ❌ TypeScript Error

let anyVariable: any = 5;
anyVariable = "string"; // ✅ TypeScript Approves (but we don't)

When complex typing becomes an issue, some developers simply resort to any, but this defeats the purpose of TypeScript by removing the nice, strict typing that TypeScript provides. I personally use ESLint to disallow any from appearing anywhere in codebases I’m collaborating on, and I recommend you do to.

TypeScript or JavaScript?

This is a question that every beginner wants to know. TypeScript can seem like a hurdle to newbies, and she’s definitely more intimidating than her older sister: JavaScript, but once you get over the relatively small learning curve, the benefits pay off immensely.

I’m hard-struck for a reason to tell anyone to go with JavaScript on any project with even an ounce of complexity. TypeScript’s static typing improves the developer experience, and eliminates time lost debugging. Not to mention the improvement to ease-of-collaboration through the enforcement of better practices, making code more skim-friendly & clear.

However, I would be lying if I said that writing raw JavaScript didn’t have its place.

The Power of Pissing Code

Pissing code is a rather inelegant name for a style of coding I and other developers often find themselves doing. Similar to shaking your bike lock every time you pass it to make sure its not magically at risk of being stolen, sometimes we developers like to double check to make sure the language we’re working with is going to function the way we expect it to.

Perhaps you want to quickly plan out a function before introducing it into a library, test a build-in method before using it in a codebase, maybe you’re just trying something new, or you simply need to write a one-off script you’re never going to touch again.

If there is no permanence, complexity, or collaboration intended for the code you’re writing, piss it into a one-off JavaScript file or a Quokka session and call it a day. Since the codebase isn’t living on, the benefits become less tangible and rewarding. If the code is short-lived, or you’re just testing something out, just piss it into a file.

Conclusion

If the code is hitting version control, you’re collaborating with others, the code is complex, or its going to be used multiple times, its best to use TypeScript and reap the rewards, otherwise don’t feel guilty for pissing the code into a file or repl you’re never going to touch again!

If you liked this post, check me out on Twitter to be kept up to date on future posts! ❤️