While AI industry is booming around the world of May 2025, Apple still cannot figure out how to make their products high-performant as competitors do. Safari performance issues, unfortunately, gives me a vibe of Internet Explorer from old days - Microsoft wasted years to support slow and ugly IE.

IE was the biggest limiting factor to write cross-browser complex UI apps. Now we have this situation caused by Apple Safari 🤦🏻‍♂️. Maybe Apple will use AI to finally fix their Safari source code, so it won't end up abandoned as IE - will see.

Live check FPS of your device

Live demo to test FPS of your current browser. Check yourself how Safari is a slow browser, and see how other browsers like Chrome on macOS do render things at 120 FPS.

Let's measure two things:

• RequestAnimationFrame (RAF)
• and scroll speed (measured during a scroll, so scroll slowly to see changes)

See HTML source code of this block to see details about how it is measured

Safari browser is limited to only 60 FPS 🦥

Wether it is modern iOS Pro, Pro Max or even Safari on MacBook Pro - you cannot get JavaScript based computation more frequently than 60 FPS, meaning:

• WebGL FPS limited to 60 FPS
• JS animations limited to 60 FPS (for example scroll based like parallax)
• iOS and iPad devices have this issue for all installed browsers, not only Safari
• JS animations look mis-synchronized (for example page scrolled or swiped and JS animations lag behind and throttle)

Checkout this prominent difference on example of WebGL for Safari and Chrome for the same MacBook Pro with M1 Pro Apple Silicon chip.

Link to check WebGL FPS yourself is https://webglsamples.org/aquarium/aquarium.html

Results for 10K fish rendering scene:

• Safari renders only 60 FPS - not smooth, even for a single fish rendering
• Chrome easily renders 120 FPS

Parallax and similar scroll-based animations will not go faster than 60 FPS on Safari

Because scroll event and other gestures will not trigger JS handler faster than 60 times per second, unfortunately. So, you cannot render smooth JS based animations on Safari.

Use JavaScript just to toggle CSS classes, so they cause CSS animations which are fast.

MacBook Chrome renders 120 FPS while Safari 60 FPS or less 🐌

Yes, even on modern MacBook Pro with Apple Silicon onboard Safari still limited to 60 FPS in best-case scenario. And when you give it a little work, for example to mutate DOM elements styles or content, FPS on Safari will easily drop to 30 and even 19 FPS.

Mobile iOS Chrome is actually Safari under the hood and therefore it is slow

Apple did a strange thing for iOS and iPad - they forced all browser apps to be based on their slow Safari. That means that browsers like Chrome on iOS is slow as Safari because it is Safari under the hood and therefore limited to only 60 FPS or even lower when there is a load on JS - for example during scroll or text selection FPS will drop to lower than 60 FPS, and could be quickly as low as 19 FPS.

Ironically, Apple needs high FPS for their own landing pages 🤣

When you check official Apple landing pages you will see a lot of JS-based animations there, mostly depending on scroll position.

Such animations require high FPS to look good and Safari is still not good browser in 2025 to run JS animations fast.

CSS will-change rule to the rescue (partially, but still limited to 60 FPS on Safari) ✅

If you still want to give your Safari and iOS users better animations, checkout CSS property will-change at MDN https://developer.mozilla.org/en-US/docs/Web/CSS/will-change

Warning: will-change is intended to be used as a last resort, in order to try to deal with existing performance problems. It should not be used to anticipate performance problems.

In general, will-change property let's your browser give more resources to run animations on specific elements, which also costs your device more memory and in general this CSS property should be avoided until really necessary (see MDN page details for that).

If you inspect Apple landing page for MacBook Air you will notice js-will-change CSS class which enables will-change: transform,opacity rule for their animated element.

This trick makes Safari animation smoother (not full 120 FPS though), with higher FPS rate, while other browser engines just normally do smooth animations for all elements even without this CSS force optimization rule.

How to detect Safari based browser engine 💡

To avoid JS based heavy animation you need to detect Safari browser or iOS device.

Here is a simple TypeScript util to do this:

// read more at https://colonel.shnyra.com/2025-safari-is-low-fps-browser-still/
export const checkIsFPSLimitedBrowser = () => {
  const isIOS = /iPad|iPhone|iPod/i.test(navigator.userAgent);
  const isSafari = /^((?!chrome|android).)*safari/i.test(navigator.userAgent);

  // iOS or Safari limited to 60 FPS and even lower
  return isIOS || isSafari;
};

Conclusion

• Avoid heavy JS based animations for Safari because they will look ugly, choppy
• Detect Safari-based browser engine to disable heavy JS based animations there
• Try to use will-change CSS property as the last resort to get better animation in Safari
• Use mostly CSS animations, as they are fastest 120 FPS, GPU accelerated where needed
• Use lightweight JS based animations for Safari - just to toggle CSS classes or to update CSS properties to trigger CSS animations for smooth experience

Here is a TypeScript trick to keep IDE intellisense suggestions for known options but still allow arbitrary strings to be provided without any compiler errors.

As the main screenshot of this article shows, the solutions is as simple as that:

type Color = 'red' | 'blue' | 'other' | (string & {});

let color: Color = 'custom-is-fine';

color = 'red';

color = '' // here will be suggestions shown to choose from 'red' | 'blue' | 'other'

All the magic is done by (string & {}) in our union of options.

By providing string as intersection with & {} we keep this string as separate option of union instead of collapsing the whole union to just any string.

This way autocomplete works by suggesting exact known literal options.

It is important to say that without intersection, our IDE autocompletions won't know what to suggest to write because union collapsed to just string as on the screenshot below:

P.S. without string intersection in union, to open arbitrary suggestions for just a string press CMD+I in VS Code on Mac OS.

The trick was found during inspection of source code for cool tsup package right on this line - https://github.com/egoist/tsup/blob/bee8f42dc72c5b40c2946422fc632069dde2a55b/src/options.ts#L94

CSS-only: Automatic Dark Mode for Images ⭐️

Just two CSS properties can adapt a light image for Dark Mode.

In Tailwind, it takes only two classes:
invert hue-rotate-180 (open in playground)

1️⃣ The invert filter turns white into black but distorts other colors.
2️⃣ However, hue-rotate shifts the hues to approximate the original colors:
→ red stays red
→ green stays green
→ blue stays blue
→ and so on.

By adjusting inversion percentage and hue rotation you can quickly fine tune your image to match dark mode the best.

With this trick you may not need to generate separate images for dark mode on your website. Just apply proper styles to existing images.

The trick inspired by https://v8.dev/blog/javascript-code-coverage images styles.

How to wrap any function without using any types to keep your code as strict as possible.

Our goal is to have a universal solution so it should:

• wrap function with zero or more arguments
• preserve types of original function (infer arguments and return type)
• should work under strict compiler options of TypeScript

This will allow us to:

• create wrappers around other functions (e.g. log function results or dispatch analytics events)
• accept other functions as arguments to call them inside
• call other functions before or after target function
• or other cases.

Solution

Look, no any and as SomeType lies to compiler 🎉

const wrap = <F extends (...args: never) => unknown>(f: F): F => f;

// no args
// ✅ const f1: () => number
const f1 = wrap(() => 55);
// with args
// ✅ const f2: (msg: string, shift: number) => number
const f2 = wrap((msg: string, shift: number) => msg.length + shift);

This solution works with strict compiler options of tsconfig.json

{
  "compilerOptions": {
    "strict": true,
  }
}

TypeScript version is 5.5.3 and you can play with this code on TS playground.

How it works

• use generics function to infer types from arguments
• constraint generic argument with extends
• args: never is a trick here to allow path functions of different signatures with and without arguments
• unknown as return type so we actually don't restrict return type

But, caveats...

Unfortunately, for more complex scenarios you may still need to mark your code with @ts-ignore or @ts-expect-error or @eslint-disable-next-line in cases like this:

const anotherWrap = <F extends (...args: never) => unknown>(f: F): F => {
    // ❌ Error Type '(...args: never) => unknown' is not assignable to type 'F'.
    //   '(...args: never) => unknown' is assignable to the constraint of type 'F', but 'F'
    //   could be instantiated with a different subtype
    //   of constraint '(...args: never) => unknown'.(2322)
    const internalWrap: F = (...args) => f(...args);
    return internalWrap;
};

Because TypeScript compiler cannot safely match types compatibility.

Even if you explicitly tell the compiler it is completely the same whole function type or the same arguments type:

// ❌ still cannot match proper type
const internalWrap: F = (...args) => f(...args);
const internalWrap2 = (...args: Parameters<F>) => f(...args);

It is really a pity that such a simple idea like monkey patching cannot work safely in TypeScript and requires lies to compiler like ignoring errors or loosing type safety via any type.

JavaScript as many other programming languages has real difficulties when it comes to rounding numbers on edge cases for floating numbers.

TL;DR;

Proper, elegant solution to round numbers in JavaScript using Number.EPSILON (MDN link) correction 🤓:

const round = (num = 0, fractions = 0) => { 
  const k = Math.pow(10, fractions); 
  const n = (num * k) * (1 + Number.EPSILON); 
  return Math.round(n) / k; 
}

With this util you can properly handle edge cases like these:

// custom round works properly
console.log(round(23.435, 1) === 23.4);// true
console.log(round(4.475, 2) === 4.48); // true
console.log(round(1.255, 2) === 1.26); // true
console.log(round(1.005, 2) === 1.01); // true
console.log(round(5.015, 2) === 5.02); // true

// native method fail to round
console.log(+23.435.toFixed(1) === 23.4);// true
console.log(+4.475.toFixed(2) === 4.48); // false
console.log(+1.255.toFixed(2) === 1.26); // false
console.log(+1.005.toFixed(2) === 1.01); // false
console.log(+5.015.toFixed(2) === 5.02); // false

View full code on TypeScript playground demo

Why this needed?

Native method to round floating numbers in JavaScript is .toFixed which causes bugs on edge cases due to Round-off error (read on wikipedia).

The most prominent example of issue is when you add two simple number 0.1 and 0.2:

0.1 + 0.2 === 0.30000000000000004

This example is so popular that there is even a website dedicated to showcase this problem - https://0.30000000000000004.com/

Why this can be a problem?

Miscalculated numbers may have different bad impact:

• ranging from bad "out of boundaries" rendering of values on frontend (UI bugs)
• to causing failed comparisons of numbers which may trigger wrong conditional branches to run actually unintended code (functional bugs)
• and potentially cause invalid financial transactions processing with wrong amount of money distributed between participants

Some effects may be noticed immediately, for example hash functions produce completely different results even when a single character out of long text is different (which is in our case may be a different small fraction of a number).

While other effects are not that obvious but may cause eventually wrong results due to accumulation of slight errors over time (imagine slightly different number multiplied millions of time in some algorithms).

How to handle advanced cases

For very complex and precise calculations with floating numbers you may need to use npm package like this - https://mikemcl.github.io/decimal.js/

Trait means behaviour or some way of appearance if we talk about UI. For example a duck has traits to walk, swim, fly and others. Similarly, components in our programs have their own behaviour. Imagine component button withConfirmationDialog behaviour (trait) or a menu tab withBadgeCounter appearance (trait).

Composition over inheritance

To understand traits more, let's first remember classic simple idea of inheritance from OOP world - behaviour and properties of an object are inherited from its parent. That is why a puppy can walk and bark similarly to its parent dog.

In programming world, things are more agile and we don't need to inherit objects to reuse a specific behaviour. This better way of reusing behaviour is achieved through a composition of traits.

Idea of trait is to extract behaviour and properties from component and reuse where needed easily. So, we can take a fish and extend it with walk trait - and it will walk! In virtual world we don't need a parent to inherit from, just get a behaviour and apply to any needed component of a program.

Adding new methods to objects is easy for JavaScript - just assign needed method to instance and voila. Some languages like Scala and PHP even made traits as part of language syntax.

But how to apply traits to functional component of React? First approach

In functional programming a trait can be expressed as a function wrapper.

Let's consider next example using builder pattern:

export const MyComponent = withQA()
  .withDefinedUser()
  .withErrorBoundary({ name: 'CustomNameComponent' })
  .withAuthorizationRequired() // show a sign in button for unathorized users instead of content below
  .render(({ currentUser }) => {
    return <div>Hello {currentUser.nickname}</div>;
  });

Here is MyComponent is a simple React component that renders authorized user's nickname, but extended with few traits:

1. withDefinedUser - makes sure currentUser prop provided to component, so we don't need to use "useCurrentUser" hook inside.
2. withQA - extends component with convenient debug tools in runtime.
3. and others

Remember those old days, when react-router suggested to use withRouter ? That's another practical example of a component trait! And withRouter is called here a "high order function" as it takes other function as argument and returns another function.

While this approach may look concise it is actually a tricky and cumbersome to implement and sometimes hard to debug rendering properly when multiple layers of traits composed to a component. Especially heavy part is for TypeScript apps where we need to forward and extend lots of generics till the needed component's rendering content - that's why I let you figure out yourself how can this builder pattern can be coded in reality.

HOC is the way to go. The winner

High order components in React works great to express traits composition. HOC is also a function wrapper actually but it leverages all the beauty of JSX syntax.

<WithConfirmationDialog
  trigger={<StyledButton>logout</StyledButton>}
  onConfirm={logout}
/>
<WithQA>
  <WithDefinedUser
    render={({ currentUser }) => (
      <Hello greeting="Hello" currentUser={currentUser} />
    )}
  />
</WithQA>
<Hello greeting="Hola" />

Reasons to use HOC instead of builder pattern or other high order functions:

• Better readability due to JSX (especially when lots of arguments configure HOC behaviour)
• Semantically proper tree in virtual DOM due to component names without hidden layers of intermediate components created by high order functions from first example
• Idiomatic way for React to compose functionality of components
• Easy to implement - just regular components with children

Because of that, I mostly use HOC to compose traits on top of my base components while builder pattern is rarely used and just for simple extensions (usually because of existing code style for a particular component).

First, developers write programs. Then, they write code (programs) which produce programs (code) based on other code (programs) - this is meta programming.

The simplest example of meta programming in JavaScript I can think of is Object.keys - iterate through any object's keys and do something with them. This allows to change behaviour of a program dynamically in runtime.

Therefore, with magical power of JavaScript we can analyze any object - check for object keys, their types, modify and assign new properties and methods to any object / class.

Thankfully, TypeScript brings clarity (again) to JavaScript magic so we can create type-safe magic-enabled apps.

Case - API silent methods

My recent case for metaprogramming with TypeScript happened with the help of key remapping in mapped types .

For REST API endpoints I use classes with static methods like next:

class ProfileAPI {
  getMyProfile() { ... }
  
  updateMyProfile() { ... }
}

Using axios for networking, I created interceptors to catch error responses and show relevant error toasters (aka snackbar notifications) using nice and simple react-toastify npm package.

But I don't want to show for every method of API, because:

1. I want to handle error differently, e.g. show response error right below button user clicked instead of toaster in top right corner
2. sometimes it is not needed, e.g. optional side-effect which runs on interval and not every request is critical.

Solution - extend API with silent methods

With little help of JS magic, I turned my APIs into new classes with more methods:

class ProfileAPI {
  getMyProfile() { ... }
  
  updateMyProfile() { ... }

  getMyProfileSilent() { ... }
  
  updateMyProfileSilent() { ... }
}

Methods with Silent suffixes are added automatically and have the same behaviour as original methods which you can then extend as you need via monkey patching.

type RemapKeysWithSuffix<O extends object, Suffix extends string> = {
  [K in keyof O as `${string & K}${Suffix}`]: O[K]
};

// add special behaviour to new "virtual" methods during class build
const build = <A extends object, Configs extends Record<string, {}>>(api: new (config?: {}) => A, configs: Configs): A & RemapKeysWithSuffix<A, string & keyof Configs> => {
  const result: Record<string, any> = new api();
  Object.keys(configs).forEach(suffix => {
    const config = configs[suffix];
    const configuredApi: Record<string, any> = new api(config);
    Object.keys(result).forEach(key => {
      // monkey patch here
      result[key + suffix] = configuredApi[key];
    });
  });
  return result as any;
}

const DemoApi = build(class DemoApi {
  method() { }
  anotherMethod() { }
}, { Silent: {} });

DemoApi.anotherMethodSilent();

Case - type safe query for database

Another prominent case I used metaprogramming for is related to Proxy.

On my backend project, which is written with a great framework NestJs I use TypeORM query builder technique to get complex data joins from PostgreSQL database while preserving type safety like next:

const subSelect = this.repo
    .createQueryBuilder(safe.Alias.sub2Submission)
    .select(safe.sub2Submission.createdDate)
    .where(`${safe.sub2Submission.participantId} = ${safe.subSubmission.participantId}`)
    .groupBy(safe.sub2Submission.score)
    .addGroupBy(safe.sub2Submission.createdDate)
    .orderBy(safe.sub2Submission.score, 'DESC')
    .addOrderBy(safe.sub2Submission.createdDate, 'ASC')
    .limit(1)
    .getSql();

Now, all "raw queries" are used only through special safe object with properties generated in runtime and only for allowed value.

Solution - Proxy query generator

With the next little util I can create string generators backed by type safety of TypeScript:

export const createSafePropertyGetter = <T>(prefix?: string): Record<keyof T, string> => {
  return new Proxy({} as any, {
    get(_, prop: string) {
      if (typeof prop === 'symbol') {
        throw new Error('try to use safe.Alias.desiredEntity');
      }
      return prefix ? prefix + '.' + prop : prop;
    },
  }) as any;
};

So, let's say I have entity (database table) called profile, we do next:

// define list of entities
type allEntityNames =
  | 'profile'
  | 'file'
  | 'member'
  | 'friend';
export const Alias = createSafePropertyGetter<Record<allEntityNames, string>>();

// create namespace to conveniently group all entities in one object
namespace nsSafe {
  export const profile = createSafePropertyGetter<ProfileEntity>(Alias.profile);
}

export const safe = {
  Alias,
  ...nsSafe,
} as const;

// now use it everywhere needed
safe.Alias.profile; // => 'profile'
safe.friend.invitedById; // => 'friend.invitedById'

Benefits of this approach is all entities names and their properties are type safe, inferred from entity interfaces and type aliases and type checked during compilation, which in turn means:

• No typos
• IDE Suggestions for available properties
• Code is linked through project files, I can find all references to any property in query builder
• Easy to refactor and maintain
• Strict and clear pattern to follow across the team

Read more

As part of metaprogramming, I encourage you to experiment with TypeScript decorators which is still in experimental mode (TC39 stage 2 proposal) after so many years, though. But I like this feature and hope they will make decorators available not only for class methods, but for plain arrow functions.

For me personally, metaprogramming is like magic because ability to program change itself in runtime based on inspection of its own code and data is a great origin story for Artificial Intelligence to appear - but that's another big topic for future 😉

As per nowadays trends, TypeScript is a smart language which can understand types of static code without explicit indication of type thanks to its type inference ability.

Type inference is really one of the best thing about this language, I use it every day I write a code. And strongly recommend you to understand where and why TypeScript can infer types and where cannot - so you have to explicitly mark appropriate type in this case.

Problem to solve

Need a way to enforce object literal structure while inferring exact properties of object as literals instead of general types "string" or "number".

Solution

Universal identity function - a function that returns exactly what it receives -

// src/utils/type.util.ts
export const inferIdentity = <BaseType,>() => <T extends BaseType>(value: T): T => value;

Usage demo:

interface CustomRoute {
    path: string;
}

const homeRoute = inferIdentity<CustomRoute>()({
    path: '/',
} as const);

const otherRoute = inferIdentity<CustomRoute>()({
    pathTypo: '/other',
//  ^ Error: Object literal may only specify known properties, and 'pathTypo' does not exist in type 'CustomRoute'.(2345)
} as const);

If some type is widely used, you can reuse identity easily:

export const identityRoute = inferIdentity<CustomRoute>();

// reuse across the app
const anotherRoute = identityRoute({
    path: '/another',
} as const);

Note, we name new util as identityRoute instead of inferIdentityRoute because function is identity function now:

• identityRoute is not a high order function anymore, but a simple function.
• inferIdentity returns identity function instead of its argument, like identity function would do.

How it works?

Because of a type closure. Similar to runtime JavaScript closure, we can capture generic type for its child function.

Therefore, actually, the "universal identity function" is not an identity function but a high order function that returns an identity function and type closure helps to constraint generic type needed.

Why it is useful?

To explain reasoning here, let's start with a simple scenario.

Imagine you need an object literal config to use across the app:

export const config = {
  timeout: 1e3,
}

// and the related type is
const config: {
    timeout: number;
}

Now, we want to use our great type inference in some places to understand exact timeout value defined. Currently timeout is any number , so we add as const to keep exact values of properties:

const config = {
  timeout: 1e3,
} as const;

// and the related type is
const config: {
    readonly timeout: 1000;
}

Cool, now we can infer types of whole config, or its properties and further transform them via mapped types and constraint code with specific union literals, for instance.

Such code is actually enough for a small demo app, but in reality production apps:

• Have much bigger object literals
• Hard to remember which exact properties are available for every object literal
• Need a reliable way (compile error) to avoid typos in object properties

For that, interfaces and type aliases comes to the rescue:

const config: IConfig = {
  timeout: 1e3,
}

Which is great - TypeScript now suggests us which properties are available for us to configure, and will raise a compile error in case of typo or wrong type defined for a property.

Only one thing left for it to be perfect - we need to know exact values of object literals instead of abstract IConfig interface.

For that, you come up with an idea of identity function:

const configIdentity = <T extends { timeout: number }>(config: T): T => config;

const config = configIdentity({
    timeout: 1e3,
} as const);

// and the related type is
const config: {
    readonly timeout: 1000;
}

Awesome, now you can create all the identity functions for all the object literals and even primitive types to make your codebase constrained and obvious.

Or you may use a single universal identity function shown at solution section of this article 😉.

Web development is full of external dependencies and frontend developers and NodeJs developers are especially depend on node_modules which we know are the heaviest objects in the universe.

Recently I faced with a critical issue with one of my code packages - NextJs caused a compiler error, so I was unable to build my app with TypeScript.

Since NextJs is a core dependency of my project, I cannot replace it with something else, so I have to find a workaround on fixing npm package in a quick way. Issue details will be explained below, but first let's define general goals on the fix:

• Solution has to be explicit, universal and elegant
• Solution has to be git tracked
• Without Pull Request on GitHub repo (no time to wait for maintainers attention and approval)
• Without forking GitHub repo to create my own version of package (I will not maintain this package as good as maintainers of official NextJs framework)
• Solution has to be easy maintained after package version upgrade

Patch-package to the rescue!

Hopefully, some good developers from a community already took care about my case - patch-package is an npm package which patches source code of any package as if I would directly commit changes to package while still git ignoring node_modules.

Solution demo

Solution was very simple and fully aligned with general goals defined abode.

Screenshot below shows a full needed changes to my package to build the app without compiler errors. (if you ignore description comments, solution is just a few lines of code).

Issue use case

In my situation, the issue was with global typings .d.ts files placed deeply inside git ignored source code of npm dependency - typings of CSS modules are defined in an incompatible way with my tsconfig.json restrictions.

Original NextJs global.d.ts file makes all classes imports from *.module.scss in form of string record:

const classes: { readonly [key: string]: string }

What is wrong with it? It is weakly typed - you can refer to any arbitrary class name in your code and by default TypeScript compiler will be fine with that allowing potential runtime bugs, especially in future:

import style from './index.module.scss';

// no error by compiler 👎
<div className={style.nameWithTypo} />
// no error by compiler 👎
<div className={style.anotherTypoMissedHere} />
// no error by compiler 👎
<div className={style.previouslyDefinedButRemovedOrRenamedNow} />

Hopefully, we can make TypeScript compiler more stricter and force us to check all arbitrary members of objects via enabled option noUncheckedIndexedAccess in tsconfig.json. With this option, all our classes from module css files are potentially undefined.

So now, every object member checked by compiler and raise compile errors in cases like that:

import clsx from 'clsx';
import style from './style.module.scss';

    <Button
      className={clsx({
        [style.autoMargin]: props.fullWidth,
//         ❌  ^ A computed property name must be of type 'string', 'number', 'symbol', or 'any'.ts(2464)
      })}
      />
      {children}
    </Button>


// error is equivalent to
const demo = { [undefined]: true };
//           ❌ ^ A computed property name must be of type 'string', 'number', 'symbol', or 'any'.ts(2464)

In code above, style.autoMargin potentially undefined and therefore not allowed to be used as key for literal object.

Of course I do not want to check in runtime existence of my class name. Also I do not want to lie to my compiler via terrible non-null assertion operator:

const panic = <T extends unknown>(value: T): NonNull<T> => {
  if (value === undefined || value === null) {
    throw new Error('value undefined');
  }
  return value;
}

// 👎 runtime check via panic looks like over engineering
<div className={panic(style.autoMargin)} />
// 👎 non-null assertion is a lie to compiler, do not spoil the code
<div className={style.autoMargin!} />

So, the solution is to change module css typings

declare module '*.module.scss' {
  const classes: any
  export default classes
}

Now we don't need to handle potentially undefined values 🎉

But wait, your classes: any is even worse than a string record

Not exactly, because I use other technique to keep my CSS modules names relevant - TypeScript plugin typescript-plugin-css-modules.

This way, my favourite IDE VS Code helps me to know relevant CSS classes and highlight issues like typos.

I believe this approach is a good balance between development convenience and type reliability. For something more important than classnames, I would rely on real compiler check (no lies via :any or ! or as SomeType) or even runtime check like with a panic util above.

Nowadays, WebGL is a popular technology for developing engaging frontend web apps. I see more and more global companies like Stripe use WebGL to create awesome animations on their landing pages.

This background mesh gradient is smoothly animated ☝️ (visit https://stripe.com/ to see it in action)

Below you can see realtime rendered by your device running WebGL programs 👇🏻

Tubes with textures

Glass

Matrix with the flag of Ukraine

Metaball

Helix

How to create such animations?

Learning WebGL might seem an overwhelming because of new terminology, new approach to render things on a screen and a setup of WebGL is not straightforward comparing to usual 2D canvas context.

Here are base steps you may do:

• Go through WebGL tutorial on MDN
• Google about "introduction to WebGL shaders"
• Install IDE extensions to to highlight and explain GLSL language (e.g. for VS Code, I recommend this one - slevesque.shader)
• Search for YouTube videos
• Feel overwhelmed 😩, rest for a while 😌
• Repeat steps multiple times ♻️
• Finally, produce first meaningful WebGL programs ✅

Or can it be simpler?

Yes! Focus only on WebGL fragment shaders without caring about vertex shaders, WebGL API and other stuff . All you need is to understand fragment shaders (written in a language called glsl).

Here are my favourite sources I recommend to go through:

• https://thebookofshaders.com/ - interactive online book with practical examples
• https://www.youtube.com/user/osakaandrew/videos - step by step video to run WebGL program

To simplify things for you, I have created an overshader - a simple NPM package to render WebGL shaders without complex details behind the scene.

Animations above - which are called WebGL programs - are created with overshader.

To get started, just checkout README.md of my package - https://github.com/overshom/overshader

Explore source code (shaders) of examples - https://overshom.github.io/overshader/github-demo/index.html

README.md on GitHub describes how you can easily launch your own WebGL shader program which is as simple as:

import { runWebglProgram } from 'overshader';

runWebglProgram({
    canvasContainer: '.responsive-canvas-container',
});

• canvasContainer - simple div, inside which canvas with WebGL program will be inserted
• by default, my package renders a simple program so you can easily see it is working

Feel free to fork or just clone my repo and launch it locally - it is fast and convenient to work with inside IDE like VS Code.

Benefits of using WebGL

• Leverage GPU processor of your device to run animations at impressive 60Hz or even 120Hz (device dependent, of course) (usual Canvas 2D context will not provide such a fast rendering for any complex animation)
• Control every pixel rendered on a screen - create very complex and mind blowing rendering scenes
• Improve your math skills (a shader program is full of vectors, matrices, dot products, sin and cos and lots of other stuff)

Debug WebGL

Short answer - there is no actual debug tools in browser yet for WebGL like console.log or Chrome Dev Inspector, no breakpoints, what we can do instead is to use canvas rendered pixels itself as our inspector.

For that purposes, I have written a simple fragment shader debugger - it renders red, green and blue channels for vec3 vectors and has vertical lines which indicate value of every vector component ( r,g,b or x,y,z if you like)

This way ☝️ you can render your values (vectors) and see their value from a range (-∞, -2, -1, 0, 1, 2, ∞+)

How it works:

• Very first vertical line on the left - means value is -2
• Second vertical line - means value is -1
• Center vertical line - means value is zero
• Next line - means value is 1
• And the last line - the very right one - means value is 2

Simpler debugging

The simplest debug you can make is just to output a high-contrast color on a screen, like red:

gl_FragColor = vec4(1., .0, .0, 1.);

Get inspired by Shadertoy

To uncover awesome approaches of using fragment shaders - visit Shadertoy - a playground and collection of interactive fragment shaders.

NOTE: fragment shaders are not efficient to render everything.

The best rendering performance (FPS) for complex scenes will be a combination of dozens different fragment and vertex shaders applied to different rendering objects, scenes, with properly optimized 3D models (exported from other tools like Blender) and other stuff.

Once you are good with fragment shaders, I recommend you to go further and learn libraries like THREE.Js

• You can play online with their editor at here - https://threejs.org/editor/

I hope now you will find an opportunity to integrate WebGL shaders into your apps and make the web even more beautiful and interactive place.

In TypeScript, enum can be represented in multiple forms:

• Numeric enums ("default")
• String enums (where key represents a literal string)
• Heterogeneous enums (mix of numbers and strings, some of them are computed in runtime)

Among these multiple forms I believe string enums are the most used in web apps development because of their human readability. Unfortunately, string enums are not "default" version of enums in TypeScript , so whenever you need to use enums in a human readable form you need to explicitly define values for every member of enum. This comes with an awkward incompatibility between enums as described below.

Issue demo

enum ERole {
    USER = 'USER',
    ADMIN = 'ADMIN',
}

enum ERoleBeta {
    USER = 'USER',
    ADMIN = 'ADMIN',
}

// 🤦🏻‍♂️ nightmare 🤦🏻‍♂️
const role: ERole.ADMIN = ERoleBeta.ADMIN;
// ❌ ^ Type 'ERoleBeta.ADMIN' is not assignable to type 'ERole.ADMIN'.(2322)

Code above in runtime (in JavaScript) will be equivalent to const role = 'USER' and we know TypeScript marked variable role as of type ERole.ADMIN which value is literal string 'USER'. Nevertheless, TypeScript compiler does not allow such assignment because different enums are not compatible even if their values are the same.

// 🤦🏻‍♂️ nightmare 🤦🏻‍♂️
const role: ERole.ADMIN = 'ADMIN';
// ❌ ^ Type '"ADMIN"' is not assignable to type 'ERole.ADMIN'.(2322)

Also, you cannot assign literal string to enum type.

All these restrictions make sense if we would use number enums, or mixed enums. But if we conventionally agree enums to be only string enums there should be a better way to write our code!

Solution goals

let assignableToEnum: EBaseRole;
// ✅ compatible with self values
assignableToEnum = EBaseRole.USER;
// ✅ compatible with literals
assignableToEnum = 'USER';
// ✅ compatible with other enums for same values
assignableToEnum = EAdvancedRole.USER;

let assignableToLiteral: 'USER';
// ✅ compatible with all enums same values
assignableToLiteral = EBaseRole.USER;
assignableToLiteral = EAdvancedRole.USER;

// ✅ error raised at compile time
let expectError: EBaseRole = EAdvancedRole.VIEWER;
//  ^ Type '"VIEWER"' is not assignable to type 'EBaseRole'.(2322)

☝️ Also, we want to avoid dirty lies to our compiler like as unknown as ERole.ADMIN

Solution implementation

const LiteralEnum = <T extends string>(...values: T[]): {
    [K in T]: K;
} => {
    const res = {} as any;
    values.forEach(v => {
        res[v] = v;
    })
    return res;
}

Create util function to build our enums from literals arguments:

• To make sure our keys equal to values
• To emphasise the way we create enums
• To easily search through a project which enums were created by our util

P.S. I decided to call the util with capitalised character to highlight its specialty. We try to workaround native language inconveniences.

The important trick!

export const EBaseRole = LiteralEnum(
    'USER',
    'ADMIN',
);
export type EBaseRole = keyof typeof EBaseRole;

Now, when we create our enum, we define type of same name as the const to leverage declaration merging technique of TypeScript.

Now, TypeScript compiler can smartly recognise context and use either type of enum or enum value 🧠 🎉

Full working demo

const LiteralEnum = <T extends string>(...values: T[]): {
    [K in T]: K;
} => {
    const res = {} as any;
    values.forEach(v => {
        res[v] = v;
    })
    return res;
}

export const EBaseRole = LiteralEnum(
    'USER',
    'ADMIN',
);
// ✅ easy to convert to union
export type EBaseRole = keyof typeof EBaseRole;

export const EAdvancedRole = LiteralEnum(
    'USER',
    'ADMIN',
    'VIEWER',
);
export type EAdvancedRole = keyof typeof EAdvancedRole;

let assignableToEnum: EBaseRole;
// ✅ compatible with self values
assignableToEnum = EBaseRole.USER;
// ✅ compatible with literals
assignableToEnum = 'USER';
// ✅ compatible with other enums for same values
assignableToEnum = EAdvancedRole.USER;

let assignableToLiteral: 'USER';
// ✅ compatible with all enums same values
assignableToLiteral = EBaseRole.USER;
assignableToLiteral = EAdvancedRole.USER;

// ✅ error raised at compile time
let expectError: EBaseRole = EAdvancedRole.VIEWER;
//  ^ Type '"VIEWER"' is not assignable to type 'EBaseRole'.(2322)

You can try this in TypeScript playground:

TS Playground - An online editor for exploring TypeScript and JavaScript

The Playground lets you write TypeScript or JavaScript online in a safe and sharable way.

An online editor for exploring TypeScript and JavaScript

Did you know?

You can easily convert enum to union of literals with the help of template literal types:

enum ERole {
    USER = 'USER',
    ADMIN = 'ADMIN',
}

const unionFromEnum: `${ERole}`;
//    ^ unionFromEnum: "USER" | "ADMIN"

// ✅ 
unionFromEnum = 'USER';
// ✅ 
unionFromEnum = ERole.USER;

This is a quick-trick for some hot fixes.

For usual development, I would suggest to stick with the LiteralEnum util we created today.

TypeScript 4.1 introduced an awesome concept of template literal types which allows us to parse literal types and extract their parts as types for further manipulations.

The most prominent use case of this approach for frontend is to get types of parameters from URL path.

ExtractRouteParams type

type ExtractRouteParams<T extends string> = string extends T
  ? {}
  : // we have start/:oneId/restOfUrl
  T extends `${string}:${infer Param}/${infer Rest}`
  ? { [k in Param | keyof ExtractRouteParams<Rest>]: string }
  : // we only have start/:oneId
  T extends `${string}:${infer Param}`
  ? { [k in Param]: string }
  : // nothing found
    {};

This is basic implementation of generic type to infer params from URL according to param pattern :param which works good for any string length due to recursion.

Use cases

Create custom React hook which will return existing params for current URL

// ✅ typed params infered from literal string
const { friendId, photoId } = useTypedParams<'/friends/:friendId/photos/:photoId'>();

Usually, you will run this hook inside a component of a specific page like useTypedParams<Routes.somePage>(); so generic can infer params from its type argument = literal string from app-wide constant of all routes.

Replace URL params to build link for navigation

// ✅ typesafe replace params via object with properties
const url = buildLink('/friends/:friendId/photos/:photoId', { friendId, photoId });

<Link to={url}>view photo</Link>

TypeScript union types represent multiple types at the same time.

It is convenient to group types into unions to explain they share something in common, they have common purpose (think of redux reducer which receives an action object of many different shapes).

For TypeScript there is an awesome technique called type narrowing

Type narrowing - technique that allows a compiler (and developer via IDE) to understand which exact type (shape) is present inside code block.

How to narrow types

Let's say we have union of two other types like below:

type SignInAction = {
  type: 'sign-in';
  email: string;
  password: string;
};

type VerifyEmailAction = {
  type: 'verify-email';
  email: string;
  otp_code: string;
};

type Action = SignInAction | VerifyEmailAction;

Now, we can narrow type of union via runtime check:

const handleAnyAction = (action: Action) => {
  if (action.type === 'sign-in') {
    // ✅ fully typed
    return action.password;
  }
  if (action.type === 'verify-email') {
    // ✅ fully typed
    return action.otp_code;
  }
};

Also, we can narrow type in types context only via built-in utility type Extract:

// ✅ structure is same as for VerifyEmailAction
type ActionWithOtpCode = Extract<Action, { otp_code: string }>;

Also, we create a generic guard which will safely narrow types like that:

const guardForActionType = <T extends Action['type']>(
  action: Action,
  type: T
): action is Extract<Action, { type: typeof type }> => action.type === type;

const handleEmailVerification = (action: Action) => {
  // makes sure that action is of type VerifyEmailAction
  if (guardForActionType(action, 'verify-email')) {
    // ✅ fully typed
    return action.otp_code;
  }
  throw new Error('invalid action provided');
};

Type narrowing via generic guard is especially useful for complex types (shapes) where you need to check multiple fields.

Concept of async / await keywords made code much more readable and maintainable in comparison of callback hell but still we need to handle errors for async operations.

Usual try / catch blocks will make a code nested, create new closure making variables created inside inaccessible outside of try / catch.

To avoid new closure and make code flat (all rows are on the same level of depth) for async / await we can use a simple util calm

Solution goals

const [value, error] = await calm(fetch('https://api.my.app/endpoint'));
if (error || !value) {
  // handle case
  return;
}

operate(value);

Implementation

type ThenArg<T> = T extends PromiseLike<infer U> ? U : T;

const calm = async <P extends Promise<any>>(p: P): Promise<[ThenArg<P> | undefined, Error | undefined]> => {
  try {
    const value = await p;
    return [value, undefined];
  } catch (error) {
    return [undefined, error];
  }
}