Как программист, привыкший к статическим языкам, справляется с отсутствием инструментов Javascript

Я программировал почти исключительно на скомпилированных языках, особенно на Java, большую часть своей карьеры. Одна из моих любимых вещей в Java - насколько вы продуктивны и как мало кода на самом деле приходится писать при использовании таких инструментов, как Eclipse.

Вы можете:

• Легко и автоматически рефакторинг ваших методов и классов
• Просмотреть мгновенно все места, где вызывается метод или используется константа (Open Call Hierarchy / Show References)
• Статическая типизация означает, что вы можете использовать автозавершение кода, чтобы показать все параметры / функции, доступные для объекта.
• Удерживая клавишу Control, щелкните имя функции / члена / класса, чтобы перейти к ее определению.

Все эти возможности заставляют меня чувствовать, что IDE - мой лучший друг. Написание Java-кода и особенно понимание программ других людей становится намного проще.

Однако меня все больше и больше призывают использовать Javascript, и мой опыт до сих пор был довольно негативным.

Особенно:

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

• Параметры передаются в функции без возможности узнать, какие свойства и функции доступны для этого параметра (кроме фактического запуска программы, перехода к точке, в которой вызывается функция, и использования console.logs для вывода всех свойств имеется в наличии)

• Распространенное использование анонимных функций в качестве обратных вызовов, которое часто приводит к спагетти запутанных путей кода, которые вы не можете быстро перемещаться.

• И, конечно же, JSLint ловит некоторые ошибки перед выполнением, но даже это не так удобно, как наличие красных волнистых линий под вашим кодом прямо в браузере.

В результате вам в значительной степени необходимо постоянно держать в голове всю программу. Это значительно увеличивает когнитивную нагрузку при написании сложных программ. И все эти дополнительные вещи, о которых нужно беспокоиться, оставляют в моем мозгу меньше места для реального творчества и решения проблем.

Конечно, быстрее просто собрать объект вместе, чем писать полное формальное определение класса. Но хотя программы могут быть немного легче и быстрее писать, по моему опыту, их гораздо сложнее читать и отлаживать.

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

GWT позволяет вам писать код для среды Javascript на Java, но, похоже, не так широко используется, как я ожидал; люди действительно предпочитают Javascript для сложных программ.

Чего мне не хватает?

Особенности на основе IDE недоступны * на динамическом языке, таком как javascript. Вы должны научиться обходиться без них. Вам придется заменить поддержку инструмента на лучший дизайн.

Используйте шаблон модуля - либо вручную, либо с помощью инструмента, подобного requirejs . Держите модули небольшими, чтобы вы могли легко рассуждать о них.

Не определяйте как можно больше типов - используйте анонимные объекты, созданные рядом с точкой вызова. Затем вы можете посмотреть на звонящего и вызываемого и узнать, что происходит.

Старайтесь не связывать свой код с DOM. Постарайтесь ограничить количество манипуляций с DOM, которые вы делаете в своем коде. Если вы можете передать селекторы или коллекции jQuery, сделайте это, вместо того, чтобы ваш код знал о структуре страницы.

* _{Если вы используете популярную библиотеку, вы можете получить поддельное автозаполнение, но это больше похоже на «показать все методы jquery», чем на «какие свойства имеет этот объект». Это экономит набор текста, но не дает никаких гарантий правильности.}

Я хотел бы добавить ответ на этот вопрос, так как в последнее время я бродил по некоторой хорошей, плохой, но в основном уродливой Java, и у меня появилась новая огромная нагрузка от грубых обобщений в отношении Java и разработчиков Java против JS и Разработчики JS, которые могли бы основываться на чем-то, смутно напоминающем полезную правду.

Есть IDE, но может быть полезно понять, почему их не было много

Я пробовал Webstorm сейчас, когда я был привлечен к разработке Node, и это не так уж и плохо, что я действительно купил его, но я по-прежнему склонен открывать js-файлы в Scite чаще, чем WS. Причина этого в том, что вы можете сделать намного больше с гораздо меньшими затратами в JS, но также потому, что работа пользовательского интерфейса дает немедленную обратную связь, инструменты разработки для браузера (в частности, Chrome и Firebug) на самом деле довольно хороши, и (учитывая контексты, не связанные с браузером) ) повторное выполнение измененного кода быстро и легко без этапа компиляции.

Еще одна вещь, в которой я полностью убежден, это то, что IDE в основном создают свои собственные требования, используя небрежный код, который вы действительно не можете позволить себе в JavaScript. Хотите узнать, как мы справляемся в JS? Это может помочь начать с попытки написать что-то нетривиальное в Java без IDE и обратить пристальное внимание на то, что вы должны начать делать и думать, чтобы реально иметь возможность поддерживать / изменять этот код без перемещения IDE вперед. IMO, те же самые вещи по-прежнему важны для написания поддерживаемого кода независимо от того, есть ли у вас IDE или нет. Если бы мне пришлось написать 4-летнюю программу обучения программированию, это не позволило бы вам в первые два года касаться среды IDE, чтобы избежать искажения инструментов и зависимостей.

Состав

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

У меня на самом деле была довольно крутая кривая обучения в понимании нашей кодовой базы Java в последнее время, пока я, наконец, не понял, что ничего из этого не было правильным ООП. Классы были не более чем набором свободно связанных методов, изменяющих глобально доступные данные, сидящие в bean-компонентах, DTO или статических геттерах / сеттерах. Это в основном тот же самый старый зверь, которого ООП должен был заменить. Поэтому я перестал искать и думать о коде в принципе. Я только что выучил сочетания клавиш и проследил путаницы, и все прошло гораздо более гладко. Так что, если вы уже не в привычке, подумайте об ООП.

Хорошо структурированное приложение JS на самом высоком уровне будет состоять из сложных функций (например, jQuery) и объектов, взаимодействующих друг с другом. Я бы сказал, что отличительной чертой хорошо структурированного, легко поддерживаемого приложения на любом языке является то, что оно легко читаемо, смотрите ли вы на него с помощью IDE или Notepad ++. Это одна из основных причин, по которым я крайне критичен к внедрению зависимостей и тестированию TDD, доведенному до крайности.

И, наконец, отпустить занятия. Изучите прототип наследования. Это на самом деле довольно элегантно легко реализовать, когда вам действительно нужно наследование. Однако я считаю, что в JS подходы к компоновке работают намного лучше, и я лично начинаю болеть и переживаю ночные кошмары EXTJS каждый раз, когда вижу более одного или двух уровней наследования на любом языке.

Основные принципы Сначала

Я говорю об основных вещах, которые должны быть извлечены из всех других хороших практик: СУХОЙ, ЯГНИ, принцип наименьшего удивления, четкое разделение проблемных областей, запись в интерфейс и написание разборчивого кода - мое личное ядро. Все, что немного сложнее, что защищает от отказа от этих практик, следует рассматривать как помощь Kool на любом языке, но особенно на таком языке, как JavaScript, где очень легко оставить наследие очень запутанного кода для следующего парня. Например, слабая связь - это отличная вещь, пока вы не зайдете так далеко, что не сможете даже определить, где происходит взаимодействие между объектами.

Не бойтесь динамического набора текста

В JavaScript не так много основных типов. По большей части, правила динамического приведения являются практичными и простыми, но стоит изучить их, чтобы вы могли лучше научиться управлять потоком данных без ненужных приведений и бессмысленных процедур проверки. Доверьтесь мне. Строгие типы отлично подходят для производительности и выявления проблем при компиляции, но они не защищают вас от чего-либо.

Изучите дерьмо из функций и замыканий JS

Первоклассные функции JS являются, пожалуй, главной причиной, по которой JS выиграл «Единственный язык, который стоит прикасаться к клиентскому веб-сайту». И да, на самом деле была конкуренция. Они также являются центральной особенностью JS. Мы строим объекты с ними. Все ограничено функциями. И у них есть удобные функции. Мы можем проверить параметры через ключевое слово arguments. Мы можем временно прикрепить и запустить их в контексте методов других объектов. И они делают управляемые событиями подходы к вещам непристойно легкими для реализации. Короче говоря, они сделали JS абсолютным чудовищем в снижении сложности и адаптации различных реализаций самого JS (но в основном DOM API) прямо в источнике.

Переоценка моделей / практики перед принятием

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

Следуйте указаниям языка и делайте больше с меньшими затратами

Я полагаю, что один из руководителей Honchos из Java где-то утверждает, что многословие на самом деле является положительной чертой, облегчающей понимание кода всеми сторонами. Фигня. Если бы это было правдой, было бы легче читать юридический. Только писатель может сделать то, что он написал, легче для понимания, и вы можете сделать это только иногда, ставя себя на место другого парня. Итак, примите эти два правила. 1. Будьте максимально прямыми и ясными. 2. Добраться до чертовой точки уже. Выигрыш в том, что чистый, лаконичный код на несколько порядков легче понять и поддерживать, чем то, где вам нужно пройти двадцать пять уровней, чтобы перейти от триггера к реальному желаемому действию. Большинство шаблонов, которые поддерживают такие вещи в более строгих языках, на самом деле являются обходными путями для ограничений, которых нет в JavaScript.

Все податливое и все в порядке

JS, вероятно, является одним из наименее протекционистских языков в популярном использовании. Прими это. Работает нормально. Например, вы можете писать объекты с недоступными постоянными «частными» переменными, просто объявляя обычные переменные в функции конструктора, и я делаю это часто. Но это не для того, чтобы защитить мой код или его пользователей «от себя» (они все равно могли бы просто заменить его собственной версией во время выполнения). Но скорее это должно сигнализировать о намерениях, потому что предполагается, что другой парень достаточно компетентен, чтобы не хотеть манипулировать какими-либо зависимостями, и увидит, что вы не должны добиваться этого напрямую, возможно, по уважительной причине.

Нет ограничений по размеру, есть только проблемные домены

Самая большая проблема, с которой я столкнулся во всех кодовых базах Java, - это переизбыток файлов классов. Прежде всего, SOLID - это просто запутанное повторение того, что вы уже должны знать об ООП. Класс должен обрабатывать определенный набор связанных проблем. Не одна проблема с одним методом. Это просто берет старый дрянной код на func-spaghetti C только с добавлением всего бессмысленного синтаксиса классов для загрузки. Нет ограничений по размеру или методу. Если имеет смысл добавить что-то к уже длинной функции, классу или конструктору, это имеет смысл. Возьми jQuery. Это полный набор инструментов длиной библиотеки в одной функции, и в этом нет ничего плохого. Нужны ли нам все еще jQuery - это спорные вопросы, но с точки зрения дизайна,

Если Java - это все, что вы знаете, балуйтесь чем-то с синтаксисом, не основанным на C

Когда я начал возиться с Python, потому что мне понравилось то, что я слышал о Django, я научился отделять синтаксис от языкового дизайна. В результате стало проще понимать Java и C как сумму их частей проектирования языка, а не как сумму вещей, которые они делают по-разному с одинаковым синтаксисом. Приятным побочным эффектом является то, что чем больше вы понимаете другие языки с точки зрения дизайна, тем лучше вы будете понимать сильные / слабые стороны того, который вы знаете лучше всего по контрасту.

Вывод

Теперь, учитывая все это, давайте поразим все ваши проблемные моменты:

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

Chrome и Firebug действительно имеют функцию отслеживания вызовов. Но посмотрите также мои пункты о структуре и сохранении вещей краткими и прямыми. Чем больше вы можете думать о своем приложении как о больших хорошо инкапсулированных конструкциях, взаимодействующих друг с другом, тем легче будет понять, чья это вина, когда что-то идет не так. Я бы сказал, что это верно и для Java. У нас есть классоподобные конструкторы функций, которые идеально подходят для традиционных задач ООП.

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Seriously though Java/C# folks, stop with the pointless getter/setters already

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

В моем коде я почти никогда не использую объектные литералы в {}качестве структурных компонентов приложения, поскольку они не могут иметь внутренние (частные) переменные, и вместо этого предпочитаю резервировать их для использования в качестве структур данных. Это помогает установить ожидание, которое поддерживает ясность намерений. (если вы видите кудри, это данные, а не компонент архитектуры приложения).

• Параметры передаются в функции без возможности узнать, какие свойства и функции доступны для этого параметра (кроме фактического запуска программы, перехода к точке, в которой вызывается функция, и использования console.logs для вывода всех свойств имеется в наличии)

Опять же, посмотрите современные инструменты браузера. Но также, почему это такой облом, чтобы снова запустить программу? Перезагрузка - это то, что веб-разработчик на стороне клиента обычно делает каждые несколько минут, потому что это абсолютно ничего не стоит. Это снова, еще один момент, с которым структура приложения может быть полезна, но это один из отрицательных компромиссов JS, который вы должны выполнить свою собственную проверку, когда принудительное выполнение контрактов является критически важным (то, что я делаю только в конечных точках, подверженных другим вещам, которые моя кодовая база не делает не контролирую). ИМО, компромисс стоит своих выгод.

• Распространенное использование анонимных функций в качестве обратных вызовов, которое часто приводит к спагетти запутанных путей кода, которые вы не можете быстро перемещаться.

Да, это плохо на что-нибудь нетривиальное. Не делай этого. Назовите ваши функции, дети. Также легче отслеживать вещи. Вы можете определить, оценить (необходимо назначить) и назначить простую тривиальную функцию в строке:

doSomethingWithCallback( (function callBack(){}) );

Теперь Chrome будет иметь имя для вас, когда вы будете отслеживать звонки. Для нетривиальной функции я бы определил ее вне вызова. Также обратите внимание, что анонимные функции, назначенные переменной, все еще являются анонимными.

• И, конечно же, JSLint ловит некоторые ошибки перед выполнением, но даже это не так удобно, как наличие красных волнистых линий под вашим кодом прямо в браузере.

Я никогда не трогаю вещи. Крокфорд поделился с сообществом некоторыми хорошими вещами, но JSLint переходит грань в стилистические предпочтения и предполагает, что определенные элементы JavaScript являются плохими частями без особой причины, IMO. Обязательно игнорируйте одну вещь о классах regEx и отрицании, за которыми следуют * или +. Подстановочные знаки работают хуже, и вы можете легко ограничить повторение с помощью {}. Кроме того, игнорируйте все, что он говорит о конструкторах функций. Вы можете легко обернуть их в фабричный функционал, если вас беспокоит новое ключевое слово. CSSLint (не Крокфорда) еще хуже в плане плохих советов. Всегда берите людей, которые много выступают с солью. Иногда я клянусь, что они просто хотят установить авторитет или создать новый материал.

И опять же, вы должны отучиться от того, что вы узнали с этим беспокойством во время выполнения, которое у вас есть. (это обычное явление, которое я видел у многих разработчиков Java / C #) Если появление ошибок во время выполнения по-прежнему беспокоит вас 2 года спустя, я хочу, чтобы вы сели и перезагрузили спам в браузере, пока он не утонул. нет разделения по времени компиляции / времени выполнения (ну, во всяком случае, не видимое - JS теперь работает на JIT). Не только хорошо обнаруживать ошибки во время выполнения, но и очень выгодно так дешево и легко перезагружать спам и обнаруживать ошибки в каждой точке остановки, к которой вы попадаете.

И взломайте эти инструменты разработчика Chrome. Они встроены непосредственно в webkit. Щелкните правой кнопкой мыши в Chrome. Осмотрите элемент. Исследуйте вкладки. Там есть много возможностей для отладки с возможностью изменять код в консоли во время выполнения, что является одним из самых мощных, но менее очевидных вариантов. Отлично подходит для тестирования тоже.

С другой стороны, ошибки ваши друзья. Никогда не пишите пустое выражение catch. В JS мы не скрываем и не хороним ошибки (или, по крайней мере, мы не должны кашлять YUI / кашлять ). Мы заботимся о них. Все, что меньше, приведет к боли отладки. И если вы действительно напишите оператор catch, чтобы скрыть потенциальные ошибки в работе, по крайней мере, молча зарегистрируйте ошибку и запишите, как получить доступ к журналу.

То, что вы говорите, является обычным явлением для единомышленников Java, которые смотрят на JavaScript.

Давайте сначала ответим на ваш вопрос ...

... мой вопрос, как другие программисты справляются с этими проблемами ...

Ответ: они не делают. Они изучают философию JavaScript, сначала отказавшись от культа Java.

Вы должны понять эту предпосылку ... JavaScript НЕ ЯВА. Дело не в синтаксисе, а в философии.

Теперь давайте рассмотрим некоторые из них ...

• Просмотреть мгновенно все места, где вызывается метод или используется константа (Open Call Hierarchy / Show References)

  Удерживая клавишу Control, щелкните имя функции / члена / класса, чтобы перейти к ее определению.

  Все это доступно - просто выберите достойную IDE.

• Статическая типизация означает, что вы можете использовать автозавершение кода, чтобы показать все параметры / функции, доступные для объекта.

  Это не проблема, с которой вы справляетесь . Это то, что требует изменения вашего взгляда на программирование. Свободная система типов - одна из сильных сторон JavaScript. Поймите свободную печать - и научитесь ценить это. Кроме того, завершение кода очень хорошо работает с JS.

• И, конечно же, JSLint ловит некоторые ошибки перед выполнением, но даже это не так удобно, как наличие красных волнистых линий под вашим кодом прямо в браузере.

  Firebug, консоль Chrome / Safari и даже IDE делают все это и многое другое.

  Существует JSHint, который может выполнять изящный статический анализ, к которому привыкли Java-программисты.

• В результате вам в значительной степени необходимо постоянно держать в голове всю программу. Это значительно увеличивает когнитивную нагрузку при написании сложных программ.

  Неправильно! Напротив, JavaScript является «легковесным» языком программирования и поощряет вас иметь более простые программы. Как говорит Дуг Крокфорд ... это "накажет" вас, если вы попытаетесь писать программы на основе моделей в JavaScript.

• хотя программы могут быть немного легче и быстрее писать, по моему опыту, их гораздо сложнее читать и отлаживать.

  Совершенно неправильно! Как вы решаете удобочитаемость на основе языка программирования? Программы читабельны (или нет) - НЕ языки. Кроме того, в JavaScript есть фантастические отладчики.

Извините, если я звучу немного грубо - но правда в том, что вы должны изменить свой настрой Java, чтобы понимать JavaScript.

Только «зрелые» Java-программисты могут ценить JavaScript - и вы не можете освоить то, что вы не цените. Опять извините за откровенную тупость.

В общем, трудно иметь инструменты, которые вы упомянули для динамического языка (если только IDE не является частью среды выполнения - то есть Smalltalk). Сказав это, как только вы изучите действительно хороший текстовый редактор, большинство IDE выглядят менее привлекательно - это, по крайней мере, мой опыт.

Это цена, которую мы платим за использование плохо типизированных языков. Можно только удивляться, почему эта мерзость стала настолько популярной. Недостатки значительно перевешивают преимущества плохо типизированных языков.

Возможно, нам следует применить принцип отказа от сотрудничества к этому мусору, чтобы он исчез.

Раньше мне не нравился javascript (и его динамическая типизация), но я вырос, чтобы оценить его объектную ориентацию, замыкания и функциональное программирование . Кроме того, его глобальные объекты и удаление бесшумного преобразования типов были глотком свежего воздуха, когда я впервые их нашел.

Мой любимый идеал для javascript - веб-шторм, так как легко заставить работать intellitext в jQuery (позор, что он не бесплатный).

Кроме того, я бы не сказал, что он растет - уже повсеместно.

Ваши конкретные моменты:

Нет непосредственного способа найти точку входа функции

Я не понимаю этого, как это может быть проще?

Параметры передаются в функции без возможности узнать, какие свойства и функции доступны для этого параметра.

Если вы настроите свой идеал на включение определения объектов, свойства объекта будут доступны через intellitext (но я мог пропустить вашу точку зрения здесь).

Распространенное использование анонимных функций в качестве обратных вызовов, которое часто приводит к спагетти запутанных путей кода, которые вы не можете быстро перемещаться.

Общее использование? Если вам не нравятся анонимные функции, не используйте их. Или вы имеете в виду jQuery, который использует их в основном? jQuery, вероятно, рассматривается большинством веб-разработчиков как самая большая экономия времени в истории веб-разработки .

JSLint ловит некоторые ошибки перед выполнением

Он ловит их всех, вы можете включить их в свой идеал . Или Webstorm включает его по умолчанию (я думаю).

Чего мне не хватает?

Вам не хватает двух огромных преимуществ, которые Javascript имеет перед Java:

• Код Javascript составляет около одной четвертой размера эквивалентного кода Java.
• Вам никогда не придется ждать компиляции и перезапуска сервера.

Я работаю по-разному в Javascript. Я добавляю немного кода за раз, насколько это возможно, и могу обновить браузер и протестировать его. С jQuery, пара строк Javascript - это все, что мне нужно в большинстве случаев.

Я обнаружил, что программирование на Java относительно непродуктивно , и сейчас пишу весь свой серверный код на Groovy по тем же двум причинам.

Я знаю, что этот вопрос старый, но как программист на C ++ / C #, у которого были те же чувства, но который в последние 10 лет много писал на JavaScript, моей первой рекомендацией было бы попробовать Visual Studio Code .

Конечно, он не может предложить все функции, которые могут быть добавлены с помощью строго типизированного языка, но он довольно близко подходит.

Он также может взять информацию о типе из машинописного текста и применить ее к JavaScript. Даже если вы никогда не используете машинописный текст, вы можете получить завершение кода и документацию по множеству API, поскольку вы печатаете на JavaScript.

Так что на ваши вопросы

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

Кажется, в основном решается в VSCode?

• Параметры передаются в функции без возможности узнать, какие свойства и функции доступны для этого параметра.

Это решается для многих IDE путем документирования кода с помощью комментариев в стиле JSDoc или машинописного текста. Редакторы прочтут комментарии и дадут вам то же завершение, к которому вы привыкли

Распространенное использование анонимных функций в качестве обратных вызовов, которое часто приводит к спагетти запутанных путей кода, которые вы не можете быстро перемещаться.

Как программист C #, анонимные функции также распространены и были добавлены в C ++. Я думаю, что к этому нужно привыкнуть.

Кроме того, хотя обратные вызовы в основном были заменены обещаниями и async / await, и если у вас есть API, который использует обратный вызов, вы можете быстро обернуть его, чтобы использовать обещание, а затем использовать async / await, чтобы устранить проблему.

И, конечно же, JSLint ловит некоторые ошибки перед выполнением, но даже это не так удобно, как наличие красных волнистых линий под вашим кодом прямо в браузере.

Вы получите волнистые линии в коде Visual Studio. Кроме того, если вы включите интеграцию с ESLint, вы получите массу удивительных предупреждений и ошибок, выделенных в вашем редакторе. Больше, чем я видел на других языках. Мой опыт заключается в том, что линкеры для C / C # / Java были довольно жестко запрограммированы, поскольку ESLint является как массивно настраиваемым, так и массово расширяемым, и поэтому такие популярные библиотеки могут даже интегрироваться, чтобы давать вам советы и предупреждения о конкретном использовании библиотеки в редакторе. Что-то, чего я лично не видел на других языках (хотя, может быть, сейчас это распространено и на других языках?)

Это также 2018 год, и ES7 - новая норма, так что вы получите class. Вы всегда используете строгий режим. Вы никогда не используете varи всегда используете constи letмножество других вещей, которые программисты C ++ / C # / Java с трудом привыкли к исчезновению. Включите no-undefправило в ESLint и исчезнет еще больше проблем

Тем не менее, изучите, как на thisсамом деле работает и как на самом деле работают функции и методы, потому что это не то же самое, что C ++ / C # / Java.

Мои первые 2-3 года JavaScript были разочарованы. В какой-то момент все щелкнуло. Я перестал пытаться заставить его быть C ++ / C # / Java, и теперь я разочарован, возвращаясь назад, когда вещи, которые занимают 15 строк в JavaScript, занимают 150 в этих других языках.

Если вам нравятся IDE и вы используете их для затмения, проверьте Aptana как IDE для JavaScript. Я думаю, что это может сделать многое из того, что вы хотите. (Я лично ненавижу IDE, но это другой разговор).

Что касается анонимных функций, я считаю, что они являются наиболее мощной функцией в JavaScript, и попытка работать на языке, в котором их нет, на данный момент довольно болезненна.

Если вам нужно что-то еще, что можно скомпилировать в JavaScript, есть множество вариантов, CofffeeScript, Clojure и GWT - все это приходит на ум, но есть и другие.

Я еще не использовал его сам, но я видел некоторые демонстрации, и я очень впечатлен Cloud 9 как JavaScript IDE.

Вы можете выбрать модель онлайн-сервиса или скачать его с GitHub.

И как доказательство его качества в качестве IDE, Cloud9 был написан с использованием ... Cloud9!