Comments 75
О, а я всё думал, когда же новая статья с хейтом JS? А то запаздывает по расписанию. Хорошо хоть про округление чисел в очередной раз не вспомнили.
У меня есть претензии, но не к ЯП, а к экосистеме и фронтовым "фреймворкам". Серьёзно, если сам стандарт ECMAScript и Node последние годы делают хорошие успехи (но недостаточно быстро!!!), то вот в комьюнити всё печально.
Иронично, что на сервере воцарился Nest (слава богам), а JS функции уже запихали почти во все БД, старые и новые, а на клиенте дела всё хуже и хуже. React отвратителен. Ember и Angular, к сожалению, катастрофически не популярны в СНГ, да и это просто лучшее из худшего. Vue умер и превратился в клон React. И ещё 50+ React-like библиотек.
А теперь ещё начали разрабатывать платформы. Next.js и иже с ним да будут трижды прокляты.
В целом, ужасающих масштабов раздробленность. Ну думал, что буду скучать по Backbone и Bower.
База, но
Хотя может покажусь наглым, но хочется примеров кода, плюс их навалом - на JS одна и та же страничка написанная на Vue, нативном JS, c использованием jQuery или React да и практически любое другое решение - выглядит так, будто это вообще не JavaScript. Хотя бы таких примеров тут)
Но в целом стоит отдать должное языку, как бы его не хаяли - он всё равно остаётся ультимативным во фронтенде, да и мне всё же нравится в его сложные штуки, "Hell callbacks", Proxy, prototype повсюду, круто же ;) А еще когда рядом WASM лежит, ощущения прям непревзойдённые, но это не по теме конечно, да.
ps, Спасибо за статью!
- не нравятся кошки?
- Да Вы просто не умеете их готовить!
Можно подумать, какой-то другой современный язык лучше. Их ляпают дебилы с болонским образованием, исключительно ради хайпа. Что можно ожидать?
Печально, что такие же дебилы настойчиво портят старый PHP, который придумали умные люди. И ведь испортят. Практически уже.
Да в общем-то любой современный язык лучше, и их делают люди, которые умеют в теорию языков программирования и много думают прежде чем принимать решения. Rust, Kotlin, Swift, можно перечислять дальше
Хотелось бы услышать подробности мнения, чем таким именно испортили пхп. Чем 8.0-8.2 хуже 7.х версий?
отсутствии многопоточности
Дальше можно не читать
Очередное нытье про то какой is ужасный. И синтаксис не такой и читаемость плохая и то не так и так не этак. Ощущение как будто авторы подобных статей из принципа не юзают современные фичи языка и фреймов чтобы потом писать какая экосистема Js гавно. Я люблю Js уж хотя бы за то что не нужно делать кучу всяких гетеров сеттеров как в джаве , что есть замыкания и тебе не нужно каждый раз пробрасывать переменную чтобы не орал тебе что он не понимает на что ты ссылаешься. Современные фреймворки тоже не то чтобы очень сложные и зная один легко пересесть на другой за неделю. Короче Джаваскрипт не идеален, но вот подобные статьи выглядят как набрасывание говна на вентилятор. Как сказал один чел - «Джаваскрипт позволяет мне оплачивать счета и еду а значит это крутой язык»
Последняя фраза - кайфовая. Спасибо! Записал)
Я, как вечный новичок в Джаваскрипт (периодически приходится на нем писать, и заново подучивать/вспоминать) скажу, что замыкания одна из сложно запоминаемых вещей. Примерно на уровне конкатенации переменных разных типов в JS. Ну это мое такое вот джуновское мнение
Не знаю, по мне супер простая штука. Представь что функция умеет видеть и помнить переменные вне самой себя. Вот и все) это по большому счету и есть замыкания)
Замыкания я знаю, мой основной язык Котлин/Джава. Просто в этих языках замыкания как-то без изысков, и соответственно запомнить легко. В случае с JS приходится подглядывать в документацию. Цепочка вызовов лексических окружений, new Function и т.д. То же самое с this в разных контекстах.
Насколько я помню даже книга есть, название что-то типа "вы не знаете замыкания" и в ней речь идет про замыкания JS. Точно такая же есть и для async await, но там понятно, целая книга для нелегкого асинхронного программирования. Но для замыканий...
Это уже книги из разряда - как усложнить простую вещь чтобы продать тебе книгу. Да есть какие то ситуативные кейсы и если упороться можно себе устроить ад замыкательный, но никто в здравом уме на пробе таким не будет заниматься. Все итак максимально функции упрощают. Поэтому на практике словить какую то серьезную траблу с замыканиями довольно тяжело если специально к этому не стремиться
Это на самом деле проблема людей кто пишут статьи - джс гавно. Они находят и придумывают какие то ужасные конструкции чтобы доказать что язык ломается и плохо работает. Но это же к реальной жизни мало отношения имеет. В реальной жизни бизнес решает задачи а ты на джс в основном просто рендериншь интерфейс да данные туда сюда гоняешь. Но нет надо писать о каком то сложном и непонятном синтаксисе искать какие то кейсы где джс ломается и потом с пеной у рта доказывать что джс вообще не должен существовать и все комьюнити и все кто зарабатывает на продуктах - не правы
С одной стороны согласен, что в первую очередь, от кого зависит выстрел в ногу - это программист. Но язык тоже должен помогать не стрелять себе в ногу. На примере джавы могу сказать - джава это наследие С и С++ . Там взяли и многие скользкие моменты убрали из языка, например вольности с неявным преобразованием типов, один из самых частых источников проблем. Но в джаве, понятно, такой дизайн с самого начала, когда не надо было оглядываться на обратную совместимость. Но в JS, на мой взгляд, очень много неоднозначных моментов, которые как раз путают и разрешают отстрелить себе просто обе ноги. И эти моменты никак не уменьшаются, не исправляются. Хотя use strict ввели, но как-то мягко он работает. Вот и получается, что на проекте первый программист пишет в одном стиле, после него приходит другой и начинает писать/переписывать в другом стиле. И начинается ад и зоопарк. И это только про стиль написания код, я не говорю про рантаймы (просто знаний не хватает говорить про это).
В этом плане мне нравится дзен питона - явное лучше неявного. Вот как раз этого, мне кажется, языку JS не хватает. Не хватает единого стиля.
Хотя, если уж быть объективным, этим страдают многие языки. И даже мой любимый Котлин, который, наверное больше всех подвержен этому. В нем можно писать и в Котлин/Функциональном стиле, с втыканием лямбд везде где только можно, но также и в Джава/ООП стиле, без этих функциональных возможностей. Благо я, пришедший в Котлин из джавы, могу читать оба стиля написания. Но я представляю чувства программиста, у которого первый язык Котлин, и он будет читать код программиста, который пишет как в Джава. И наоборот. Мне лично тяжело было перестроиться, а тем более читать код в стиле Котлина, когда я только начал его изучать.
Просто не совсем понятно перевели, я тоже долго не мог запомнить.
Укупорка. Вот понятное объяснение.
Укупорка переменных внутрь функции.
Столько поинтов про зоопарк, но у 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. Их вы как-то не затронули.
Вывод должен быть такой, что всё познаётся в детальном сравнении. Чем больше работаешь с технологией и делаешь больше разнообразных задач, тем больше замечаешь в ней минусы и недостатки, которые были скрыты под белизной хайпа или решения простых задач. Да бывает больно, но другие ЯП если и решат проблемы, то точно принесут новые. Выбирать язык надо с умом. А как именно на вряд ли кто-то скажет, всегда зависит от ситуаций. И в большинстве случаев, что знает команда, то используется.
Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма.
Любая Java VM полностью поддерживает спецификацию языка. Код, скомпилированный на одном JDK, будет без проблем выполняться на другой JVM. Kotlin и Skala также компилируются в байткод и выполняются одинаково на любой JVM, разница только в лицензиях и, небольшая, в производительности.
Какая поддержка JavaScript у JavaScript рантаймов? Сколько времени займет переписывание программы под Bun на Node.js?
Ваша аргументация имеет слабое отношение к тому, что написано в статье
То, что вы не встречались с проектами, которые работают (могут работать) только с yarn или pnpm, и не видите существенных отличий между ними, говорит о вашем опыте.
Любая 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 лет очень сильно изменился, много оптимизаций произошло и всё благодаря сторонним пакетным менеджерам.
Код, скомпилированный на одном JDK, будет без проблем выполняться на другой JVM
Я вообще не могу понять, откуда ты это взял. У нас на работе приходится использовать три разных jre номинально одной версии для разных приложений, и эти приложения совершенно точно не могут запускаться на тех jre, под которыми не были сделаны. Вообще воо этот джавовский "write once, run everywhere" полнейший миф, о котором пора бы уже забыть.
>Для C# тоже есть .NET Framework, .NET Core, Mono
Это боль
Представляю, как больно когда их больше десятка
Maven, Gradle (Groovy, Kotlin). Пакетов эти тонны и в разных стилях.
А продолжить вот этот вот список (Maven, Gradle...) сможете? Ну хотя бы на 2-4 имени (только без Ant -- это уже история). Groovy и Kotlin (и Clojure, и Scala, и JRuby и Jython и ...) -- языки программирования, использующие в качестве среды выполнения JVM, а не системы сборки проектов. К чему вы их упомянули рядом с Maven как будто это вещи одного порядка? Их много языков программирования, которые практически "бесшовно" встраиваются в Java. Специально для тех кто любит разнообразие и типа "ненавидит" каноническую Java.
Пакетов тонны потому, что проектов тысячи тонн. И задач миллионы тонн. А вот разных стилей совсем немного. И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
А продолжить вот этот вот список (Maven, Gradle...) сможете?
А помимо npm, yarn, pnpm тоже сможете? Автору и этого хватило.
К чему вы их упомянули рядом с Maven как будто это вещи одного порядка?
Не к Maven, а к Gradle, в котором конфигурации можно писать либо на Kotlin, либо на Groovy. Это не какой-нибудь JSON/XML по-быстрому выучить для конфигурации билда и зависимостей.
И то, как правило, если дисциплины на проекте нет и код ревью не делается достаточно профессионально.
То же правило действует и для проектов на JavaScript/TypeScript. Виновен ли в этом язык? Нет, конечно.
Не к Maven, а к Gradle, в котором конфигурации можно писать либо на Kotlin, либо на Groovy.
В Gradle, как и в Maven, в 90% случаев можно вообще ничего ни на чём не писать. Просто грамотно указать чего вы хотите. Да, порой это мутно немного. Увы, есть такое. А Groovy/Kotlin это уже как бонус. Для тех проектов которые плохо организованы и нужно тут подпрыгнуть, а тут пригнуться, тут с того утянуть, а тут это вот отфильтровать. Есть такие дурные, тянущиеся веками проекты, где неумные програмеры ленятся один раз перехерачить всё и сделать по уму. Дабы не заклеивать бесконечно дырки лейкопластырем.
Для примера, в Java тоже есть несколько рантаймов, а кол-во SDK вообще тьма.
Неправда. Количество SDK всего несколько штук. Ну там 6 примерно. Причём массово используется лишь примерно пара. Остальные возникли по своим причинам и вы можете вообще про них не знать.
Рантайм может компоноваться в зависимости от нужд развёртываемого приложения с целью не тащить ненужный код. Это появилось позже для удобства. И он всё равно будет состоять из стандартных кусков. Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
Причём массово используется лишь примерно пара
Так в мире JavaScript тоже. Опять же если не брать фронтенд, то это в подавляющем большинстве - Node.js. Остальное, как я и писал - сырое или что-то специально для cloud решений, там в общем всё кастомное, в том числе и рантаймы Java попадаются.
Увы, но вы для красного словца довольно сильно передёргиваете несложные и известные факты в свою пользу. Это не есть хорошо. ))
Я не передёргиваю) А всего лишь даю понять, что если капнуть чуть глубже, ситуации похожи, чего автор статьи совсем не хочет видеть.
если не брать фронтенд, то это в подавляющем большинстве - Node.js.
Если не брать фронтенд, то о js на сервере лучше вообще забыть как о страшном сне. По уму оно и на фронте лучше бы об нём забыть. Ну да ладно. Что есть то есть.
Так вот, никакой объективной причины/повода/смысла тянуть js на сервер никогда не было и нет. Там работают вполне себе половозрелые, состоявшиеся взрослые языки и фреймворки на соответствующих своим задачам языках. Никому там нах не упал этот недоделанный js. Он не даёт никаких преимуществ от слова вообще.
А зачем же он там возник? Это объясняется просто. Резко усложнился фронт. Потому что всё теперь под браузером. Такая политика, такая философия. Потребовалось реально много js програмеров. И появилась куча вот этих js програмеров, умных мальчишек с недалёким горизонтом планирования (простите парни) у которых "реализация ООП в js шикарна".
Но и бэкэнд же нужно делать. Людей где брать в промышленных масштабах? Как вот утилизировать навыки этих всех js мальчишек, самозабвенно влюблённых в js и никогда не знавших по жизни ничего иного кроме как прочитанного из интернет статей? Переучивать их и развивать? Годами? Да ну нах кому они упали. Пусть сами себе варятся. Учатся отличать ФП от ООП. Никто не будет за это платить.
А сделать можно просто. Дадим фреймворк, работающий на сервере на их родном js. Node/Next... Для большинства задач мощности этих фреймворков достаточно. Людей можно брать с фронта. Главное чтобы они любили свой бэк и верили в него. Бизнесу это выгодно. Сразу появилась большая масса "серьёзных", знающих js людей, уже готовых пилить серверную часть. Неважны детали. Главное языком владеть. И язык этот -- javascript.
всего лишь даю понять, что если капнуть чуть глубже, ситуации похожи
Если вы хотите куда-то что-то копать, то это имеет смысл только если делать из копанья адекватные выводы. Не переворачивать их с ног на голову.
И если покопать, то быстро становится понятно, что Java экосистему удалось удержать в разумных рамках. Стоило некоторой крови. Это да.
А вот js удержать не удалось. И это "лоскутное одеяло" сейчас беда для всей индустрии.
Хватило первого предложения. Дальше не читал.
А зачем тогда комментировать? Это как минимум не уважению к писавшему. Заявление по типу "Не читал Бродского, но осуждаю!" (хотя если знать контекст, то и там не всё так просто было). Можно не соглашаться с автором, даже с первых слов его работы и это - нормально! Я тоже вот не согласен с тем, что детям надо начинать программировать с HTML+ JS. Это одна из худших связок, от которой потом очень тяжело будет увести в более формализованные языки, так как учит безолаберности в коде, ибо эта связка уж слишком "прощает" ошибки разработчика, и как следствие вырабатывает в нём привычку не думать о последствиях своих действий. А это для программиста, тем более если он потом в проекте с кем то работает - очень плохо. Я встречался с такими на проектах, и потом после них переделывать приходится 90% кода. Но возвращаясь к вашей фразе, так комментировать это извините, просто хамовато по отношению к труду писавшего. Не нравится - закрой вкладку и листай дальше.
Хамовато вот такое писать в первой строчке. Мне, например, JS нравится. Это мой любимый язык программирования, где самая шикарная реализация ООП, хотя я 99% времени имею дело с обычным СИ. Но, например, мне Java не нравится до чёртиков. И что теперь? Мне специально сделать пост, где написать в первом предложении "Java ужасный язык программирования" ? Простите за французкий, но автор жидко обделался ещё в самом начале. Читать дальше не вижу смысла.
Это ваше субъективное мнение по содержимому статьи, на которое вы конечно имеете право, тут никто и не спорит. Но скажите, какой смысл заполнять ленту комментариев такими односложными "протестами", вместо развёрнутого, по типу того, что вы мне ответили выше? Для этого есть система оценок. Если каждый кто минусет или плюсует будет ставить ещё и комменты по типу вашего, то ни писавший, ни заинтересованный читатель, просто до полезного чего-то, что могут сказать комментаторы можно и не добраться. Есть что по делу сказать - пиши. Нет - зачем спамить в комментах своими односложными "фи", или "спасибо"!?
Может я чего-то не понимаю, но что полезного несёт статья автора? Его личные фе и фу по отличному языку программирования? Зачем это нам? Зачем это Хабре? Своё "фе" про статью высказали многие, не только я. Может владельцы Хабра увидят комментарии и заблокируют статью. По крайней мере я на такое надеюсь.
Ну, допустим сомнительное утверждение для статьи с положительным (на момент данного комментария) числом голосов. Лично я, например, с автором согласен, хотя ни разу не фронтэндщик, и вообще к js избегал прикасаться всю свой более чем 30летний стаж в программировании.
Язык действительно во многих смыслах наляпанный по мере необходимости затыкания разных текущих дыр в вэб-программировании. Его распространённость, как раз и есть обратная сторона его бестолковости. Он очень много прощает, что не простят многие другие языки. К тому же, есть очень много готовых решений. С помощью грамотного копипаста можно много чего быстренько слепить. Но как только потребуется что то серьёзно поменять под себя, в этих многочисленных фреймворках или модульных библиотеках - пиши пропало. Искать что, где и как надо поменять порой можно до "редькиного заговения" и в итоге пишется очередной ласапед, который хоть как то исправляет ситуацию. И в этом смысле, я полностью согласен с автором. Писать надо максимально читаемый и понимаемый код, без всех новомодных синтаксических фанктиков, которые потом сменятся согласно какого нибудь нового стандарта, и уже через год-другой никто не сможет толком пояснить, что делала та или иная функция. Для формы с парой кнопок не надо тянуть за собой Angular или React. А для больших приложений, и использовать нужно уже не Electron и т.п., а что то более для этого подходящее
Что-то я не пойму. Так это язык плохой или руки кривые у программистов? Это ведь разные вещи.
Язык как язык. В чём то хороший, в чём то - так себе. Его просто грамотно использовать надо, как и любой другой яп. О чем собственно и резюме в статье. А что до рук, то я про них и не писал ничего. Многие те, кто на нём научились писать несложные обработчики для форм, вряд-ли такие уж и программисты. Но и те, кто освоил крутые фреймворки на JS, так же не факт что имеет при этом такие уж прямые руки. Всё дело в голове, если уж на то пошло.
Перефразирую известную фразу -- у меня нет для вас других программистов.
Всегда найдётся тот, у которого кривые руки. Абсолютно в любом деле. А когда что-то поставлено на поток и требуется в промышленных масштабах -- таких будет десятки тысяч. Вот именно поэтому (!) и ценятся те инструменты, которые не поощряют плохие практики работы. Чтобы вот эти вот с кривыми руками коленки себе и другим не прострелили. И да, javascript в этом смысле язык достаточно неудачный. Он появился скорее как забава и изначально не был предназначен для тех вещей, для которых его сейчас используют. Ну а затем понеслось/поехало. И имеем то, что имеем. И тянуть сложно и отползать накладно.
Всё тоже самое можно про другие языки написать. Например, я раньше частенько вылазил в СИ за пределы массива и портил память. Потом долго думал. Теперь из-за этого СИ язык плохой? Или у меня руки кривые просто?
Как я уже писал выше -- язык программирования не должен "вертеться" конкретно вокруг именно ваших рук. Какими бы замечательными они и не были. Он должен принимать в расчёт среднестатистические руки доступные в индустрии.
И в этом смысле (в смысле безопасности использования) язык С -- достаточно плохой, опасный язык. Но это было сделано сознательно с целью сохранения максимальной эффективности откомпилированного кода. Не забываем сколько ему уже лет и на тот момент это был прорыв для своего класса задач. Ассемблер он ведь куда опаснее. Ну а далее появились С++, Rust... и сейчас уже нужны достаточно весомые основания чтобы начинать проект на чистом С. Человек, сейчас выбирающий язык С для реализации "обычной" задачи -- просто впустую тратит своё время и деньги работодателя.
Да ладно. На чем прикажете мне писать программу работы реле стеклоочистителей? На расте? Серьезно?
JS нравится. Это мой любимый язык программирования, где самая шикарная реализация ООП
Хватило этого предложения. Дальше не читал.
Typescript, bun, eslint и 90% боли уходит.
Ну а ts runtime checks убирает оставшиеся 10%.
https://googlefeud.github.io/ts-runtime-checks/
Ну а то, что TypeScript "в целом ситуацию только ухудшает" это полнейший бред не имеющий отношения к реальности.
Автор не разобрался в вопросе и сделал не правильные выводы.
перешёл с vue/angular на Blazor, советую попробовать. back на C#
А что мешает взять конкретную технологию и писать на ней, не переписывая каждый день под новый Фреймворк? Много же проектов которые давно работают на «устарешвих» технологиях, тот же Fb, gitlab и так далее. Не надо забывать что js это всего лишь способ оживить страницу, никто не мешает использовать SSR или вообще отдавать готовый HTML на клиент. Все новомодные решения созданы для решения какой то проблемы, все эти проблемы по сути генерируются требованиями к интерфейсам. Бэкенд технологии не меняются так активно так как у них не появилось за последние 20 лет такого количества новых клиентов как у фронта (веб, мобилы, планшеты, десктоп приложения, вебаппы) как читали/ писали из бд и отправляли json, так оно и осталось. И по сути со времён Es6 фундаментальных каких то вещей которые бы упрощали жизнь / ломали бы старый код не появилось, а это уже 9 лет между прочим. Да и вообще зачем относится к языку как к чему высеченному на камне, не нравится - пишите на стандартном html+css, которые почему то тоже постоянно добавляют новые фичи, при этом не ломают старый функционал
Попробуйте найти мой доклад на YouTube по словам JPoint Праздников. Там как раз про то как делать веб на java
Очередной красноглазик не смог в динамическую типизацию :) а виноват язык
семь человек одну и ту же несложную задачу могут написать на нём семью различными способами
Это справедливо, как минимум, для любого ЯП, на котором можно писать императивный код.
Это не так. В ООП языках, например, Java, есть классы, объекты, методы и аттрибуты и простые операции с минимально нужным синтаксисом, и, по сути всё, разработчик в этом всем ограничен
В JavaScript есть, например, function declaration и function expression. Можно сказать, полностью идентичные определения функций. Кто-то привык так, кто-то так, но наверно большинство разработчиков когда видит чужой стиль испытывает негативные чувства. Я хочу увидеть блок кода с functions, а мне визуально приходится отделать функции от computed во Vue, например.
И это всего лишь один небольшой пример. Контексты исполнения, функция это объект, чистые функции и нечистые, объекты, свойства которых можно задать как функции, а потом использовать для манипуляций и фильтраций через Object.keys(), Object.values(). И, вместо того, чтобы работать, ты сидишь, смотришь 20 минут на эти 20 строк и пытаешься понять, что хотел сказать автор, и почему нельзя писать не через жопу. А если там еще и типизация по полной, то вообще финиш. А ты ведь не гуру js и не хочешь им быть - у тебя еще бэкенд, база данных, облачные сервисы, тесты, CI/CD, люди, с которыми надо работать. Тебе хочется понятный читабельный код. Поэтому потом идешь, и пишешь эту статью.
смотришь 20 минут на эти 20 строк и пытаешься понять, что хотел сказать автор, и почему нельзя писать не через жопу
ну как бы в нормальных командах есть общепринятые подходы к написанию кода, стайлгайды, линтеры и притиер. Если разработчик не в силах им следовать то зачем такой разработчик. Понятие "читабельный код" для "не гуру js" можно так же переложить на любой язык. Я не гуру в go, и для меня там читать код довольно сложно, но это не значит что он написан через жопу
Типизация же наоборот делает язык похожим на "тот самый строгий синтаксис как Java / C#" так что тут тоже не понял наброс
а на счёт Function Declaration vs Function Expression
я не знаю каким видением нужно обладать чтоб "сломать глаза" об этот код и не понять что это одно и то же
// Function Declaration
function sum(a, b) {
return a + b;
}
// Function Expression
var sum = function(a, b) {
return a + b;
}
varsum=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 где встречается такой ужас
Так не пишут. Пишут так:
Малость позанудствую. Насколько мне известно, со времен широкого распространения ES6 в подобных случаях обычно используют не var, а const. Кроме того, в небольших функциях иногда обходятся без return, и получается однострочная функция:
const sum = (a, b) => a + b;Забавно, что в английской версии соответствующей статьи на сайте MDN сплошь и рядом фигурирует const, а в русской версии почему-то var.
function declaration и function expression
Но в Java тоже есть анонимные функции с похожим синтаксисом. И даже есть анонимные классы. Чем вам не class expression?
Мне кажется, вы накидываете, только чтобы накидать. Но в суть не вникаете. И видимо плохо знаете Java, которую в противопоставление ставите.
Не знаю, сколько не копался в кодах на гитхабе, смотрел, как одно решение реализовано у разных людей - все вполне понятно и логично, даже если код написан по-другому абсолютно, все равно понятно. Мб у автора проблемы не с js, а с чем-то другим?
Если сомневаетесь в словах человека, просто посмотрите на его аватарку. Он знает о чём говорит ☝️
В каких случаях он выберет JavaScript? Видны три варианта:
Он/его команда больше ничего не умеют
Его вынуждают это сделать силой
Он не совсем в здравом уме.
Звучит как оскорбление разработчиков, дальше не стал читать. Это уже не хейт яваскрипта, а просто жидкий пук под себя
Мне лично наоборот нравится быстрая эволюция тулзов и экосистемы. Они же с каждой итерацией лучше становятся; ты даже и не думал как может быть хорошо, а тут сделали лучше
Вью тот же уже третью реинкарнацию переживает
Быстрая эволюция возможна только для инструментов на которых ничего большого и серьёзного не реализовано. Как только что-то большое и серьёзное появляется, вы вынуждены взвешивать каждый следующий шаг в изменении вашего инструмента, дабы поддержать совместимость и преемственность. Иначе у вас всё работающее -- рухнет. Это основная причина из-за которой широко используемые инструменты не могут скакать во всё новое как небольшие поделки.
Ну, фронтенд может быть большим и серьезным
А во вторых, веб платформа одна из самых стабильных. До сих пор сайты, написанные в 00-х работают. Посмотри zen garden: до сих пор работает. Джаваскрипт же сохраняет обратную совместимость все годы существования. Не было такого, как в питоне, например, что новая версия ломает обратную совместимость
Зен гаден -- это сайт. Просто приятный милый сайтик, посвящённый "таинствам" CSS. Его вроде один человек поддерживает. Энтузиаст. Там этого Javascript-а -- кот наплакал. Скорее можно говорить о стабильности HTML. Но даже и он не раз менялся за свою историю. Когда говорят об аде Javascript, то речь идёт о тяжёлых SDI/MDI приложениях, заменяющих то, что раньше называлось "толстый десктоп клиент". Ибо всё переносится под браузер.
Одно время, совсем не так и давно, лет 7-8 назад, заметки про Javascript начинались словами: "пока я писал этот абзац, на планете, скорее всего, появилось ещё более десятка новых javascript фреймворков и мой текст возможно уже устарел...". Эту лавину "шлака" немного удалось притормозить c появлением Typescript и сплочением трезвомыслящей общественности вокруг большой тройки голов фреймворков, но времена по прежнему оставались стрёмными. И "какой-нибудь" Гугл всё ещё мог себе позволить в одну ночь отрубить одну голову выбросить на свалку первую версию известного фреймворка. Но некая стабильность всё же впереди замаячила. Но увы, похоже это только мираж... ))
На бэкенде еще есть возможность выбрать для работы другой язык, но на фронте глобально поможет только создание и внедрение нового с нуля
На фронте есть транспайлеры (которые автор даже упоминает). Среди них есть очень экономные по зависимостям. То есть можно всё писать на нормальных языках, не затягивая следом мегатонны ненужной ерунды.
Однако ничего не получило достаточного распространения
Вы определитесь - вам мода нужна или продукт качественный?
По опыту скажу так - затраты на выбор инструментов и создание каких-то велосипедов для их увязки в единое целое не занимает много времени. Если сравнить с корпоративными нормативами, то всё указанное делается практически бесплатно и очень быстро. Поэтому звучащий отовсюду стон "ну это же мало кто использует!" воспринимаю исключительно как отсутствие опыта создания целостных решений. Хотя бывает и так, что целостное решение не укладывается в голове даже весьма неглупых людей из-за ряда психологических особенностей и давлеющей повсеместно моды. Но это всё опять же следствие очень простого явления - человек никогда в жизни не тратил достаточно времени на серьёзное осмысление своей деятельности. Если же потратит, то рано или поздно он найдёт некое устраивающее решение. Хотя часто это будет очередной велосипед, да. Только по другому (без велосипедов) вы никак не наберёте нужный опыт.
Но, к сожалению, мода давит не только на разработчика, но и на тех, кто оплачивает его работу, а потому опыта создания эффективных решений нет почти ни у кого. У корпоративных разрабов опыта не может быть из-за моды и засевших гораздо выше "архитекторов" (кем себя называют все, кому не лень, почитав пару книжек про модные тренды в архитектуре), а у разработчиков менее масштабных решений опыта нет из-за отсутствия возможности проверить свои поделки на крупных проектах.
Так что жаловаться следует не на JavaScript, а на сложившиеся условия работы, определяемые профанами в области разработки.
JavaScript мой любимый язык программирования :-) Он позволил мне избавиться от ООП шаблонов раз и навсегда в моем собственном коде. Код получается лаконичный, простой, понятный и легкоуправляемый. Дешево и сердито...
Статья — отличный байт на комменты, браво
Что касается отличий в написании — для этого существуют статические анализаторы. А они ещё и автофиксить могут.. Поэтому в рамках команды/проекта/системы/чегохотитедругого составляется стайлгайд, пишутся для него автоматизации и внедряется в проекты. А потом 25 человек, которые «пишут по-разному», оказывается, что пишут одинаково. Заходишь в любой кусок кода и заранее знаешь, что и где искать. А для нетривиальных ситуаций существуют комментарии. Их, вроде, никто не отменял
На любом ЯП можно написать такой код, чтобы его никто кроме автора не понял. Смотря какая цель :)
Вот это наброс конечно, особенно на фоне появления Web-interoperable Runtimes Community Group.
Такое ощущение, что из типизации сделали идола, а вокруг неё секта.
Особенно забавно было прочитать про многопоточность
Язык программирования это в первую очережь инструмент, где-то этот инструпент подходит лучше где-то хуже, если не знаешь как и где применить, это не значит что инструмент гавно.
Для фронта и прототипирования JS идеальный язык. Для бэкенда тоже ничего особо сложного, просто нет готовых решений или библиотек, как в других языках, но это не проблема языка.
Я знаю C(++), python, Kotlin, C# даже немного ковырял go и rust. И я понял, что в JS не так много магических конструкций, как в этих языках. Он простой и в этом его плюс. В нем не нужно думать о многопоточности, почти нет мета конструкций, которые есть только в этом языке, а все фичи других языков легко реализуются, было бы желание.
Самая большая проблема JS это то, что он простой, популярный и слабо стандартизированный, а значит на нем легко говнокодить и плодить библиотеки и свои стандарты, о чем и была статья.
Лонгрид о JavaScript