UPD: в статье JavaScript как мыслевирус @pnovikov оскорбил всё сообщество JavaScript, назвав их фанатиками. Как вы считаете, это этично? Не нравится JavaScript — пишите на TypeScript, CoffeeScript и т.п., никто не принуждает. По мне, большие фанатиков среди противников JS, посмотрите хотя бы на содержательную составляющую их статей. Юмор, эмоции, жалобы, но контента нет, они просто не профессионалы.
Лично я пишу на JavaScript уже 15 лет (в том числе, в должности старшего программиста Microsoft, а так же технического руководителя в своём бизнесе). Не то, чтобы это было какое-то достижение, уверен на хабре есть ребята с опытом и 20, и 25 лет, но уж совсем смешно, когда неофит ругает язык не разобравшись с преобразованием типов и пишет про это статью. Я искренне считаю JavaScript одним из самых мощных ЯП на сегодняшний день, поэтому не позволю неучам вводить читателей хабрахабра в заблуждение. В статье будет, по возможности, аргументированная позиция относительно основных тезисов критики. По правде, вышеупомянутая статья не стоит того, чтобы на неё отвечать, но у новичков действительно часто возникают проблемы с JavaScript. Вводит в заблуждение приставка Script и несерьёзный имидж языка, а на деле обнаруживается, что язык применяется от front-end и back-end до дескопных и мобильных приложений, программирования интегральных микросхем, обработки видео и в множестве других сфер. Я давно хотел раскрыть частые заблуждения про JavaScript, а тут как раз появился повод, поэтому welcome под кат.
На данный момент JavaScript — самый популярный ЯП на планете. Причина по которой JavaScript стал таким популярным (кроме монополии в веб) — его демократичность. Он позволяет программировать и в процедурном стиле, и в объектно-ориентированном и в функциональном. Он накладывает минимальные ограничения на разработчика, позволяя творить любую «глупость». Но ирония состоит в том, что то, что является глупостью применимо к одному классу задач, применимо к другому является более чем целесообразным. Легенда гласит, что JavaScript был создан за 2 недели. И опять ирония жизни, в таких условиях можно заложить в язык только самое главное, оставив за бортом всё лишнее, традиционное, «правильное». Первая версия языка получилась очень компактной и лаконичной. Все эти get/set, const и await появились гораздо позже. Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений. Конечно к этому были и негативные причины, политика Microsoft и Mozilla, многое другое, но, уверен, не многие из других популярных языков смогли бы пройти такое же испытание и подняться после этого. Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений. Причина по которой JavaScript выжил очень проста, он решает одну задачу и делает это идеально.
JavaScript не претендует быть синтаксическим сахаром или набором клёвых фич, их программист может написать/подключить и сам. JavaScript скрывает от вас аппаратную часть устройства, даёт возможность делать что угодно с логикой и просто оставляет вас с этим. Хотите eval — пожалуйста, хотите переопределить любой объект — нет проблем, хотите передать в функцию то, что «нельзя» передавать — welcome, потому что это «нельзя» только в вашей голове. Программистам на Go или C# очень сложно понять почему это хорошо. Чтобы не вызвать на себя их хейт, это прекрасные языки, просто другие. Классически в языках ставятся барьеры, не дающие программистам отстрелить себе ногу, это и проверка типов, и различные обязательные best practices, и многое другое. В JavaScript этих барьеров нет, вы в праве стрелять куда угодно, и в 0.01% случаев стрельба в ногу тоже имеет смысл. Это можно сравнить со спортивным автомобилем, у многих языков заблокирована часть функций, а в JavaScript — нет. Если вы водите плохо — возможно это для вас минус, опасности и т.п., но если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти. Для частных — можно, для общих, универсального — объективно нет. Многие возразят, мол в Java тоже можно создавать словари, аналог JS-объектов, Python и Ruby тоже не типизованные, много где есть и eval и duck typing, но применять это так просто, как в JavaScript не получится нигде. В Java, например, словари это только дополнение, приделанное на типизованную класс-ориентированную основу, а в JavaScript — это основа языка, и создаётся всего двумя символами "{}". Это как если бы в спортивном автомобиле форсаж вызывался не тремя кнопками и рычажком, а одной кнопкой под большим пальцем правой руки. Свобода не просто возможна, она поощряется.
Многих это вводит в ступор, потому что они привыкли, что им не дадут расшибить лоб. Это как переход с Windows на Linux. «Я ввёл sudo rm -Rf / и всё сломалось. Не система, а г… но». С такими рассуждениями путь до мастера будет очень долгим. Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались. Причём у человека может быть 20 лет опыта в Lisp, но по JavaScript он всё равно даже документацию не читал, типа и так умный. Этого достаточно, чтобы писать простые программы, но если человек хочет понять почему true < 2 === true, и почему это правильно и логично — прочитать про преобразования типов must have, а в идеале всю документацию (или хорошую полную книгу), это не долго.
Теперь отвечу на критику по пунктам:
Вопрос 1: однопоточный рантайм
Это очень удобно, не возникает проблем с блокировками и владением объектами и других прелестей многопоточности. Зачем вам нужна многопоточность? Выполнять программу дальше пока ждёте выполнения долгой операции? Колбеки справляются с этим гораздо лучше. NodeJS на одной средней машинке может держать по 100 000 коннектов. Сколько бы их было при замене колбеков на поточный подход? На многопроцессорных машинках js прекрасно параллелится запуском локального кластера. 8 ядер — 8 процессов, 16 ядер — 16 процессов, каждый независим друг от друга и прост внутри. Это реальный пример из практики применения, как главной серверной технологии онлайн игры с 8 миллионами пользователей. Работа с ассинхронностью/потоками это не слабость, а одно из мощнейших преимуществ JavaScript. Это может требовать переучивания и изменения привычек, но поверьте, вы приобретёте очень многое.
Вопрос 2: отсутствие единой системы / стандартов реализации модулей
В JavaScript два основных варианта работы с модулями:
- официальный, через import
- и традиционный, через require
Оба способа прекрасно работают, и полностью совместимы друг с другом. Вы можете выбирать тот способ, который вам больше нравится. Мне, например, больше нравится require, потому что его можно переопределить, и это больше соответствует философии JavaScript. Иногда это имеет смысл, например при написании своих препроцессоров. Почему я говорю, что два «основных» варианта, так это потому, что JavaScript сообщество открыто к любым новаторствам, и вы можете создать третью, четвёртую, тысячную систему работы с модулями (и многие уже создали). Другой вопрос, будут ли ей пользоваться за пределами вашего проекта. Описанные два способа являются де факто стандартом в веб-разработке, если вам интересны именно стандарты.
Вопрос 3: отсутствие единых стандартов структуры проекта (все творят как хотят, в исходниках бывает очень сложно разобраться)
Сочувствую вам с коллегами, которые «творят что хотят». Или коллегам с вами. В веб-разработке есть несколько типовых структур проекта, как правило используется одна из них, но это нигде не постулировано, и каждый действительно волен писать свою программу исходя из своего взгляда на целесообразность. А что вы хотели? Это самый популярный язык на планете, а не какой-то DSL. В разных сферах применения JS разные стандарты, и это правильно. Что касается практики, я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю. Нарабатывайте опыт и изучайте распространённые паттерны.
Вопрос 4: слабые типы с неявными (и порой довольно странными) преобразованиями
Странными для кого? Программистов Java, C#, PHP, Python, Lisp или Ams? Скажете asm не странный? А Lisp? Мир гораздо богаче вашего любимого языка и то, что для одних странно, для других норма. Посмотрите хотя бы на Haskell с его монадами и функторами (очень мощные штуки, кстати. В JS тоже используются, в jQuery). В институте этому не учили, правда? ООП это только малая часть мира, настолько малая и настолько заезженная, что даже скучно говорить. А типы в JavaScript не слабые, их принципиально нет (кроме примитивных). WeakMap и прочее ввели только для того, чтобы порадовать переселенцев из других языков. Перечитайте про duck typing и научитесь им пользоваться, проблем с типами у вас не возникнет.
Вопрос 5: отсутствие нормальных классов / ООП
Опять же, специально для переселенцев с других языков и для IDE уже довольно давно введены классы. Их поддерживают все основные браузеры, не говорю уже про NodeJS. ООП в JavaScript богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы. Во многих случаях правильного применения JavaScript прототипы оказываются быстрее, удобнее и логичнее, а программа компактнее и более читаемой. Но опять же, этому не учат в институте, а JavaScript сообщество должно потом доказывать, что так тоже можно.
Вопрос 6: отсутствие единого вменяемого и работающего статического анализатора кода (добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function)
Это общая проблема всех интерпретируемых языков с eval, и отказываться от этой мощи ради возможности ловить 5% самых глупых ошибок — сомнительная идея. А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Вопрос 7: отсутствие вывода типов в самом языке или в каком-либо инструменте
Это есть, изучайте синтаксис. Один из вариантов, в зависимости от ситуации:
typeof myVar
myVar.constructor
Вопрос 8: этот чудесный контекст this (что это значит this в этом месте кода — объект? функция?)
При правильном использовании проблем с this не возникает. Если вы вызываете функцию как myObj.func(), то можете быть уверены, что this будет равен myObj. При назначении колбеков или передаче функций как параметров, информация о myObj теряется и, если необходимо, следует задавать его явно через bind. Это логично и понятно знающим JS, так как вы, например, можете сделать так myObj2.func = myObj.func, и функция будет методом сразу нескольких сущностей. Не правильно назначать this равным myObj или myObj2, так как они симметричны. Не правильным было бы и использовать лексический контекст, так как это внесёт путаницу в миксины, прототипное наследование и многое другое. Поэтому this в таких случаях равен window или undefined, в зависимости от использования strict mode. Но это не должно вас волновать, и это принципиальный момент. Это один из типичнейших примеров стрельбы себе в ногу. На что вы надеетесь, вызывая this у функции, вызванной без контекста? Явно не на что-то хорошее. Есть много таких примеров, люди складывают массивы с числами, делят получившееся на объект и жалуются, что получают странные результаты. Во-многих странных вещах есть логика, но в особо странных это может быть просто произвол. JavaScript гибкий язык и позволяет вам делать то, с чем с C++ у вас программа даже не скомпилировалась бы, в надежде на то, что вы знаете, что делаете. Не нужно пренебрегать этим доверием и творить не весть что. Если вы хотите результат, то просто используйте this правильным логически обоснованным образом, а фразы а-ля «я воткнул себе нож в горло и у меня 2 раза потекла тёмная кровь, а 2 раза светлая, почему так?» оставьте для холиваров. И не надо хвастаться тем, что вы знаете чему в данной неочевидной ситуации равно this или как складываются несуммируемые типы. Профессионально правильной позицией будет, как ни странно, не знать это и не использовать, так как в разных браузерах и в разном контексте вы можете получить разный результат. Но JavaScript всё равно позволяет вам, если вы хотите это использовать, например для того, чтобы отличить PhantomJS c поддельным User-agent от настоящего Chrome — дорога открыта.
Вопрос 9: абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined
Два совета:
- не делайте логических ошибок. Ваши ошибки — не вина языка
- если хотите сделать регулярные выражения удобнее — используйте или напишите библиотеки. Похоже на то, что ругать C# за то, что он с Facebook не интегрирован. Руки есть, голова есть, напишите что хотите, или возьмите одну из многочисленных библиотек.
Вопрос 10: отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async (если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку)
И колбеки, и промисы, и async/await — нативные, поэтому код они не утяжеляют. Не знаю, что вы называете фьючерсами, я этим не торгую. И это прекрасно, что у вас есть выбор, что использовать. Колбэки это основа всего и ни промисы ни async/await без них не будут работать, это базовый кирпичик языка. Промисы и async/await прекрасно совместимы друг с другом и вы легко можете использовать await с любой функцией, возвращающей промис. Если же вы имели ввиду популярную библиотеку async для node, то сочувствую, ваши знания JS устарели. Библиотека хорошая, но используется всё реже ввиду появления вышеуказанного функционала в ES6. Но подтянуть её в зависимости на ноде тоже не страшно, серверные зависимости не отдаются пользователю и легко бекапятся, на случай удаления с npm (на моей практике такого не было ни разу). А ещё есть Fibers, и Sync, и много классных инструментов, используемых по назначению врача. Выбирайте тот, что больше подходит под конкретные задачи, и не жалуйтесь, что их слишком много.
Вопрос 11: const ( который на самом деле НЕ const )
Не знаю, почему вы так решили. Моя простая проверка в консоли показала обратное:
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
at <anonymous>:1:1
Но на самом деле так это или нет — не важно, const создан не для вас, а для интерпретатора. А вам не нужно без глубокого знания языка менять const. Тем более, что на разных движках/браузерах/устройствах этот функционал может работать по разному, и вполне возможно найти какой-нибудь холодильник, программируемый на диалекте JavaScript, в котором случатся ваши самые страшные кошмары. Язык то открытый и версий реализации великое множество. В браузерах данная ошибка не подтверждена.
Вопрос 12: абсолютно безумный npm, с пакетами качества «братишка я тебе покушать принёс»
Плата за свободу творчества и отсутствие премодерации. Проблема не большая, просто всегда смотрите на число скачиваний или звёзд на github. Качество топовых пакетов очень высокое. Мало популярные тоже бывают неплохие, бывают и такие, как вы нашли. Ответственность за используемые зависимости полностью на вас. Это открытое сообщество и никто вам жёванную пищу в клюв класть не будет. На мой взгляд, эта ситуация лучше, чем в решениях от одного поставщика/судьи, так как у библиотек сотни тысяч вендоров и тысячи из них очень достойные. Если хотите однообразия — посмотрите на решения, например, от Sencha. Они платные, но про них были вполне неплохие отзывы. В npm тысячи классных библиотек, но вам надо было найти плохую и выстрелить себе в ногу. Стреляйте, кто же вам запретит.
В JavaScript нет защиты от дурака, поэтому эта категория граждан набивала шишки, набивает, и будет набивать. В этой статье я постарался больше раскрыть именно философию и принципы JavaScript. Часто люди ждут от него того-же, что привыкли ждать от своего старого языка программирования. Но JavaScript имеет свой характер, и подружится с ним не сложно. Надеюсь кому-то эта статья была полезна.
Комментарии (253)
DeLuxis
04.08.2017 06:53+4Минус языка в том, что его невозможно на все 100% контролировать. Особенно с учетом всяких сборщиков, полифиллов, и прочих ES5 конвертеров.
Разные реализации в браузерах.
Второй минус, это производительность на стадии инициализации. Уже часто встречаются кривые сайты тормозящие при старте.
Третий минус, это низкий порог вхождения. Из-за чего часто сталкиваемся с ужасным кодом, опять же тормозными фронтами.
Все это выходит в виде потерь клиентов. У кого-то андроид слабый и не может просто отобразить страничку, у другого ошибки.
flancer
04.08.2017 07:03+7Минус языка в том, что его невозможно на все 100% контролировать.
несколько офтоплю, но… а что можно контролировать на все 100%?
wing_pin
04.08.2017 12:34+1Aссемблер конечно же
zharikovpro
04.08.2017 13:13Тогда уж не ассемблер, а машинные коды.
GrafDL
04.08.2017 13:36не, в кодах легче запутаться
zharikovpro
04.08.2017 13:40+1Тут речь шла про максимальный контроль, а не про «легче». Максимальный контроль дают самые низкоуровневые инструменты.
dplsoft
05.08.2017 03:24+3осмелюсь быть усыпанным минусами, но если под «контролировать» понимать «прогнозирование поведения программы», то имхо, к этому ближе всего java.
и это стоило очень больших больших усилий sun, а теперь стоит очень больших усилий ораклу.
и 100% обратная совместимость, и максимально возможная спека языка с требованиями к джава-машине с эталонным поведением.
Mysterious
04.08.2017 11:28+10Так не используйте сборщики, полифилы, трансплиттеры и прочую «камасутра кухню».
Одна из проблем JS, на мой взгляд — то что чьи-то фантазии и эксперименты, или узкоспециализированные штуки и точечные решения — на волне хайпа быстро поднимаются чут ли не до уровня стандартов и «ты обязан в этом разбиратся».
Кому-то мозолит отсутствие «его любимой фичи из другого языка потому что он привык кодить в таком стиле», и он обганяя стандарты ES запиливает трансплиттер. Кто-то терпеть не может скобочки или точки с запятыми. Есть любители «написать свой велосипед и назвать его фреймворком нового поколения».
По сути в последнее время развитие JS напоминает базар — кто громче кричит (за свой фреймворк) у того и покупают (берут как маст ноу).
Так это я о чем: JS сам по себе довольно шустрый и мошьный, но именно потому что его заставляют работать «как другой язык», загоняя в трансплиттеры и обвешивая фреймворками он так и тормозит.
Потому — не хотите терять клиентов — не насилуйте язык.
pm_wanderer
04.08.2017 14:36Придерживаюсь аналогичного мнения.
Только мой камень в огород фреймворков, сборщиков и транспилеров имеет немного иную форму:
Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
Найти человека, который знает javascript намного проще, чем выискивать уникальную смесь из скиллов, типа Vue, Redux, Gulp, LESS и т.д. Сообщество слишком раздроблено и объединять его надо под флагом чистого JS.
Я не ратую за революцию… я за реставрацию)Zenitchik
04.08.2017 15:02Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк
Я бы сформулировал иначе: не бойтесь переделывать выбранный фреймворк под себя, и через год-другой у вас будет свой фреймворк, заточенный под ваш проект.
У нас от выбранного некогда JavaScriptMVC не осталось камня на камне, все его элементы постепенно заместились своими.pm_wanderer
04.08.2017 15:21В таком случае проще сразу написать свой, чем переделывать чужое)
Там по сути не так уж много кода внутри: обсервер/медиатор и модули. Практически все фреймворки работают по этой схеме (правда некоторые предпочитают хранить стейт во внешней модели, а другие — внутри модуля в его замыкании, но это нюансы). Для CRUD-приложений еще может понадобиться некое подобие виртуального dom.
dplsoft
05.08.2017 03:50+7Напишите свой продукт один раз на JS и больше не понадобится переписывать его на очередной хайповый фреймворк по прихоти 23-летнего сеньера, который увлекся функциональщиной и теперь лоббирует очередной HaskellScript в продакшн.
напишите, ага) только есть пара-тройка особенностой иусловий для вашего проекта, что бы он стал успешным на какое то время на js:
1. он не должен иметь долгий жизненный цикл. потому что есть over 100500 причин, что он перестанет работать с заменой ядра движка в следующем поколении браузеров. никто не обещает обратной совместимости.
2. он должен быть маленьким. вы не сможете написать свой продукт, потому что верхний порог логики и сложности, который вы сможете контролировать в условиях динамической типизации не даст вам развернуться. я не говорю о таких «сложных» системах как курсовая, проект jQuery, или пошаговая ммо-игрушечка. я говорю о действительно вещах типа СЭД, учетные системы с историяеской отчетностью, хранилище данных, олап, и тд и т.п.
3. вам не стоит к нему возвращаться что бы рефакторить и добавлять в него фичи. потому что если вы создадите большого монстра, со ложной бизнес-логикой, то как только вы начнете рефакторить и модифицировать свой продукт (под влиянием времени, и изменния требований окружения) — вы поймете что «не успеваете». ни оттестировать, ни предсказать влияние ваших изменний. потому что прогнозировать влияние изменний в языке с динамической типизацией сложно. и typescript не панацея. потому что… где стандартна тайпскрипт и гарантия обратной совместимости? (см проблему 1).
а так, да, js, вполне прикольный, для маленьких здесь и сейчас задач. как прослойка скриптовапия компонентами, для задач, где где бизнес-логика примитивна, задачи прозрачные, а ответственность минмальна — самое то.
(не в конце концов, никто же не умрет, аэс не взорвется, поезда с рельс не сойдут, если ваш мега сайтик с оvер 8миллионов конекшенов просто подохнет, после обновлепия или какого иного чиха.
просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
это глупо.
а так… хайп кончится, будет новая мода. visualbasic, delphi, php, python, ruby, javascript… что из этого продержалось на волне популярности долго?..
raveclassic
05.08.2017 04:25никто не обещает обратной совместимости.
Если бы не было обратной совместимости, мы бы давно имели нормальный современный язык.
2.
Нет возражений. Язык явно не для этого.
3.
typescriptсм пункт 1
просто не надо думать что js может заменить, или тем более вытеснить джаву, c++ или ассемблер.
это глупо.Странно, что вы так думаете. никто не собирается никуда вытеснять ваши (наши) любимые плюсы.
будет новая мода
Казалось бы, "питон не брошу, потому что он хороший"? Да и пхп пока никто не списывает?
voischev
05.08.2017 11:40+1Второй минус, это производительность на стадии инициализации. Уже часто встречаются кривые сайты тормозящие при старте.
Я всегда думал что это разработчики должны контролировать – что 95% их кода при старте не нужно инициализировать.
viru0
04.08.2017 06:56-12Люто плюсую! JavaScript прекрасен. Зачем в него все таки классы притащили в упор не пойму. Прототипное наследование по-моeму в разы гибче и проще той же Java
rpsv
04.08.2017 08:42+12А чем классы от прототипа отличаются?
Разве class не просто языковая конструкция, которая сводиться к тому же прототипному наследованию?
Delphinum
04.08.2017 17:00+1А чем классы от прототипа отличаются?
Конструкция class декларирует семантику его экземпляров, а прототип является экземпляром и ничего более не декларирует. На практике это означает следующее:
1. class позволяет организовать проверку типов, а прототипам доступна только утиная типизация
2. class может наследовать семантику нескольких классов, прототипам множественное наследование не доступно (только миксины)
3. class может наследовать только классы, прототипом же может выступать любой объект
4. прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы
продолжать можно долго.Zenitchik
04.08.2017 19:41class может наследовать только классы, прототипом же может выступать любой объект
Это недостаток.
прототипам не доступны интерфейсы, то есть невозможно объявить семантики или абстрактные классы
Мы пробовали. Не взлетело.
Delphinum
05.08.2017 20:10+2Это недостаток.
Ну для кого то это недостаток, а для кого то существует паттерн Prototype, применимый в контексте class. Вопрос образования и опыта, только и всего.
Мы пробовали. Не взлетело.
Ну так я и говорю, что прототипам семантические объявления не доступны, можно было и не пробовать )
prostofilya
04.08.2017 07:32+1Забавно, исходные факты в обоих статьях одинаковые, а выводы абсолютно противоположные.
peter_m
04.08.2017 15:18+1Зона комфорта. :) Для тех кому привычна среда — это плюс, для других как минимум не комфортно.
franzose
04.08.2017 08:29+17Вводит в заблуждение приставка Script
А мне кажется, что в заблуждение вводит как раз таки
Javaв названии. Т.к. JavaScript к Java не имеет никакого отношения.KoCMoHaBT61
04.08.2017 11:01Это был мощнейший просчёт.
Если в те самые времена был VBScript как упрощенный Visual Basic, то JavaScript по логике, это упрощённая Java.franzose
04.08.2017 11:22+2то JavaScript по логике, это упрощённая Java.
Да никакая это не упрощенная Java. Хотя бы потому, что в JavaScript прототипное наследование, а это существенная разница.
А еще все почему-то забывают про язык ActionScript, который является одной из реализаций стандарта EcmaScript. С виду весьма неплохой язык (я на нём не программил) со статической типизацией (привет TypeScript), пакетами (привет ES6) и т.д. Если бы в своё время звёзды сошлись иначе, мы бы сейчас холиварили по поводу него, а не JavaScript, но нет)
KoCMoHaBT61
04.08.2017 16:16По моему очучению ActionScript монополизирован Адобом.
А люди, когда читают Java* подразумевают Java в основании, несмотря на то, что ничегошеньки общего (кроме сишных фигурных скобочек) с жабой язык не имеет.franzose
05.08.2017 01:28По моему очучению ActionScript монополизирован Адобом.
Так он и был. Наверное, если бы Adobe в своё время подсуетилась, сейчас писали бы по-другому.
Mysterious
04.08.2017 17:04+5Вот кстати отличнейший язык был. Особенно его применение вместе с FLEX — я пару лет проработал на нем. Очень жаль что он загнулся. Там было все и строгая типизация, и классы с наследованием и модули и кастомные компоненты и соккеты… и все это в 2007м… без всяких трансплитеров, сборщиков и конверторов. Кросплатформенность и защищенность кода. Единй компилятор и мощьнейшие возможности… помнил… любим… скорбим…
franzose
04.08.2017 08:32+6Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений.
C++ жил, жив и будет жить. Хотя стандарт очень долгое время оставался стабильным.
rboots Автор
04.08.2017 22:07-7C++ это легенда, а ваш пост только подтверждает то, что хорошие вещи не требуют частых изменений.
franzose
05.08.2017 03:18+2Отсутствие изменений — это стагнация.
rboots Автор
05.08.2017 12:15-4В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам. Это не стагнация, а единственно правильный путь. В информатике ситуация похожая и есть программы и библиотеки, не меняющиеся десятилетиями, но так как дисциплина очень молодая, не прожила ещё и одного века, то таких решений очень мало. Поверьте, через 100-200 лет никто не будет переписывать языки каждый год, а сформируют единый стандарт, который достаточно хорош и самодостаточен.
SirEdvin
05.08.2017 12:16+3В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам
Не-а. Почитайте, например, истории теории множеств. Там было несколько разных версий :) И так много где в математике. Просто оно менее заметно, чем в программировании, потому что там выпуск версии дольше тянется.
pnovikov
05.08.2017 12:21+3Молодой человек, в математике помимо теорем какбы вот… есть еще алгоритмы, которые время от времени ревизируются и меняются, разрабатываются новые версии, гибридизируются. Улучшать инструмент со временем — это нормально. Менять факты со временем — нет. Язык программирования — это не теория, подлежащая проверке или опровержению. Это инструмент решения задачи. Для него нормально периодически меняться. Вы же гвозди камнем не забиваете, верно? Камень, слава богу, успел за много лет развиться до молотка.
samizdam
06.08.2017 16:25Простите за занудство, но очевидно, что молот(-ок) как орудие появился, раньше гвоздей. Таким образом факт забивания гвоздей камнем противоречит логике. Не самая удачная аналогия.
А так разделяю вашу позицую.
franzose
05.08.2017 13:23+1В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.
Не думаю, что сравнение корректно. Стандарт языка не подразумевает единственного правильного пути для решаемых задач, он разрабатывается так, чтобы быть удобным при решении этих задач. Где-то максимально эффективно, где-то максимально быстро (в плане времени разработки), где-то максимально элегантно. К тому же время меняется, сегодня все любят быстро, модно и сахарно. Вот и C++ и решил к растянутому свитеру добавить что-нибудь из модненького.
Я бы провёл аналогию не с математикой, а с естественными языками. Посмотрите на латынь и европейские языки, из неё вышедшие. Латынь красива, помпезна, но достаточно сложна, чтобы быстро и кратко донести мысль. Другие же европейские языки пошли по пути упрощения в силу различных обстоятельств. И они продолжают меняться, это неизбежно. Поэтому я уверен, к этому
Поверьте, через 100-200 лет никто не будет переписывать языки каждый год, а сформируют единый стандарт, который достаточно хорош и самодостаточен.
вряд ли всё идет. Языки программирования, подобно языкам естественным, развиваются практически безостановочно. Потому что возникают новые идеи, относительно того, как сделать разработку быстрее и проще, возникают новые предметные области и задачи, которых раньше не было.
PsyHaSTe
07.08.2017 16:45В математике, если теорема один раз доказана, создатели не выпускают каждый год новую версию доказательства, а спокойно переходят к другом задачам.
Да, именно поэтому факт, что 0.(9) = 1 доказан только одним-единственным способо… А нет, не одним.
franzose
04.08.2017 08:37+5лучше языка чем JavaScript для общих задач вам не найти
Слова евангелиста, похоже. Вы видели тот же жирный Electron? Это всего лишь обёртка над Chromium, которая отжирает памяти мама не горюй.
Ну, а что до браузеров — так сложилось. Вместо JavaScript мог быть любой другой из семейства EcmaScript. При всём при этом я считаю JS нормальным языком. Сейчас на волне хайпа он еще обрастает новыми возможностями, так что писать становится приятнее)
franzose
04.08.2017 08:45+3Вопрос 11: const ( который на самом деле НЕ const )
Насколько я понял, там было про объекты. Мол,
constне делает объекты неизменяемыми. Но мне всегда казалось это и так понятным.
Gennadii_M
04.08.2017 09:17+1const не даёт изменить сущьность, на которую ссылается переменная. Если это примитив — то const относится к value, соотвтетственно string или number изменить нельзя. В случае с объектом — reference. Переменную с объектом нельзя переопределить, но всё, что внутри объекта остаётся изменяемым. По-моему тоже логоично.
franzose
04.08.2017 09:19+2Собственно, я об этом и написал.
Gennadii_M
04.08.2017 09:22+3Да. я так и понял. Просто малость расширил для тех, кто «который на самом деле НЕ const»
rpsv
04.08.2017 09:30+1Но по сути есть же Object.freeze, как по мне логично что const должен вести себя аналогичным образом когда применяется к объектам.
Gennadii_M
04.08.2017 09:37Вы имеете ввиду, что const к объектам должен применять, как Object.freeze и не давать изменять его поля?
rpsv
04.08.2017 09:51+1Ага)
По крайней мере я именно так понимаю выражение «константный объект».
Вроде так нигде не работает и это все мой воспаленный мозг, но все же хочется))Gennadii_M
04.08.2017 09:58value и reference говорят, что логично как раз так, как это щас работает. Ну, а, если хочется, чтоб совсем const, то есть freeze. Да и тот при переопределении свойства объекта не ругнётся, а просто не переопределит (без стрикт мода) )
Это ж философия js — дать возможность делать практически всё, что хочешь.
Да и const же только в ES6 заехал. Раньше и того не было.
Opaspap
04.08.2017 17:49+1на какую глубину?
africaunite
07.08.2017 11:37вот дельное замечание, кстати.
я уж не спрашиваю про инициализацию и прочее, банально объясняющее такое поведение в любом языке, поддерживающем парадигму объекта и доступа к нему по ссылке
hubhito
04.08.2017 15:33-1Суть в том что переменная — это не объект. Переменная — это всегда указатель, преобразование «строка» -> «адрес в памяти». И const фиксирует это преобразование, а не данные.
Keyten
05.08.2017 18:08А я так понял, что речь про ускорение с помощью const. Ну типа, в компилируемых языках const имеет только одно отличие от других переменных — компилятор на момент компиляции проверяет, не хочет ли кто его переопределить. Т е. по скорости никаких отличий.
(или даже — где-то встречал, что const — это аналог #define, который считается в момент компиляции и подставляется препроцессором)
В js же const ставит специальный флаг у переменной, и интерпретатор наоборот должен тратить доп. ресурсы и следить, чтобы эту переменную никто не изменил.
rpsv
04.08.2017 08:49+10Вопрос 11: const ( который на самом деле НЕ const )
Не особо вы ответили на этот вопрос, ошибка у вас выпала о невозможности заново объявить переменную (если бы убрали const упала бы нужная ошибка).
А имелось ввиду, что const не работает с объектами.
Код ниже вполне ок работает без ошибок (в браузере по крайней мере):
const a = { b: 1 } a.b = 2
А вообще основная претензия к JS, то что он все разрешает, а основной аргумент автора данной статьи в том, что «сам дурак, не фиг в ногу стрелять».
По такому принципу любой язык хорош, если в нем разобраться.
Язык который ставит ограничения ЗАСТАВЛЯЕТ программиста писать как надо (либо бежать в ужасе), и тем самым повышает профессианализм самого программиста т.к. приходится решать задачи с ограниченным набором инструментов, которые позволяют сделать правильно (не факт, но все же).
А т.к. JS позволяет делать все, программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто.Odrin
04.08.2017 11:46+9А имелось ввиду, что const не работает с объектами
Ссылка на объект не изменилась, const работает как и должен.
программисту чтобы написать нормальный код нужно читать мануалы и книги, это не круто
Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.rpsv
04.08.2017 11:59+1А имелось ввиду, что const не работает с объектами
В другой ветке это обсуждают, там интереснее)))
Читать мануалы и книги — это единственный способ программисту писать хороший код. Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
Вообще не согласен.
Можно прочитать все книги и мануалы по конкретной теме, но нифига в ней не разобраться.
А можно делать правильные вещи, не зная что ты используешь какой-нибудь паттерн.
Если человек не читал книги, но сам допер как нужно делать правильно, неужели он не является хорошим программистом?
Немного странная логика
Особенно веселят теоретики-отличники — это прям победа.
Прочитали кучу книжек, типа умные, а вот руки к сожалению (или к счастью) не из того места растут.GrafDL
04.08.2017 12:51+1Даже очень умный человек, который сам додумался до какого-нибудь паттерна, может почерпнуть в книгах идеи, о которых он и не думал, и начать их пробовать и применять. Мы ведь за этим и заходим на хабр.
rpsv
04.08.2017 15:50+1Человек может подчерпнуть новые идеи не обязательно в книгах.
Почему у всех книги это панацея?!
Книга написано конкретным автором (иногда несколькими), у которых свой взгляд на вещи, и своя точка зрения.
По вашей логике, чтобы было прям совсем круто, нужно прочитать книги нескольких авторов, с разной точной зрения, чтобы быть красавчиком, однако пока вы будете погрязать в чтении книг, некоторые/многие моменты уже устареют.
Я не против изучения новой/другой информации, а против чтения книг ради этого.
В чем проблема: в книге написано много всего, с кучей воды и, опять-таки, с одной точки зрения.
Рассмотрим конкретный пример/случай из жизни: нужно изучить паттерны, чтобы разрабатывать «правильно».
Я не бегу скачивать книгу Фаулера, я иду в гугл и вбиваю: «паттерны», «паттерны веб-разработка», «паттерны JS» и т.д.
То есть я не трачу время на изучение всего подряд, что мне может-быть когда-нибудь пригодиться, я ищу конкретные вещи.
Да я понимаю, что статьи и советы других людей это в большей степени аккумулирование книг, НО если после прочтения книги, мной будет усвоена часть информации (а так чаще всего и бывает, а пригодиться еще меньше (скажем 25% из книги мной было усвоено и пригодилось в жизни), то какой смысл мне читать ВСЮ книгу?
rpsv
04.08.2017 12:11А как вы интересно относитесь к дистанционному обучению?
GeekBrains или Hexlet?
Окончание таких курсов тоже показатель крутости программиста и без наличия их сертификатов человек не может стать хорошим разработчиком?
Че-то пришла гениальная мысль:
Недостаточно читать книжки, чтобы быть хорошим программистом.
Чтобы стать хорошим программистом, необходимо читать книжки/статьи/слушать советы опытных ребят.
franzose
04.08.2017 13:39+1Не круто — это когда кто-то считает себя разработчиком, ничего при этом не читая.
Чукча не читатель, чукча писатель, ага)
GrafDL
04.08.2017 12:48Это очень субективное мнение, как и критерий «правильности». Я вот, например, терпеть не могу когда язык нянчится и не дает мне сделать то, что я хочу. Если я знаю что делаю, то я не хочу бороться с компилятором.
Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.
По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.rpsv
04.08.2017 15:58+3Это очень субективное мнение, как и критерий «правильности». Я вот, например, терпеть не могу когда язык нянчится и не дает мне сделать то, что я хочу. Если я знаю что делаю, то я не хочу бороться с компилятором.
Язык — это лишь инструмент. Не нравится, используйте другой. Но опять-таки, не нужно думать, что ограничения придуманы просто так.
Решение задач единственным способом к развитию вообще не имеет отношения. Наоборот — это ограничение выбора.
Почему люди так критично относятся к ограничениям?
Ограничения нужны не для того, чтобы как то ущемить программиста, а для того чтобы он не сделал себе больно.
А написать пару лишних классов, которые в будущем облегчать вам возможность изменений (а точнее расширение функционала), для вас наверное моветон?
По последнему предложению вообще забавно. Мануалы как раз нужны, когда на каждый чих надо искать то самое единственное «правильное» решение.
Про мануалы я погорячился, они как раз таки самый нормальный источник информации. А про книги тут.
KasperGreen
04.08.2017 14:43+1Пожалуйста не кричите на меня. То, что не делается правильно, может делаться левельно (за счёт мастерства и глубокого понимания происходящего)(в основе юмора английское слово Level которое ты и так знаешь %username%). И это здорово — можно не вставлять квадратное в треугольное в угоду правильности и закостеневшим в мозгу паттернам.
Я не пытаюсь сказать, что паттерны это плохо, а лишь намекаю на волновую структуру жизненного цикла [людей и программ]. Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу. Послезавтра, когда надоест танцевать на граблях, снова примешь чью-то новомодную методу. Далее по синусоиде, но уже с пониманием того почему ты использовал этот паттерн и почему именно таким образом. А дальше ночь, улица, фонарь, аптека…
Автор соседнего поста ругает ES8 за низкий порог входа, но ПМЛМ это зря. Язык разрабатываемый десятком светил до которых не достать, может быть сколь угодно крутым, но что толку если программирует на нём всего сотня-другая людей?
PHP в своё время взлетел и стал очень популярен из-за своей доступности. Достаточно было скачать бинарники, написать в командной строке
php file.phpв котором написано<?=6*7?>и получить ответ 42. Ну или можно поставить себе локальный денвер и байбай консоль, теперь можно результаты вписывать в разметку\оформление. Красиво. А до него был Perl.
Сейчас вообще ничего скачивать не нужно и файлов создавать тоже. Жмёшь заветные ctrl + shift + i, пишешь
2**10и получаешь 1024 в ответ! Даже знать о том, что пишешь наJSES не нужно. А стоит узнать о том, как пользоваться переменными и всё — ты программист. И тут я понимаю всё негодование тех кто отучился не один год, чтобы написать свой первый хеловорд. Такая щемящая несправедливость просто, обязана не давать им покоя.
Интерпретируемые языки имеют отличную от компилируемых парадигму разработки. Если для компилятора ты готовишь свою программу, пишешь, потом ещё пишешь, потом исправляешь и только потом компилируешь и наслаждаешься результатом. То в интерпретируемых скриптах мелкоитеративный цикл разработки, в котором ты смотришь на результат во время программирования (привет LiveReload), сверяя его с тем чего ожидаешь.
Сделав изменение в одну букву, можешь сразу посмотреть результат и убедиться, что всё идёт так как задумано. В таких условиях недостатки отсутствия строгой типизации вываливаются сразу, а не накапливаются и выдаются в качестве непредсказуемых результатов после компиляции. Если складываешь цифру со строкой, то заметишь, что в результате у тебя не цифра. И это здорово. Пишешь интуитивно и лаконично. Сразу получаешь результат.
А если с типом накосячил в компилируемом языке, притом в не очевидном месте, то можно провести не один час в поисках ошибки которую допустил час назад и строгая типизация тут и вправду помочь может. Но что, тебе поможет если ты перепутал две очень похожие функции, тем более если они отличаются в названии всего одним символом? Статическая типизация, компиляция, строгие правила — не панацея. Если ты достаточно везуч и любознателен, ты найдёшь способ выстрелить себе в ногу, даже если разработчики языка всеми силами стараются этому помешать.
Но если ты хочешь программировать здесь и сейчас то, JS твой почти безальтернативный выбор. И помни, что наговнокодить можно на любом языке и только годы практики и танцев на граблях отделяют тебя от чистого кода (совершенного кода кстати не бывает, это вектор, а не точка). И на чём бы ты ни писал, год за годом ты будешь смотреть на свой код, написанный год назад и мысль — «Что за говнокод?», тебя не покинет.
ЗЫ всё это моё личное мнение, я не учился в институте и руководствуюсь только своим опытом разработки на PHP/JS. Ну а то, что я так и не написал своё первое приложение на C++ это потому, что [irony]С++ плохой и сразу не работает[/irony]
KasperGreen
04.08.2017 16:06+1Похоже слишком простыня вышла, извините за то, что вам пришлось читать этот поток сознания.
Если коротко:
Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
Gennadii_M
04.08.2017 16:44+2Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.
rpsv
04.08.2017 16:56+3Сейчас ты упарываешься по паттерну и делаешь всё правильно (хотя и не понимаешь почему именно так правильно). Завтра упираешься в его углы и начинаешь мыслить за пределами его границ и получаешь свободу, в том числе выстрела в ногу
Если вы выходите за границы паттерна, то это уже ошибка.
Паттерны не делают вас тупее, они говорят как надо делать правильно (никто не машает вам разобраться почему именно так правильно).
А если вы выходите за рамки паттерна, значит уже делаете что-то не так.
Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
А каким образом это сделает мир лучше?
Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?
Сомнительная польза для мира, да и для разработчика.KasperGreen
04.08.2017 17:41-2Даст кучу «разработчиков», которые могут использовать язык как калькулятор и писать Hello World?
Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.
Слово переменная для них будет ассоциироваться не с погодой, а цикл станет не менструальным. Что в конечном итоге даже если они будут писать калькуляторы сделает их жизнь чуть проще, а они хоть и не большая, но часть мира. И если чуть лучше им, то чуть чуть лучше миру.
И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.
Как по мне, то основы лучше осваивать не на js. А низкий порог входа означает низкое качество кода в целом.
Возможно если поставить себе цель стать программистом то есть более подходящие языки.
Но у меня такой цели не было например. А была цель не править шапку сайта с играми в локалке на каждой странице и для решения этой задачи подошёл PHP с его include(), а потом ещё были задачи и он тоже отлично подходил.
Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее. Это была чужая прога и в исходниках не сказал бы, что удалось разобраться. Вся остальная часть сайта продолжала работать на PHP/MySQL и с этими задачами язык продолжал прекрасно справляться. Потом для решения задач понадобился JS и сейчас на нём писать классно.
А низкий порог входа означает низкое качество кода в целом.
В целом конечно. Но кто вообще это целое видел и зачем?
Я полагаю среде JS хватает высококлассных программистов которые пишут качественный код и могут на ревью джунов подтянуть.
Но от того, что нубы марают светлое лицо языка кому от этого хуже кроме статистики?
Если есть софт который написан некачественно, и софт которого нет — какой лучше?
rpsv
04.08.2017 18:08+2И это не означает, что от этого станет классно всем разом на планете. Те кто не хочет, чтобы им было классно, могут оставаться в том расположении духа которое им по душе.
Как то вы слишком крутите и филосовствуете.
На хрен это надо?
Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.
Этакий язык Шредингер — может все в теории, пока не проверишь на практике.
Даст кучу «разработчиков» которые сами смогут решать свои задачи и не отвлекать «других разработчиков» по пустякам. Или смогут лучше объяснить, чего они хотят от других разработчиков если сами не справятся.
Я могу показаться немного адольфиком, но все же.
Если уже есть куча говнокодеров, которые прошли курсы, прочитали пару статей и книг, и считают себя программистами, то это не значит, что нужно вносить свою лепту в эту кучу говна.
Но когда стало нужно держать миллион коннектов, PHP оказался слоном и прога написанная на C++ работала в миллион раз быстрее.
PHP для веба, а не для highload.
Все почему то этим упрекают РНР и говорят, что он говно.
Но по факту РНР и не для highload.
Как по мне, то нода тоже вряд ли справиться с такой нагрузкой.
Но это, как говориться, не точно.
Если есть софт который написан некачественно, и софт которого нет — какой лучше?
Очень и очень плохая позиция.
Где то рядышком с «зачем трогать если работает?».
В некоторых, не побоюсь даже, во многих вопросах пусть уж лучше нет ничего, чем кривой табурет с педалями на одной ножке.KasperGreen
04.08.2017 18:40-1Не нужно говорить что JS крутой язык, универсальный, может все и всегда, а по факту используется только в вебе, во фронтенде и периодически на бекенде.
Соглашусь JS крутой язык (моё субъективное мнение). Насчёт остального не от меня информация. Можно действительно многое. Но я нынче фронтенд программист, поэтому не искушён в забраузерных возможностях. Но в браузере оно будет работать без установки, на любой платформе где есть браузер. Без компиляции и скачивания инсталяторов. Кроссплатформенность — это круто.
От себя скажу, что написав функциональность на клиенте со сборкой SVG, я конечно не мог принимать результат на бэкенде. Там пришлось написать нечто похожее, принимающее только исходные настройки и повторяющее из них то, что видел в браузере пользователь. Это было проще чем фантазировать как победить XSS. Если бы на бэкенде тоже был на JS, то мне не пришлось бы после каждой правки переписывать и тестировать обе версии.
Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.
Я могу показаться немного адольфиком, но все же.
Это не круто.
пусть уж лучше нет ничего, чем кривой табурет с педалями на одной ножке.
Для того кто его сделал быть может он нужен (мало ли шоу какое устраивает), а ты можешь его не замечать и для тебя его не будет.
Но ты предпочитаешь замечать и выбиваешь у шоумена табурет из под ног потому, что табурет не правильный. Надеюсь у шоумена не было петли на шее. Извини, опять филлосовствую.
А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.
Мне кажется вообще все мастера из всех областей начинали с «куска говна» который потом выбрасывали, чтобы сделать новый «кусок чего-нибудь».
Отрывать им руки за первый блин, по Адольфски.
rpsv
04.08.2017 18:52Это я к тому, что повторно использовать код, а не писать велосипеды и на клиенте и на бэкэнде — это круто.
Вот все про это говорят, а кто нибудь может привести пример?
Это мой реальный интерес, очень часто слышу как достоинство JS + Node.js, но по факту это маловероятно.
Frontend — это абсолютно событийно-ориентированное программирование. Только события, ничего более.
Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
Ваш пример про SVG вполне можно перенести, но вот часто ли такое случается?
А тем временем человек сделавший табурет, может (если ты конечно уже не успел его линчевать) в следующий раз учесть ошибки проектирования и сделать табурет который тоже будет говном, но не вонючим. А потом новый, следующий, ещё один, сто пятый и наконец классный.
Абсолютно согласен.
И это применимо ко всему.
Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
И это опять такие мое, и думаю не только, мнение.KasperGreen
05.08.2017 03:27Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
И в результате получить 42
По мне так вызов метода API это уже событие. Да, что там вызов метода. Запуск программы это тоже событие! А передача ей входных данных, ещё какое событие! Наступление определённого времени? Достижение конца файла? Подключение с определённого IP? Без тех или иных событий смысл в программировании сомнителен.
Или вы под событиями только onClick понимаете?
Вот только речь здесь про то, что говняных табуреток с JS будет больше, чем с каким-нибудь C#.
И это опять такие мое, и думаю не только, мнение.Сложнее станет выбирать себе поверхность без наклона? Или от них место в интернете закончится? С мнением я не спорю. Спорю скорее с тем, что взывает вас к сжиганию всего, что расходится с вашим чувством прекрасного.
raveclassic
05.08.2017 03:33Backend — разве это событийно-ориентированное программирование? Как по мне, бэкенд можно спокойно разложить в последовательный (синхронный) порядок выполнения.
Смотрели CQRS + Event Sourcing?
rpsv
05.08.2017 20:29CQRS
Это вообще не про события
Event Sourcing
Ну, а также есть другие способы работы без событий.
Я к тому, что МОЖНО на событиях организовать и бизнес-логику, и весь бэкенд, вот только на сколько это адекватно?raveclassic
05.08.2017 20:36Вполне адекватно для больших систем
rpsv
05.08.2017 20:42Нуууу, большого опыта в разработке больших систем у меня нет, а который есть никуда не годиться, но все же я думаю когда на выполнении одного экшена цепляется 10-20 событий, то отлаживать это достаточно трудоемко.
Не считая того, что события в моделях (бизнес-логике) я считаю вообще не должны быть.
Но это отдельный разговор, и кто я такой чтобы навязывать свое мнение)))
Delphinum
05.08.2017 21:20Можно увидеть сорцы хотя бы одной крупной системы на ноде с Event Sourcing архитектурой?
raveclassic
05.08.2017 23:19Разве кто-то говорил про ноду? :)
Ну и подозреваю что сорцов таких систем в открытом доступе нет.
А то, что я читал по этой технологии — это все .net, если кто поделится примерами под другие платформы, буду только радDelphinum
06.08.2017 00:38А разве речь не про ноду? Если нет, то хороший пример такой системы это 1С. Правда терминология немного другая:
* Регистраторы = Event
* Регистры = Events Store
* Агрегаторы = Snapshot
Говорят еще Redux работает в том же духе.
В остальном самому интересна эта тема, частично даже применяем, но есть много минусов.rpsv
06.08.2017 08:04Ну раз уж на то пошло: а какие минусы возникают?))
Delphinum
06.08.2017 11:56Чтобы было более понятно, на минусы этого решения надо смотреть с точки зрения идеальной реализации, а это:
1. Довольно ресурсоемко — далеко не везде вам требуется хранить историю событий, приведших к текущему снимку состояния сущности, а значит, вы будете тратить ресурсы впустую
2. Сложно в тестировании — возможно тут проблема больше в инструментарии, нежели в решении, но такую систему сложно тестировать модульными тестами, и просто сквозными
3. Новичкам взрывает мозги — для работы с такой системой нужно быть теоретически подкованным, иначе становится довольно сложно разбираться во всех этих неявных связях (немного помогают графы состояний и взаимосвязей компонентов в виде схемы)
4. Сложность в реализации — событийная модель накладывает одно серьезное ограничение на архитектуру, она: «асинхронна» — на деле это означает, что вы не сможете выполнять синхронные операции над доменом, к примеру: «пользователь заполняет тест и сразу получает результат анализа»
Есть и другие пункты, я просто их не могу пока припомнить. В остальном решение интересное, если его хорошенько изучить и правильно применить. По сути это паттерн «Команда», только немного в иной обертке и с другой областью применения, но с теми же плюсами и минусами.
KasperGreen
05.08.2017 04:00Вот все про это говорят, а кто нибудь может привести пример?
Лично сталкивался только с примером для SVG, но сферически могу предположить:
- Балансировку нагрузки между клиентом и сервером;
- Преобразования форматирования для вывода на сайте или отправки электронных писем с сервера;
- Генерацию\верификацию открытых\закрытых ключей;
- Можно рендерить страницы на сервере и отправлять в IPFS;
- Писать проверки данных на клиенте и использовать тот же код на сервере, чтобы не дать клиенту на эти проверки повлиять, но не плодить запросы к серверу;
- Давать клиентам возможность на себе выполнять абстрактные операции, а по подписке принимать их на сервер;
- Comming soon…
franzose
05.08.2017 01:32Низкий порог входа это здорово. Так больше людей сможет научиться основам программирования. Это сделает мир лучше.
С одной стороны, да. А с другой — рынок наводняется неквалифицированными специалистами, из-за чего общая ценность этого занятия падает.
KasperGreen
05.08.2017 02:52Сомневаюсь, что это негативно повлияет на ценность высококвалифицированных специалистов.
bini1988
04.08.2017 15:27+1Код ниже вполне ок работает без ошибок (в браузере по крайней мере):
const a = { b: 1 }
a.b = 2
Все верно, однако присваивание a = {} выдаст ошибку, что вполне очевидно, на мой взгляд. С объектами const гарантирует, что ссылка будет всегда указывать на заданный при объявении объект. Для объектов с неизменяемыми полями следует смотреть в сторору Object.freeze().
akuzmin
04.08.2017 16:40В JS можно сделать разные виды «правильности», очень непохожие друг на друга. Это зависит от задач. Сравните, например, Angular приложение, написанное на ES6 (или Angular2 на TypeScript), и какой-нибудь jQuery-Plugin пятилетней давности (ну для кастом-скролла, например), написанные в одном файле на прототипах. Это как абсолютно разные вселенные со своими, иногда очень строгими правилами, но работающие в том же пространстве JS как механизма, который позволяет «очень много». В этом и есть главная сила JS.
VladVR
04.08.2017 23:27А имелось ввиду, что const не работает с объектами.
Можно спросить у автора, что имелось ввиду, он даже здесь отметился.
Я рискну предположить, что const должен быть константой на все время работы приложения. То есть это реально должна быть константа. Как например в языке C#. const же в javascript работает так как readonly в С#.
То есть в функции вы можете написать const a = weatherOnMars === 42? 4: 2; И при первом выполнении функции a будет 4, при втором 2. То есть, по сути своей это не константа вовсе. В функциональных языках именно так себя ведет var(могу ошибаться).
Keyten
05.08.2017 18:12На любом языке можно написать фигню.
Например, мне может захотеться сделать в плюсах #define true false, и писать исходя из этого. Или я могу захотеть сортировать массив пузырьком, чтобы найти максимум.
Так что читать мануалы и книги действительно нужно. В любом языке.
Gennadii_M
04.08.2017 09:21+3имхо: у js много неочевидных особенностей, отличающихся от других языков. Но, если понимать, как работает язык, то можно писать вполне хороший код. Проблема в том, что не все хотят копать внутрь и разбираться. Ну и низкий порог входа пораждает множество низкокачественного кода. А налажать в js очень легко )
Nimo_tsi
04.08.2017 15:28Потому что в JS приходит много школьников-верстальщиков, которым не хватает возможностей jquery и bootstrap.
k12th
04.08.2017 09:26+8Можете наследовать через классы, можете через прототипы.
Тот неловкий момент, когда забыл, что классы в JS работают через прототипы...
GIum
04.08.2017 10:25+1Тут разница в подходах. Когда говорят про прототипное наследование предполагается, что можно наследовать один объект через другой без создания классов:
const proto = { hello () { return `Hello, my name is ${ this.name }`; } }; const george = Object.assign(Object.create(proto), { name: 'george' }); console.log(george.hello());
И это порой очень гибко и удобно. С таким подходом, например, вы можете сделать factory, которая будет отлично альтернативой классам (и многим это нравится из-за отсутствия необходимости писать
new)
const greeter = (name) => Object.assign(Object.create(proto), { name }); const george = greeter('george'); const msg = george.hello();
И надо понимать, что именно это базовый подход в js для наследования. А классы, которые используют под капотом этот же механизм просто вариант для тех, кто не видит наследования без них.
Gennadii_M
04.08.2017 10:46+2Я далеко не гуру js, но обращаться в методе hello к this.name, которого нет, подразумевая, что потом где-то дальше будет Object.assign, в котором будет объект со свойством name — это уж сильно неочевидно…
flancer
04.08.2017 11:04Да, это инерция объектного подхода к программированию. Мне тоже тяжело давалось (и до сих пор дается) понимание что javascript'овый this — это не надежный java'вский this, а что-то ближе к сишным указателям. Отметил тенденцию, что все чаще встречается мысль, что можно и совсем без this в JS'е обходиться. Не спрашивайте как — я тоже далеко не гуру в JS :)
k12th
04.08.2017 11:35Да тут уже была статья на этот счет, в комментах хором сказали «а собсно зачем»? Да, он не везде нужен и много где можно без него, но насильно отказываться смысла нет. ООП и в частности инкапсуляция придумана не дураками и имеет свои удобства. Серебряной пули нету, надо уметь сочетать парадигмы:)
novice2001
04.08.2017 09:29+17Ну, что можно сказать?
Автор повторил свои мантры 3-летней давности о том, какой JS замечательный, мощный и безграничный (в смысле отсутствия границ для программиста: хочешь — стреляй в колено, а хочешь — в лодыжку) язык. Конечно, если ты идеальный (сферический в вакууме) программист, каковым себя автор, похоже, и считает. Хотя в его первой статье на хабре его поймали на том, что он сам толком не знает деталей поведения языка.
Я — не профессиональный программист. Но считаю, что ценность языка программирования должна заключаться не в том, что он позволяет тебе застрелиться бесконечным количеством способов, а в том, чтобы с его помощью можно было написать программу с минимальным количеством ошибок, привлекая для этого многочисленных разработчиков средней квалификации, а не редких и дорогих гуру, познавших дзен JS.oleg_gf
04.08.2017 12:54-3Популярность JS говорит о том, что возможность написать программу (привлекая для этого кого-попало), которая работает, невзирая на ошибки, ценнее возможности написать программу с минимальным количеством ошибок, привлекая для этого многочисленных разработчиков средней квалификации.
novice2001
04.08.2017 13:07+2Только вот сфера применения таких программ будет весьма ограниченной. Ну, сломалась веб-страница — и фиг с ней. Она же не ядерный реактор и не ракета-носитель в конце концов.
Но автор-то позиционирует язык как универсальный, пригодный для любых сфер применения.rboots Автор
04.08.2017 15:40-1Вы пишите, что не программист, и при этом ругаете язык. Любите критиковать то, в чём не разбираетесь? Автор написал тонну текста и сделал пару описок, это вы называете незнанием деталей языка, а вы что знаете? Кто вы, менеджер, дизайнер, кто-то ещё? Я руководил программистами на JavaScript и средние программисты с ним справляются прекрасно, достаточно дать им наставления как можно делать, как нельзя, и составить базовую архитектуру. У JS очень низкий порог входа, что даёт возможность посадить кого угодно и научить его делать хорошие вещи, вся сложность языка закрывается на уровне технического руководителя. Ваши жалобы идут или от теоретизирования, или от невежества, не можете руководить программистами — меняйте профессию.
TimTowdy
04.08.2017 15:54+1Я руководил программистами на JavaScript и средние программисты с ним справляются прекрасно
Понимаете, в данном контексте «прекрасно» это сравнительная характеристика. «Прекрасно» должно быть не само по себе, а по сравнению с чем-то. Если бы вы руководили программистами на других языках, и они справлялись менее «прекрасно» с аналогичными задачами, тогда можно было бы о чем-то говорить. А у вас получается аргументация «я пишу на JS, больше ничего не знаю и знать не хочу, но меня все устраивает». Лично для вас этот аргумент конечно работает, но для остальных выглядит неубедительно.
novice2001
04.08.2017 16:12+5Вы пишите, что не программист, и при этом ругаете язык. Любите критиковать то, в чём не разбираетесь?
Я пишу, что я не профессиональный программист (т.е. что не зарабатываю этим себе на жизнь), а не то что я не программист.
А профессиональный программист (как, впрочем, любой инженер вообще) просто обязан пользоваться максимально точным языком. Хотя, возможно, долгое использование JS могло вызвать такой эффект.
Так вот, я не менеджер и не дизайнер. Я инженер-системотехник, специальность «Вычислительные машиины, комплексы, системы и сети». Поэтому чуть-чуть разбираюсь в теме. И критикую я не язык, а необъективное его восхваление. Как уже было написано до меня, JS — замечательный язык для той сферы применения, для которой он был изначально создан. Не более того.
Автор написал тонну текста
Автор написал даже 2 тонны текста — 3 года назад и сейчас. И, по сути, ни одного аргумента почему JS восхитителен кроме «могу писать как хочу» так и не привел.
и сделал пару описок
Описки — в письме, здесь могут быть опечатки. Но приведенный пример — это именно ошибка.
А ваши жалобы идут
Это не жалобы, и они, соответственно, никуда не идут. Это констатация фактов.
Keyten
05.08.2017 18:26Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.
Keyten
05.08.2017 19:20Автор вовсе не говорил, что возможность застрелиться большим количеством способов — непревзойдённое преимущество. Автор говорил именно о свободе действий — да, в том числе и свободе стреляться.
Дабы не быть голословным, покажу код.
Есть у меня библиотека для рисования на канвасе DeltaJS (ранее известная как Graphics2D.js, я даже писал о ней на Хабре). Сейчас она в фазе активного переписывания и дописывания, и её можно найти вот тут: https://github.com/keyten/Graphics2D
В ней можно создать квадрат на канвасе:
ctx.rect(10, 10, 200, 200, 'red');
Каждая из координат прогоняется через функцию `Delta.distance`.
Вдруг в какой-то момент разработчик вспомнил, что существует Ретина, и захотел рисовать квадраты с шириной не в px (пикселях), а в pt. Что ж, он делает так:
var oldDistance = Delta.distance; Delta.distance = function (dist) { if (isPtDist(dist)) { return convertPtToPx(dist); } return oldDistance.apply(this, arguments); }
И всё, благополучно можно писать
ctx.rect('10pt', '10pt', '200pt', '200pt', 'red');
Вообще-то все css-единицы итак поддерживаются в Delta, однако distance всё ещё может быть переопределение, чтобы добавить, например, полярные координаты или какие-нибудь специальные координаты в условиях специального Layout. По факту, distance специально вынесена как публичная функция, чтобы её можно было переопределить, тем самым вмешавшись в логику всей библиотеки, меняя лишь маленький кусочек. Требование при переопределении одно: возвращаться должно число. В пикселях.
Если мне понадобится что-то более существенное, например, изменить порядок аргументов функции или добавить новые, я могу переопределить Delta.Context.prototype.rect.
И подобных точек вмешательства несколько. Можно вмешаться в логику attr (Delta.Drawable.prototype.attr), добавив или изменив своё в attrHooks. Вмешаться в логику событий через eventsHooks. Через тот же attrHooks вмешаться в логику animate.
Обсуждая это с людьми, пишущими на плюсах, я спросил, как с этим справляются они. Что, если захочется добавить дополнительный параметр в std:sort или научить новому методу std:string?
Никак — ответили мне. Так ты можешь только выстрелить в ногу.
Но… — попытался возразить я.
Никаких но. Нога.
Между тем, jQuery таким образом существует уже фиг знает сколько лет. Со своими плагинами и многим другим. Ты можешь добавить на страницу сто плагинов, которые вмешиваются во внутреннюю логику jQuery и меняют разные куски, и — внезапно окажется, что у кода на js настолько большой запас прочности, что это всё будет отлично работать и синхронизироваться друг с другом, делая ровно то, что ты от них ожидаешь. Даже если меняют ровно одно и то же (при этом сохраняя предыдущее переопределение функции и передавая ему управление, если нужно).
Да, иногда плагины бывают несовместимы. Но это не отменяет того, что концепция крутая и работает.Keyten
05.08.2017 19:27Упс, прошу прощения, неправильно выразился.
Стоило написать так: представь, что ты пишешь std:sort или std:string, и захотел разрешить в каком-то месте их расширять.
Да, в определенных пределах, выход за которые грозит отстрелом ноги.
novice2001
06.08.2017 11:51Считать, что знание языка определяется тем, помнит ли человек, что возвращается при делении на 0… Ну не знаю.
Я не рискну выразить в двух словах что такое знание языка. Тем более, как я уже указал выше, я — не профессиональный программист. Но, IMHO, знание неочевидных особенностей этого языка туда входит.
Поясню на примере естественных языков. Мы говорим на русском и не считаем его сложным. Но на деле это такой себе JS среди естественных языков — очень много конкретных случаев, которые нужно знать вместо малочисленных четких правил. К примеру, ударения. В русском языке правил для них нет вообще! Нужно знать все(!) случаи. И это ад для любого человека, родной язык которого имеет правила для ударений.
Причем даже носители русского языка делают кучу ошибок в ударениях, причем даже в очень распространенных словах, типа «позвОнишь» вместо «позвонИшь».
Или можно взять случаи, когда носители делают ошибку в грамматическом роде существительных — «шампунью» вместо «шампунем».
В общем, большинству всей жизни не хватает для того, чтобы грамотно научиться говорить по-русски.
И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.
Автор вовсе не говорил, что возможность застрелиться большим количеством способов — непревзойдённое преимущество. Автор говорил именно о свободе действий — да, в том числе и свободе стреляться.
Только свобода застрелиться как раз и вытекает из свободы «вообще». Причем на практике (скорее всего) первое будет превращаться во второе.
Взять тезис о том, что если программа вместо аварийного прекращения продолжает стараться хоть как-нибудь работать дальше — это хорошо. Ну, на самом деле. Программа завершилась с ошибкой — это же кошмар. Надо же искать ошибку, исправлять ее, это ж лишняя работа. А так программа кое-как работает, пусть неправильно, ну и что? Ведь правильность не самое главное, верно? Зато разрабатывается быстро!
То же самое насчет системы типов, насчет статического анализа.
Я даже могу не знать вообще абсолютно ничего о языке. Если язык позволяет делать какую-то ошибку — люди обязательно ее сделают. И в случае с JS это означает, что люди делают гораздо больше ошибок, чем в других языках. Обязательно.
При этом доводы о том, что в JS можно сделать то, что в других языках сделать нельзя, меня не впечатляют.
Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
ctx.rect(10, 10, 200, 200, 'red', CSS_PT); ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
Тогда можно будет единообразно рисовать эти самые квадраты независимо от единиц измерения, например в цикле. В вашем же случае с «мощным переопределением» для px нужно передавать числа, а для pt — строки, которые нужно еще и сформировать. Нет, конечно же, можно сделать и переопределяемую функцию рисования квадратов в цикле… Но зачем???
Я допускаю, что раз в году найдется такой пример, который без переопределения никак нельзя сделать. Но, блин, на мой взгляд, вы используете не потому, что без этого никак или смертельно неудобно, а потому что можно и потому что привыкли. и иначе уже просто не мыслите.TimTowdy
06.08.2017 14:14Если задуматься, многие сегодняшние недостатки JS 20 лет назад были его достоинствами. Web ведь строился по Robustness принципу — «be conservative in what you do, be liberal in what you accept». Отчасти это и обеспечило ему взрывной рост. Невалидная разметка, некорректные заголовки, кривой код — браузер все проглотит и не поперхнется. В эпоху, когда джаваскрипт использовался для придания динамики веб-страничкам, это реально было плюсом.
Но время прошло, и JS превратился в промышленный язык. А от детских болезней избавиться так и не смог. Сообщество (за исключением некоторых фанатов, которых мы здесь наблюдаем) понимает его недостатки, но избавиться от них не могут из-за обратной совместимости.
В этом и состоит основной недостаток JS — сложившаяся экосистема не позволяет сломать обратную совместимость, вследствие чего детские болезни остаются в нем навсегда, а развитие происходит в основном за счет синтаксического сахара и костылей типа Symbol.
Keyten
07.08.2017 00:29-2Я тоже хотел привести пример с естественными языками ). Но больше в том плане, что приходить в английский и говорить «у вас неправильно, потому что у вас перфекты, вот смотрите, у нас в русском всего 3 времени, и нам норм» (что, к слову, не так, перфекты в русском вроде бы вполне себе есть) — как минимум, не очень правильно.
И язык программирования такого типа (условно) никак не может считаться хорошим универсальным языком.
Сравнивать языки программирования и естественные тоже не очень правильно по очевидной причине. Правильнее сравнивать ЯП с эсперанто, токи пона, ифкуилем, илакшем и иже с ними.
А так программа кое-как работает, пусть неправильно
А может, внезапно, работать правильно! Хотя бы чуть-чуть.
Вот я пишу-пишу в программе на Java, и вдруг там непойманный exception в одном из модулей, и вся программа вылетает. И мой несохранённый документ… тоже вылетает.
А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.
Если я правильно понял ваш пример.
Мне совершенно неочевидно, почему сразу не написать функцию, которая позволяла бы явный выбор единицы измерения.
ctx.rect(10, 10, 200, 200, 'red', CSS_PT); ctx.rect(10, 10, 200, 200, 'red', CSS_PX);
Напрашивается заметить, что все 4 параметра могут быть в разных системах координат, а там ещё есть и цвет, и делать ещё 5 доппараметров в функции как-то некрасиво, как минимум.
Но тут гораздо важнее иное: логика превращения каких-то единиц в пиксели может быть достаточно сложной (сложнее, чем взять константу и, например, умножить на число). Ну, например, я написал плагин для изометрии и хочу делать так (пример немножко утрированный):
var pointInIsometria = { plane: planeObject, rectOfPlane: [x, y, z] }; ctx.rect(pointInIsometria, pointInIsometria, 200, 200, 'red'); // или даже так: ctx.rect(planeObject, [x, y, z], 200, 200, 'red');
Кроме того, мне не нужно добавлять какие-то дополнительные параметры, чтобы позволять что-то расширять. Я по умолчанию разрешаю это делать практически со всеми своими объектами и методами (но с риском выстрелить в ногу, разумеется). И совершенно не забочусь, что пойдёт, если кто-то расширит как-то не так.
На ум пришла аналогия: это как продавать машину, разрешать на ней менять колёса, двигатель и дворники (компоненты, хочу заметить, вполне себе самостоятельные, и замена любого из них на делающий то же, но по-другому, и предоставляющий тот же io-интерфейс, не ломает систему в целом), но забивать на гарантию в случае нестоковой комплектации ).
P.S.Признаться, я совершенно не думал о доппараметре в функции (хоть он тут и совсем не к месту). Из той же библиотеки у меня есть интересный пример, связанный с прототипным наследованием. Интересно, сможете ли вы реализовать подобное на C / C++, например? Да и на любом языке без прототипов, вообще говоря, было бы интересно.
У меня у объектов на канвасе есть функцияattr. Она возвращает / изменяет значение во внутреннем хэше объекта:
rect.attr('x'); // -> 20; работает как getAttr rect.attr('x', 200); // работает как setAttr
Но кроме этого она проверяет наличие геттера / сеттера в объекте attrHooks в классе, и дёргает его. Например, на изменение координат прямоугольника дёргается перерисовка.
Фишка в том, что есть несколько классов (Rect, Circle, Path, Image, Text), которые наследуются от абстрактного класса Drawable. У Drawable есть свои общие attrHooks, и у каждого из классов есть свои специфические. При этом я хочу, чтобы при добавлении новых методов в attrHooks у Drawable они появлялись у всех его наследников (если они там не перезаписаны, естественно). Но не наоборот — специфические attrHooks у Rect не должны затрагивать attrHooks у Drawable.
На прототипах это реализовалось достаточно легко:
function drawableAttrHooks() {} Drawable.prototype.attrHooks = drawableAttrHooks.prototype; Rect.prototype.attrHooks = new drawableAttrHooks(); // теперь если я напишу Drawable.prototype.attrHooks.someProperty = 5; // то оно прокинется в Rect: Rect.prototype.attrHooks.someProperty; // -> 5 // но в обратную сторону это не действует: Rect.prototype.attrHooks.someAnotherProperty = 8; Drawable.prototype.attrHooks.someAnotherProperty; // -> undefined
grossws
07.08.2017 03:21+2А вот я пишу-пишу в программе на JS / [другом языке, позволяющем ошибки], и вдруг там непойманный exception в одном из модулей. Пол-интерфейса ломается, зато второй половины мне хватает, чтобы сохранить документ. И я благополучно перезапускаю программу и работаю дальше.
Это если вам очень повезло. Довольно часто можно оказаться в ситуации, что сохранить-то удалось, а ошибка была в каких-нибудь внутренних структурах. В итоге сохранён мусор. Тихая порча данных засчёт проглоченной ошибки — куда более неприятная ситуация, чем просто падение.
irbis_al
04.08.2017 09:36Вы знаете...Node популярна(я это и в той ветке написал)… Что её коэффициент Эффективность/Простота=Очень высок...java тоже эффективна, но не простая.(с Другими языками не знаком).
Есть вещи которые бы не рискнул разрабатывать на node(Это связанно с ООП и с глубоким наследованием)…
i360u
04.08.2017 09:46-2Респект автору, согласен на 200%. Хейтить то, чего не понимаешь — обычное человеческое свойство, но будучи инженером — ты, имхо, должен быть осторожее и объективнее. Легко называть всех вокруг идиотами, но будте готовы потом доказать что сами не идиот. Хейтеры, по моему опыту, доказать этого чаще всего не могут, а споры "о вкусах" тут не имеют смысла, ибо значение имеют только "pros/cons".
rpsv
04.08.2017 10:06+1Тут дело немного в другом: JS позволяет делать ВСЕ что хочешь, с очень небольшими ограничениями, и множеством вариаций.
И сейчас «мир раскололся» на 2-3 лагеря:
1. те кто любят псевдосвободу и придерживаются позиции «сам дурак», а JS красавчег
2. те кто считают, что инструмент должен минимизировать ошибки разработчика.
3. все остальные
Основной аргумент 1 лагеря и автора статьи, это то что если программист нормальный, то все будет ок.
Но если программист норм, то проблем в принципе не должно быть.
JS (как инструмент) никак не уменьшает число ошибок, а наоборот местами способствует их появлению, зато имеет низкий порог
Но надо оговориться, порог вхождения в программки типа «Hello World» действительно низкий, а вот порог вхождения в мир качественной разработки, ни чуть не ниже чем у других «ограничивающих свободы» языков.JSmitty
04.08.2017 14:25+1Зачем тогда люди так сильно до сих пор любят C/C++? Где в этом мире единорогов прекрасный паскаль? Почему так слабо популярен хаскель, который вроде как декларирует, что если программа собралась — значит, в ней нет ошибок?
ЗЫ Печально видеть, что JS всё больше тянут в сторону Java, нежели скажем Python.rpsv
04.08.2017 16:02Порог вхождения.
Популярность и эффективность/правильность/качество — это к сожаления далеко не одно и тоже.
Очень далеко.
И, опять таки к сожалению, низкий порог вхождения, как раз таки в большей степени и определяет популярность.
0xd34df00d
05.08.2017 22:36Потому что вокруг хаскеля ореол академичности, отсутствие поддержки крупных корпораций на уровне продакшена и, соответственно, курино-яйцевая проблема отсутствия людей для поддержки проектов на нем.
raveclassic
05.08.2017 23:23По моему скромному опыту хаскель требует невиданных теоретических познаний от простых разработчиков, которые являются основной целью найма.
0xd34df00d
06.08.2017 09:48Невиданные теоретические познания нужны, чтобы писать библиотечный код, но вы в любом языке простых разработчиков вам библиотеки ваять сажать не будете.
Чтобы писать не сильно performance-critical-код, даже семнатику ленивых вычислений не обязательно достаточно хорошо понимать.
fillpackart
04.08.2017 10:15+1Спор надо вести не о том, плох ЯП или хорош, но о том, готовы ли мы оплачивать свободу потенциальными ошибками, или безошибочность свободой. Мне кажется, для высококлассных разработчиков верно первое.
pm_wanderer
04.08.2017 10:20+3если вы действительно хорошо разбираетесь и в языках, и в архитектуре, и в парадигмах, и умеете всем этим пользоваться — лучше языка чем JavaScript для общих задач вам не найти.
Порог входа в JavaScript был и остаётся очень низким, это даёт повод многим новичкам ругать то, в чём они не разобрались.
я, например, прекрасно читаю даже обфусцированный код библиотек, чего и вам желаю.
Перечитайте про duck typing и научитесь им пользоваться
А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Общий посыл статьи понятен — язык великолепный, просто вы не умеете программировать)
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
А если попробовать так:
const a = 5; a = 4;
Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.tehSLy
04.08.2017 10:30Насколько я помню, в этом случае значение останется равным пяти, но никаких уведомлений об ошибках не последует.
"use strict"; const a = 5 undefined a = 3 VM156:1 Uncaught TypeError: Assignment to constant variable. at <anonymous>:1:3
Хром умеет такое вылавливать, тут уже вопросы к разработчикам движков.
Dreyk
04.08.2017 10:37Uncaught TypeError: Assignment to constant variable.
я буду обновлять комментарии перед написанием своего
onix74
04.08.2017 10:25+1В большинстве случаев проблема не в языке (или каком-либо другом инструменте), а в том, кто им пользуется и что от него ожидает. Привычка — вторая натура и себе любимому проще сказать: «Это не ты не знаешь как пользоваться, это язык (инструмент) хреновый.» А заставить себя посмотреть критично и допустить возможность другого подхода часто бывает очень сложно. Думаю, все с этим сталкивались.
ReklatsMasters
04.08.2017 11:04+1В JavaScript два основных варианта работы с модулями:
Ещё одно важное уточнение по поводу модулей. Их не 2, а больше. Первый действительно официальный и прописан в стандарте. Второй вариант называется common.js. А есть ещё amd. И говорить, что эти способы совместимы друг с другом неверно. Как минимум, commonjs и es6 modules не совместимы (про amd не в курсе, не использовал). Суть в том, что es6 modules асинхронны по своей природе, в то время как commonjs синхронны и модуль выполняется в момент подключения. Именно поэтому возникла большая проблема с интеграцией es6 модулей в ноду. Подробнее
genew
04.08.2017 11:53JS прекрасен: https://github.com/denysdovhan/wtfjs
dplsoft
05.08.2017 04:05+1но согласитесь, до руби ещё далеко. тот ещё прекраснее.
и дело даже не в наличии у джаваскрипта хоть какой-то ecma-спеки.
как мне показывали, руби восхитителен вплоть до превращения класса в переменную типа стринг, с естественным «обломом» при попытке создать объект этого класса после такого финта ушами.
особенно это прекрасно, если этот финт ушами проделал падаван в левом подключенном модуле, при попытке дополнить класс «очень нужными мегафичами».KasperGreen
05.08.2017 04:34class ololo { constructor() { this.hello = 'Привет';} } class hohoho extends ololo { toString() { return this.hello; } } let bathert = `${new hohoho}`; console.log(bathert);
JS может всё, или Ruby может так?
class ruby { constructor() {this = 'Строка'} }
JS второй пример не может
raveclassic
05.08.2017 04:50class ruby {
constructor() {this = 'Строка'}
}Страшно представить, что это
firk
04.08.2017 12:12+4Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений. Конечно к этому были и негативные причины, политика Microsoft и Mozilla, многое другое, но, уверен, не многие из других популярных языков смогли бы пройти такое же испытание и подняться после этого. Просто представьте, что стало бы с TypeScript или Rust после 10 лет отсутствия обновлений. Причина по которой JavaScript выжил очень проста, он решает одну задачу и делает это идеально.
Да он прожил 10 лет без изменений и решал свою задачу — добавление лёгкого скриптования к свёрстанному html-коду. Как только какие-то умники решили на нём "программировать" всё сразу пошло наперекосяк.
Sayonji
04.08.2017 12:42+3Если вы вызываете функцию как myObj.func(), то можете быть уверены, что this будет равен myObj.
Всё-таки почти уверены:function f() {console.log(this.field)} let obj = {field:321, f:f.bind({field:123})} obj.f()
Movimento5Litri
04.08.2017 12:54Повторю и тут пожалуй:
На данный момент JavaScript — самый популярный ЯП на планете. И, как бы я не уважал TypeScript, Java, C#, Go, другие языки — у них нет шансов изменить статус кво.
Лол, лол, лол, вы на какой планете живёте?
На планете Земля самый популярный язык — Java, без Script
Он даёт действительно много свободы и в нём нет защиты от дурака, поэтому такие люди там не задерживаются.
Лол, толпы jquery-говнокодеров-формошлёпов и не знали…
мир гораздо богаче вашего любимого языка и то, что для одних странно, для других норма. посмотрите хотя бы на haskell с его монадами и функторами, очень мощные штуки,
Лол, вы говорите это человеку который
всю жизнь писал на Erlang, Elixir, Haskell и Lisp
Как спортивный байк
Спортивный байк под тяжестью костылей весящий 30 тонн? Не, спасибо.
не делайте логических ошибок и будет вам счастье
Лол, даже лучшие в мире программисты и компании тратящие 7 миллиардов долларов на разработку делают ошибки.
отсутствие нормальных классов / ООП — ооп здесь богаче, чем в большинстве других языков. Можете наследовать через классы, можете через прототипы.
Идите создайте интерфейс
Лично я пишу на JavaScript уже 15 лет, искренне считаю его одним из самых мощных ЯП на сегодняшний день, поэтому не позволю его обижать
Ещё один защитничек не знающий язык который защищает https://habrahabr.ru/post/214087/#comment_7360557
И колбеки, и промисы, и async/await — нативные, поэтому код они не утяжеляют. Не знаю, что вы называете фьючерсами, я этим не торгую.
И вы себя называете программистом?
https://en.wikipedia.org/wiki/Futures_and_promises
Изначальные принципы языка были настолько хороши, что 10 лет (с 1999 по 2009) язык прожил вообще без изменений.
TimTowdy
04.08.2017 15:43+5однопоточный рантайм — это очень удобно.
Иногда удобно, иногда нет. Ваш «гибкий» и «мощный» джаваскрипт не дает выбора. Я например пишу на python, и там похожая проблема (GIL). Но я, в отличие от вас, отсутствие выбора не собираюсь заносить ему в достоинства. Как сказал один умный человек, «lack of something is not a feature».
NodeJS на одной средней машинке может держать по 100 000 коннектов
И это прекрасно. А потом у вас появляется код, который делает что-то в цикле над несколькими объектами. А потом бизнес вводит новое правило, и в каких-то редких случаях у вас будет не 3 объекта, а 3000. (пример: как-то обрабатываем сообщения пользователя отправленные за последнюю минуту, потом добавили фичу «рассылка», где пользователь отправляет сообщения целой группе).
И в результате у вас «пусть весь мир подождет» — все ваши 100 000 коннектов подвисают на время выполнения цикла. Любая CPU-bound задача вешает все ваши сотни тысяч коннектов. Вы думаете все программисты при написании каждой строчки кода задумываются о том, может ли она стать cpu-bound при каких-то условиях? Как только вы уходите от IO-bound формошлепства, внезапно оказывается что нужна архитектура. И тут «гибкость» джаваскрипта дает вам широчайшие возможности налажать с этой самой архитектурой.
Работа с ассинхронностью/потоками это не слабость, а одно из мощнейших преимуществ JavaScript. Это может требовать переучивания и изменения привычек, но поверьте, вы приобретёте очень многое.
Какбэ асинхронный ввод-вывод появился задолго до NodeJS. Просто в какой-то момент кучка JS-разработчиков дорвалась до него и стала вовсю визжать о революции. Было дововльно забавно слышать все эти вопли, ведь те, у кого была потребность в async IO и так давно о нем знали (python-twisted например вышел в 2002 году, если говорить о динамических языках).
слабые типы с неявными (и порой довольно странными) преобразованиями
Странными для кого?
Перечитайте про duck typing и научитесь им пользоваться, проблем с типами у вас не возникнет.
5 - '3' // 2 5 + '3' // "53"
Странными для здравого смысла. Львиная доля багов в JS-коде связана именно с ними. Это реальность.
Если бы можно было просто «перечитать про duck typing» и все баги пропали, люди давно бы это сделали. За последние 24 года пока им это не удалось. Наверное челлендж состоит не только в «перечитать про duck typing». Наверное duck typing, имеет как достоинства, так и недостатки. Наверное ситуации, где недостатки перевешивают достоинства возникают довольно часто.
Во многих случаях правильного применения JavaScript прототипы оказываются быстрее, удобнее и логичнее
Ага, а шотландцы не насилуют женщин, потому что во многих случаях насилие в Шотландии совершается ненастоящими шотландцами. Ведь "настоящий шотландец" не будет никого насиловать.
Понимаете, проблема в том, что случаев «правильного», как вы выразились, применения Javascript очень мало. И, как ни странно, почти всегда эти примеры «правильного» использования навеяны какой-то другой экосистемой.
А вообще, развивайте дисциплину кода, не всё время за юбкой IDE прятаться. Это не стёб, анализаторы это хорошо, но если для вас проблема такие ошибки — как-то вы не правильно программируете.
Понимаете, когда дисциплина навязывается, а не является опциональной, это зачастую (пусть и не всегда) позволяет сократить издержки. Именно поэтому и придумали typescript и его аналоги.
отсутствие вывода типов в самом языке или в каком-либо инструменте
Это есть, изучайте синтаксис.
myVar.constructor
Странно, что за 15 лет разработки вы так и не узнали что такое Type inference. Ах да, вы же 15 лет пишете на JS.
(впрочем, аргумент про type inference в динамическом языке выглядит довольно странно)
При правильном использовании проблем с this не возникает
Опять это волшебное «правильное использования». Понимаете, при «правильном использовани»и проблем не возникает ни на perl, ни на C++, ни на brainfuck. Суть в том, насколько быстро разработчики проходят путь от «неправильного» использования до «правильного». В случае джаваскрипта — они зачастую его не проходят вовсе. Аргумент «я один стою тут в пальто красивый» не работает когда критикуют экосистему, а не вас.
не делайте логических ошибок. Ваши ошибки — не вина языка
Если средний разработчик решая некую задачу на языке Х в среднем делает 10 ошибок, а на языке У — 5 ошибок, то это вина языка Х.
если хотите сделать регулярные выражения удобнее — используйте или напишите библиотеки
Автор, речь идет не о регулярных выражениях, а о pattern matching. Вы точно 15 лет в разработке?
В общем, оригинальная статья конечно была слабой, но ваша уж совсем ни о чем. Состоит наполовину из фанбоизма и наполовину из непонимания основ и терминологии.
Synoptic
04.08.2017 18:02-3Вот нее лень писать такие большие комментарии, а документацию почитать или хотя бы осилить Good Parts Крокфорда(100 страниц!!!) лень.
Язык мало то, что не однопоточный, так как в нем есть потоки — называется WebWorker, но даже и без них он не однопоточный — джаваскриптовый движок для кучи ситуаций использует потоки.
Где была асихнронная функциональность в других языках в том виде, в котором она была популяризирована Node.js? В недрах бекенда? Ну так не бекендом единым, фронденд разросся и оттяпал себе оттуда кусок, не надо зевать.
5 — '3' // 2
5 + '3' // «53»
Вы так делаете в коде на реальных проектах? Вы — говнокодер.
Понимаете, когда дисциплина навязывается, а не является опциональной, это зачастую (пусть и не всегда) позволяет сократить издержки. Именно поэтому и придумали typescript и его аналоги.
«Зачастую, пусть и не всегда», тьфу. Пруфы? А то я тоже так могу: утверждаю, что когда дисциплина является опциональной, а не навязывается, это зачастую(хоть и не всегда) позволяет сократить издержки. Чудеса демагогии.
Опять это волшебное «правильное использования»
Инструментом надо уметь пользоваться. Пользуешься правильно — профит, неправильно — не профит. Не хочешь — не используй совсем, как этот делает тот же Крокфорд.
Если средний разработчик решая некую задачу на языке Х в среднем делает 10 ошибок, а на языке У — 5 ошибок, то это вина языка Х.
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Тьфу.rpsv
04.08.2017 18:17+1Инструментом надо уметь пользоваться. Пользуешься правильно — профит, неправильно — не профит. Не хочешь — не используй совсем, как этот делает тот же Крокфорд.
Речь про удобство использования инструмента.
Если многим людям не удобно пользоваться инструментом, значит это в большей степени проблема инструмента, нежели кривых рук.
Если говорить про «правильно не правильно» — правильно используют язык, наверное малая часть людей которая им пользуется, и проблема это из-за низкого порога вхождения.
В этой ветке про это.
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Ну вообще то да — это очевидные вещи.
JS имеет очень мало ограничений, и многие (в том числе автор и многие комментаторы тут) ставят это в достоинство.
Исходя из-за малого количества ограничений (которые как раз таки уберегают от ошибок), гораздо проще сделать ошибку, в сравнении с тем же РНР.
JS динамическая типизация.
В сравнении с языками со статической типизацией, он явно уступает в количество ошибок типов.
Это все не пруфы, а логика и здравый смысл, а не истерика с пеной у рта.Synoptic
04.08.2017 18:26-1Многим это сколько? Их больше, чем «немногих»? Где это посмотреть? Мне вот, например, вполне комфортно. На основании чего я — немногих? На основании вашего личного мнения?
Статическая типизация, достаточная чтобы удовлетворить большую часть потребностей в JavaScript
давно есть. Опциональная динамическая типизация позволяет разработать и запустить проект быстрее, что в этом плохого?rpsv
04.08.2017 18:42+1Многим это сколько? Их больше, чем «немногих»? Где это посмотреть? Мне вот, например, вполне комфортно. На основании чего я — немногих? На основании вашего личного мнения?
На основании того, что JS в большей степени используется для придания динамики веб страничкам.
На основании того, что использование JS заключается в привязке событий с помощью jQuery и использовании вышеупомянутой библиотеке (при чем это заслуга библиотеки, а не языка).
На основании того, что существуют различные TypeScript, CoffieScript, и др. вещи, которые расширяют язык (явно не от хорошей жизни, верно?).
Если вы еще и для этого пруфы попросите, то я тут бессилен.
Статическая типизация, достаточная чтобы удовлетворить большую часть потребностей в JavaScript
давно есть.
Большую — это какую, пруфы пожалуйста.
Опциональная динамическая типизация позволяет разработать и запустить проект быстрее, что в этом плохого?
Плохо что быстро запуститься калымага, которая может сломаться в любой момент, просто потому что произошла конкатенация вместо сложения.Synoptic
04.08.2017 21:26На основании того, что JS в большей степени используется для придания динамики веб страничкам.
Это не так. Лет эдак пять как. Года эдак три как это не знают только те, кто в коме.
На основании того, что существуют различные TypeScript, CoffieScript, и др. вещи, которые расширяют язык (явно не от хорошей жизни, верно?).
Для вас может и верно, для меня это напротив показатель гибкости языка, который позволяет делать в том числе и вот такие штуки, удовлетворяя потребности многих из тех, кто раньше от языка плевался, и при этом оставаясь тем же самым языком.
А вот тех, кому TypeScript излишен и не нужен, да хоть студиям, клепающим трехстраничные лендинги, или тех, кто занимается прототипированием проектов для проверки идеи чтобы обогнать конкурентов и чтобы все равно потом переписать прототип(а прототипы надо и создавать, и переписывать) никто по прежнему не заставляет его использовать. Это опциональность, и это круто. Люди, ругающие JavaScript, но отдающие знак уважения TypeScript просто подтверждают аргументы оппонентов в подобных дискуссиях. Так что да, попрошу пруфы.
Большую — это какую, пруфы пожалуйста.
Статическая типизация#Преимущества
Например, это:
- Многие ошибки исключаются уже на стадии компиляции.
- В интегрированной среде разработки осуществимо более релевантное автодополнение, особенно если типизация — строгая статическая: множество вариантов можно отбросить как не подходящие по типу.
- Чем больше и сложнее проект, тем большее преимущество дает статическая типизация, и наоборот.
Плохо что быстро запуститься калымага, которая может сломаться в любой момент, просто потому что произошла конкатенация вместо сложения.
Я возможно открою вам глаза, но в реальной жизни, в реальной работе огромное число проектов переписываются заново независимо от языка на котором они были изначально написаны. Основные причины тому обычно изменение требований к проекту после проверки идеи, необходимость оптимизации(писать под хайлоад с самого начала ни один менеджер проекта в своем уме не даст). Да вообще необходимость переписывания прототипа хорошо известное правило, которое часто не соблюдается и говнокод получается независимо от языка разработки. Тоже надо пруфов?SirEdvin
04.08.2017 22:13+2Для вас может и верно, для меня это напротив показатель гибкости языка, который позволяет делать в том числе и вот такие штуки, удовлетворяя потребности многих из тех, кто раньше от языка плевался, и при этом оставаясь тем же самым языком.
Причем тут гибкость языка? Это просто транслитераторы из одного синтаксиса в другой. Такое можно сделать вообще для любого языка, никакой особенности для javascript тут нет. Для Java вот есть MPS.
Synoptic
04.08.2017 22:24-2Я не писал, что это особенность JavaScript. Я писал, что TypeScript и JavaScript — это один и тот же язык, и ругая одно его проявление и хваля другое, по факту хвалится сам JavaScript.
SirEdvin
04.08.2017 22:28Нет. Это разные языки. В Javascript нет строгой типизации, в typescript есть. Одно это отличие позволяет весьма четко их разделить.
Это как, например, ругать Java и хвалить Kotlin вполне нормально, потому что хоть runtime и один, языки то разные.
И вы перепутали коммент. Вы тут выше отвечали на то, что существование таких вещей, как TypeScript, говорит вам о том, что
для меня это напротив показатель гибкости языка, который позволяет делать в том числе и вот такие штуки
Но вот причем тут гибкость языка, совсем не понятно.
rpsv
04.08.2017 22:29+2WAAAT?!
Вы уже сами не знаете как оправдать JS.
Небольшой вопрос-пример:
В TS есть такая замечательная вещь как интерфейсы.
И вы хотите сказать что это заслуга-особенность JavaScript?!
WAT?!Synoptic
04.08.2017 23:02-2Зачем мне оправдывать JavaScript? Он сам себя давно оправдал. Мне даже напрягаться особо не приходится, комментируя вас. А вот вам приходится забивать на неудобные моменты и переводить тему в плоскость TypeScript это JavaScript или нет.
Я уже устал, а тред пусть останется на будущее.
rpsv
04.08.2017 22:22+1Статическая типизация#Преимущества
Например, это:
Многие ошибки исключаются уже на стадии компиляции.
В интегрированной среде разработки осуществимо более релевантное автодополнение, особенно если типизация — строгая статическая: множество вариантов можно отбросить как не подходящие по типу.
Чем больше и сложнее проект, тем большее преимущество дает статическая типизация, и наоборот.
А теперь, чтобы не быть голословным, приведите пожалуйста пример статической типизации, на native JS, которая так сможет.
Я возможно открою вам глаза, но в реальной жизни, в реальной работе огромное число проектов переписываются заново независимо от языка на котором они были изначально написаны
И это я так понимаю очередная крутость JS?
Давайте быстренько напишем на JS, все равно получится говно и потом придется переписать на другой нормальный язык?
Основные причины тому обычно изменение требований к проекту после проверки идеи, необходимость оптимизации(писать под хайлоад с самого начала ни один менеджер проекта в своем уме не даст). Да вообще необходимость переписывания прототипа хорошо известное правило
Можно писать проект на одном языке, если хорошо подойти к вопросам архитектуры и ограничений.
Но я так понимаю это невозможно с JS, т.к. «язык не ставит никаких рамок и это его основная особенность», нет?
Это не так. Лет эдак пять как. Года эдак три как это не знают только те, кто в коме.
Там для вас специально написано в БОЛЬШЕЙ степени (выделю побольше чтобы наверняка).
Если я не прав, то просвятите меня, где JS используется чаще, чем во frontend?Synoptic
04.08.2017 22:33-2А теперь, чтобы не быть голословным, приведите пожалуйста пример статической типизации, на native JS, которая так сможет.
Откуда взялось Native JavaScript когда речь шла о JavaScript?
И это я так понимаю очередная крутость JS?
Давайте быстренько напишем на JS, все равно получится говно и потом придется переписать на другой нормальный язык?
Да, это очевидная для любой компании крутость JavaScript — это прекрасный инструмент для создания полнофункциональных прототипов. Наверное удивитесь, людям которые такие прототипы создают платят кучу денег. К слову переписать можно(выдыхайте) опять на JavaScript.
Можно писать проект на одном языке, если хорошо подойти к вопросам архитектуры и ограничений.
Но я так понимаю это невозможно с JS, т.к. «язык не ставит никаких рамок и это его основная особенность», нет?
На каком, например? Или вы опять выкидываете клиент, и переключаете фокус на бекенд-часть? Клиент-то все равно будете писать либо на JavaScript, либо на чем то более специфическом типа Dart, что таки редкость.
Там для вас специально написано в БОЛЬШЕЙ степени (веделю побольше чтобы наверняка). Если я не прав, то просвятите меня, где JS используется чаще, чем во frontend?
Специально для вас — ПРУФЫ про большую степень. Если вы сайты-визитки клепаете на апворке или фигачите в JSP, это не значит что весь остальной мир занимается тем же самым. Кроме того, более 10 лет существуют настоящие монстры типа Sencha / ExtJS которые написаны на JavaScript.
Если я не прав, то просвятите меня, где JS используется чаще, чем во frontend?
Я цитирую вас:
На основании того, что JS в большей степени используется для придания динамики веб страничкам.
«для придания динамики веб страничкам.» === «чаще, чем во frontend»
Front-end для вас ограничивается приданием динамики веб-страничкам? Мда, с кем я разговариваю?
rpsv
04.08.2017 22:44+1Откуда взялось Native JavaScript когда речь шла о JavaScript?
Но мы уже выяснили это ваше воспаленное сознание считают TypeScript, Dart (так уж и быть) и… «обычным» JS, так что тут уже выяснять нечего.
Да, это очевидная для любой компании крутость JavaScript — это прекрасный инструмент для создания полнофункциональных прототипов. Наверное удивитесь, людям которые такие прототипы создают платят кучу денег. К слову переписать можно(выдыхайте) опять на JavaScript.
Т.е. люди платят за прототип (чего вот только вопрос, frontend, backend, всего вместе?), и потом платят за перепись прототипа.
Интересно у вас дела делаются.
«для придания динамики веб страничкам.» === «чаще, чем во frontend»
Front-end для вас ограничивается приданием динамики веб-страничкам? Мда, с кем я разговариваю?
Таки я допустил ошибку, черт((((
Специально для вас — ПРУФЫ про большую степень. Если вы сайты-визитки клепаете на апворке или фигачите в JSP, это не значит что весь остальной мир занимается тем же самым. Кроме того, более 10 лет существуют настоящие монстры типа Sencha / ExtJS которые написаны на JavaScript.
WAAAAAAAAAAAAAAAAAAT?!
А чем эти монстры занимаются?
ExtJS — «JavaScript framework for web application»
React — «A JavaScript library for building user interfaces»
AngularJS — «Superheroic JavaScript MVW Framework»
Мне кажется или только frontend'ом?
Synoptic
04.08.2017 23:16Но мы уже выяснили это ваше воспаленное сознание считают TypeScript, Dart (так уж и быть) и… «обычным» JS, так что тут уже выяснять нечего.
Тупо ложь. Я писал про TypeScript. Про Dart я такого не говорил.
Т.е. люди платят за прототип (чего вот только вопрос, frontend, backend, всего вместе?), и потом платят за перепись прототипа.
Интересно у вас дела делаются.
Да, в наиболее благоприятных условиях это самый лучший вариант. Не всегда возможный когда ресурсов мало, что выливается в говнокод. Видимо вас ждет еще много удивительных открытий в жизни.
WAAAAAAAAAAAAAAAAAAT?!
А чем эти монстры занимаются?
ExtJS — «JavaScript framework for web application»
React — «A JavaScript library for building user interfaces»
AngularJS — «Superheroic JavaScript MVW Framework»
Мне кажется или только frontend'ом?
Откуда тут взялись ReactJS и AngularJS? Потому что вы захотели подкрепить свое мнение, а не получалось? ExtJS это супермашина, которая умеет создавать вообще весь юай, очень сложный, основываясь только на данных с бекенда. Это называется «придание динамики страничкам»? Это и есть сами «странички», лол, попробовали бы бы сами придать такую динамику страничкам, глядишь и поменялось бы отношение к фронтенду.
Даже упомянутые вами реакт и ангуляр — это не «придание динамики страничкам» если только не считать «страничкой» пустой index.html с точкой входа в клиентское приложение.
Так что открою еще одну большую тайну: современный фронтенд сейчас это UI целиком и еще кусок бекенда в придачу, который отдали фронтендщикам чтобы они уже наконец отстали от занятых людей и готовили себе свои модельки для формочек сами. И отдавали данные желательно тоже сами, а еще лучше, чтобы и вообще API для этих прослоек сами создали и задокументировали, и чтоб саппортили, чтобы бекенд-разработчики могли спокойно жить в своем мире баз данных и сложной бизнес-логики.
А все это фронтендщикам оказалось удобнее делать на джаваскрипте, который они уже знали. И решив так, получилось очень даже неплохо для всех. Кроме, похоже, некоторых «бекендщиков», которые теперь остались без работы и у которых теперь от этого пукан бомбит — «а вот в твистед это было», «а вот тут это было».
Ну да. А теперь это называется фронтенд на джаваскрипте. Отнюдь не «придание динамики веб-страничкам», не так ли?raveclassic
04.08.2017 23:38+2современный фронтенд сейчас это UI целиком и еще кусок бекенда в придачу, который отдали фронтендщикам чтобы они уже наконец отстали от занятых людей и готовили себе свои модельки для формочек сами. И отдавали данные желательно тоже сами, а еще лучше, чтобы и вообще API для этих прослоек сами создали и задокументировали, и чтоб саппортили, чтобы бекенд-разработчики могли спокойно жить в своем мире баз данных и сложной бизнес-логики.
А все это фронтендщикам оказалось удобнее делать на джаваскрипте, который они уже знали. И решив так, получилось очень даже неплохо для всех. Кроме, похоже, некоторых «бекендщиков», которые теперь остались без работы и у которых теперь от этого пукан бомбит — «а вот в твистед это было», «а вот тут это было».Прекрасно сказано.
rpsv
05.08.2017 20:36+1Давайте ко сверим буковки:
А чем эти монстры занимаются?
ExtJS — «JavaScript framework for web application»
…
Мне кажется или только frontend'ом?
Ваш ответ:
ExtJS это супермашина, которая умеет создавать вообще весь юай, очень сложный, основываясь только на данных с бекенда
WAT?!
Ну да. А теперь это называется фронтенд на джаваскрипте. Отнюдь не «придание динамики веб-страничкам», не так ли?
Ну как бы это и есть придание динамики веб страничке)))
А у вас видимо истерика из-за того что парни из frontend — это недооцененные гении?)))
SPA — это тоже придание динамики веб страничкам.
При ответе только постарайтесь не забрызгать меня слюной.
Ну пожалуйста…
TimTowdy
04.08.2017 19:12+6Язык мало то, что не однопоточный, так как в нем есть потоки — называется WebWorker
Да ладно? Вебворкеров вообще-то нет ни в стандарте ECMAScript (оттуда их убрали), ни в серверном джаваскрипте (NodeJS). А знаете где есть API вебворкеров? В браузерах. А когда люди говорят о многопоточности, обычно речь вовсе не о них. Вы предлагаете на серверах запускать браузеры для числодробилок что-ли?
Где была асихнронная функциональность в других языках в том виде, в котором она была популяризирована Node.js?
«В том виде» — это на колбеках что-ли? Где нужно там и была, в том же Twisted например. В 2002 году. Просто никто не кричал на весь мир что это революция, т.к. там все-таки сообщество ближе к инженерам, чем к истеричным хипстерам.
Вы так делаете в коде на реальных проектах? Вы — говнокодер.
Скатились до перехода на личности в первом же комментарии. Не умеете холиварить :)
Но суть не.в том, пишет так какой-то конкретный программист или нет. Суть в том, что такие ошибки возникают у огромного кол-ва JS-разработчиков. И не возникают у разработчиков на других языках (даже динамических).
Вот вам пример из жизни: API одного из монополистов некоего рынка возвращает цену услуги, обычно числом, но иногда внезапно строкой. В документации естественно об этом ничего нет. Вы решили стать посредником, берете с юзера цену за услугу, и добавляете к ней $5. Пишете на своем любимом nodejs:
Тестируете — все работает. Запустили в продакшен, клиенты приходят, все вроде хорошо.itemPrice = api.requestPrice(item) chargePrice = itemPrice + COMMISSION
И вдруг через несколько месяцев вы узнаете, что в 0.1% случаев вы чаржили с юзеров в 10 раз больше, чем обещали. $3005 вместо $300. Был бы код на другом языке, при первой же такой ситуации вы бы получили runtime error, traceback, и уведомление. Решили бы проблему в тот же день. Но поскольку вы писали на JS, вместо этого вы получили несколько месяцев скрытого бага. Корпоративные клиенты от вас в страхе уходят, обычные юзеры угрожают подать в суд и ругают вашу компанию в соцмедиа.
Плохое third-party API? Безусловно. Но факт остается в том, любой другой вменяемый язык спас бы вас от этой ситуации. Но у вас же дажваскрипт. «Г» —говгибкость.
Пруфы?
Само существование (и достаточная популярность) typescript является пруфом того, что та же статическая типизация бывает полезна.
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Это было всего лишь опровержением достаточно глупого утверждения: «ваши ошибки — не вина языка». И тут важно не то, о каком языке это было сказано, а лишь то, что аргумент ложный. Ошибки, которые программисты допускают в одних языках чаще, чем в других — это вина и языка, и программиста.Synoptic
04.08.2017 19:59-3Да ладно? Вебворкеров вообще-то нет ни в стандарте ECMAScript (оттуда их убрали), ни в серверном джаваскрипте (NodeJS). А знаете где есть API вебворкеров? В браузерах. А когда люди говорят о многопоточности, обычно речь вовсе не о них. Вы предлагаете на серверах запускать браузеры для числодробилок что-ли?
В Node.js нет и многих других вещей, которые есть(или нет) в стандарте. Некоторых нет пока, некоторых не будет скорее всего вообще. Это само по себе никакой не аргумент.
Я предлагаю попробовать решить нерешаемую «нормально» с вашей точки зрения задачу(какую?), и вдруг окажется, что это вдруг не на клиентской стороне(как то незаметно мы сузились до бекенда кстати) она прекрасно решается даже и без веб воркеров. Что при этом не отменяет возможность их использования на клиенте.
«В том виде» — это на колбеках что-ли? Где нужно там и была, в том же Twisted например. В 2002 году. Просто никто не кричал на весь мир что это революция, т.к. там все-таки сообщество ближе к инженерам, чем к истеричным хипстерам.
Не кричали, свои языки для клиента не продвигали, когда они там были нужны. Теперь это сделали за вас те, кто кричал и продвигал то, что им нравится. А теперь они пишут на том, что им нравится. И идут дальше.
Вот вам пример из жизни: API одного из монополистов некоего рынка возвращает цену услуги, обычно числом, но иногда внезапно строкой. В документации естественно об этом ничего нет. Вы решили стать посредником, берете с юзера цену за услугу, и добавляете к ней $5. Пишете на своем любимом nodejs:
Пишете критические для вещи не зная инструментария? Вы и на другом языке свою компанию на деньги поставите. Как работают числа в JavaScript один из первых пунктов не просто руководств и документации, а каких-нибудь говнокаучингов «стань девелопером за 30 дней». Причем тут язык?
Само существование (и достаточная популярность) typescript является пруфом того, что та же статическая типизация бывает полезна.
TypeScript это и есть JavaScript
Это было всего лишь опровержением достаточно глупого утверждения: «ваши ошибки — не вина языка». И тут важно не то, о каком языке это было сказано, а лишь то, что аргумент ложный. Ошибки, которые программисты допускают в одних языках чаще, чем в других — это вина и языка, и программиста.
Зачем вы пишете это мне? Это мое утверждение?
Я ничего не утверждал — я попросил вас доказать ваше утверждение, что на JavaScript допускают больше ошибок, чем на других языках. Статей на эту тему на самом деле в интернете полно, Good Parts да не будет упомянут всуе написан именно чтобы огородить людей от легаси-граблей и странностей. При этом книга была написана чуть не 10 лет назад, допускают ошибки уровня вашей аргументации только непрофессионалы, а люди имеющие минимальную экспертизу и реальную практику — смотрят на вас как на… ну не важно.TimTowdy
04.08.2017 20:23+1Смешной вы.
Вы сказали что в языке есть многопоточность в виде вебворкеров. Я вам показал почему это утверждение ложное: в языке нет вебворкеров (есть API в браузерах), и ту многопоточность о которой вам говорят, они не дают.
Пишете критические для вещи не зная инструментария?
Вы даже не удосужились прочитать мой комментарий? Повторю еще раз, более коротко: есть баг (заранее неизвестный) в third-party API. Плохой язык позволил бы этот баг проглотить без каких-то уведомлений, и выдать непредсказуемый результат. Это — очевидный недостаток языка. Что никак не отменяет того, что баг-то на самом деле в API. Но его поменять нельзя, а язык — можно.
TypeScript это и есть JavaScript
Ха-ха. А еще Python — это и есть Javascript. Да и вообще, любой Тьюриг-полный язык — это JavaScript.
Я ничего не утверждал — я попросил вас доказать ваше утверждение, что на JavaScript допускают больше ошибок, чем на других языках
Перечитайте мой комментарий: «Если средний разработчик решая некую задачу на языке Х в среднем делает 10 ошибок, а на языке У — 5 ошибок, то это вина языка Х». Я специально не упоминал JS. Потому что мое утверждение применимо к любой комбинации Х и У.Synoptic
04.08.2017 20:54-1Снова демагогия. Давайте пойдем дальше, чего еще нет в JavaScript:
- возможностей работы с DOM (DOM API)
- возможности работать с видео и аудио (Video & Audio API)
- возможности использовать геолокацию
- возможностей работы с 2D и 3D графикой (SVG, Canvas & WebGL API)
- возможностей для взаимодействия с сервером (XMLHttpRequest API, fetch API, WebSocket API)
- возможностей обеспечения offline работы (Service Workers API)
- Еще вот этого нет
Всего этого в языке JavaScript нет. Ведь это лишь API. Как ни странно, несмотря на то, что всего этого в языке JavaScript нет, всем этим добром можно пользоваться и даже(о боже) считать что все это в JavaScript есть.
Ха-ха. А еще Python — это и есть Javascript. Да и вообще, любой Тьюриг-полный язык — это JavaScript.
Что никак не отменяет того, что баг-то на самом деле в API. Но его поменять нельзя, а язык — можно.
Лол.
fukkit
06.08.2017 17:49itemPrice = api.requestPrice(item)
chargePrice = itemPrice + COMMISSION
Проект проклят ровно с момента, когда кто-то решил использовать для финансовых вычислений язык, в котором itemPrice теоретически может оказаться чем угодно, и в самом лучшем случае — float'ом.
Валидные математические операции над разнородными объектами и применяемый при этом тупой автокастинг — существенный минус языка, непонятно зачем задизайненный изначально.iShatokhin
07.08.2017 11:26Можно попробовать соответствующие библиотеки — bignumber.js и decimal.js
Они и эксепшен бросят, и ошибки округления постараются не допустить.
SirEdvin
04.08.2017 22:16Вы так делаете в коде на реальных проектах? Вы — говнокодер.
Так это как? Суммирую две переменных? Да это часто люди делают в своих проектах. И в других языках такого дикого неявного приведения типов почти нет, что очень помогает.
Synoptic
05.08.2017 00:19Да, суммируя две переменных разных типов, не зная как работает приведение типов в языке. Об этом говорится в любом туториале. Не знаешь как работает и не хочешь знать — ну и не используй, приведи тип вручную — parseInt() трудно добавить? Никто не заставляет использовать приведение типов.
SirEdvin
05.08.2017 12:15-1Но ведь заставляют использовать, потому что оно происходит автоматически. Если там получилось, что в функцию попадает строка, вместо числа, то в таком случае мне нужно везде ставить проверки.
Зачем вообще нужно такое отбитое поведение? Можете привести хотя бы один кейс, где оно реально было бы полезно?
pnovikov
05.08.2017 09:17+1Где была асихнронная функциональность в других языках в том виде, в котором она была популяризирована Node.js?
В C# была как на клиенте так и на сервере (async/await). А без async/await — дык любой делегат можно было вызвать асинхронно где-то с .NET 2.0 (Это за 10 лет до появления nodejs, если что). В плюсах была (boost::asio).
Пруфы на то, что в случае с JavaScript это так? Статистика использования, сравнение одинаковых проектов на разных языках, замеры? Ах да, это же «всем очевидные вещи».
Когда человек для настолько очевидных утверждений начинает требовать "статистику и пруфы" — что-то с его пониманием субъекта обсуждения не так.
Synoptic
05.08.2017 09:26-1Что за такой клиент на C#?
Когда человек для настолько очевидных утверждений начинает требовать «статистику и пруфы» — что-то с его пониманием субъекта обсуждения не так.
Нет «очевидных» вещей. Все надо проверять, как оно на практике, причем время от времени перепроизводить проверки — а вдруг что-то поменялось? Когда приходят люди, которые используют в своей речи слово «очевидный» — это хороший маркер того, что надо пойти и проверить информацию.pnovikov
05.08.2017 11:16+2Что за такой клиент на C#?
Вы серьезно? WPF, WinForms, Xamarin, консоль… Я сказал "клиент" потому что некоторые из собравшихся ошибочно полагают что на C# можно писать только backend.
Нет «очевидных» вещей.
Очевидные вещи есть. Дышать — хорошо, не дышать — плохо. Типизация — хорошо, отсутствие типизации — плохо. Наличие стандартов и регламентов — хорошо, хаос и беспорядок — плохо. И любое "плохо" — оно не с потолка берется. Если у вас в коде хаос и беспорядок — очевидно что вы будете больше времени тратить на то, чтобы разобраться где что лежит и дописать требуемое. Если компилятор не проверяет для вас типы данных — значит у вас есть риск столкнуться рано или поздно с рантайм-ошибкой (если конечно у вас у самого в голове нет пары плашек RAM и мощного процессора). И это — печальные факты окружающей действительности. Следовательно, для того чтобы понять, что в решениях, оформленных на языке без контроля типов и дозволенным хаосом будет больше багов и они будут хуже поддерживаться — статистика не нужна. Для этого достаточно проанализировать факты и сделать выводы. Если несмотря на это, вы требуете от оппонента статистического анализа — то вы или знаете далеко не все факты, что идентифицирует вас как новичка в вопросе, или же вы не умеете делать логические выводы, что идентифицирует вас как человека откровенно глуповатого для профессии разработчика.
Keyten
05.08.2017 19:39Простите, я правильно понял, у вас львиная доля багов в коде происходит из-за вычитания строк из чисел?
Zenitchik
06.08.2017 00:06Из суммирования переменных, без предварительного приведения их к числовому типу. Вот, например, достал я из XML-ки значение, и мне нужно прибавить его к некоторой переменной.
accumulator +=+ valueFromXML;
Если второй плюсик забыть — будет неприятность.
Конечно, это привычно. Конечно, это не вызывает особых затруднений. Но если задуматься, если бы второй операнд всегда приводился к первому — было бы удобнее.
AxisPod
04.08.2017 16:1311. Автор предыдущей статьи скорее всего не знает разницы между reference-type и value-type, поэтому так и говорит.
const o = {}; o.a = 5;
Работает без проблем. Хотя переназначить o естественно нельзя, очень даже предсказуемое поведение, если знать типы данных.TimTowdy
04.08.2017 16:19Автор наверняка знает. А вот абстрактный средний JS-разработчик, когда пишет const практически всегда хочет получить неизменяемость значения. А язык ему подсовывает неизменяемость ссылки. Да, разработчик плохой, т.к. не знает матчасть. Но и язык плохой, т.к. не следует принципу наименьшего удивления.
Synoptic
04.08.2017 17:40-1Нет такого принципа
rpsv
04.08.2017 18:21Нет такого принципа
Правило наименьшего удивления
Что простите?
Есть даже целый язык, который следует этому принципу.
Synoptic
04.08.2017 18:20А если имелась в виду эргономика, то эргономика она знаете ли, разная бывает. Мне например, как JavaScript разработчику, который столкнулся с Java после, а не до изучения JavaScript, удивительна работа this там. А JavaScript уже обогнал Java по популярности или хотя бы сравнялся с ней.
Почему я не могу применить тот же аргумент к Java? Потому что так было принято? Ну а вот в JavaScript принято так. И?rpsv
04.08.2017 18:24+1А JavaScript уже обогнал Java по популярности или хотя бы сравнялся с ней
Может хватит уже может сравнивать проекты на JS и на Java?
Если вы считаете за использование различные куски кода, для добавления «динамики» веб страницам, то это не стоит сравнивать с программами на Java, которые совсем не для этого и не могут быть такими простыми.
Почему Node.js используется в крупных и серьезных проектах реже чем та же Java?
Может потому что в ней легко отстрелить себе ногу?
А в биллинговых системах (например), крайне важна надежность?Synoptic
04.08.2017 18:32Еще как можно сравнивать, особенно когда в рамках одной компании используются для одних и тех же целей оба языка. Это доказано тучей здоровенных проектов, на ряде из которых работал например я сам.
О каких конкретно программах на Java речь? Давайте предметнее. Node.js успешно применяется в энтепрайз веб разработке, как просто для приготовления моделей для фронтенда, так и для сложнейших высоконагруженных систем — пруфы надо? JavaScript сам по себе монополист на клиенте, давайте сравним… кстати с чем, с GWT? Кстати, где он? Пруфы надо?
Почему Node.js используется в крупных и серьезных проектах реже чем та же Java?
В каких конкретно проектах, хотя бы класс? Давайте на них посмотрим? Может быть им вполне подошел и JavaScript?rpsv
04.08.2017 19:00+2Ну погнали, примеры где используется Java:
— Jenkins
— Jira
— Eclipse
— NetBeans
— Intellij
Ну и Java окопалась в мобильной разработке (хотя вроде как ее двигает Kotlin).
И немного про Highload.
Я не Java-разработчик и уж тем более Java-евангелист, так что не могу похвастаться знаниями проектов на данном языке.
Но судя по вашим требованиям пруфов по любому вопросу, вы очень активно пользуетесь «презумпцией невиновности» языка.
Однако это не значит что JS хорош :-)Synoptic
04.08.2017 19:22Что из этого нельзя написать на JavaScript? Да нет тут такого. Более того, пишут и успешно. Те же ребята из Wrike и команды Visual Studio Code.
Крупные проекты типа Идеи давно уже написаны, и аналогов им нет не только на JavaScript, но и на других языках особо не наблюдается. Потому что не в языке тут дело.
Я не говорил, что JavaScript хорош. Я говорю, что это нормальны язык программирования, и большинство предъявляемых ему претензий происходят от незнания.
rpsv
04.08.2017 19:40+1Что из этого нельзя написать на JavaScript? Да нет тут такого. Более того, пишут и успешно. Те же ребята из Wrike и команды Visual Studio Code.
Конечно можно.
Вот только насколько можно будет сравнивать полученные проекты по надежности или скорости и удобству разработки?
Крупные проекты типа Идеи давно уже написаны, и аналогов им нет не только на JavaScript, но и на других языках особо не наблюдается. Потому что не в языке тут дело.
Visual Studio достойный тяжеловес, по моему на Сишке или на одном из отростков.
Но это не точно.
Вы сами выше упомянули про VS Code, он написан на Electron (кстати Atom на нем же, и собственно атомом я пользуюсь и очень доволен).
Но это лишь один пример, другие, достойные вряд ли есть.
Вообщем как раз таки в языке дело, насколько он подходит под определенные задачи.
Я не говорил, что JavaScript хорош. Я говорю, что это нормальны язык программирования, и большинство предъявляемых ему претензий происходят от незнания.
Незнание в большей степени исходит из-за непонимания некоторых вещей, которые в других языках совсем иначе выглядят.
Мне например, как JavaScript разработчику, который столкнулся с Java после, а не до изучения JavaScript, удивительна работа this там
Дело в том, что также как в Java и в других языках (C# как минимум), а JS во многих вопросах единственный в своем роде: стоит в сторонке и ссыт против ветра.Synoptic
04.08.2017 20:10Ну тогда получается что претензия к тому, что он просто другой. С этим по-моему никто и не спорит. И об этом, опять же, предупреждают на первых страницах любого учебника по JavaScript. Во всех, что я читал предупреждают сразу, что синтаксис JS обманчив.
rpsv
04.08.2017 20:18И это одна из проблем, что в нем не так как у всех.
Хочешь пиши в JS на ООП
Но нет многих конструкций interface и trait/mixin, да и классы недавно появились (в их обычном представлении).
В js прототипное наследование, не такое как у всех.
Хочешь пиши в JS в функциональном стиле
Тут вроде ок, но опять таки если сравнивать с TRUE функциональными языками (lisp, prolog, ...) js не чисто функциональный, и отличается от них.
То есть откуда бы не пришел человек, он будет ловить много WATов достаточно продолжительное время, прежде чем начнет делать все как надо.Synoptic
04.08.2017 20:33Еще раз — у кого у всех? Проблемы с пониманием у всех людей с бекграундом из Java и C#(да нифига не у всех на самом деле), не осиливших одну книгу? Это — не все.
И по статистике самых популярных языков программирования, похоже уже даже не большинство.
TimTowdy
04.08.2017 19:59Я говорю, что это нормальны язык программирования
Что такое «нормальный»? Какая метрика нормальности? Если нормальный — это на нем пилят рабочие проекты, то конечно нормальный. Если нормальный — это снижение выстрелов в ногу, то очень ненормальный.
большинство предъявляемых ему претензий происходят от незнания.
Вы издеваетесь? Большинство претензий к нему как раз от знания чего-то за пределами JS. А большинство аргументов в защиту (по крайней мере на хабре) именно от ограниченного кругозора.
«Я пишу только на JS и у меня все хорошо.»
«Пишите правильно, тогда ошибок не будет.»
«Во всех проблемах виноваты плохие программисты, я проблем не замечаю.»
«Язык не умеет Х, потому что это не нужно.»
«Что-то работает криво, но это описано в спецификации, значит все ок.»
«Раньше было еще хуже, скажите спасибо что язык развивается»
SirEdvin
04.08.2017 22:17Ни один из указанных проектов не написан на javascript. VS code написан как и Atom на coffeescript, а wrike используют dart.
rpsv
04.08.2017 22:27-1Тише-тише.
CoffeeScript это такой же «язык» как и TypeScipt.
А написаны данные IDE на Electrone.
Тут подробнее.Synoptic
05.08.2017 00:30+1Видимо такие люди потом создают вакансии «Требуется CoffeeScript-разработчик» или «Electron-разработчик».
rpsv
05.08.2017 20:40Это ошибка или все таки вы в нужную ветку ответили?
А то как то страшно немного становится.
Видимо такие люди потом создают вакансии «Требуется CoffeeScript-разработчик»
Ну а вообще ничего постыдного в такой вакансии нет.
Ведь если вся команда пишет на Coffie, то они вряд ли будут искать JS разработчика.
Или мол и так выучит, нормально?
или «Electron-разработчик».
А я разве писал что Electron это язык?
По вашей логике .NET язык?
Грустно товарищи, грустно когда не знаешь к чему прицепиться((((
rpsv
04.08.2017 19:05Node.js успешно применяется в энтепрайз веб разработке, как просто для приготовления моделей для фронтенда, так и для сложнейших высоконагруженных систем — пруфы надо
Естественно, да!
JavaScript сам по себе монополист на клиенте, давайте сравним… кстати с чем, с GWT? Кстати, где он? Пруфы надо?
И тут определенно да.
Вот только еще стоит оговориться: JS монополист на клиенте потому что нет альтернатив.
Так что JS будет в любом случае лучшим выбором, как бы лютым дерьмом он не был, лишь только потому, что нет альтернатив.
Ну а вообще есть TypeScript, CoffieScript,… которые, хоть и впоследствии компилируются в JS, но не являются JS в полной мере.
Другой синтаксис, другие конструкции.
Так что это как раз таки можно рассматривать, как альтернативы Native JS.
И поэтому каким таким монополистом он является?Synoptic
04.08.2017 19:28Естественно, да!
Первая ссылка в гугле
И тут определенно да.
Вот только еще стоит оговориться: JS монополист на клиенте потому что нет альтернатив.
Судя по оговорке, пруфы тут не нужны.
Ну а вообще есть TypeScript, CoffieScript,… которые, хоть и впоследствии компилируются в JS, но не являются JS в полной мере.
Являются, в полной мере, TypeScript к примеру надмножество JavaScript. А CoffeeScript — вы серьезно? Хотя бы Dart или Elm привели бы в пример, вот как раз по их объему использования и динамике роста статистика вполне общедоступна.
И поэтому каким таким монополистом он является?
Со смертью Flash и Java Applets — полным.rpsv
04.08.2017 19:48Являются, в полной мере, TypeScript к примеру надмножество JavaScript. А CoffeeScript — вы серьезно? Хотя бы Dart или Elm привели бы в пример, вот как раз по их объему использования и динамике роста статистика вполне общедоступна.
Как раз НАДмножеством, т.е. расширяет нативные возможности языка.
Как по мне, это вполне можно считать другим языком, т.к. языковые конструкции другие/новые.Synoptic
04.08.2017 20:06Ну а как по мне — нельзя так считать. Кто прав?
rpsv
04.08.2017 20:22+1Конечно же я)))
Но а если вернуться к пруфам, то:
Язык программи?рования — формальный язык, предназначенный для записи компьютерных программ
TypeScript имеет свой синтаксис, поэтому его вполне можно назвать ЯП.
Если не заглядывать под капот (то что TS в итоге компилируется в JS), то можно провести аналогию между C# и C++, или C# и Java.
Синтаксис похожий, все друг у друга заимствуют конструкции и синтаксис.
По вашей логике C# это НАДстройка над C++, или я не прав?Synoptic
04.08.2017 20:30Я не имею ничего против TypeScript, пишу на нем на работе, просто считаю его расширением JavaScript и не разделяю их, так как они почти всегда в рамках одного проекта живут вместе и даже перетекают из одного в другое.
Для меня, для моих коллег кого я знаю, которые занимаются тем же самым — это не отдельный язык программирования. А раз это лишь вопрос формулировок, то предлагаю особо и не спорить, какая разница.SirEdvin
04.08.2017 22:19Для меня, для моих коллег кого я знаю, которые занимаются тем же самым — это не отдельный язык программирования. А раз это лишь вопрос формулировок, то предлагаю особо и не спорить, какая разница.
Это получается демагогия немного) JavaScript не поддерживает написание DSL, а значит TypeScript — не его часть. И это довольно важно, так как показывает, что сам по себе javascript очень сильно не тянет для больших компаний.
Synoptic
04.08.2017 23:21+1Все он тянет, если использовать юнит тесты нормально. Прекрасно можно жить без TypeScript(ни в коем случае не в обиду TS). Это тут комментаторы считают, что без TypeScript жизнь с JavaScript-ом невозможна.
А она не просто возможна, она местами даже лучше, чем с TS.
fairwind
05.08.2017 11:04+3Это обсуждение любопытно тем, что уважаемый Synoptic в одном месте под предметом обсуждения подразумевает собственно JavaScript, а в другом — множество языков, включающее TypeScript.
Такое мышление сильно напоминает поведение this в JavaScript, из чего можно сделать предположение, что Synoptic — бот, написанный на JS.
Однако, если это предположение неверно, имеем две других возможности:
1) JS подходит людям с определенным складом мышления;
2) либо же взаимодействие с JS воздействует определенным образом на мозг, меняя мышление человека.
Второе из них пугает, ведь в таком случае, время от времени используя JS, следует опасаться негативных воздействий на логику. Сигналами могут быть подмена контекста обсуждения (this), изменение значений терминов (const) по ходу беседы, успешные операции сложения килограммов с вольтами.
Это предположение требует дополнительных исследований, однако будем осторожны уже сейчас, не дожидаясь предупреждений Минздрава о вреде JS!
С уважением, ваш DC-4C5866
pnovikov
05.08.2017 09:49Первая ссылка в гугле
Там всего лишь перечислены компании, которые используют nodejs в production-е. Если у MS крутится лендинг из трех страниц на ноде и собирает фидбеки от пользователей — я не удивлюсь. Вопрос был про готовые enterprise-проекты, а не про "вот эти люди когда-то скачали ноду".
Synoptic
05.08.2017 09:59Если у MS крутится лендинг из трех страниц на ноде и собирает фидбеки от пользователей — я не удивлюсь.
Вторая ссылка из гугла
Это лендинги?
Вопрос был про готовые enterprise-проекты, а не про «вот эти люди когда-то скачали ноду».
Вы в энтерпрайзе работали? В курсе, что крупных энтерпрайз-проектов целиком на одном языке не бывает, что там всегда туча подмодулей и каждый пишется на том, что больше подходит.
Ссылка выше показывает, что NodeJS в энтерпрайзе отвечает не только за лендинги.pnovikov
05.08.2017 11:25крупных энтерпрайз-проектов целиком на одном языке не бывает, что там всегда туча подмодулей и каждый пишется на том, что больше подходит.
Вот именно. И если ноде в этой куче подсистем отведено место сборочного инструмента, или же сервера для лендингов ну или она просто сидит и куда-то копирует файлы — то ваш восторг сильно преувеличен.
Synoptic
04.08.2017 18:35А в биллинговых системах (например), крайне важна надежность?
Не стал бы делать таких громких заявлений, можно подождать и посмотреть пока язык еще более стабилизируется и обрастет необходимыми фреймворками. Глядишь, окажется что и биллинг вполне можно написать.rpsv
04.08.2017 18:53Не стал бы делать таких громких заявлений, можно подождать и посмотреть пока язык еще более стабилизируется и обрастет необходимыми фреймворками. Глядишь, окажется что и биллинг вполне можно написать.
Отлично-отлично.
А сколько ждать?
Автор статьи тут утверждает что 10 лет язык не менялся и это круто.
Так какие перспективы?Synoptic
04.08.2017 19:32Понятия не имею, как и вы о том, что этого не случится.
Я лично этого не жду вообще, мне JavaScript интересен в других сферах — по случаю именно тех, за которые его тут часто хают — клиент-сайд, энтерпрайз, да даже и мобильная разработка.
Пока не видел тут статей от тех, кто пытался написать на нем биллинг и не получилось. Появится — почитаю.rpsv
04.08.2017 19:43Понятия не имею, как и вы о том, что этого не случится.
Но нет и довыдов что это случиться.
Пока не видел тут статей от тех, кто пытался написать на нем биллинг и не получилось. Появится — почитаю.
То что нет статей о том «как мы пытались поднять биллинг и не получилось», может говорить также о том что никто просто этим и не занимается, нет?
Все больше и больше убеждаюсь что JS это какой-то язык Шрединегра))))))Synoptic
04.08.2017 20:05То что нет статей о том «как мы пытались поднять биллинг и не получилось», может говорить также о том что никто просто этим и не занимается, нет?
Конечно, может. В чем вопрос-то? Это ж вы чего-то ждете, а не я. Мне нормально.
dplsoft
05.08.2017 04:24Не стал бы делать таких громких заявлений, можно подождать и посмотреть пока язык еще более стабилизируется и обрастет необходимыми фреймворками. Глядишь, окажется что и биллинг вполне можно написать.
не обрастет. и не во фреймворках дело.
дело в прогнозируемости результата, в динамической типизации, и как следствие этого всего — низкая скорость рефакторинга.
все это — заложено by dezign.
кроме того, что бы js оброс такими фичами как аннотации в java и системой метаданных, что бы с объекты в базу данных запихивать с теми же фичами и удобством как это делается в jpa, или можно было тот же xml ваять, так же удобно и просто (с валидацией, кстати) как это делается с jaxb или simple xml framework… для этого js должен перестать быть джава скриптом.
оставьте эту роль догоняющего сишарпу ;) у него много чего появилось, но пока и он не тянет и половины только что перечисленного.
TimTowdy
04.08.2017 19:33-1Почему я не могу применить тот же аргумент к Java?
Потому что ваш аргумент субъективный: «мне, как js-разработчику, удивительна работа this в Java». Подсказываю, он начинается со слова «мне».
Вы про const так и не ответили, а уже на this в Java перескакиваете.
Кстати, тот же const в Java называется final. Делает то же самое, но соответствует POLA.
const, между прочим, в других языках обычно как раз означает неизменяемую сущность, а не неизменяемую ссылку. Потому что когда программисты говорят о константах, они обычно заинтересованы именно в первом.Synoptic
04.08.2017 20:04+1Подсказываю, он начинается со слова «мне».
Кому удивительна this в JavaScript? Абстрактному святому духу? Или конкретным людям, особенно с бекграундом из других языков? Если им, то разве это не их личное «мне»?
Про const я вообще не вступал ни в какие дискуссии. Упреждая вопросы — лично мне работа const понятна и интуитивна.
Movimento5Litri
05.08.2017 02:19А JavaScript уже обогнал Java по популярности или хотя бы сравнялся с ней.
О, ещё один житель другой планеты.
Вы видимо с Альфа-Центавры?
На планете Земля на 1 месте — Java а JavaScript — на восьмом.raveclassic
05.08.2017 03:03https://insights.stackoverflow.com/survey/2017#most-popular-technologies
PS. я думаю, это то ребята не с центавры?
TimTowdy
05.08.2017 04:04Это все-таки напоминает «опрос в интернете показал что 100% людей пользуются интернетом».
Лучше смотреть на кол-во вакансий или профили разработчиков.
Я например поискал по skill на angellist:
Java: 267,012
JavaScript: 247,781
Думаю это ближе к истине. Хотя тут тоже стоит учитывать, что многие Java разработчики знают JavaScript, а вот обратное обычно не верно.
pnovikov
05.08.2017 09:54Это же статы от stackoverflow. Мне кажется, что если собрать статистику "по какой технологии люди больше всего задают вопросов" — это будет ни разу не "какой технологией люди больше всего пользуются". Если JavaScript лидирует по количеству задаваемых на stackoverflow вопросов, то я вам доложу что что-то не так с этим языком :)
Movimento5Litri
05.08.2017 10:18Это не рейтинг популярности а рейтинг к какому языку возникает больше вопросов.
Рейтинг популярности вот: https://www.tiobe.com/tiobe-index/
GraDea
04.08.2017 22:10+1Представил себе город, где самым популярным транспортом является спортивный автомобиль. Не уверен, что там комфортно ездить, хотя автогики там наверняка кайфуют)
vgoloviznin
05.08.2017 12:33Дубай? :)
pnovikov
05.08.2017 12:49В Дубае кайфуют не только автогики. Там вообще все только и делают что кайфуют.
SirEdvin
04.08.2017 22:23Причина по которой JavaScript стал таким популярным (кроме монополии в веб) — его демократичность
Основная причина только одна — это монополия на web. Не было бы этой монополии, такие штуки как nodejs вообще бы никогда бы не появились, а javascript умер бы в конце нулевых.
Ну и как многие уже написали — javascript очень кривой сам по себе и тысячи попыток исправить это лишь доказывают то, как он плох. Но пока он един в качестве веб-скриптового стандарта, эта боль компаний будет продолжатся.
raveclassic
04.08.2017 22:46Больше даже бесит не его кривость, она то как раз нивелируется языками-заменами (раз уж браузеры больше ничего не понимают) — typescript, purescript, elm, clojurescript и так далее, а тем, что, чем "дальше" от родного js, тем выше риски по найму, и, соответственно, нельзя просто так взять и обучить команду, например, purescript, так как разработка проекта на этой команде и кончится.
То есть как бы вот оно перед носом, бери не хочу, только протянуть руку. Но нет, нельзя, ни один менеджер в зравом уме не позволит вести проект на purescript.
sashagil
05.08.2017 12:37Жаль, никто не вспомнил Вижуал Бэйсик (очень демократичный язык, карма не попёрла, что ли).
Theo_from_Sed
06.08.2017 01:12Вопрос 11: const ( который на самом деле НЕ const )
Не знаю, почему вы так решили. Моя простая проверка в консоли показала обратное:Скорее всего поэтому:
const a = [1,2]
a.push(3)
console.log(a);
[1, 2, 3]
Livid
06.08.2017 01:34+2Автор не понимает о чем говорит. Пустая спекуляция, но вероятно других языков не знает и серьёзных проектов не делал. Теория ЯП прошла мимо в институте, если была. Javascript как язык г-но, не потому что слабая типизация, не потому что eval, или ещё что-то. А потому что базовые принципы непоследовательны. Очень тяжело думать на javascript. Очень тяжело гонять код на javascript в интерпретаторе, встроенном в мозг. И наконец, более-менее сложная архитектура на javascript не поддается изменению, проще переписать, чем поменять. Это я на личном опыте утверждаю, а не абстрактно. На секундочку, пишу на C++, Python, Php, Haskell, Go, VB, asm, ну и на js конечно (хотя больше на ts), и именно как язык хуже js пожалуй разве что vba, который в офис встроен, да и то спорно. Если совсем копать, то bash ещё ужасен. Но на нем не пишут северное ПО. И клиентское тоже не пишут. Так, скрипты мелкие в основном.
grossws
06.08.2017 19:10+2Вводит в заблуждение приставка Script и несерьёзный имидж языка, а на деле обнаруживается, что язык применяется от front-end и back-end до дескопных и мобильных приложений, программирования интегральных микросхем, обработки видео и в множестве других сфер.
Do tell me all about it.
Большая часть интегральных микросхем высечены в кремнии и не программируются вообще. Варианты, когда nodejs запускается на микрокомпьютере (raspberry pi и подобное) — это обыкновенный nodejs на обыкновенном linux'е. Промежуточный вариант (микроконтроллеры) — только запуск сильно урезанного варианта на старших моделях без всяких библиотек из nodejs, т. к. нет ОС, нет всяких примитивов типа файлов, сетевых сокетов и т. п. В теории можно написать слой совместимости, удовлетворяющий nodejs и вместить его на имеющийся 1-2 MiB ROM, но сделать на этом что-либо полезное уже не получится.
Про другие сферы типа обработки видео тоже хочется услышать. Желательно, чтобы там не вызывался сишный/плюсовый кодек, а тупая обвязка была на js. Ибо иначе — это простой маркетинговый буллшит.
worker4food
06.08.2017 19:51+2Посмотрите хотя бы на Haskell с его монадами и функторами (очень мощные штуки, кстати. В JS тоже используются, в jQuery).
Ничего себе, а где можно посмотреть на монады в jQuery?
firegurafiku
07.08.2017 04:22+8UPD: в статье JavaScript как мыслевирус pnovikov оскорбил всё сообщество JavaScript, назвав их фанатиками.
JavaScript пока не канонизирован православной церковью, чтобы так оскорбляться в ответ на вполне невинную статью, да ещё и не лишённую справедливости. Немного самоиронии не помешало ещё ни одному сообществу.
Как вы считаете, это этично?
Считаю, что вы этой припиской только подтвердили исходный тезис о мыслевирусе.
Duster
07.08.2017 13:45-3Простите, а чего вы хотели от человека, у которого в статусе ".NET-Программист", и который пишет статью «JS ужасен»? Со своим уставом здравый окрепший ум в чужой монастырь не полезет.
Мне вот не нравятся плюсы по ряду объективных лично сформированных причин, но это не означает, что я сиюминутно должен броситься стряпать статью «C++ как мыслевирус». Я просто не пишу на нем без явной на то необходимости. Что, ящщитаю, логично. Или, например, шарп. Я пишу на нем, но могу сформировать ряд неловких вопросов к профильным дотнеттерам. Но зачем? Практически на любом языке можно написать требуемый тебе функционал, но практически во всех этих случаев найдётся язык, в котором этот функционал написать проще и правильнее; и практически всегда обратное. Нет универсального языка. И это не повод усомниться в чужом интеллекте просто потому, что свой не способен воспринять другой стиль программирования.
PS: И, да, я бы хотел почитать мнение автора той статьи о Аде, Форте или Фортране. Ну так, чисто для себя, поржать…
roman_kashitsyn
07.08.2017 13:58+3Зачем вам нужна многопоточность?
Чтобы использовать железо более эффективно и делать больше CPU-bound задач в единицу времени. Если вы пишите бложик для 100 пользователей, то да, вам это ни к чему. Откройте для себя разницу между Concurrency и Parallelism.
не делайте логических ошибок. Ваши ошибки — не вина языка
При работе с любой средой важнее не то, что происходит, когда ошибок нет, а то, что происходит при наличии этих самых ошибок.
Это общая проблема всех интерпретируемых языков с eval, и отказываться от этой мощи ради возможности ловить 5% самых глупых ошибок — сомнительная идея.
Скорее наоборт: сомнительная идея иметь eval ради того 0.001% случаев, где он полезен (смелое предположение, ни разу не находил eval полезного применения), если это ломает статический анализатор, способный мгновенно поймать 99% глупых ошибок. Правда, на самом деле eval тут не при чём.
Скажете asm не странный? А Lisp?
В Lisp как раз с типами всё хорошо. Я частенько читаю спеки Common Lisp, удивляюсь, насколько всё-таки умные люди над ним работали. Он, конечно, далеко не идеален, но по сравнению с лиспом современный js выглядит как поделка из шишек и клея.
А типы в JavaScript не слабые, их принципиально нет (кроме примитивных).
Это предложение лишено всякого смысла.
rboots Автор
07.08.2017 17:11-4С типами знакомо 100% программистов, закончивших любой технический ВУЗ, поэтому ваша картинка верна, если заменить её на ровно противоположную.
roman_kashitsyn
07.08.2017 17:36+3С типами знакомо 100% программистов, закончивших любой технический ВУЗ
На картинке (которая, к слову, не моя) речь идёт не о "типах" а о "теории типов". Разница примерная такая же, как "быть знакомым с числами" и "быть знакомым с теорией чисел". Для первого достаточно закончить 3 класса школы, для второго нужна более серьёзная подготовка. Так что ваша фраза не опровергает, а лишний раз подтверждает справедливость изображения.
Вы знаете, к примеру, что такое параметрический и ad-hoc полиморфизм? Типы-суммы и типы-произведения?
Зависимые типы? Линейные типы? Фантомные типы? Структурная типизация? Что такое Hindley-Milner System и System F?
stanislavkulikov
07.08.2017 17:13Для любого языка есть свая область и своя сфера применения. JS создавался для фронта и он хорош в решении фронтовых задач. Java специализируется на высоконагруженных серверных решениях с большой ценой ошибки. На C# пишут приложения под Win. И т.д. Мне кажется, что ошибка этих холиваров всегда в том, что Porsche 911 GT пытаются сравнить с БелАЗ-75710. Но они оба хороши, просто каждый в своей области.
fillpackart
08.08.2017 09:43Тут дело в идее фикс, по которой ты можешь не учить другие языки. Первые два года в разработке я знал только C#, естественно я хотел писать на нём всё. И разработчики языков/платформ дают такую возможность. И это вызывает проблемы, ведь большинству svift-разработчиков не нравится мысль, что я могу сделать ios-приложение на C#. И они начинают критиковать xamarin. Так же и с JavaScript. Он проникает во все сферы, остальные разрабы недовольны. Ведь сегодня бизнес заказчик может нанять одного чувака со знанием js и ему не нужен буду я со своим C#, и т.д. Т.е. у разрабов на других ЯПах создается впечатление, что кто-то хочет отнять их хлеб, они боятся, что их технологии умрут и протестуют против этого. Это в корне не верно.
Не язык определяет тебя, а ты определяешь язык ©
zolt85
Лично у меня только одна претензия к JS — дебажить его то еще удовольствие. И если на клиентской части у тебя есть DevTools браузера, то на сервере такой радости нет. И только по-этому я с опаской посматриваю на JS в качестве back-end инструмента.
Я не против свободы, но как показывает практика, разработчику лучше ехать по «рельсам». Набрать команду хотя бы из 5 адекватных разработчиков, которые будут делать «все правильно» очень не просто.
Ну и «миллионы мух не могут ошибаться — что-то в этом есть»…
rboots Автор
Чтобы дебажить сервер можно использовать Node Inspector
inoyakaigor
Единственное что он не показывает контекст твоего скрипта. Т.е. я имею ввиду, что на фронте можно определить какую-нибудь переменную в глобальной области видимости, а потом в консоли браузера написать что-то в духе myVar и получить её значение. В Node Inspector так не работает, хотя, я допускаю, что я просто не знаю как ведь, на Ноде я написал пока только полприложения
vgoloviznin
Вообще глобальные переменные — зло. В ноде есть глобальный объект — global, к нему можно что-то подцепить, но смысла в этом я особо не вижу
vgoloviznin
VS Code с легкостью решает все проблемы дебага ноды
Tantrido
Опередил! :) Да, на VS Code это всё без проблем: сам удовольствие недавно получил: дебаг просто летает.
kernel72
В Webstorm отличный дебаггер.
F0iL
Для современных версий ноды
после чего пользуетесь любимыми DevTools :)
PavelDymkov
В ноде тоже есть DevTools:
update: опоздал с комментарием
djw
Команду из "правильно пишущих" набрать сложно и в других ЯП. В каждом есть крайности. В принципе, большинство проблем решается грамотными гайдлайнами для разработчиков.