JavaScript — ужасный язык программирования. По сравнению с другими распространёнными языками он выглядит генетическим уродом. Дело даже не в отсутствии многопоточности, или статической типизации, или того, что node_modules для простого проекта занимают сотни мегабайт, а в том, что в JavaScript столько стилей и подходов, что семь человек одну и ту же несложную задачу могут написать на нём семью различными способами. Каждый из них с трудом будет понимать, что написал другой, и тихо материться. Причем, так напишут и новички, и опытные программисты, которые просто привыкли писать по‑своему или захотели выпендриться.
Синтаксис и семантика JavaScript неадекватно усложнены и запутаны, что явилось следствием того факта, что его основа была придумана на коленке за десять дней, и в последующем изменена множеством акторов, каждый из которых преследовал свою цель и видение вместо следования единой стратегии.
Важная цель при разработке языка программирования — сделать так, чтобы он был понятен, логичен и хорошо сформулирован, не приводил к возникновению странных тупиковых ситуаций. Но JavaScript даже близко не подвели к достижению этой цели. С каждым выпуском языка его странности растут как снежный ком, неизменно усугубляя ситуацию. В нем появляется множество тупиковых и критических проблем
Дуглас Крокфорд, программист, автор формата JSON, исследователь JavaScript
Принято считать, что Java — серьезный язык для серьезных проектов, а JavaScript — лёгкий скриптовый язык для веб‑страничек. В принципе, да, вот только код на Java получается намного проще, чище и читабельней кода на JavaScript. В нём на порядок меньше всевозможных абсолютно ненужных рудиментарных заморочек. И, в то же время, с возможностями Java как языка можно реализовать практически всё.
Я пишу преимущественно на JavaScript (Vue.js). За неимением альтернатив, JavaScript удобен для фронта, для несложных скриптовых блоков кода в SFC и ES модулей. Когда обучаю детей программированию, то предпочитаю начинать с простой веб‑разработки — сделать HTML страничку, скриптом добавить небольшую анимацию, потом загрузить через fetch прогноз погоды с открытого API и красиво отрисовать его. Это их заинтересовывает, знакомит с различными веб технологиями в понятной форме и даёт энергию для дальнейшего изучения программирования. Так получилось, что этот язык удобен для знакомства с IT.
На JavaScript можно написать несложный бэкенд API на Express.js или serverless функцию, но это его потолок. Использовать его для чего‑то серьезного на серверной стороне — ошибка. Небольшие скрипты на JavaScript удобно писать, но когда кода много, логика сложна, и пишут это разные люди, то кодовая база превращается в месиво из‑за отсутствия и следования не столько даже `code style guide`, сколько `language style guide`. Это как люди с одним, вроде бы, формальным разговорным языком, но разными диалектами, плохо понимающие друг друга.
Выпуски новых редакций стандарта ECMAScript не приводят к устранению серьезных проблем JavaScript, а иногда и создают новые проблемы. Комитет по стандартам имеет ограниченные полномочия по коррекции языка. Его представители обладают практически безграничной властью над развитием языка, делая его все более сложным и странным. У них есть достаточные полномочия, чтобы не усугублять ситуацию, но заинтересованы ли они в этом?
Дуглас Крокфорд, программист, автор формата JSON, исследователь JavaScript
Но отсутствие стандартов и узаконенных лучших практик в написании кода это далеко не всё.
Все уже привыкли к зоопарку фронтенд фреймворков, когда специально учишься писать под конкретный, если хочешь на нем работать. И это понятно — если используешь библиотеку, нужно жить в рамках её интерфейса. Но это только часть айсберга. Многие npm пакеты тоже должны быть адаптированы или сделаны под этот фреймворк, образуя свою «экосистему». И меняя фреймворк надо менять и экосистему.
Есть еще сборщики. В том числе и для бэкенда их используют. И их не один, и не два, и не три. И чтобы в твоем прикладном коде просто отобразить на странице картинку, ты должен подчиняться правилам конкретного сборщика и выполнять нетривиальные миграции при переходе с одного на другой.
А у сборщиков есть плагины, и чтобы отобразить на странице svg иконку, ты должен подчиняться правилам выбранных плагинов. И еще есть js runtimes. И их тоже уже не только Node.js — Deno, Bun, Cloudflare Workers, Netlify, Vercel Edge, AWS LLRT, — один другого краше. А под ними — js движки. V8, SpiderMonkey, Boa, QuickJS и еще несколько десятков.
Вроде бы уже дно? Нет, у движков и сборщиков есть еще версии, и то, что работает на Node 16, не работает на Node 20, и наоборот.
Всё? Почти. Окружение, включая операционные системы. Нравится удобство Cloudflare workers — пиши под Cloudflare. Supabase? Только Deno до недавнего времени. Хочешь быстрый Bun? Переписывай всё под него. И он на Windows не работает пока, если что. Netlify, Vercel, AWS Lambda — у каждого свои требования и особенности.
Ощущение, что всё-таки что-то забыли
Пакетные менеджеры — npm, yarn, pnpm, — и их деривативы: Yarn workspaces, Lerna и даже новые реестры пакетов типа jsr.io
Когда изобрели Java, у нее был девиз: Write once, run everywhere. Не сильно ошибусь, если скажу, что программу, написанную на С или Java 25 лет назад можно без особых проблем скомпилировать и запустить и сейчас. А как этот слоган применим к JavaScript? Никак. Ты должен ходить везде с чемоданом набитым своим фреймворком, экосистемой библиотек под него, сборщиком, плагинами к сборщику, пакетным менеджером, js рантаймом, движком и только по своим хостингам. И всё чтобы было своих определенных версий. И ходить можно только очень небольшое количество лет (иногда от силы 2–3 года), после которых ты вместе со всем этим чемоданом безнадежно устареешь.
Может фронтенд‑разработчики честно подсчитают для себя, сколько процентов их рабочего времени за последние годы ушло на переписывание кода следуя моде или потоку времени с одной библиотеки/фреймворка/сборщика/пакетного менеджера/js runtime на другую, или из‑за апгрейда её/его версии? То есть, техническая работа без, по сути, изменения функционала программы. Для JavaScript это воспринимается как естественная данность, следование фарватеру эволюции, хотя для других языков это дикость.
И, самое веселое, что со временем всё не упрощается и унифицируется, а совсем наоборот.
Теперь представим архитектора или техлида в здравом уме, который должен решить, на чем писать нетривиальное серверное приложение с расчетом на работу дольше одного года. В каких случаях он выберет JavaScript? Видны три варианта:
Он/его команда больше ничего не умеют
Его вынуждают это сделать силой
Он не совсем в здравом уме.
TypeScript может давать локальное симптоматическое лечение, но в целом ситуацию только ухудшает.
На бэкенде еще есть возможность выбрать для работы другой язык, но на фронте глобально поможет только создание и внедрение нового с нуля, как это было с Java или C#, с продуманными спецификациями языка программирования и виртуальной машины и всех нужных API.
Было множество попыток как создать новый язык, так и написать компилятор в JavaScript какого‑то существующего (краткий список). Например, Google AdWords был написан на Java с последующей компиляцией в JavaScript (хотя это больше попытка работы с UI). Однако ничего не получило достаточного распространения.
Так что пока JavaScript ужасный язык программирования, но другой альтернативы нет.
Поэтому, для минимизации рисков, в своей работе приходится следовать нижеописанному принципу и использовать только самые необходимые, ясные и разумные элементы JavaScript, инвариантные и для большинства других языков.
Вот мой самый эффективный инструмент для наилучшего использования языка программирования:
Если что‑то в одних случаях полезно, а в других — опасно, и есть более подходящий вариант, нужно именно им и воспользоваться.
Взяв этот принцип на вооружение, я всегда стараюсь свести язык к его меньшей и лучшей части, чтобы по возможности избежать того, что с большой долей вероятности может привести к возникновению ошибок
Держитесь подальше от всего, что приводит к тупиковым и крайним ситуациям. Не углубляйтесь в этот мрак. Оставайтесь в той части языка, где все просто и понятно. Там есть все, что вам нужно для написания хороших программ. Истинное мастерство проявляется в создании хороших программ, код которых легко читается, сопровождается и не содержит ошибок. Оптимизация с целью использования характерных особенностей приводит к обратным результатам.
Дуглас Крокфорд, программист, автор формата JSON, исследователь JavaScript
Все цитаты и иллюстрация взяты из его книги «How JavaScript works»
Комментарии (60)
sumdy-c
27.03.2024 14:35+1База, но
Хотя может покажусь наглым, но хочется примеров кода, плюс их навалом - на JS одна и та же страничка написанная на Vue, нативном JS, c использованием jQuery или React да и практически любое другое решение - выглядит так, будто это вообще не JavaScript. Хотя бы таких примеров тут)
Но в целом стоит отдать должное языку, как бы его не хаяли - он всё равно остаётся ультимативным во фронтенде, да и мне всё же нравится в его сложные штуки, "Hell callbacks", Proxy, prototype повсюду, круто же ;) А еще когда рядом WASM лежит, ощущения прям непревзойдённые, но это не по теме конечно, да.ps, Спасибо за статью!
RichardBlanck
27.03.2024 14:35Можно подумать, какой-то другой современный язык лучше. Их ляпают дебилы с болонским образованием, исключительно ради хайпа. Что можно ожидать?
Печально, что такие же дебилы настойчиво портят старый PHP, который придумали умные люди. И ведь испортят. Практически уже.
Virviil
27.03.2024 14:35+1Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Stauroman
27.03.2024 14:35+5Хотелось бы услышать подробности мнения, чем таким именно испортили пхп. Чем 8.0-8.2 хуже 7.х версий?
Andrew0610
27.03.2024 14:35+5Очередное нытье про то какой is ужасный. И синтаксис не такой и читаемость плохая и то не так и так не этак. Ощущение как будто авторы подобных статей из принципа не юзают современные фичи языка и фреймов чтобы потом писать какая экосистема Js гавно. Я люблю Js уж хотя бы за то что не нужно делать кучу всяких гетеров сеттеров как в джаве , что есть замыкания и тебе не нужно каждый раз пробрасывать переменную чтобы не орал тебе что он не понимает на что ты ссылаешься. Современные фреймворки тоже не то чтобы очень сложные и зная один легко пересесть на другой за неделю. Короче Джаваскрипт не идеален, но вот подобные статьи выглядят как набрасывание говна на вентилятор. Как сказал один чел - «Джаваскрипт позволяет мне оплачивать счета и еду а значит это крутой язык»
Sigest
27.03.2024 14:35+1Я, как вечный новичок в Джаваскрипт (периодически приходится на нем писать, и заново подучивать/вспоминать) скажу, что замыкания одна из сложно запоминаемых вещей. Примерно на уровне конкатенации переменных разных типов в JS. Ну это мое такое вот джуновское мнение
Andrew0610
27.03.2024 14:35Не знаю, по мне супер простая штука. Представь что функция умеет видеть и помнить переменные вне самой себя. Вот и все) это по большому счету и есть замыкания)
Sigest
27.03.2024 14:35Замыкания я знаю, мой основной язык Котлин/Джава. Просто в этих языках замыкания как-то без изысков, и соответственно запомнить легко. В случае с JS приходится подглядывать в документацию. Цепочка вызовов лексических окружений, new Function и т.д. То же самое с this в разных контекстах.
Насколько я помню даже книга есть, название что-то типа "вы не знаете замыкания" и в ней речь идет про замыкания JS. Точно такая же есть и для async await, но там понятно, целая книга для нелегкого асинхронного программирования. Но для замыканий...
Andrew0610
27.03.2024 14:35Это уже книги из разряда - как усложнить простую вещь чтобы продать тебе книгу. Да есть какие то ситуативные кейсы и если упороться можно себе устроить ад замыкательный, но никто в здравом уме на пробе таким не будет заниматься. Все итак максимально функции упрощают. Поэтому на практике словить какую то серьезную траблу с замыканиями довольно тяжело если специально к этому не стремиться
Andrew0610
27.03.2024 14:35Это на самом деле проблема людей кто пишут статьи - джс гавно. Они находят и придумывают какие то ужасные конструкции чтобы доказать что язык ломается и плохо работает. Но это же к реальной жизни мало отношения имеет. В реальной жизни бизнес решает задачи а ты на джс в основном просто рендериншь интерфейс да данные туда сюда гоняешь. Но нет надо писать о каком то сложном и непонятном синтаксисе искать какие то кейсы где джс ломается и потом с пеной у рта доказывать что джс вообще не должен существовать и все комьюнити и все кто зарабатывает на продуктах - не правы
Sigest
27.03.2024 14:35С одной стороны согласен, что в первую очередь, от кого зависит выстрел в ногу - это программист. Но язык тоже должен помогать не стрелять себе в ногу. На примере джавы могу сказать - джава это наследие С и С++ . Там взяли и многие скользкие моменты убрали из языка, например вольности с неявным преобразованием типов, один из самых частых источников проблем. Но в джаве, понятно, такой дизайн с самого начала, когда не надо было оглядываться на обратную совместимость. Но в JS, на мой взгляд, очень много неоднозначных моментов, которые как раз путают и разрешают отстрелить себе просто обе ноги. И эти моменты никак не уменьшаются, не исправляются. Хотя use strict ввели, но как-то мягко он работает. Вот и получается, что на проекте первый программист пишет в одном стиле, после него приходит другой и начинает писать/переписывать в другом стиле. И начинается ад и зоопарк. И это только про стиль написания код, я не говорю про рантаймы (просто знаний не хватает говорить про это).
В этом плане мне нравится дзен питона - явное лучше неявного. Вот как раз этого, мне кажется, языку JS не хватает. Не хватает единого стиля.
Хотя, если уж быть объективным, этим страдают многие языки. И даже мой любимый Котлин, который, наверное больше всех подвержен этому. В нем можно писать и в Котлин/Функциональном стиле, с втыканием лямбд везде где только можно, но также и в Джава/ООП стиле, без этих функциональных возможностей. Благо я, пришедший в Котлин из джавы, могу читать оба стиля написания. Но я представляю чувства программиста, у которого первый язык Котлин, и он будет читать код программиста, который пишет как в Джава. И наоборот. Мне лично тяжело было перестроиться, а тем более читать код в стиле Котлина, когда я только начал его изучать.
mihmig
27.03.2024 14:35+1Просто не совсем понятно перевели, я тоже долго не мог запомнить.
Укупорка. Вот понятное объяснение.
Укупорка переменных внутрь функции.
hello_my_name_is_dany
27.03.2024 14:35+7Столько поинтов про зоопарк, но у Java ситуация не лучше в этом плане. Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях. И если уж сравнивать кол-во зоопарков и велосипедов, то C++ точно победит в этом соревновании.
Не скажу за фронтенд, но бекенд вполне себе ок писать на node.js. Другие рантаймы либо слишком специфичны для каких-то cloud решений (но там в принципе обычно делают всё своё - базы, очереди, балансеры и пр), либо очень сырые - тот же bun. Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма. Для C# тоже есть .NET Framework, .NET Core, Mono. Пакетные менеджеры - кто-то, конечно, использует по старым заслугам отличные от npm, но это редкость. Пакетов (библиотек) в Java/C#/C++/Python/Go и тд тоже много и на разные случаи жизни. Про стили кода странный поинт. В других ЯП ситуация та же, для этого собственно и придумали линтеры и разные гайды (опять таки вспоминаем C++). Языки с богатой семантикой часто предполагают, что одну задачу можно решить абсолютно по-разному, тут ситуация такая же, как и в Ruby/Python. Их вы как-то не затронули.
Вывод должен быть такой, что всё познаётся в детальном сравнении. Чем больше работаешь с технологией и делаешь больше разнообразных задач, тем больше замечаешь в ней минусы и недостатки, которые были скрыты под белизной хайпа или решения простых задач. Да бывает больно, но другие ЯП если и решат проблемы, то точно принесут новые. Выбирать язык надо с умом. А как именно на вряд ли кто-то скажет, всегда зависит от ситуаций. И в большинстве случаев, что знает команда, то используется.
gmtd Автор
27.03.2024 14:35Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма.
Любая Java VM полностью поддерживает спецификацию языка. Код, скомпилированный на одном JDK, будет без проблем выполняться на другой JVM. Kotlin и Skala также компилируются в байткод и выполняются одинаково на любой JVM, разница только в лицензиях и, небольшая, в производительности.
Какая поддержка JavaScript у JavaScript рантаймов? Сколько времени займет переписывание программы под Bun на Node.js?
Ваша аргументация имеет слабое отношение к тому, что написано в статье
То, что вы не встречались с проектами, которые работают (могут работать) только с yarn или pnpm, и не видите существенных отличий между ними, говорит о вашем опыте.hello_my_name_is_dany
27.03.2024 14:35+2Любая Java VM полностью поддерживает спецификацию языка
У JavaScript тоже есть спецификация языка (ECMAScript) и её рантаймы поддерживают (точнее движки). Они реализуют разный API, это к спецификации языка не имеет никакого отношения.
Какая поддержка JavaScript у JavaScript рантаймов? Сколько времени займет переписывание программы под Bun на Node.js?
Сколько времени делали поддержку GraalVM в Spring? Тоже небыстро. А если вы будете делать свой фреймворк, то вам тоже придётся озаботиться. Так и на кого это возлагать? На себя или мейнтенеров библиотек и фреймворков? Вопрос открытый.
Разные JDK реализуют стандарт по API, это конечно лучше, чем разный API на разных рантаймах JavaScript. Но эко-система JavaScript тоже потихоньку к этому идёт, пример этому - Web API. В этом плане просто язык помоложе будет, так как по сути с года 2012 начали его активно использовать вне браузеров, где кстати API довольно устойчив. И только относительно недавно начали создавать аналоги Node.js. Тот же молодой Bun пытается поддерживать API от Node.js в отличии от остальных (привет, Deno).
Случай с Java довольно уникален, потому что как не крути и не создавай комитеты, но она принадлежит Oracle. И без нужных откатов ничего вы не поделаете, достаточно вспомнить споры Oracle и Google по JVM/JDK в Android. Все просто бояться делать отличное. Либо будь добр реализовывай по стандарту или делай полностью своё. Но ведь если делать полностью своё и хоть капельку там будет похожего на стандарт, то Oracle нападёт на тебя с толпой юристов. И не у всех компаний есть столько денег на юристов, как у Google. А мы вообще-то любим free and open source, без него не будет развития, но с ним и приходит разнообразие в виде кучи библиотек, кучи разных рантаймов с разным API, что вам так не нравится.
То, что вы не встречались с проектами, которые работают (могут работать) только с yarn или pnpm, и не видите существенных отличий между ними, говорит о вашем опыте.
А я не говорил, что таких проектов нет, как и не говорил, что они ничем не отличаются от npm, не надо выдумывать. Я лишь сказал, что их некоторые используют за старые заслуги и что это редкость. npm за последние 10 лет очень сильно изменился, много оптимизаций произошло и всё благодаря сторонним пакетным менеджерам.
nightingazer
27.03.2024 14:35Код, скомпилированный на одном JDK, будет без проблем выполняться на другой JVM
Я вообще не могу понять, откуда ты это взял. У нас на работе приходится использовать три разных jre номинально одной версии для разных приложений, и эти приложения совершенно точно не могут запускаться на тех jre, под которыми не были сделаны. Вообще воо этот джавовский "write once, run everywhere" полнейший миф, о котором пора бы уже забыть.
kozlov_de
27.03.2024 14:35>Для C# тоже есть .NET Framework, .NET Core, Mono
Это боль
Представляю, как больно когда их больше десятка
Steamus
27.03.2024 14:35+1Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях.
А продолжить вот этот вот список (Maven, Gradle...) сможете? Ну хотя бы на 2-4 имени (только без Ant -- это уже история). Groovy и Kotlin (и Clojure, и Scala, и JRuby и Jython и ...) -- языки программирования, использующие в качестве среды выполнения JVM, а не системы сборки проектов. К чему вы их упомянули рядом с Maven как будто это вещи одного порядка? Их много языков программирования, которые практически "бесшовно" встраиваются в Java. Специально для тех кто любит разнообразие и типа "ненавидит" каноническую Java.
Пакетов тонны потому, что проектов тысячи тонн. И задач миллионы тонн. А вот разных стилей совсем немного. И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
Steamus
27.03.2024 14:35Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма.
Неправда. Количество SDK всего несколько штук. Ну там 6 примерно. Причём массово используется лишь примерно пара. Остальные возникли по своим причинам и вы можете вообще про них не знать.
Рантайм может компоноваться в зависимости от нужд развёртываемого приложения с целью не тащить ненужный код. Это появилось позже для удобства. И он всё равно будет состоять из стандартных кусков. Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
rubinstein
27.03.2024 14:35Хватило первого предложения. Дальше не читал.
starfair
27.03.2024 14:35+2А зачем тогда комментировать? Это как минимум не уважению к писавшему. Заявление по типу "Не читал Бродского, но осуждаю!" (хотя если знать контекст, то и там не всё так просто было). Можно не соглашаться с автором, даже с первых слов его работы и это - нормально! Я тоже вот не согласен с тем, что детям надо начинать программировать с HTML+ JS. Это одна из худших связок, от которой потом очень тяжело будет увести в более формализованные языки, так как учит безолаберности в коде, ибо эта связка уж слишком "прощает" ошибки разработчика, и как следствие вырабатывает в нём привычку не думать о последствиях своих действий. А это для программиста, тем более если он потом в проекте с кем то работает - очень плохо. Я встречался с такими на проектах, и потом после них переделывать приходится 90% кода. Но возвращаясь к вашей фразе, так комментировать это извините, просто хамовато по отношению к труду писавшего. Не нравится - закрой вкладку и листай дальше.
rubinstein
27.03.2024 14:35Хамовато вот такое писать в первой строчке. Мне, например, JS нравится. Это мой любимый язык программирования, где самая шикарная реализация ООП, хотя я 99% времени имею дело с обычным СИ. Но, например, мне Java не нравится до чёртиков. И что теперь? Мне специально сделать пост, где написать в первом предложении "Java ужасный язык программирования" ? Простите за французкий, но автор жидко обделался ещё в самом начале. Читать дальше не вижу смысла.
starfair
27.03.2024 14:35+1Это ваше субъективное мнение по содержимому статьи, на которое вы конечно имеете право, тут никто и не спорит. Но скажите, какой смысл заполнять ленту комментариев такими односложными "протестами", вместо развёрнутого, по типу того, что вы мне ответили выше? Для этого есть система оценок. Если каждый кто минусет или плюсует будет ставить ещё и комменты по типу вашего, то ни писавший, ни заинтересованный читатель, просто до полезного чего-то, что могут сказать комментаторы можно и не добраться. Есть что по делу сказать - пиши. Нет - зачем спамить в комментах своими односложными "фи", или "спасибо"!?
rubinstein
27.03.2024 14:35Может я чего-то не понимаю, но что полезного несёт статья автора? Его личные фе и фу по отличному языку программирования? Зачем это нам? Зачем это Хабре? Своё "фе" про статью высказали многие, не только я. Может владельцы Хабра увидят комментарии и заблокируют статью. По крайней мере я на такое надеюсь.
starfair
27.03.2024 14:35+1Ну, допустим сомнительное утверждение для статьи с положительным (на момент данного комментария) числом голосов. Лично я, например, с автором согласен, хотя ни разу не фронтэндщик, и вообще к js избегал прикасаться всю свой более чем 30летний стаж в программировании.
Язык действительно во многих смыслах наляпанный по мере необходимости затыкания разных текущих дыр в вэб-программировании. Его распространённость, как раз и есть обратная сторона его бестолковости. Он очень много прощает, что не простят многие другие языки. К тому же, есть очень много готовых решений. С помощью грамотного копипаста можно много чего быстренько слепить. Но как только потребуется что то серьёзно поменять под себя, в этих многочисленных фреймворках или модульных библиотеках - пиши пропало. Искать что, где и как надо поменять порой можно до "редькиного заговения" и в итоге пишется очередной ласапед, который хоть как то исправляет ситуацию. И в этом смысле, я полностью согласен с автором. Писать надо максимально читаемый и понимаемый код, без всех новомодных синтаксических фанктиков, которые потом сменятся согласно какого нибудь нового стандарта, и уже через год-другой никто не сможет толком пояснить, что делала та или иная функция. Для формы с парой кнопок не надо тянуть за собой Angular или React. А для больших приложений, и использовать нужно уже не Electron и т.п., а что то более для этого подходящееrubinstein
27.03.2024 14:35+1Что-то я не пойму. Так это язык плохой или руки кривые у программистов? Это ведь разные вещи.
starfair
27.03.2024 14:35+1Язык как язык. В чём то хороший, в чём то - так себе. Его просто грамотно использовать надо, как и любой другой яп. О чем собственно и резюме в статье. А что до рук, то я про них и не писал ничего. Многие те, кто на нём научились писать несложные обработчики для форм, вряд-ли такие уж и программисты. Но и те, кто освоил крутые фреймворки на JS, так же не факт что имеет при этом такие уж прямые руки. Всё дело в голове, если уж на то пошло.
Steamus
27.03.2024 14:35+1Перефразирую известную фразу -- у меня нет для вас других программистов.
Всегда найдётся тот, у которого кривые руки. Абсолютно в любом деле. А когда что-то поставлено на поток и требуется в промышленных масштабах -- таких будет десятки тысяч. Вот именно поэтому (!) и ценятся те инструменты, которые не поощряют плохие практики работы. Чтобы вот эти вот с кривыми руками коленки себе и другим не прострелили. И да, javascript в этом смысле язык достаточно неудачный. Он появился скорее как забава и изначально не был предназначен для тех вещей, для которых его сейчас используют. Ну а затем понеслось/поехало. И имеем то, что имеем. И тянуть сложно и отползать накладно.
Steamus
27.03.2024 14:35+1JS нравится. Это мой любимый язык программирования, где самая шикарная реализация ООП
Хватило этого предложения. Дальше не читал.
SWATOPLUS
27.03.2024 14:35Typescript, bun, eslint и 90% боли уходит.
Ну а ts runtime checks убирает оставшиеся 10%.
https://googlefeud.github.io/ts-runtime-checks/Ну а то, что TypeScript "в целом ситуацию только ухудшает" это полнейший бред не имеющий отношения к реальности.
Автор не разобрался в вопросе и сделал не правильные выводы.
langrafik
27.03.2024 14:35+1А что мешает взять конкретную технологию и писать на ней, не переписывая каждый день под новый Фреймворк? Много же проектов которые давно работают на «устарешвих» технологиях, тот же Fb, gitlab и так далее. Не надо забывать что js это всего лишь способ оживить страницу, никто не мешает использовать SSR или вообще отдавать готовый HTML на клиент. Все новомодные решения созданы для решения какой то проблемы, все эти проблемы по сути генерируются требованиями к интерфейсам. Бэкенд технологии не меняются так активно так как у них не появилось за последние 20 лет такого количества новых клиентов как у фронта (веб, мобилы, планшеты, десктоп приложения, вебаппы) как читали/ писали из бд и отправляли json, так оно и осталось. И по сути со времён Es6 фундаментальных каких то вещей которые бы упрощали жизнь / ломали бы старый код не появилось, а это уже 9 лет между прочим. Да и вообще зачем относится к языку как к чему высеченному на камне, не нравится - пишите на стандартном html+css, которые почему то тоже постоянно добавляют новые фичи, при этом не ломают старый функционал
pkirill
27.03.2024 14:35Попробуйте найти мой доклад на YouTube по словам JPoint Праздников. Там как раз про то как делать веб на java
Genrehopper
27.03.2024 14:35+1Очередной красноглазик не смог в динамическую типизацию :) а виноват язык
Alexandroppolus
27.03.2024 14:35+1семь человек одну и ту же несложную задачу могут написать на нём семью различными способами
Это справедливо, как минимум, для любого ЯП, на котором можно писать императивный код.
gmtd Автор
27.03.2024 14:35Это не так. В ООП языках, например, Java, есть классы, объекты, методы и аттрибуты и простые операции с минимально нужным синтаксисом, и, по сути всё, разработчик в этом всем ограничен
В JavaScript есть, например, function declaration и function expression. Можно сказать, полностью идентичные определения функций. Кто-то привык так, кто-то так, но наверно большинство разработчиков когда видит чужой стиль испытывает негативные чувства. Я хочу увидеть блок кода с functions, а мне визуально приходится отделать функции от computed во Vue, например.
И это всего лишь один небольшой пример. Контексты исполнения, функция это объект, чистые функции и нечистые, объекты, свойства которых можно задать как функции, а потом использовать для манипуляций и фильтраций через Object.keys(), Object.values(). И, вместо того, чтобы работать, ты сидишь, смотришь 20 минут на эти 20 строк и пытаешься понять, что хотел сказать автор, и почему нельзя писать не через жопу. А если там еще и типизация по полной, то вообще финиш. А ты ведь не гуру js и не хочешь им быть - у тебя еще бэкенд, база данных, облачные сервисы, тесты, CI/CD, люди, с которыми надо работать. Тебе хочется понятный читабельный код. Поэтому потом идешь, и пишешь эту статью.langrafik
27.03.2024 14:35+3смотришь 20 минут на эти 20 строк и пытаешься понять, что хотел сказать автор, и почему нельзя писать не через жопу
ну как бы в нормальных командах есть общепринятые подходы к написанию кода, стайлгайды, линтеры и притиер. Если разработчик не в силах им следовать то зачем такой разработчик. Понятие "читабельный код" для "не гуру js" можно так же переложить на любой язык. Я не гуру в go, и для меня там читать код довольно сложно, но это не значит что он написан через жопу
Типизация же наоборот делает язык похожим на "тот самый строгий синтаксис как Java / C#" так что тут тоже не понял наброс
а на счётFunction Declaration vs Function Expression
я не знаю каким видением нужно обладать чтоб "сломать глаза" об этот код и не понять что это одно и то же// Function Declaration
functionsum(a, b){
returna+b;
}// Function Expression
varsum=function(a, b){
returna+b;
}gmtd Автор
27.03.2024 14:35varsum=function(a, b){a
return+b;
}Так не пишут. Пишут так:
var sum = (a, b) => { return a + b; }Если разработчик не в силах им следовать то зачем такой разработчик.
Я говорил о случае, когда разбирал библиотеку, написанную совсем посторонним человеком
Типизация же наоборот делает язык похожим на "тот самый строгий синтаксис как Java
Это тип flatMap из lodash
flatMap<T>(this: LoDashImplicitWrapper<List<Many<T>> | Dictionary<Many<T>> | NumericDictionary<Many<T>> | null | undefined>): LoDashImplicitWrapper<T[]>;Покажите мне в Java где встречается такой ужас
Lazytech
27.03.2024 14:35+3Так не пишут. Пишут так:
Малость позанудствую. Насколько мне известно, со времен широкого распространения ES6 в подобных случаях обычно используют не var, а const. Кроме того, в небольших функциях иногда обходятся без return, и получается однострочная функция:
const sum = (a, b) => a + b;Забавно, что в английской версии соответствующей статьи на сайте MDN сплошь и рядом фигурирует const, а в русской версии почему-то var.
hello_my_name_is_dany
27.03.2024 14:35function declaration и function expression
Но в Java тоже есть анонимные функции с похожим синтаксисом. И даже есть анонимные классы. Чем вам не class expression?
Мне кажется, вы накидываете, только чтобы накидать. Но в суть не вникаете. И видимо плохо знаете Java, которую в противопоставление ставите.
Jenmaru
27.03.2024 14:35+3Не знаю, сколько не копался в кодах на гитхабе, смотрел, как одно решение реализовано у разных людей - все вполне понятно и логично, даже если код написан по-другому абсолютно, все равно понятно. Мб у автора проблемы не с js, а с чем-то другим?
Pr1me-HQ
27.03.2024 14:35Если сомневаетесь в словах человека, просто посмотрите на его аватарку. Он знает о чём говорит ☝️
strokoff
27.03.2024 14:35+7В каких случаях он выберет JavaScript? Видны три варианта:
Он/его команда больше ничего не умеют
Его вынуждают это сделать силой
Он не совсем в здравом уме.
Звучит как оскорбление разработчиков, дальше не стал читать. Это уже не хейт яваскрипта, а просто жидкий пук под себя
YChebotaev
27.03.2024 14:35Мне лично наоборот нравится быстрая эволюция тулзов и экосистемы. Они же с каждой итерацией лучше становятся; ты даже и не думал как может быть хорошо, а тут сделали лучше
Вью тот же уже третью реинкарнацию переживает
Steamus
27.03.2024 14:35Быстрая эволюция возможна только для инструментов на которых ничего большого и серьёзного не реализовано. Как только что-то большое и серьёзное появляется, вы вынуждены взвешивать каждый следующий шаг в изменении вашего инструмента, дабы поддержать совместимость и преемственность. Иначе у вас всё работающее -- рухнет. Это основная причина из-за которой широко используемые инструменты не могут скакать во всё новое как небольшие поделки.
YChebotaev
27.03.2024 14:35Ну, фронтенд может быть большим и серьезным
А во вторых, веб платформа одна из самых стабильных. До сих пор сайты, написанные в 00-х работают. Посмотри zen garden: до сих пор работает. Джаваскрипт же сохраняет обратную совместимость все годы существования. Не было такого, как в питоне, например, что новая версия ломает обратную совместимость
murkin-kot
27.03.2024 14:35+1На бэкенде еще есть возможность выбрать для работы другой язык, но на фронте глобально поможет только создание и внедрение нового с нуля
На фронте есть транспайлеры (которые автор даже упоминает). Среди них есть очень экономные по зависимостям. То есть можно всё писать на нормальных языках, не затягивая следом мегатонны ненужной ерунды.
Однако ничего не получило достаточного распространения
Вы определитесь - вам мода нужна или продукт качественный?
По опыту скажу так - затраты на выбор инструментов и создание каких-то велосипедов для их увязки в единое целое не занимает много времени. Если сравнить с корпоративными нормативами, то всё указанное делается практически бесплатно и очень быстро. Поэтому звучащий отовсюду стон "ну это же мало кто использует!" воспринимаю исключительно как отсутствие опыта создания целостных решений. Хотя бывает и так, что целостное решение не укладывается в голове даже весьма неглупых людей из-за ряда психологических особенностей и давлеющей повсеместно моды. Но это всё опять же следствие очень простого явления - человек никогда в жизни не тратил достаточно времени на серьёзное осмысление своей деятельности. Если же потратит, то рано или поздно он найдёт некое устраивающее решение. Хотя часто это будет очередной велосипед, да. Только по другому (без велосипедов) вы никак не наберёте нужный опыт.
Но, к сожалению, мода давит не только на разработчика, но и на тех, кто оплачивает его работу, а потому опыта создания эффективных решений нет почти ни у кого. У корпоративных разрабов опыта не может быть из-за моды и засевших гораздо выше "архитекторов" (кем себя называют все, кому не лень, почитав пару книжек про модные тренды в архитектуре), а у разработчиков менее масштабных решений опыта нет из-за отсутствия возможности проверить свои поделки на крупных проектах.
Так что жаловаться следует не на JavaScript, а на сложившиеся условия работы, определяемые профанами в области разработки.
SergeyEgorov
27.03.2024 14:35JavaScript мой любимый язык программирования :-) Он позволил мне избавиться от ООП шаблонов раз и навсегда в моем собственном коде. Код получается лаконичный, простой, понятный и легкоуправляемый. Дешево и сердито...
matim_ioioi
27.03.2024 14:35Статья — отличный байт на комменты, браво
Что касается отличий в написании — для этого существуют статические анализаторы. А они ещё и автофиксить могут.. Поэтому в рамках команды/проекта/системы/чегохотитедругого составляется стайлгайд, пишутся для него автоматизации и внедряется в проекты. А потом 25 человек, которые «пишут по-разному», оказывается, что пишут одинаково. Заходишь в любой кусок кода и заранее знаешь, что и где искать. А для нетривиальных ситуаций существуют комментарии. Их, вроде, никто не отменял
На любом ЯП можно написать такой код, чтобы его никто кроме автора не понял. Смотря какая цель :)
TAZAQ
27.03.2024 14:35Вот это наброс конечно, особенно на фоне появления Web-interoperable Runtimes Community Group.
Такое ощущение, что из типизации сделали идола, а вокруг неё секта.
Особенно забавно было прочитать про многопоточность
IoannP
27.03.2024 14:35Язык программирования это в первую очережь инструмент, где-то этот инструпент подходит лучше где-то хуже, если не знаешь как и где применить, это не значит что инструмент гавно.
gmtd Автор
27.03.2024 14:35Я так понимаю, что между качественными дорогими немецкими плоскогубцами и китайским говном за 200 рублей вы не видите никакой разницы - и то, и то инструмент же.
Тогда да, ваше высказывание имеет смысл
IoannP
27.03.2024 14:35Согласен, есть разница, но это уже из категории лучшу-хуже для конкретной ситуации, в этом случае нужно сравнить js со схожими языками, тогда да, можно уже и решить чем является js, немецкими плоскогубцами или китайским говном за 200 рублей.
dlc
О, а я всё думал, когда же новая статья с хейтом JS? А то запаздывает по расписанию. Хорошо хоть про округление чисел в очередной раз не вспомнили.
У меня есть претензии, но не к ЯП, а к экосистеме и фронтовым "фреймворкам". Серьёзно, если сам стандарт ECMAScript и Node последние годы делают хорошие успехи (но недостаточно быстро!!!), то вот в комьюнити всё печально.
Иронично, что на сервере воцарился Nest (слава богам), а JS функции уже запихали почти во все БД, старые и новые, а на клиенте дела всё хуже и хуже. React отвратителен. Ember и Angular, к сожалению, катастрофически не популярны в СНГ, да и это просто лучшее из худшего. Vue умер и превратился в клон React. И ещё 50+ React-like библиотек.
А теперь ещё начали разрабатывать платформы. Next.js и иже с ним да будут трижды прокляты.
В целом, ужасающих масштабов раздробленность. Ну думал, что буду скучать по Backbone и Bower.
Djaler
интересное заявление, а подкреплено чем-то?
slavaRomantsov
Может он имел ввиду VUE2 умер, да здравствует VUE3
gmtd Автор
Скорей это