Hi ,

Welcome to a brand new issue of ProgrammingPro.

In today’sExpert Insight, we bring you an excerpt from the recently published book, TypeScript 5 Design Patterns and Best Practices, Second Edition, which discusses how developers transitioning from Java or Go often bring non-idiomatic patterns—such as Java’s verbose POJOs or Go’s explicit error-checking—both of which TypeScript simplifies with interfaces, factory functions, and exception handling.

News Highlights: ByteDance launches Trae, an AI-powered code editor with free DeepSeek R1 and Claude 3.7 Sonnet access; GitHub expands Advanced Security tools to Team subscribers; major AI updates include OpenAI's GPT-4.5 preview and Claude Code; and seven malicious Go packages deploy malware on Linux and macOS.

My top 5 picks from today’s learning resources:

But there’s more, so dive right in.

Stay Awesome!

Divya Anne Selvaraj

Editor-in-Chief

Sign Up|Advertise

Legend:🎓 Tutorial/Course | 💼 Case Study | 💡 Insight/Analysis | 📜 Academic Paper |

📖 Open Source Book

Here’s an excerpt from “Chapter 10: Anti-Patterns and Workarounds" in the book, TypeScript 5 Design Patterns and Best Practices, Second Edition, by Theofanis Despoudis, published in February 2025.

When developers transition to TypeScript from other languages, they often bring coding patterns and idioms that may not be ideal in TypeScript. Although many programming concepts are shared between many languages,

such as control loops, classes, and functions, there are many other concepts particular to one language that cannot be used in adifferent language.

In the next subsections, we show some obvious cases where using some idiomatic constructs from other languages will not work well with TypeScript, starting first with theJava language.

Java developers often usePlain Old Java Objects(POJOs) orJavaBeans. Let’s look at how this pattern might be inappropriately applied in TypeScript and then how toimprove it.

POJO is a naming convention for creating a class that follows some rules, especially in the context of Java EE where object serialization is crucial for some operations. The more standardized version of POJOs is the JavaBean naming convention. When following this convention, you will need to adhere to thefollowing rules:

To understand why using POJOs in TypeScript is not ideal, we’ll show an example class in TypeScript for a typicalEmployeemodel:

Idiomatic-code.ts

class Employee {
constructor(private id: string, private name: string) {}
getName(): string {
return this.name
}
setName(name: string) {
this.name = name
}
getId(): string {
return this.id
}
setId(id: string) {
this.id = id
}
}

If you attempt to declare more than one constructor in TypeScript, then you will find that it’s not allowed, so you cannot provide both a no-argument constructor and another one with arguments. Additionally, TypeScript will complain if you provide a no-argument constructor as the property’snameandIDmay have notbeen initialized.

You will see thefollowing errors:

Figure 10.1 – TypeScript compiler message when it complains when you use a no-argument constructor

The concept of serialization applies to Java only, so it’s not relevant to TypeScript. However, you can serialize plain TypeScript objects using theJSON.stringifymethodas follows:

console.log(JSON.stringify(new Employee("Theo", "1")));
//{"id":"Theo","name":"1"}

You will find that this works only for basic cases and does not handle polymorphism, object identity, or when containing native JavaScript types such asMap,Set, orBigInt. However, in most cases, you can implement a custom object mapper or use a Factory Method to convert an object to JSON andvice versa.

The use ofget/setmethods is overly verbose and not needed most of the time. If you want to provide encapsulation, you can only havegettermethods and if you want to modify an existingEmployeeclass method, you just create a newEmployeeinstance with the updated fieldname instead:

const theo = new Employee("Theo", "1");
new Employee(theo.getName(), "2");

Finally, you may opt out of using classes altogether as you can work with types, type assignments, and object de-structuring,as follows:

Idiomatic-code.ts

interface Employee {
readonly id: string;
readonly name: string;
readonly department: string;
}
function createEmployee(id: string, name: string,
department: string): Employee {
return { id, name, department };
}
function updateEmployee(employee: Employee,
updates: Partial<Employee>): Employee {
return { ...employee, ...updates };
}
const emp = createEmployee('1', 'John Doe', 'IT');
console.log(emp.name); // John Doe
const updatedEmp = updateEmployee(emp,
{ department: 'HR' });
console.log(updatedEmp.department); // HR

This approach uses an interface instead of a class for simple data structures and provides factory functions for creation and updates, promoting immutability. This form is more idiomatic TypeScript and is the preferred way to workwith types.

Now let’s look at some of the idiomatic constructs from theGo language.

TypeScript 5 Design Patterns and Best Practices, Second Edition was published in February 2025. Packt library subscribers can continue reading the entire book for free or you can buy the book here!

That’s all for today.

We have an entire range of newsletters with focused content for tech pros. Subscribe to the ones you find the most usefulhere.

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.

If you have any suggestions or feedback, or would like us to find you a learning resource on a particular subject, just respond to this email!