news.shamcode.ru | Почему JS (и TS) это плохой язык

Я знаю, что на эту тему уже было сказано много, но настал мой черед. На JS я пишу больше 10 лет, так что терпел я достаточно :)

Когда мы говорим “джаваскрипт”, мы подразумеваем много разных вещей:

Стандарт EcmaScript
Среда исполнения (NodeJS, браузер)
Экосистема (библиотеки, фреймворки, тулинг)

Иногда есть смысл поговорить об этих вещах по отдельности, но сегодня мы обсудим их все сразу, и назовем это просто “джаваскрипт”. А именно, я объясню, почему джаваскрипт это плохой язык.

Что значит плохой?

А что значит “плохой” (или хороший)? Кто-то из великих сказал: “есть 2 типа языков, те которые не ругают, и те на которых пишут”. Джаваскрипт буквально олицетворяет вторую категорию: его ругают почем свет стоит, и при этом он самый популярный язык программирования в мире.

JS это хороший язык в том смысле, что он, определенно, решает свою задачу (иначе он не был бы столь популярен), и это очень плохой язык в смысле того, насколько много усилий нужно приложить, чтобы решить тривиальную задачу.

Если последнее утверждение кажется вам неочевидным (как же так, hello world на JS можно написать в 1 строку, а на условном Go в 5-10), то нужно уточнение — программисты не слишком часто пишут хеловорды на работе. Чаще всего человеку, волею судеб столкнувшемуся с JS нужно работать с графическим интерфейсом, либо писать серверный код, и размеры таких приложений в большинстве своем превышают тысячу строк кода.

JS не масштабируется

Не даром слоган TS — “JavaScript that scales”. Во всяком случае, был. Этот язык был спроектирован много лет назад для решения задач, которые совершенно не похожи на сегодняшние. Написать скрипт, максимум, в несколько сотен строк кода это совершенно не то же самое, что поддерживать огромный проект с десятками сложнопереплетенных сущностей, где цена отказа это большие деньги.

Да, разработчики EcmaScript и движков вроде V8 большие молодцы, что развивают язык. Так, например, в нем со временем появились импорты и async-await, но, во-первых, там есть нюансы (об этом чуть позже), а, во-вторых, этого недостаточно. Помимо этого нужна как минимум статическая типизация, линтинг и форматтер. Если мы говорим про фронтенд среднего и выше размера, то добавьте сюда: минификацию, обфускацию, сжатие картинок, транспиляцию под старые браузеры и, черт знает, что еще. Вам может особенно “повезти”, если вы разрабатываете под какую-то нестандартную платформу вроде Chrome или VSCode расширения, где на вас упадут дополнительные ограничения с которыми вы останетесь один на один. И часто проблема решается написанием каких-то кастомных скриптов для сборки вашего кода каким-то нетривиальным способом.

Короче, из коробки JS годится лишь для написания очень маленьких вещей, а как только ситуация меняется, начинаются маневры, и поверх основной технологии (собственно, языка), начинают наслаиваться дополнительные, и все это (из-за основной причины, отсутствия нужных инструментов в самом языке), ходит ходуном и шатается от ветра как карточный домик.

Итого, JS “из коробки” не масштабируется — факт. Для масштабирования требуется сильное усложнение системы путем добавления в нее компонентов неочевидного качества. И дело даже не в комьюнити - разработчики сторонних инструментов большие молодцы, что решают насущные проблемы, но они просто не могут решить их по настоящему качественно, потому они сами вынуждены писать на джаваскрипте. Это рекурсия и порочный круг.

Фронтенд это боль

Как вы могли понять из предыдущего абзаца, проблема “JS не предоставляет из коробких нужных инструментов” удесетеряется в случае, если вы пишете не для сервера, а под браузер. Это забавно, учитывая, что JS был создан для фронтенда, а бэкенд на нем, в итоге, писать проще.

Это не значит, что надо тащить JS на бэкенд, он все еще остается плохим языком, просто на фронтенде страданий еще больше. К тому же, злая ирония такова, что на бэкенде, где JS еще можно как-то стерпеть, есть из чего выбрать (например, Go), а вот на фронтенде выбора нет. Более того, выбор может пасть на JS (и вполне адекватно, к сожалению) даже когда вы пишете мобильное и/или десктопное приложение, например, на React Native или Electron. Как сложилась такая ситуация, отдельная история, но это факт, и с ним надо мириться.

Ситуация с фронтендом настолько ужасна, что самый популярный и стабильный фреймворк React заставляет вас писать на языке jsx (tsx), который является абстракцией над JS и HTML. Альтернативы еще хуже, например, Svelte также добавляет свой html-js-подобный язык с различными магическими директивами.

В итоге этот “динамический” язык не работает без кучки компиляторов, каждый из которых имеет свои конфиги, свою экосистему плагинов (каждый из коротых в любой момент может может сломать обратную совместимость, не обновиться вовремя, стать depracated и прочее).

Веб нельзя ломать

Логика разработчиков JS проста — миллионы сайтов и приложений работают на джаваскрипте, следовательно, из джаваскрипта ничего нельзя удалить. В итоге в него все добавляют и добавляют, как следствие, на нем можно писать в десяти разных стилях и одна проблема решается дюжиной разных способов. Как думаете, как это влияет на качество и удобство разработки? Правильно, влияет очень плохо. Два проекта даже на React могут выглядеть совершенно по разному, не говоря уже о проектах с разными фреймворками. Они даже синтаксически (из-за бесконечного юзания различных настроек и сахаров) легко могут отличаться.

Но это по беды. Так как ни одно минимально работающее приложение на JS невозможно без огромной пачки зависимостей (будь то рантайм или для тупо сборки), то будьте готовы к тому, что пакеты не дружат друг с другом. В одном пакете CommonJS импорты, в другом ES6 импорты, в третьем еще какая-нибудь херня. Или ситуация, что пакет который вам нужен внезапно не поддерживает нужный вам формат импортов.

Я остановлюсь тут, но, мне кажется, подобных причин для поломки, которые следуют из того факта, что “веб нельзя ломать” можно выдумать еще много.

TypeScript не помог

Опять же, не поймите неправильно. Ребята из Microsoft большие молодцы, что решают насущную проблему, и без них было бы намного хуже. Однако, их решение, во-первых, не решает проблему полностью а, во-вторых, добавляет своих проблем.

Начнем с того, что у вас в системе +1 компонент - компилятор тайпскрипта. У него (ну разумеется) есть свой конфиг. Версия вашего компилятора должна матчится с вашими зависимостями.

Далее, TypeScript не дает никаких гарантий. Вообще. Как же так? Компонент в систему добавили, +1 язык выучили, а undefined все еще is not a function? Причина в том, что TS был разработан для gradual adoption, то есть плавной интеграции с JS. Разработчики предположили (и правильно предположили), что просто взять и переписать весь джаваскрипт в мире на TS не получится, и любой TS-код будет взаимодействовать с небезопасным JSом. Как следствие, очень и очень часто в своем TypeScript проекте вы будете видеть тип any который как бы говорит “хз что это, делай с этим что хочешь но на свой страх и риск”. Классная типизация, да?

Выводы

JS это плохой язык и тулинг эту проблему не решает, видимо, потому что это просто невозможно в принципе
Иногда брать JS/TS можно и нужно, ситуации бывают разные, но это за пределами статьи
Если вы не писали на Go, советую попробовать, вы удивитесь, насколько жизнь может быть приятнее (как бонус еще и конская производительность)

Дополнительно

Я посвятил три года изучению языков программирования и написал свой. Он совсем не похож на JS потому что он потоко-ориентированный (dataflow/flow-based) и в нем все работает параллельно by default. В его архитектуру я заложил все, чтобы работать с ним было легко и приятно. К сожалению, сейчас у меня нет времени заниматься им, но мне будет приятно, если вы на него посмотрите.

https://github.com/nevalang/neva

Мои Telegram Каналы

Еще у меня есть 2 tg канала где я пишу про запуск своего проекта и программирование с помощью LLM.