Состоялся релиз Node.js 23.0.0, платформы для выполнения сетевых приложений на языке JavaScript. Node.js 23.0 отнесён к промежуточным веткам, сопровождение которых осуществляется в течение 7 месяцев (до июня 2025 года). В ближайшие дни будет завершена стабилизация ветки Node.js 22, которая 29 октября получит статус LTS и будет поддерживаться до апреля 2027 года. Поддержка прошлых LTS-веток Node.js 20.x и 18.x продлится до апреля 2026 и 2025 годов соответственно...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62066
Даже нода стала развиваться в правильном направлении после появления дено и других банов.
В JS вполне существует типизация, а вот то что для того что бы ей воспользоваться нужно новый синтаксис завозить это я щитаю провальный провал.
>платформы для выполнения сетевых приложений на языке JavaScriptтеперь уже не платформа для бэк разработки? что бы это вообще значило "выполнения сетевых приложений"?
>>платформы для выполнения сетевых приложений на языке JavaScript
> теперь уже не платформа для бэк разработки? что бы это вообще значило
> "выполнения сетевых приложений"?Ну так для бэкэнда не берут, а для написания всяких клиентов, маскирующихся под браузеры - очень даже. Чем не сетевые приложения. Смешно, конечно.
>> Ну так для бэкэнда не берутС чего вы это невежество взяли? Попробуйте сделать реальный тест производительности - очень удивитесь. Node позволяет создавать весьма производительные сервера, так-что не стоит эту платформу недооценивать. А сообщество у JavaScript большое. Вакансий полно, нода востребована.
А что значит бэк? Задней разработки? Програмульки предназначенные для WWW стоит называть паутинными програмами.
Не прошло и ста лет. В это же время разработчики массово сваливают с тайкпскрипта на ванильный яваскрипт
Почему сваливают? что не так с ts?
ненужная прослойка
Типизация позволяет не допустить множества ошибок ещё на этапе разработки. Очень печально что некоторые люди не могут осилить TypeScript. На практике это месяцы экономии времени за год. Может JavaScript разработчики свои маленькие задачки быстрее выполняют за день, но совокупность задач за год у них явно меньше, потому что ошибка на ошибке и ошибкой погоняет. Всё зависит как считать - комитмент на спринт у них вроде больше, а по ценностям скрама разработчики TypeScript как правило выигрывают, так как на более долгие сроки у них комитмент выше. Именно из-за типизации. Более того слаженность команды выше также из-за типизации. Поддержка проще, точно по тем же причинам.
>На практике это месяцы экономии времени за годхотелось бы более точных данных, но понятно что нет пока такой возможности
Возьми несколько проектов, да и сравни задачи и поговори с разработчиками - получишь данные самые актуальные, для своей компании. Если разработчики TS знают и применяют, то качество задач и кода должны быть выше. А JS может выглядеть так будто они в 2–3 раза больше задач сделали, только большая часть это работа над ошибками, которая растягивается в процессе TL-QA-SD над одной реальной задачей. А если до этих гениев тесты приходит в голову писать - то эти весьма важные люди о-о-очень медленно начинают работать. Впрочем все зависит от проекта, в вебе тесты не так часто нужны, разве-что если BDD на каком-нибудь финтехе. Потом заметь взаимодействие команд - внезапно JS команды как правило маленькие и не могут вырасти, а вырастают - продуктивность не особо увеличивается. Их приходится дробить, задачи делить, заниматься их взаимодействием. А TS просто могут использовать контракты на многих этапах разработки, впрочем проблемы могут быть точно те же, только реже из-за особенностей ЯП. Впрочем у каждого по разному. И все зависит кто что использует для разработки.
Скажите это относиться и к питон, пхп, руби итд? И если несложно расскажите какой красивый и легко поддерживаемый код у java разработчиков пожалуйста.
слишком много сарказма в таком коротком сообщении))
> Скажите это относиться и к питон, пхп, руби итд?И во все три за последние годы была добавлена статическая типизация, в том или ином виде. Хотел поиронизировать, а так неудобно получилось)
И архитектура играет роль. Можно и тех, и других организовать быстро и эффективно, только реальность в том что менеджеры и тим-диды назначаются сверху-вниз и как правило не всегда удачно.
Разработка свиcтопepделок - это уже смешно. И уж тем более, когда используют 100500 всяких промежуточных этапов.
Есть и другие способы выявления ошибок кроме тотальной типизации. И для команды лучше потратить время более эффективно. Ошибок которые может предотвратить только ts очень мало. Каждый рас когда на проде выявляется ошибка за которую "стыдно" задаю себе вопрос, а помог бы ts ее выявлении - и да иногда бы помог, но это все из за того что поспешил или клал большой на тесты.
Выигрыш от скорости и гибкости который дает js в сто рас окупает себя. Я лучше быстрее доведу продукт до бета-тестирования и выявлю важные ошибки (и не буду блокать других участников команда) чем буду тратить время на описание типов (это как дорогу посыпать соломкой, а то вдруг упаду).Есть задачи где безопасность кода нужно довести до абсурда. Но стоит начать с более эффективных инструментов.
Яб сказал что это вы не осилили js. А в решении задач недостаточно глубоко прорабатываете решение. Чтоб качественно писать на js нужно читать код который вы используете, а не доверять ide и типам.
>> Выигрыш от скорости и гибкости который дает js в сто рас окупает себя.Что за? Занимайтесь своим бэкэндом и типа быстрыми ЯП вместо ноды. Скажите честно - вы не знаете ни того ни другого и жмете рабочие места ради ЧСВ беря в заложники компанию и небольшой прибавке к з.п. к этому
Да то что TS транслируется в JS и типы у него только на этапе трансляции. Более того всегда есть возможность его использовать и без типов.
>Ошибок которые может предотвратить только ts очень мало.Вы не понимаете. Он предотвращает ошибки слабых программистов, не способных экран кода в голове устойчиво удерживать. Ошибки уровня присвоить в счетчик строку. Ошибки людей с двузначным айкью. Капиталистам не хватает исполнителей их придурочных хотелок и они нанимают полностью профнепригодных.
>Я лучше быстрее доведу продукт до бета-тестирования и выявлю важные ошибки
Это если у вас изначально полная постановка задачи. Обычно манагеры в принципе не знают, чего хотят и постановка невозможна. Жс программисты в этих условиях выполняют то, что успели поставить. И код в проект добавляется коровьими шлепками, а не пишется как реализация некой цельной идеи продукта.
В такой дебильной разработке тс помогает нивелировать низкое качество исполнителей и несколько снизить вероятность, что ближе к бизнесовому дедлайну проект будет в полностью неподдерживаемом состоянии. Если сравнивать плохой код на жс и тс, второй все-таки более защищен от дурака и лучше структурирован, при прочих равных. К нему с более высокой вероятностью будут пристроены инструменты запрещения добавления заведомо нерабочего кода (ребятки обожают его добавлять, уж не знаю, почему).
Так что, если предполагается работать с идиотами (в корпоративной среде), я бы выбрал тс (при том, что я персонально люблю динамические языки и ванильный жс, причем в стиле <=ES4, полностью ФП).
Прямо на старте проекта выбрать тс долгосрочно выгодно - идиотам хотя бы не придет в голову на него переходить, придется программировать.
>> Вы не понимаете. Он предотвращает ошибки слабых программистов, не способных экран кода в голове устойчиво удерживать. Ошибки уровня присвоить в счетчик строку. Ошибки людей с двузначным айкью. Капиталистам не хватает исполнителей их придурочных хотелок и они нанимают полностью профнепригодных.Проверено на практике - нет, даже с опытными программистами это не работает. Эти опытные программисты понатыкивают any а потом удивляются почему у одного на TS за несколько месяцев все получилось, а у другого - нет и постоянно вылетают ошибки. И рассказывают как они непомерно трудились и быстро сдавали задачу, но в ней 100500 ошибок находилось приходилось что-то "новое делать". Наверно все дело в том что его часть сложнее была (хоть это не правда). Самое дурацкое в этой ситуации тим-лид, который видит что у одного получился ожидаемый результат, у другого нет, видит код, но выбирает на повышение того, у кого задач было больше.
Опыт даже в 10 лет в коммерческой разработке современного типа не означает сильного программиста. Увы.
Мне приходилось писать на тс под ангулар/рхжс, но я никогда этот недоязык специально не учил. Для меня это вообще никогда не было программированием. Пишешь бэкэнд и тут же пару компонентов на тс под фронтенд, чтобы не ждать фронтендеров. any кстати никогда не использовал. Дженерики писал и скучаю по ним, когда приходится мутить с интерфейсами в голанге. Суть в том, что если бы все были хотя бы моего не особо высокого уровня программерами, можно было бы и на жс разрабатывать, и на тс, на чем угодно. Проблем бы не было. Но 95% программистов тупо дно. И ситуация только ухудшается.Кто там кого выбирает на повышение - это вообще нерелевантно. Мне как тимлиду постоянно приходится принимать решения, с кем мы дальше можем работать (несмотря на косяки), и без кого в проекте точно станет лучше - даже с учетом того, что какое-то время не будет хватать рук. Специфика мб не самая распространенная, работаю в какой-то заднице.
> Прямо на старте проекта выбрать тс долгосрочно выгодно - идиотам хотя бы не придет в голову на него переходить, придется программировать.Так вы своих коллег не уважаете, только себя одного, с кем вам работать тогда?
> В такой дебильной разработке тс помогает нивелировать низкое качество исполнителей и несколько снизить вероятность, что ближе к бизнесовому дедлайну проект будет в полностью неподдерживаемом состоянии. Если сравнивать плохой код на жс и тс, второй все-таки более защищен от дурака и л...Я прочитал все это и понял что уже вас не уважаю. Может вам какой-нибудь курс тим-лидерства нужен где учат уважать людей? Или где рассказывают как толерантно относится к людям и делать из них хороших разработчиков, а не душевных калек после такого отношения?
Главный косяк TS это политика - его разрабатывает Microsoft.
А нодажыэс, разрабатывается гитхабом, который принадлежит...да-да, гений, именно.
Нода гуглом. Когда это гитхаб разрабатывал ноду?
> Не прошло и ста лет. В это же время разработчики массово сваливают
> с тайкпскрипта на ванильный яваскриптДа ну, не верю. Буквально в каждом проекте как чуть стагнация разработки начинается из-за слабого менеджмента, так сразу начинают "рефакторить" и "переписывать на тайпскрипт". Это у ребят как религия. Все проблемы проекта решаются переходом на тайпскрипт. Ну как переходом - тут главное процесс, начать переходить, определить правила - что на тс, что на жс. При мне эти процессы никогда не заканчивались.
весь интернет полон: why you should reconsider using TypeScript and shift back to pure JavaScript или Big projects are ditching TypeScript... why?
А это для тех у кого процесс таки закончился, не смотря на все усилия. Теперь и им есть чем заняться и что написать в отчет.
>Это у ребят как религия.согласен. тс религия. да и вообще модный стек это религия
Сначала изобрели язык без типов, а потом добавили в него типы. Что за прикол?
Никто никуда ничего не добавлял.
JavaScript как не имел типов, так и не имеет.
TypeScript изначально был с типами.
JavaScript имеет типы! Можешь прямо сейчас попробовать в консоли:if (typeof 'value' !== 'boolean') alert('boo!')
Это рантайм типы, которые есть в практически любом языке. Вопрос в статической типизации, которая работает до выполнения кода.
А зачем статическая типизация в языке с динамической?
Сильно облегчает программирование. В IDE можно ткнуть точку и посмотреть чем можно дополнить. Также, валидатор сразу определяет ошибочные типы.
Kek. И причём тут типы?
Чтобы генерировать максимально производительный низкоуровневый код.Например, в c#, ввели readonly структуры. Затем значительное количество кода стало работать быстрее практически забесплатно.
Ну и чтобы получать решения, которые не боишься поддерживать. Любой динамический код дешевле с нуля писать, чем поддерживать. Статика рефакторится на порядок легче и безопаснее.
Так а что мешает вгедрить в JS режим строгой типизации, на подобие строгого режима?
TS разве не компилируется в JS в итоге, если так то это просто плагин для IDE.
> Так а что мешает вгедрить в JS режим строгой типизации, на подобие строгого режима?годы.
При том, что уже давно есть платформы, которые делают это гораздо лучше. За это время в JAVA окончательно внесут весь необходимый синтаксический сахар, которого нехватает js разработчикам, а в dotnet окончательно снимут ограничения с нативной АОТ компиляции.
Зачем пытаться делать из JS dotnet, если можно просто взять дотнет?
> TS разве не компилируется в JS в итоге, если так то это просто плагин для IDE.
Сложно назвать это компиляцией
JS с режимом строгой типизации (статической, конечно) - это и есть TypeScript
Ну нее, как вышенаписали, TS транслируется в JS, и вся типизация на этом заканчивается
> Так а что мешает вгедрить в JS режим строгой типизации, на подобие строгого режима?Есть asm.js и некоторые фреймворки его используют.
> Чтобы генерировать максимально производительный низкоуровневый код.
> Например, в c#, ввели readonly структуры. Затем значительное количество кода стало работать
> быстрее практически забесплатно.
> Ну и чтобы получать решения, которые не боишься поддерживать. Любой динамический код
> дешевле с нуля писать, чем поддерживать. Статика рефакторится на порядок легче
> и безопаснее.Если тебе нужны фичи из дотнета, используй дотнет, не нужно джаваскрипт портить.
> Если тебе нужны фичи из дотнета, используй дотнет, не нужно джаваскрипт портить.Ну как бы я так и делаю. Каждый раз удивляюсь, когда люди бекендовые проекты начинают на JS или пэйфоне. Ни тебе скорости, ни типизации. Чуть что, надо переписывать на c#/go/cpp
Вообще они называются примитивы, если быть занудным.
А можно проверить, у меня на руках int32 значение, или float32 ?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...However, with the addition of classes, the creation of hierarchies of objects and the inheritance of properties and their values are much more in line with other object-oriented languages such as Java. In this section, we will demonstrate how objects can be created from classes.
то что оно все корявое поверх прототипов, так в JS/TS все корявое, если бы не массовое применение в браузерах померло бы давно
Корявым все становится, когда люди с квадратно-гнездовым мышлением приходят из своих плюсов и пытаются в жс накостылировать то, к чему привыкли.
Это вы сейчас про типы, да?
Ну исторически так сложилось - класс там является синтаксическим сахаром над функцией-конструктором. И зашибись! Это преимущество этого языка.
Главный вопрос - они насмерть завирусованный npm оставили по умолчанию?
Все так же, неизвестный производитель костыль-фреймворка может втихую подменить его на вредоносный код, который автоматически распространиться на все инсталляции использующие его?
Не бывать такому! Тысячи глаз не допустят!
Уже допускали и не раз. Самое эпичное было на моей памяти это парсер командной строки с 2М скачиваний. И ещё странная индусская либа для работы с ФС.
А зачем вы используете костыль-фреймворки у себя и при этом даже не лочите версии зависимостей?
И главный вопрос: какое решение вы предлагаете взамен?Я не троллинга ради, мне действительно интересно послушать аргументы тех, кто выступает против NPM (и не только NPM, а вообще всех публичных репозиториев). Критику я слышу, а вот конструктивных предложений что-то ни от кого не поступает
> кто выступает против NPM (и не только NPM, а вообще всех публичных репозиториев).Я тут выступаю как капитан очевидность.
Использовать то, что идет в репозиториях текущих дистрибутивов?
Т.е. абсолютно тоже самое только запакованное в пакеты?Товарищ вообще хоть раз видел пакеты вживую?
В их скриптах в 99% сейчас это скачивание tar.gz с версией с GitHub.
> Т.е. абсолютно тоже самое только запакованное в пакеты?Которое не подменить.
> Товарищ вообще хоть раз видел пакеты вживую?
Шуткуешь?
> В их скриптах в 99% сейчас это скачивание tar.gz с версией с GitHub.
Что?
Похоже просто ляпнуть что-нибудь решил.
Он не знает как локальный репозиторий поднять. Скажем честно - вот это недостаток, просто это действительно не делается
> Он не знает как локальный репозиторий поднять. Скажем честно - вот это недостаток, просто это действительно не делаетсяЗачем это? Если от твоей программы будут зависеть другие, написанные на другом языке, как зависимость прописать?
Я не знаю что тут за нашествие троллей не имеющих никакого отношения к js\ts, но вы даже не пытаетесь реально что-то узнать, у вас просто задача разжечь срач на пустом месте. Ну если вы хоть раз были на коммерческой разработке веб-проекта вы вроде должны знать ответ на вопрос.
О в ответе как раз житель песочницы проклюнулся:"на коммерческой разработке веб-проекта"
Да какое дело до песочниц остальным?
Вот те кто на электроне пишут, у которых эта самая нода, у которых этот самый ts.
Они интересны. Доросли до нормального уровня, то заточка на npm на корню рубит возможность конкурировать.
Пакеты в npm тоже не подменить.Объясняю на пальцах. Есть система сборки пакетов дистрибутива - какой-нибудь OBS. У каждого пакета есть скрипты сборки, скрипты инсталляции и т.п.
Перед тем как собрать пакет из исходников, эти исходники скачиваются.
И о чудо! Они скачиваются НАПРЯМУЮ из GitHub, который для версий выкладывает автоматически запакованный архив исходников tar.gz.
Естественно больше в этот собранный пакет и из чего он там собран никто не будет.
Понятно объяснил?
> Пакеты в npm тоже не подменить.Зато легко удалить.
А при тотальных локах на конкретной версии легко получить в зависимостях один модуль разных версий.
> И о чудо! Они скачиваются НАПРЯМУЮ из GitHub, который для версий выкладывает автоматически запакованный архив исходников tar.gz.
Так это и есть недостаток.
> Понятно объяснил?
На целевой системе должны использоваться пакеты лежащие в репозитарии целевой системы.
Иначе, как была песочница - так песочницей и останется.
Твоя "целевая система" и есть песочница.
А так - если есть открытый исходный код - пусть дистрибутивы и собирают. А то что они не осилили так .... проблемы индейцев шерифа не волнуют.
> Твоя "целевая система" и есть песочница.Обидно да? Но это жизнь. Играются со своими игрушками разрабтчики в песочнице.
И пока не дорастут до понимания целевой аудитории так и останутся игроками в песочнице.
> А то что они не осилили так .... проблемы индейцев шерифа не волнуют.
Тут ровно наоборот.
Пока темным лесом идут разработчики которые не задумываются о целевых системах.
Дошли руки у кого-нибудь пакет собрать - хорошо. Нет - так и бог с ним и со всем от него зависящим. Пусть разработчики как нибудь по другому себе аудиторию ищут.Тут вон уже python перестают выбрать из-за того, что пакеты в целевых системах, то есть - то нет. Ни в одном нельзя быть уверенным.
А то, что не идёт - нинужно, да?
> А то, что не идёт - нинужно, да?Именно. Или ложишь рядом со своими исходниками.
И ТЫ за них отвечаешь?
Или делаешь пакеты и ТЫ за них отвечаешь.
Ты уже начал отвечать за 20 миллионов строк кода ядра?Как успехи?
> Ты уже начал отвечать за 20 миллионов строк кода ядра?
> Как успехи?Ядро лежит в пакетах целевых систем.
А что идёт в текущем дистрибутиве ноды, кроме самой ноды и пакетного менеджера?
NPM ныне во владении Microsoft. Они и есть нынче тот самый тысячеглаз. Хотя скорее всего ещё и всунькомунадопинок.
Скриптовой язык с типами - это все неудобства типизации вместе с низкой производительностью скриптового языка. Контроль типов ущербный. Все как любят профнепригодные. Не представляю себе людей, которые _это_ предпочтут какому-нибудь голангу (мальчику уже 10 лет исполнилось, если чо).
> Контроль типов ущербныйСейчас очередной гофер расскажет как надо сделать хорошую систему типов. Шаблоны уже начал использовать хоть?
> голангу (мальчику уже 10 лет исполнилось, если чо).Почему телеметрию добавляют в 10 лет? Это какой-то обряд?
Я, конечно же, не любитель голынга с этими как их... горутинами, но телеметрию добавили вроде в конь-эпилятор, в сам бинарь она не пихается.
Пока что. Тем более откуда ты знаешь конь не получает сигналы из центра вместе с отсылкой телеметрии?
>о телеметрию добавили вроде в конь-эпиляторИ этого уже достаиочно, чтоб избегать.
Так у C# тоже есть. И в Linux билде от microsoft.Она вообще скоро везде будет.
> Почему телеметрию добавляют в 10 лет? Это какой-то обряд?Значит у компаний которые этим занимаются такие длительные итерации - 10 лет.
> производительностью скриптового языкаСкриптовые языки by design не предназначены для утилизации максимальной производительности. Для этого есть всякие Си, Rust и прочие Turbo Pascal. Если же говорить про Ноду, то в 99% случаев её использования, всё упирается в I/O.
Ну не пишут веб-сайты на всяких C, Rust. Почему-то все хотят простой язык, да ещё и такой, чтобы один программист мог и фронт и бак делать. И что-то мне подсказывает, что вариантов такого универсального языка раз, два и обчёлся. Даже если поискать всякую экзотику типа CoffeeScript.
Немного не так: все хотят ничего не делать. Максимум скопировать пару строчек из примера использования очередного фреймворка.
Я бы поспорил - на Rust и Golang вроде вакансии есть.
Так не лучше ли сделать конвертор из PHP в JavaScript чтобы везде писать на одном языке PHP?
Так пытались уже писать трансляторы из чего-нибудь в Javascript. Неоднократно пытались. Даже монстры типа Scala или Kotlin. Но нет, JS/TS. А касаемо PHP, то, что он самый распространённый в использовании не значит, что он самый желанный для программистов.
А как он дополняет JavaScript? Ах ну да - никак, т.е. это совершенно некорректное сравнение. Трансляторы из разных языков в JS есть, только вот обратного использования как правило не предусматривается или через одно место. А на TS пишешь и люди на JS спокойно используют. Более того это не ориентировано на одну группу разработчиков серверного кода. То что на php написано под сервер вы не сможете использовать - какой смысл тогда? Есть более интересные смыслы в других языках ориентированных именно на JS, но там хотя-бы цель есть. Допустим писать простой и безопасный код на JS. Порой что-то такое в вакансиях встречается.
> Удалена поддержка 32-разрядных систем с ОС Windows.Впечатление будто это форсируют искусственно чтобы принуждать людей обновлять железо.
У них сроки поддержки старых ОС ограничена, но эта информация где-то публичная, где-то не публичная. И да, окончание поддержки это форсирование. Таковы правила порождены менеджментом с маркетологами.
Можно подумать, что кто-то под 32-битной вендой занимается разработкой на nodejs.
Было бы куда хуже, если 32-битный debian почит в Бозе.
А так, в целом, обидно, досадно, но ладно.
Не, он все правильно говорит. Проблема в том что задачи ОС вроде как поддерживать оборудование, одна из задач программ в поддержке - ОС. А тут вас как-бы вынуждают покупать новое американское железо и софт. Ну т.е. вам навязывают. Это извращение смысла торговли ради сверхприбылей. Правда Google в этом плане вроде по человечески поступает - предупреждает, старую версию как правило можно скачать. Так-что жаловаться вроде не на что. Они и не обязаны старое оборудование поддерживать.
Да не будет никто выставлять сервер на Win32. Сам вопрос выставить что-то под виндой в инет - это странный вопрос.
Нода это ещё и электрон.
Ну почему? Когда я учился в ВУЗе, то сервер нашей комнаты был найден на свалке. Вернее какая-то компания выбросила старый ПК и мы сразу подобрали. Работал он долго, форум держал. Ребята с Припяти сидели в основном на нем. Один из жильцов был оттуда. Денег не было у нас как у студентов, но это было совсем другое время. Сейчас может и студенты богаче, оборудование все-же дешевле (б.у. во всяком случае). Может немного стыдно, но оно работало.
Самый страшный и сложный в использовании ЯП. Наличие такого огромного количества фреймворков для него только подтверждает этот тезис.
Людям нравится писать комментарии и в скобочках ничего толкового не видеть. Они либо помнят, либо угадывают что нужно передать в параметре. И вроде бы как при деле.
Так может не такой уж и страшный язык, если под него пишут фреймворки и либы?
Но при этом самый используемый конечными пользователями - абсолютно все пользователи Интернета им пользуются. И в первой пятёрке языков по используемым на серверах - https://w3techs.com/technologies/overview/programming_language
Да чего вы взъелись то? Typescript кто-то использует, кто-то нет. Ненависть то с чего распространять? Мне лично нормально что теперь Node поддерживает TS, правда от этого ни жарко ни холодно, т.к. по старому буду транслировать все в JS. Это для тех кто хочет запускать свой TS без трансляции как JS, вот и все. Им просто упростили жизнь.
Ненависть распространяют исключительно апологеты Typescript. Видимо чсв зашкаливает.
Люди спорят о том что более целесообразно на проектах использовать - Typescript или JavaScript? Дело не в ЧСВ, а в деньгах в итоге. Кто знает и то и другое вероятнее всего не париться, а тому кому стоило бы изучить Typescript для работы это в общем-то может ударить по кошельку и возможностях его наполнить. А учить что-то это ж время, ну и кому-то деньги нужно выделять.
Вообще все эти разговоры о том что лучше - JavaScript или Typescript, лежат в политической плоскости. Инженеры либо подчиняются менеджменту/тим-лиду/архитектору в необходимых технологиях, либо вольны сами выбрать решение для своего проекта. А вот вопрос споров и что с этим делать удел партийных членов.