Это все веб код или под ноду? Страшно предположить сколько весит итоговый собранный бандл. Может вам сразу на Rust переписать и в webassembly перегнать потом.
Не станут вас в чем-то убеждать. Если комфортно работать с сырым JS, то пожалуйста, каждому свое. Ваши выдуманные «интерфейсы в JS» таковыми не являютсят. В JS нет возможности гарантировать что в StringFactoryConsumer прилетит аргументом именно экземпляр FirstStringFactory или SecondStringFactory. Это просто бесполезный рантайм оверхед.
Все более-менее популярные библиотеки описаны. Но все равно я предпочитаю использовать пускай менее функциональные но изначально написанные на TS библиотеки. Потому что часто возникают ситуации когда декларации расходятся с самой библиотекой или когда декларации не могут полностью выразить функционал библиотеки или делают это наоборот неполноценно (например без дженериков). Кроме этого я больше доверяю коду написанному на TS чем сырому JS. Уже заметен тренд переписывания популярных библиотек на TS и это замечатально, разумность приходит в массы.
Очевидно имелся ввиду дизайн модели данных/типов, сигнатур методов.
Почему вы считаете что в JS нет интерфейсов?
Уже появились?
Ну то есть к примеру возьмем мы и напишем программу на языке C, запустим компилятор и он ее откомпилирует успешно. Означает ли это автоматически наличие хорошего дизайна в компилируемой программе?
Очевидно потому что там нету типизации и нет интерфейсов, модель данных не опишешь и не зашаришь ее по всему приложению, между сигнатурами всех функций/методов/конструкторов. В сыром JS приоритет направлен на сговнякать что-то по быстрому и в продакшен. В сыром JS дизайн если он изначально в каком-то виде существовал, то очень быстро обесценивается тк он не подкреплен компилятором. Это как издать указы и потом просто считать и народ убеждать что они уже исполнены (реальный случай). Достаточно запустить например статический анализатор JS кода на любом более-менее крупном проекте и почти наверняка там вылезут грабли, как например самый частый случай — передача лишних аргументов в функции/методы. А если речь идет о разработке библиотек или взаимодействии между разными системами, то сырой JS использовать вообще вредно когда существует TS.
не люблю продукты фейсбука, много хайпа, мало пользы
Причины такого положения дел обсуждались на различных англоязчных сообществах. Основная как я понял состоит в политике повышений в должности и соответственно зарплате. Фейсбук поощряет запуск новых штуковин, это один из показателей проактивности влияющий на повышение. Но обнаружился лайфхак, можно просто запустить, развивать эти поделки и фиксить там баги не обязательно для получения повышения.
Это не так. Начальный оферхед есть, но это даже не оферхед, а инвестиция в дизайн системы который как таковой отсутствует при использовании голого JS. Со временем, с ростом проекта и команды при использовании TS преимущества будут только увеличиваться в отличии если бы использовали сырой JS где нарастала бы боль.
Слить бэкенд и фронтенд можно было бы, сделав весь бэкенд на Node.js, но как-то не хочется.
Возможно бэкенде совсем не нужен с этой штукой www.prisma.io? Особенно если сапописанный бэкенд это мерзкий питон и под реакт (который самый первый потребитель graphql)? Идеальный код это ведь ненаписанный код.
Так никто не мешает работу работать и творить после работы, будь то какое-либо искусство или тот же open-source на github. Или попробовать выбить на работе немного времени на open-source. Или найти другую работу, менее ентерпрайзную. Еще можно подумать об удаленной работе.
Это не интерфейсы но их реализация в виде абстрактных классов. TS позволяет описать StringFactoryConsumer и stringFactory без их реализации.
Уже появились?
Это означает что сигнатуры и типы не поломаны.
PS При использовании лок файлов зависимостей сборка того же самого кода должна проходить успешно тк typescript компилятор остается тот же.