Неправославным

Небыстрый, да, но все ж быстрее Интернета 🤔

На самом деле надо просто подумать что тебе нужно.
В первой и второй ссылках, ребята просто постоянно перезаписывали объекты. И в первом случае, как ответили, очень много времени уходило на JSON.parse/stringify .
Если хранить мало информации,  и нужно что бы она была постоянно в кэше браузера. То выбор хороший.
В случае же с данными которые меняются часто, и не столь критичны, то можно юзать sessionStorage.
Но в обоих случаях данных должно быть мало, ибо это не БД.
А и ещё там было написано что localStorage такой медленный потому что он хранится на жёстком диске.

Кстати, а почему не запросить эти данные о пользователе как только  перезагрузил страницу и сохранить их в каком нибудь сервисе? Так и быстрее и с ними работать будет проще.

Подскажите. Тупой вопрос... У меня бэкенд на ноде (TypeScript) и ангулар приложение. Общие сущности описывать в виде интерфейсов или классов? )

это зависит от конкретного подхода

в TypeScript (я могу ошибаться, если так — поправльте) разницы особой нет. В классах могут добавляться еще функции, а интерфейс — это аналог структур в C++). Ещ возможен подход, который используется в Java или том же PHP, когда интрефейс — это "нулевой уровень абстракции", эдакое неявное условие, к которому могут подойти классы любой реализации, не имеющие родственной связи с, допустим, абстрактными классами-полуфабрикатами какой-то классовой библиотеки. А сдругой стороны — они это гарантия унификации отдельных частей.

Но вот, кстати, интересный вопрос

Что хороший тон в  TypeScript?

Мы использовали интерфейсы

Интерфейсы — это просто структуры, или это интерфейсы в понимании Java?

Потом перешли на классы, когда поняли что разницы нету в итоге

После компиляции оно по сути одно и тоже

Ну здесь больше вопрос идеологический

Почему перешли - потому что логический это классы, а не интерфейсы

потому что в итоге — это все просто JS-объект

Вот как вы умудряетесь бэк на ts писать?

В любом ооп языке это были бы классы. Поэтому мы выбрали из

Их*