Being a big proponent of TypeScript, I keep noticing that this language inherits all the flaws of JavaScript. However, it does not mean we have no choice. The problem Consider a function that turns an object representing a URL into a string: type UrlRecord = { protocol: string; host: string[]; } function urlToString(urlRecord: UrlRecord): string { const { protocol, host } = urlRecord; return `${protocol}://${host.join('.')}`; } This code snippet looks innocent and pretty solid. TypeScript compiler will let the users of this function know if they are passing the wrong data into the function: ...

In the ever-evolving landscape of web development, the choice of tools and technologies can have a profound impact on the flexibility, scalability, and longevity of a code base. One critical decision that developers often face is whether to use a framework or embrace more framework-agnostic solutions like Web Components when building a UI library. In this post, we’ll explore why opting for Web Components can offer unparalleled advantages when it comes to ensuring flexibility and avoiding lock-in. ...

I chose the railway photo for the cover for a reason. TypeScript as a type system has many powerful and unique features. But people often do not know about them or neglect them. In this post, I want to highlight some common escape hatches that people use and why they make TypeScript feel like bloated JavaScript. More often than not, we use TypeScript as bloated JavaScript. For example, { options: Record<string, string> } I would argue that this is why people keep saying that TypeScript doesn’t add much value. In fact, this type tells me (or the users of my code) nothing about what the options are. Consider another example: ...

As computer programmers, it’s easy to get carried away into the vast and interesting world of software engineering. However, we must remember that people use computers as a means to an end, they need to get their jobs done. Despite having endless possibilities of all the features we can build, it’s important to stay focused and true to the needs of our users. This is where the Jobs to be Done (JTBD) framework comes in. Tony Ulwick pioneered this approach, and the basic idea is to take a job that your user needs to do with a computer, and build the best possible software for that particular job. You can of course extend this idea beyond software. By doing so, you put the customer at the centre of your development process and ensure that your software really does serve their needs. ...

Onboarding new team members can be a time-consuming and complicated process, especially when it comes to ensuring they have the right software and tools to do their jobs. Traditional onboarding documentation can be unreliable and quickly outdated. In addition, IT professionals need to keep the device fleet up to date and free of vulnerabilities. Relying on others to maintain the documentation is often unsuccessful, as people tend to disregard updating documentation as a non-essential task. Even those who have worked on the project for a long time can find it difficult to help a newcomer to run the application locally. ...

Lately, I wondered if there is a difference between a software engineer and a software developer. I tried to draw some similarities between the software and construction industries. Both have architects, developers and engineers. So, how come, a software developer can become a software architect, while it is pretty hard to imagine a construction worker becoming an architect just by accruing experience and attending a few online courses? This situation bothered me, especially after observing several software projects that had become hard to maintain and develop due to poor engineering or architectural decisions. Also, I gained a lot of insights from griding Leetcode to prepare for the coding interviews. But this is a story for another post, I guess. ...

Designing applications can be a challenging task. Over the course of my career, I have developed a few guiding principles that I would like to share with you. These are more food for thought, rather than hard rules to follow. Throughout this article, I use adjectives like “good” and “bad” - purely subjectively. Why do we need interfaces? Public interfaces provide an overview of the capabilities of the module. If an interface and its methods have descriptive names (defined later), that interface can be a valuable addition to the documentation. People often talk about tests as documentation. In my opinion, tests document behaviour, while interfaces describe capabilities. ...

As modern front-end applications become increasingly complex, it is becoming more and more important to maintain the separation of concerns between the view layer and the business logic. New toys, old problems Having seen several modern codebases, I can say that history is repeating itself. Back in the day, when PHP was growing in popularity, but the ecosystem was not mature enough, the separation of concerns was a hot topic. For example, rushing to deliver the working code on time, people would query or write to a database directly from the views. ...

A colleague of mine asked a good question: does TypeScript make JavaScript a better OOP language? To answer this question, I decided to compare OOP JavaScript to its opposite, Functional JavaScript. TypeScript has become crazy popular. Many people bet on it as a magical language that will solve their JavaScript problems. Well, it won’t. As Kyle Simpson described in his upcoming book, the quirks of JavaScript don’t disappear. In my opinion, we should not attribute any superpowers to TS apart from just helping developers to feel more confident in the larger codebase. As we know, all the type annotations are wiped out, and all we have left is pretty much JavaScript. Yes, the compiler may add some boilerplate code, like the inheritance implementation (depending on what is in the tsconfig.json file). ...

Tailwind provides a solid base level, sort of a starting point for your application. The library is a set of utility CSS classes that use Custom CSS properties (a.k.a CSS variables). Some of these variables abstract away a default set of design tokens. As such, it is easy to create a dark theme (should a user prefer dark mode) or take some accessibility aspect into account (like reduced animations). I only described the tip of the iceberg. There is a whole ecosystem to support your developer experience. ...