[recovery mode] JavaScript как явление
Комментарии (127)
2 августа 2017 в 22:29
+17↑
↓
Какая-то бессмысленная истерика.2 августа 2017 в 22:34
–8↑
↓
Не истерика, а набор фактов и вопрос «почему всё так?» к обсуждению3 августа 2017 в 00:35
+5↑
↓
В чем факт ужасности return? В том, что не нравится лично вам, не иначе.
torbasow
3 августа 2017 в 09:10
+1↑
↓
Чем плох return, я могу предположить. Когда у функции несколько точек выхода, это не очень надёжная конструкция. Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.
Но фигурные скобочки и точка с запятой… Тут я теряюсь.3 августа 2017 в 09:26
0↑
↓
Единственная проблема с return в JS — нельзя перенести возвращаемое на следующую строку (будет undefined если перенести).
vintage
3 августа 2017 в 09:33
+1↑
↓
Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.
return такого не умеет.
3 августа 2017 в 09:41
–3↑
↓
function foo() { var f = () => { return 42; }; f(); } console.log(foo()); // undefined
AndreyRubankov
3 августа 2017 в 10:04
0↑
↓
Известно, что функция может возвращать значение только через return (а стрелочная может и без него),
и тут назревает логичный вопрос: Если в конце тела функции нету return, то в чем здесь проблема в языке или в том, кто даже основ языка не прочитал?-
vintage
3 августа 2017 в 10:11 (комментарий был изменён)
+2↑
↓
А, кажется понял вашу претензию. Вы хотели выйти из метода, но не заметили, что находитесь в стрелочной функции и вышли из неё? Тут и любую другую функцию можно не заметить, если кода много, а форматирование так себе.
3 августа 2017 в 10:12 (комментарий был изменён)
0↑
↓
Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.
-
vintage
3 августа 2017 в 10:23
+2↑
↓
Я изменил тот комментарий.
Было бы странно, если бы return выходил сразу из нескольких функций.
3 августа 2017 в 10:26
+1↑
↓
Да, это и правда было бы странно (хотя в Scala вроде как return так и работает). Но искать точку выхода из переусложненной функции эта странность не помогает :-)
franzose
3 августа 2017 в 11:22
0↑
↓
Вы ожидали, что console.log выдаст 42?
3 августа 2017 в 11:23
0↑
↓
Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.
dlf42
3 августа 2017 в 11:34
0↑
↓
Я думаю, имелось в виду «можно перепутать return из малозаметной стрелочной функцией внутри метода с return из самого метода»
3 августа 2017 в 09:52
0↑
↓
Я, может, не совсем понимаю что вы подразумеваете под надежность. Но известные мне компилеры других языков не скомпилят программу, пока в каждой точке выхода не будет return. Если функция, конечно, не void func () :-)-
AndreyRubankov
3 августа 2017 в 09:56
+1↑
↓
Есть множество языков, где есть return, но его можно не использовать (php кажется, один из таких, а еще Scala) и есть множество языков, где return отсутствует как таковой (если не ошибаюсь, к ним относится Python).
Во всех этих языках результат последнего действия будет возвращен как результат функции.3 августа 2017 в 10:00
+1↑
↓
В python точно есть return
flancer
3 августа 2017 в 10:05
+1↑
↓
есть != обязателен к использованию
-
AndreyRubankov
3 августа 2017 в 10:06
0↑
↓
спасибо, значит ошибся.
3 августа 2017 в 11:37
0↑
↓
В Python функция без return вернет None.
Такие ошбки ловятся статическим (опциональным) анализом типов, но могут доставить немало «приятных» минут.
andreysmind
3 августа 2017 в 12:35
0↑
↓
К ним Ruby относится :)
-
torbasow
3 августа 2017 в 11:09
+1↑
↓
А тут я перестал понимать, о чём речь. В Javascript никакой точки выхода без return быть не может, если это только не конец функции. Я имею в виду вот что: «модуль (в данном случае функция) должен иметь только одну точку входа и только одну точку выхода».
-
franzose
3 августа 2017 в 11:20
0↑
↓
Как мне кажется, это уже не проблема языка, а то, как пишут код конкретные программисты. Потому что запутанный код можно писать на любом языке)
-
torbasow
3 августа 2017 в 12:39
0↑
↓
Но некоторые конструкции упрощают эту задачу.
3 августа 2017 в 09:26
0↑
↓
return не плох, он коварен. В том смысле, что он обязателен — функция не возвращает значение последнего выражения.-
AndreyRubankov
3 августа 2017 в 09:53 (комментарий был изменён)
+3↑
↓
Так это не в return дело, а в том что девелопер привык писать на языке, который не использует return.
Если девелопер начинал обучение с более низкоуровневых языков Pascal/C/C++/C#/etc. то ему будет напротив непривычно, что return не используется.return коварен в Scala, где он при определенных условиях может сделать больше, чем ожидается. Но в JS он ведет себя как в большинстве C-подобных языков.
3 августа 2017 в 10:00
0↑
↓
Я вот писал на JS после многих лет C/C++ и даже Питона и никаких проблем с return и скобочками не испытывал вообще!
-
AndreyRubankov
3 августа 2017 в 09:43
+2↑
↓
«почему всё так?»
js, как язык существует уже почти 20 лет (или больше?), но js, как полноценный язык, на котором можно писать больше, чем обработчик onclick, существует всего лет 5–7, ну, а js, который уже имеет зачатки для больших проектов (ES2015) и того меньше, — ему всего 2 года.Но язык и платформа невероятно быстро развиваются. И большим недостатком этого развития является то, что «каждый тянет одеяло на себя» (на фоне этого развития можно стать SuperStar! если успеешь сделать библиотеку, которой все будут пользоваться, такую как jQuery). И теперь давно минувшие «браузерные войны» превратились в «войны фреймворков».
К тому же стоит смотреть на историю развития: сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы, которые невзлюбили те, что освоили прототипное, а теперь и вовсе хайп на стороне функционального js.
Ах, еще JSX появился, который позволяет писать на js внутри html пока пишешь на js, который тоже не все любят.— Это все ведет к разделению сообщества на множество мелких юзергрупп, каждая из которых проповедует свою истину и не сильно любит чужую.
ps: А хайп девелопмент очень просто объяснить. Большинство JS девелоперов выросли на фронтендах, где все делается не так просто, как на бекенде, и любая новая библиотека призванная улучшить ситуацию воспринимается на ура.
-
vintage
3 августа 2017 в 10:21
+1↑
↓
Примечательно, что до примитивного JSX был чудесный E4X, который был стандартом, поддерживался Мозиллой, Флешом и Акробатом, и который… не взлетел.
3 августа 2017 в 10:29
0↑
↓
В то время фронтэндщики еще не свыклись с идеей о необходимости компилировать свои проекты, а firefox — не единственный браузер.
-
vintage
3 августа 2017 в 10:38
0↑
↓
Тем не менее, сейчас бы сдуть пыль со старичка, да внедрить, но индустрия как барышня «всё, поезд ушёл, ты был классный, но я к тебе больше не вернусь, буду мучиться с новым перспективным козлом». :-) Вот и мучаются люди с огрызком в виде JSX.
3 августа 2017 в 10:40
0↑
↓
Ну, все же E4X заменой JSX назвать трудно. Обработчики событий через E4X не поставить, сложные объекты — не передать. Все-таки, JSX по сравнению с E4X — шаг вперед.
-
vintage
3 августа 2017 в 10:46
0↑
↓
Шаг вперёд — два шага назад :-) Добавить в E4X возможность передавать в атрибутах сложные объекты было бы не так уж сложно.
3 августа 2017 в 10:48
0↑
↓
… и чем бы оно тогда от JSX отличалось? :-)
-
vintage
3 августа 2017 в 10:58
0↑
↓
DOM на выходе с возможностью его произвольного процессинга (от от DOM API и E4X селекторов, до XSLT трансформаций). Нативной поддержкой без препроцессоров. Стандарт в конце концов.
Ashot
3 августа 2017 в 11:07 (комментарий был изменён)
0↑
↓
сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы
так прототипное ООП никуда не делось — классы в JS это по сути синтаксический сахар, прототипный подход остался на месте
3 августа 2017 в 09:06
+3↑
↓
По моему всё по делу. Почти со всем согласен с автором, то что в 2017 году во сферы пытаются запихать однопоточный рантайм, это не нормально.Я считаю это результат курса ан опопсение программирования. Бизнесу не хватает программистов и они прикладывают силы чтоб любой js junior мог пилить их бизнес задачи.
3 августа 2017 в 11:31
+1↑
↓
Бизнесу же в конце концов надо решить задачу. Задач много, а программистов мало. С их точки зрения лучше, когда «дешёвый» js-разработчик быстренько напишет на однопоточном ЯП решение без разруливания проблем с race condition, синхронизацией и т.п., чем это будет «правильно» пилить «дорогой» разработчик на той же Java. А затем на сервере или в кластере поднимут нужное количество инстансов приложения, и вот вам многопоточность.
В случае же, если бизнес решает, что лучше делать правильно и дорого, то он джавистов и нанимает.
3 августа 2017 в 11:38
0↑
↓
Однопоточность не решает проблемы race condition. Вот один из самых известных исторических фактов по этому вопросу.
CodeViking
2 августа 2017 в 22:47
+7↑
↓
Может быть я не очень хороший программист, но JS я люблю. Однако считаю синдромом мечтать о том, чтобы всё было на JS.
begemot_sun
2 августа 2017 в 22:49
+6↑
↓
Наболело.2 августа 2017 в 22:50
+9↑
↓
Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру
А зачем же они это делают? Почему не вливают в кошерные языки?
2 августа 2017 в 23:04
–1↑
↓
Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до. То есть они пишут инструмент для себя. Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много, при необходимости обучить написанию тестов и дать ему таск чтобы он писал тесты и облазил в дебаггере код вдоль и поперёк пока всё не заработает как надо чем искать Scala / Java / Erlang / Elixir / Haskell / какого-то ещё разработчика.2 августа 2017 в 23:30
+3↑
↓
Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до.
Ну по идее ничто не мешает делать то-же самое на бэкенде и со строгими языками, зачем-же cвязывться с js?Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много
Вот это может быть более похоже на правду.
i360u
3 августа 2017 в 09:29
+2↑
↓
Хороший фронтендер на JS в среднем будет ничуть не дешевле аналогичных по уровню разработчиков на других популярных стеках. А зачастую и дороже. Дешевизна тут — большой миф, корни которого уходят к традиционно пренебрежительному отношению к «недопрограммистам» верстальшикам. Однако, в современных реалиях фронт часто оказывается гораздо сложнее бека.
seniorcote
3 августа 2017 в 00:03 (комментарий был изменён)
0↑
↓
У них есть ряд причин так делать, но забота о разработчиках и их нервах в этот ряд не входит.
2 августа 2017 в 22:53
+5↑
↓
Тащить на backend интерпретируемые языки, а еще и без типизации — маразм. Только компилируемые и со строгой, желательно именной, типизацией (Golang или Rust, конечно же).
На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность. Современные SPA фреймворки позволяют один такой bundle запустить на любом устройстве с экраном.
Но не на backend, ни в коем случае.
Пишу этот коммент только для того, чтобы выудить умные противоположные мысли из комментов к нему, если они будут.2 августа 2017 в 23:12
+1↑
↓
[Update]
В качестве JS только TypeScript.2 августа 2017 в 23:24
+3↑
↓
Говорят, что v8 компилирует js в нативный код, думаете врут?2 августа 2017 в 23:36
–4↑
↓
Судя по бенчмаркам, скорее всего, врут.
knekrasov
3 августа 2017 в 11:18
0↑
↓
А в конечном счете, все выполняется на вполне себе нативном ядре процессора с его микрокодом. Так что не врут.Вопрос в другом, какие assumptions сделает компилятор, пока будет превращать JS в нативный код? Статическая типизация в этом смысле поможет избежать ложных assumptions и четче декларировать намерения. Но ее нет :-)
3 августа 2017 в 11:39
0↑
↓
На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность.
Вы с css не путаете?
Есть всего 3,5 браузерных js движков, и все они более менее поддерживают стандарты.3 августа 2017 в 12:27
0↑
↓
Языки с типизацией — унылое старьё.))))
Wedmer
2 августа 2017 в 23:00
+3↑
↓
Сразу вспомнилось Wat видео от Destroy All Software.
aleXoid
2 августа 2017 в 23:02
+2↑
↓
Боль автора полностью обоснована. В последнее время я несколько увлёкся написанием ботов с MS Botframework, используя nodejs. Пока не перешёл полностью на Typescript — написание приложения больше 1000 строк, было настоящим мучением. Очень советую автору присмотреться к Typescript, как к костылю, который частично облегчает жизнь.2 августа 2017 в 23:17
0↑
↓
Благодарю! В современном мире увы каждый разработчик соприкасается с JS хочет он того или нет — больше или меньше, но это явление есть. Порой когда обсуждаю с друзьями-разработчиками какую-нибудь современную технологию кажется что находишься в клубе анонимных алкоголиков — то есть все знают что такое JS, почему он плох, но по разным причинам каждый становится замешан в этой экосистеме, иногда так и кажется что кто-то скажет— Привет, меня зовут Олег, и я иногда пишу на JS. Нет, вы не подумайте в основном я Scala разработчик, но вот иногда приходится и в npm полазить и для grunt с webpack скрипты написать. Кстати, я не писал на JS уже 2 недели
— Давайте похлопаем Олегу:)
2 августа 2017 в 23:26
+6↑
↓
Я бы не сказал, что Typescript костыль.3 августа 2017 в 00:01
0↑
↓
Хорошая вещь является костылём, если её предназначение — заставлять работать плохую вещь, когда её [почти] невозможно заменить.
Если бы браузеры понимали Typescript, он бы не был костылём.3 августа 2017 в 00:18
0↑
↓
Компилятор Typescript написан на… Typescript. Если я ничего не путаю, можно прикрутить компилятор к страничке и генерировать код в браузере на лету, но так никто не делает, потому что зачем.3 августа 2017 в 00:29
0↑
↓
А как прикрутить к страничке что-либо, написанное на Typescript?3 августа 2017 в 07:11
0↑
↓
Написан на typescript и скомпилирован в javascript
prostofilya
3 августа 2017 в 07:58
+2↑
↓
Что-то ребята на C++/C#/Java и тд тп всю жизнь компилируют и как-то не жалуются
3 августа 2017 в 07:40
0↑
↓
От этого браузер не начнёт понимать js, вы просто увеличите время загрузки)-
andreysmind
3 августа 2017 в 12:41
0↑
↓
Браузер переживет. А вот время разработки и отладки уменьшится.
3 августа 2017 в 10:28
0↑
↓
Глядишь и поймут скоро без жс. с вебассембли ;-)
2 августа 2017 в 23:06
+4↑
↓
Согласен со многими фактами, приведенными в статье, но позвольте несколько замечаний и вопросов (я JS разработчик).1. const — слышу о нём почти отовсюду. Но вот незадача — почему все думают что он должен работать точно так же как в С/С++/<вставьте любимый язык>. Я не спорю, реализация у него не лучшая, но это специфичная для языка конструкция, коротая имеет довольно простую функцию.
2. this — подобно const, крайне непонятая многими особенность языка. И опять же — использовать её необязательно.
3. Отсутствие нормальных классов/ООП. Недостаток только для людей, которые привыкли к ООП. Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/<добавьте свой язык>.
4. «Многомиллионные инвестиции кровавых денег от больших корпораций». Вы так говорите, как будто это что-то плохое. Ни один язык не станет популярным на голом энтузиазме его последователей. Нужны деньги, нужна реклама, нужна раскрутка. Как, по-вашему, работодатели узнают о языке/библиотеке/фреймворке, если он на слуху только в технических кругах?
В общем и целом, я к тому, что у всех языков есть недостатки и достоинства. У всех есть свои ниши и свои задачи. Языки — всего лишь инструменты.
С тем же NodeJS, многие его хаят за то, что он посягает на святая-святых — backend. Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться. Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления. И если этого будет недостаточно, то люди перестанут этим языком пользоваться. И он уйдёт из этой ниши. На его место прийдет другой и попытается привлечь к себе внимание, чтобы начать дискуссию. Потому как дискуссия и обсуждение — главные способы сделать язык лучше.
Java тоже не сразу стала удобной. Её тоже не все готовят правильно, есть жуткий код, есть хороший.
С радостью выслушаю мнения насчет JS и его представления на уровне backend.
sfi0zy
2 августа 2017 в 23:47
+4↑
↓
this — подобно const, крайне непонятая многими особенность языка
Но стоит один раз понять — и все, больше никогда этот вопрос не доставит проблем. А со стрелочными функциями использовать this стало очень приятно.Но соглашусь, те попытки создать ООП в JS, которые были — очень далеки от привычных многим концепций в Java/C/C++/C#/
Да нет, в ES6 классы сделали вполне нормальные. Да, в них может не хватать чего-то, к чему привыкли приходящие из других языков, но это уже не та жесть на прототипах, которую писали 10 лет назад.Жалобы поднимут дискуссии, появятся решения, новые версии, патчи и исправления.
В последние годы JS вообще очень сильно развивается, столько всего появилось… Автор поста говорит, что в JS нет единой системы в отношении модулей, работы с асинхронностями, и.т.д., но ведь это по сути является следствием того, что язык развивается, люди пробуют разное и пытаются выбрать лучшее. Просто здесь (как и в том же С++, кстати) не выпиливаются многие старые решения, они просто используются все меньше и меньше.3 августа 2017 в 00:46
+1↑
↓
Полностью согласен. Очень многие вещи усваиваются с полпинка. Как вы сказали — это уже не та жесть, которую писали 10 лет назад.
ES6 для меня был как глоток свежего воздуха. Последующие стандарты только улучшают ситуацию.
Я думаю, что люди из других языков и парадигм нужны в JS сообществе. Способность посмотреть на вещи под другим углом может привнести (и зачастую, привносит) хорошие идеи.
3 августа 2017 в 00:17
0↑
↓
Но я думаю, что если JS не подходит для backend и он настолько плох — разработчики будут жаловаться
С чего бы это? Его в бекенд отнюдь не java/c#-гуру тащат, а вчерашние формошлепы, которые больше ничего другого не знают и знать не желают. Вот они конечно же всем довольны, а так как таких с каждым днем все больше становится, то никуда эта зараза уже не денется. Можно хоронить нормальный бэкенд, его уже не спасти.О чем речь, эсли эта хипстота свой жабаскрипт даже на контроллеры тащит? Типичный представитель, которому лень учиться и поэтому он все хочет писать на любимом js.
Я уже молчу про десктоп, который благодаря гигантской производительности сегодня готов простить пользователю даже «электрон».
3 августа 2017 в 02:03
+4↑
↓
Вы знаете, после бекенда на lua/java/c++ бэкенд на node js (es7–8) сплошное удовольствие.
erlyvideo
3 августа 2017 в 11:00
–1↑
↓
это первые 20 строк кода, просветление наступит позже. А луа конечно сравнивать нельзя: кошмар похлеще js
3 августа 2017 в 11:29
+2↑
↓
Не гребите всех под одну гребёнку. Фармошлёпов хватает во всех языках. Сам факт появления NodeJS (как и других библиотек/движков/языков) недвузначно намекает, что не всем нравится java/C# на бэкенде. Называть людей фармошлёпами только потому что они решили попробовать что-то новое, ИМХО, несправедливо.
И опять же — никто не забирает хлеб у Java/C# — в них тоже денег вливают неплохо. За ними тоже не кто-попало стоит. У всех свои ниши и NodeJS — не серебряная пуля, как, впрочем, и Java/C#.
