Как стать автором
Обновить

Чем плох JavaScript в большом проекте? С какими проблемами мы столкнулись и как их решали

Время на прочтение 1 мин
Количество просмотров 41K
Всего голосов 35: ↑20 и ↓15 +5
Комментарии 67

Комментарии 67

Не понравилось.

Про JS:
— Знания размазаны по коду или сосредоточены в голове
— Большое желание (и возможность) написать костыль
Это проблемы workflow, недостаточно ревью, документации, модульности.
— Слабая поддержка ООП
Аргумент "вот вам код с SO" шикарен, конечно.
— Проблема с изоляцией и модульностью
Докладчик упоминает ES модули, но "ведь можно загадить глобальный неймспейс" — опять нет ревью?

Про Dart:
Богатая стандартная библиотека (пакетный менеджер, сборщик и д.р.)
Не вижу преимуществ перед стандартным набором DOM+jQuery/underscore/что-душе-угодно+browserify/bower/что-там-ещё. А учитывая огромное сообщество JS, мне кажется, инструментарий JS слегка побогаче будет.
Скорость работы
Не быстрее чем JS же.
Не только JS разработчики могут писать код
Не понял вообще. Dart разработчиков явно меньше, чем JS разработчиков.
Выкидывает лишний код
Только из себя, в JS нечего выкидывать.

Про TS:
Пакетный менеджер, сборщик, библиотека
См. выше
Писать на TS как на JS
Ревью?
Копипастить код
Флаг в компиляторе.
НЛО прилетело и опубликовало эту надпись здесь
И опять же — среди JS-разработчиков таких будет явно больше, чем среди Dart-разработчиков. Может, не в относительных цифрах, но в абсолютных — точно.
Всё так, на современном яваскрипте уже можно писать большие проекты. Но про стандартную библиотеку не согласен — она очень-очень-очень нужна. Почему? Потому, что она работает. Представляете? Не глючит, не имеет альтернативно одаренной имплементации, проблем с обратной совместимостью и списка поддерживаемых браузеров. А работает. ES6 делает шаги в правильном направлении, но до приличных языков его библиотеке еще расти и расти.
По-поводу первого пункта: всё можно решить процессом (ревью, workflow). Любое ревью упирается в человека, а это плохо масштабируется. В случае Dart я могу быть по крайней мере уверен, что в коде, пришедшем на ревью нет банальных опечаток (кстати интересный тред). А это значит я могу больше обращать внимание на архитектуру и то, что написано, а не как.

Не вижу преимуществ перед стандартным набором DOM+jQuery/underscore/что-душе-угодно+browserify/bower/что-там-ещё. А учитывая огромное сообщество JS, мне кажется, инструментарий JS слегка побогаче будет.

Ниже уже отписали. Минусы подхода юзать что-душе-угодно в том, что во-первых, нужно ещё выбрать, какую из множества библиотек юзать. Найти самую поддерживаемую/известную/удобную. Например я хочу логгировать что-то в Node. Иду в npm и вижу сотни библиотек. Во-вторых кто мейнтейнит эти либы? А что если либа, которую я юзаю загнётся? Ну и, в-третьих, всё-таки один фреймворк использовать удобнее, чем несколько.

Не быстрее чем JS же.

Это вопрос дискуссионный. Конечно говорить что Dart всегда быстрее, чем JS — не совсем правильно (а я и не говорил). Однако в определённых случаях это вполне возможно. Мы можем покидаться ссылками друг в друга (например), но я бы хотел говорить о конкретном примере. Меня удовлетворяет характеристика уж точно не медленнее

Не понял вообще. Dart разработчиков явно меньше, чем JS разработчиков.

Да, но разработчиков C#+Java+ещё-что-нибудь-ооп я думаю больше, чем JS разработчиков. И они вполне успешно работают. Как я говорил, у нас есть Senior C++ разработчики, которые решили поменять область. И кривая обучения у них менее болезненная, чем с JS.

Только из себя, в JS нечего выкидывать.

А тут я не понял. Да, из себя. Если мне нужна библиотека Dart math, в которой я использую одну функцию — она и будет в результирующем коде, а не целиком вся либа, чего ни JS ни TS не умеют.
А давайте сравним не на синтетическом тесте, а на более-менее реальном приложении? Вот, например, бенчмарк на основе todomvc. Там есть пара реализаций на дарте, одна не рабочая, другая (на дарт-ангуляре) — тормозит. Вас же не затруднит добавить реализацию на православном дарте?
А тут я не понял. Да, из себя. Если мне нужна библиотека Dart math, в которой я использую одну функцию — она и будет в результирующем коде, а не целиком вся либа, чего ни JS ни TS не умеют.

Тут вы, батенька, ошибаетесь. Современные сборщики прекрасно с этим справляются.
Да ладно? Я знаю только один такой сборщик — google closure compiler. И он будет корректно работать, только в режиме advanced optimizations, который требует чтобы весь код был правильно аннотирован, фактически требуется писать на его диалекте.
По-поводу первого пункта: всё можно решить процессом (ревью, workflow). Любое ревью упирается в человека, а это плохо масштабируется. В случае Dart я могу быть по крайней мере уверен, что в коде, пришедшем на ревью нет банальных опечаток (кстати интересный тред). А это значит я могу больше обращать внимание на архитектуру и то, что написано, а не как.

Вообще, для этого используются юнит-тесты. Только они гарантируют, что можно не обращать внимание на «как». Потому что в банальные опечатки входят не только имена переменной/поля/метода (которые как-то ±отлавливаются IDE и jshint/lint), но и такие опечатки как «вместо одного поля написал другое», «вместо "&&" написал "||"», «не ту переменную в цикле инкрементировал», «не тот индекс в массиве взял» и тому подобное. Товарищи из PVS Studio не дадут соврать — они собаку съели на поиске таких затупов в самом что ни на есть строго типизированном коде, и таки успешно находят практически всюду.
http://habrahabr.ru/company/pvs-studio/

Ниже уже отписали. Минусы подхода юзать что-душе-угодно в том, что во-первых, нужно ещё выбрать, какую из множества библиотек юзать. Найти самую поддерживаемую/известную/удобную. Например я хочу логгировать что-то в Node. Иду в npm и вижу сотни библиотек. Во-вторых кто мейнтейнит эти либы? А что если либа, которую я юзаю загнётся? Ну и, в-третьих, всё-таки один фреймворк использовать удобнее, чем несколько.

Во-первых, это исключительно просто — нужно смотреть на число звёзд у репы и когда был последний коммит.
Во-вторых, ну да, Дарт в этом месте даёт отличную гарантию — если он загнётся, то ЦЕЛИКОМ, бугагага. Учитывая, что Гугл (а) отказался от планов делать нативную поддержку Дарта, (б) вписался в WebAssembly, то такое развитие событий представляется весьма возможным.

Да, но разработчиков C#+Java+ещё-что-нибудь-ооп я думаю больше, чем JS разработчиков.

Во-первых, судя по статистике гитхаба, примерно поровну.
http://githut.info/
Во-вторых, на ES6 с классами, модулями и arrow functions вполне можно использовать как обычный классово-ориентированный ОО-язык и вообще ничего не знать про прототипы.
Что у Senior C++-разработчика «болезненная» кривая обучения с JS — это курам на смех, простите. Основная боль во фронтенд-программировании — это гора велосипедов и костылей «браузерные API», которые работают на радуги и магии. Dart в этом месте не помогает никак.
Тут, правда, есть религиозные убеждения из серии «не могу без статической типизации» и «ненавижу прототипное наследование». Выскажу жесткое имхо — если старший разработчик не хочет осваивать новые концепции, то ему на пенсию пора, независимо от.
Например я хочу логгировать что-то в Node. Иду в npm и вижу сотни библиотек. Во-вторых кто мейнтейнит эти либы? А что если либа, которую я юзаю загнётся?

Потому что либы решают разные задачи. Например, Debug от холовайчука — изоморфное, простое и незатейливое решение, которое просто работает. Его очень удобно внедрять в библиотеки.
Bunyan же — интересная и относительно сложная тулза, заточенная под пайпинг в всякие там logstash-ы c elasticsearch-ами.

Обе уже просто работают. Они не загнутся, потому что решение просто работает.
После того, как Google отказались от планов по внедрению нативной поддержки Dart в Chrome, лично я решил не дергаться пока и использовать ES6+, хотя Dart мне нравился. А указанные недостатки — это скорее недостатки процесса, чем языка.
ES6+ тоже до конца всеми не поддерживается.

А указанные недостатки — это скорее недостатки процесса, чем языка.

Возможно. Я бы сравнил процесс с законами: да, красть и убивать запрещено и жестоко карается, но всё равно это происходит. Однако если бы была исключена сама возможность — всё было бы иначе.
ES6+ тоже до конца всеми не поддерживается.

А что, у дарта поддержка лучше? Вот так новость.
В докладе я высказывался, что это субьективная точка зрения. Мне кажется, в отрыве от реального примера обсуждение бессмысленно. В нашем случае — ООП нужен.
В JS грубо говоря свой ООП — прототипноориентированный. Его нужно понимать и им нужно уметь пользоваться, а не пытаться натягивать ООП из других языков.
Тут можно много копий сломать (например), однако вот мои мысли, опять таки весьма субьективные

  • Не подавляющее большинство JS разработчиков знают тонкости реализации и как оно работает, а значит порой не понимают и не умеют пользоваться
  • Порог вхождения в JS не очень большой, плюс web достаточно моден, чтобы на JS писало много людей из пункта выше
  • прототипноориентированный ООП не преподают (или очень редко) преподают в институте
  • JS позволяет писать в разных стилях, например в процедурном

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

Тогда это не JS-разработчики.
JavaScript — язык для (а) быстрой, (б) событийно-ориентированной разработки. Чего тут копья ломать-то?
Если вдруг вы пишете приложение, в котором нет быстро меняющихся требований, бедная предметная область, высокие требования к надёжности работы фронтенда и нет высоких требований по производительности — ради бога, Дарт и TypeScript в помощь.
Если в тексте и в ваших словах заменить javascript на developer, то все становится ясно.
Отнюдь. Тут разница в том, что инструмент должен форсить девелопера писать хорошо. Тут действует закон больших чисел: если кода и людей очень много — вероятность ошибки возрастает. Поэтому чем строже окружение — тем лучше.
Извините конечно, но инструмент ни кому ничего не должен. Человек (даже не девелопер) сам выбирает подходящие под задачи инструменты.
Можно сказать что определенный инструмент хорош для одних задач, и не очень удобен для выполнения других.
Как разработчик нескольких небольших коммерческих приложений на Dart могу сказать, что огромный плюс Dart не в том, что там есть всё, что душе угодно, а в том, что там по умолчанию есть всё, что нужно для разработки. В чем отличие от JS, в том, что не нужно долго искать и выбирать, есть стандартная библиотека, которая делает почти всё, а чего не делает, есть в pub, который стоит по умолчанию, что опять очень удобно. Отдельно хочется отметить неготовность Dart к обслуживанию серверной части, недостаточно инструментария для связи с БД и другие мелкие недоработки. Как AS3/C# разработчику Dart для изучения был несравненно легче для освоения. От JS отпугнуло в первую очередь отсутствие более или менее единого подхода к разработке, одни советуют Angular, другие jQuery, третьи React и еще кучу вспомогательных библиотек, во вторых отсутствие привычного автокомплита, когда я пишу имя объекта, ставлю точку и мне даётся список только тех полей к которым я действительно имею доступ, в JS он есть, но не всегда адекватен. ES6 решает многие из проблем JS, но по факту ES6 сейчас такой же Dart/TS, надо настраивать транслятор и работать с транслированным кодом.
Dart-angular2 безусловно. Остальное мне нравится меньше. Еще полимер гладко работает, но у меня к нему личные счеты. И да, я понял, что ваш комментарий — сарказм. На Dart перепробовать все эти библиотеки дело получаса. Если с чем-то придётся возиться дольше 10 минут, значит оно не готово к использованию.
На Dart перепробовать все эти библиотеки дело получаса. Если с чем-то придётся возиться дольше 10 минут, значит оно не готово к использованию.
Замените Dart на js (npm) и получите тоже самое.
Зачем обманываете? Это TS, а не JS.
Angular2 рекомендует TS. Так что все честно. Тут уже с точки зрения workflow не особо есть разница ts или es6.
С точки зрения здравого смысла ES6 и TS разные вещи.
с точки зрения здравого смысла "быстрый старт с IDE" уже звучит неверно. Что если я использую sublime/atom?
Если вы используете Notepad, то я вообще не знаю что вам делать.
Смешно, разница между Notepad и "Hackable" редакторами небо и земля. Из того же Atom можно сделать полноценную идешку, причем можно дописать все что надо самому, у саблайма горы плагинов и работает он значительно быстрее чем Java IDE от Jetbrains.
Тот же https://code.visualstudio.com/ это форк Atom. Хотите сказать microsoft пилит Notepad?
Да хоть в том же Notepad, быстрый старт должен вообще не зависеть от IDE.
Быстрый старт не должен зависеть от OS, мне нравится kolibrios, быстрый старт не должен зависеть от архитектуры процессора, у меня Эльбрус. Кто вам такую глупость сказал? Есть инструмент, есть рекомендации как его использовать удобнее и проще, то, что вы человек спортивный и азартный и любите придумывать себе сложности на ровном месте, это ваша проблема.
Atom/Sublime как раз таки в моем случае решает проблему скорости, тормознутости и раздутия интерфейса. Всего этого из коробки там просто нет. Ставятся все нужные плагины очень очень быстро. Только не говорите мне что вы не настраиваете Jetbrains idename совсем. Я пользовался какое то время ими, они круты, но скорость работы интерфейса удручает, а настраивать точно приходилось.

Поэтому и нужно давать отдельно инструкцию по "быстрому" запуску без всех этих идешек.
Вы свой личный опыт обобщаете и вам кажется, что все так делают. Вы ошибаетесь. Я не настраиваю IDE для работы, от JetBrains включаю только отображение звёздочкой изменённых файлов, остальные настройки по умолчанию меня устраивают. Я не пользуюсь Atom потому, что он для меня менее удобен чем Webstorm для моих нужд.
Быстрый старт на то и быстрый старт чтобы ознакомиться с технологией, посмотреть как удобнее всего это делать с IDE или без неё. А как встроить интересующую технологию в привычную среду разработки это уже не вопрос быстрого старта, в крайнем случае, если интересует быстрое создание проекта, можно написать утилиту для этого.
То о чем вы говорите, это вопрос вашего личного удобства, но не быстрого или удобного старта.
То, что VS Code работает на Electron, не означает, что это форк Atom.
А они весь интерфейс писали или использовали какую то часть кодовой базы Atom? поиску по файлам выглядит идентично, дерево тоже. Я не думаю что они с нуля это писали, можете как то опровергнуть?
Могу повторить: VS Code (как и Atom) основан на Electron, но это не означает, что он является форком Atom. Откройте википедию, почитайте, возможно это покажется вам любопытным.

P.S. Я вообще в IDEA работаю, так что — на всякий случай предупреждаю — не спешите обвинять меня в предвзятости.
Я работаю с dart через Atom. Работает отлично, т.к. что в webstorm, что в atom, используется один и тот же analysis server.
НЛО прилетело и опубликовало эту надпись здесь
Мозг не нужен ни в первом, ни во втором случае, но webpack еще нагуглить надо(сам ни разу не натыкался), а Webstorm на каждом углу рекламируется как лучшее IDE для Dart, а дальше и гуглить не надо, просто создать новый проект из шаблона по умолчанию.
Пишу на Dart где-то с полгода. Впечатления от языка в целом весьма положительные.

Плюсы:

  1. Типизация.
  2. Хорошая поддержка рефакторингов из коробки почти для любого редактора.
  3. Нет проблем с this.
  4. Синтаксис очень приближенный к es6.
  5. Классная стандартная библиотека.

Минусы:

  1. Небольшое сообщество по сравнению с js.
  2. Совместимость с существующим js.

В целом если у вас dart-only проект, то минусы все уходят.

Если есть наследие на js, то есть несколько решений.

Например js-interop. Классная вещь наподобие .d.ts файлов, только для dart. Очень удобно описывать интерфейсы через аннотации.

Есть сложности с загрузкой модулей из es6. Одно из решений это:
https://github.com/dart-lang/dev_compiler/
Он позволит компилировать dart в максимально совместимый es6-код с поддержкой модулей. Релиз намечен на конец первого квартала.

Или можно обернуть require, module.exports через js-interop, написать пару строчек в конфиге webpack и использовать их уже сейчас.

Сборка одного dart-проекта с нуля проходит быстрее, чем сборка js-проекта со сравнимой кодовой базой, написанного на webpack.
Если сравнивать время инкрементальной компиляции, то результат приблизительно одинаковый. Он во многом зависит какое количество трансформеров используется в вашем проекте. Трансформеры это аналог babel-плагинов написанных под dart. Только их вы можете использовать не только для js, dart, но и для любых других файлов.

В целом если стоит выбор TS или dart, то выбор сложный и у меня нет ответа на вопрос что лучше использовать. Есть плюсы и минусы с одной и другой стороны. Если проводить их сравнение все выродится в один сплошной холивар. Для своего нового проекта, я бы использовал dart.
В большом проекте с JS действительно встает вопрос организации кода.
Но, скажем, тот же angular его решает. Тем более, если вам не нравится angular, то есть и другие фреймворки.

На мой взгляд, ООП в JS действительно запоздал. Но не забывайте, что любая парадигма — это способ организации кода.

А благодаря колоссальному количеству библиотек и фреймворков, организовать код на JS можно и в большом проекте.

Конечно, такое разнообразие может выйти боком: сложно найти разработчиков, которые хорошо знают множество технологий.
Поэтому в JS и нужно ООП. Поскольку по ООП есть тонны литературы и все паттерны проектирования хорошо описанны.
А альтернативы в виде elm или ScalaJs вы не рассматривали?
Если к Dart есть претензии, что он "экзотичен и не распространён", то эти альтернативы уж и подавно.
Но этот недостаток вполне может быть компенсирован преимуществами этих языков.
Elm — хорошая статическая типизация, основанная на алгебраических типах данных, реактивное программирование, как основная парадигма (что позволяет не писать кучу вспомогательного кода), элеганный хаскелеподобный синаксис (хотя я сталкивался с людьми, которых отсутствия скобок и запятых пугает, мне кажется что без лишнего мусора программы становятся читабельнее), не приходится работать с DOM.
ScalaJS — это Scala, с значительной частью инфраструктуры. Конечно, язык не простой, но те, кто его уже знают смогут использовать всю его мощь.
Из вашего ответа я так и не понял в чем же их преимущество. Недостаток вполне очевиден — нераспространённость языка, следствием этого идут следующие недостатки: нехватка специалистов, недоработанность готовых библиотек и их малое число. Преимущества Dart, помимо статической типизации и красивого синтаксиса, это глубокая продуманность стандартных библиотек, наличие качественных IDE и быстрый цикл правки-запуска, т.е. код Dart работает прямо в браузере без трансляции в отличие от того же TS. Еще одним преимуществом сложно, но можно назвать синтаксическую и поведенческую схожесть с C#/AS3/(с натяжкой Java), т.е. если нет специалиста, то легко его переобучить.
Простите, а можно поинтересоваться. Ваш большой проект на JavaScript — это сколько строк?
Попробуйте прочитать статью, для начала:

Как решить проблемы JS, когда количество кода превышает 2 млн строк, а команда насчитывает более 20 человек и постоянно растет?
Из них на JavaScript — ?
Достаточно много, наверное 65% на JS, но соотношение постоянно увеличивается в пользу Dart
Я скажу свое мнение. После того, как я попробовал Dart, я понял для себя, что это просто удивительный язык, сродни Python. Он очаровывает моментально. Он как будто подстегивает писать код правильно (актуально для овер9000 jQuery программистов в наше время). И можно бесконечно долго спорить на счет правильного применения прототипно-ориентированной парадигмы, но от JS Dart отличается именно ощущением того, что второй язык продуман невероятно досконально в отличие от первого, написанного на коленке.
Судя по плюсам и минусам в конце стаьи тайпскрипт лешил бы все проблемы.
Меня, как и автора, больше всего беспокоит отсутствие в JS какой либо спецификации у сущностей — модулей, классов, объектов. Т.е. не до конца понятно какие у них свойства и методы и как с ними работать. И да, это в конечном счете упирается в проблему сопровождения проекта. Т.е. по сути что TS что Dart дает нам такую спецификацию на уровне классов и интерфейсов.
Но в динамический языках существует другая практика TDD — spec файлы, т.е. файлы спецификации модулей и классов, которые являются чистыми юнит-тестами. Эти тесты должны быть максимально просты и очевидны. Такие файлы сразу дают явную рабочую спецификацию модуля или класса и примеры работы. Так что это проблема вполне решаема административными мерами — просто каждый модуль должен иметь спецификацию.
А все остальные проблемы вполне решаемы стандартными методами: gulp + requirejs(browsify) + strict mod + jshit(lint).
Ну и код ревъю для крупного проекта никто не отменял, независимо от того на чем вы пишете хоть на Dart хоть на C++
Меня в Dart очень радуют возможности стандартной библиотеки по работе с List, Map и потрясающе лаконичный синтаксис.
К примеру:

  /// Выбираем минимальный индекс у массива
  int minIndexBase = cacheMap.keys.reduce((int a, b) => (a < b) ? a : b);

А сериализации/десериализации объектов в JSON из коробки здорово не хватает. В результате выкручиваемся расстановкой @Field аннотаций Redstone.dart на сериализуемых полях.

Wriketeam, а как вы это делаете в своем проекте?
И чем же этот код отличается от JS? Уберите int и оно запустится.
ko11ega чаще всего стандартным JSON.encode, но пробовали и dartson.
А я все ждал, когда врайк начнет вещать свою истину о том, что дарт это хорошо не только на собеседованиях, но и на хабре. Дождался.
Wrike — большой проект? Не смешите. Могу привести примеры проектов по 500-1000 классов, и огромное количестов неклассовых сущностей, в которых чистый JavaScript без расширений работал замечательно. Разумеется для этого нужно грамотно проектировать архитектуру, не пихать где надо и не надо паттерны из класс-ориентированных языков, где нужно и на полную использовать утиную типизацию, мультипарадигменность с её монадами, функторами, не плодить классы без необходимости, где можно обойтись объектом, разделять приложение на слои и т.п… Вы просто не умеете его готовить и жалуетесь, что на больших проектах у вас возникли проблемы. Самая большая проблема JavaScript — низкий порог входа, позволяющий людям, недавно научившимся писать на нём странички, заявлять, что на больших JavaScript плох.
Вы слышали про такой проект как kolibrios? Говорит ли его существование о том, что FASM это отличный выбор для подобных больших проектов? Вы сейчас пытаетесь доказать примерно то же самое. Да, на JavaScript можно написать качественный и большой проект. Вопрос в том насколько компетентная команда для этого нужна. Если у вас неограниченный бюджет, то почему бы и нет, а в реальности большинство выбирает более подходящие инструменты.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий