Каковы плюсы и минусы Coffeescript? [закрыто]

48

Конечно, один большой плюс - это количество синтаксического сахара, которое во многих случаях приводит к сокращению кода. На http://jashkenas.github.com/coffee-script/ есть впечатляющие примеры. С другой стороны, я сомневаюсь, что эти примеры представляют собой код сложных реальных приложений. Например, в моем коде я никогда не добавляю функции к голым объектам, а скорее к их прототипам. Более того, функция прототипа скрыта от пользователя, предлагая классический ООП, а не идиоматический Javascript.

Пример понимания массива будет выглядеть в моем коде, вероятно, так:

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...
Филипп
источник
7
Это не понимание массива. Это JQuery.map ().
Рейн Хенрикс
1
Конечно, поэтому я имею в виду не «понимание массива», а «пример понимания массива [на сайте]».
Филипп
Справедливо. Я хотел сказать, что foldl (map) является в некотором роде вырожденным случаем понимания списка (который, как правило, более мощный).
Рейн Хенрикс
Ну, в общем, я задаю этот вопрос, потому что мне интересно, является ли глупым решение использовать Javascript, а не Coffeescript. Я согласен, понимание массива намного мощнее, с другой стороны, никто не станет утверждать, что Python более мощный, чем Ruby, из-за понимания массива и маркировки блоков с помощью отступа, а не начала / конца.
Филипп
Rails сделал кофейный скрипт драгоценным камнем по умолчанию. Это вызвало "обсуждение" github.com/rails/rails/commit/…
generalhenry

Ответы:

53

Я являюсь автором будущей книги о CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

Я был убежден, что CoffeeScript стоит использовать примерно после недели игры с ним, хотя в то время языку было всего несколько месяцев, и у него было гораздо больше неровностей, чем сейчас. Официальный сайт делает большую работу по перечислению (большей части) возможностей языка, поэтому я не буду повторять их здесь. Скорее, я просто скажу, что плюсы языка:

  1. Поощряет использование хороших шаблонов JavaScript
  2. Не поощряет анти-паттерны JavaScript
  3. Делает даже хороший JavaScript-код короче и более читабельным

№ 3 привлекает гораздо больше внимания, чем первые два (даже в моей книге), но чем больше я об этом думаю, тем больше понимаю, что не сделал прыжок только из-за симпатичного синтаксиса; Я сделал скачок, потому что язык подтолкнул меня к лучшему, менее подверженному ошибкам JavaScript. Чтобы привести несколько быстрых примеров:

  • Поскольку переменные имеют автоматическую область видимости, вы не можете случайно перезаписать глобальные переменные, пропустив var, скрыв переменную с тем же именем (за исключением именованных аргументов), или разместив переменные в разных файлах, которые взаимодействуют (см. Https://stackoverflow.com/questions). / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
  • Потому ->что чертовски проще писать, чем function(){}проще использовать обратные вызовы. Семантический отступ дает понять, когда обратные вызовы вложены. И =>облегчает сохранение thisпри необходимости.
  • Потому что unless xпроще для носителей английского языка , чтобы разобрать , чем if (!x)и if x?проще , чем if (x != null), чтобы дать только два примера, вы можете тратить меньше циклов мозга на логическом синтаксисе и больше на самой логики.

Отличная библиотека, такая как Underscore.js, может позаботиться о некоторых из этих проблем, но не обо всех.

Теперь о минусах:

  1. Компиляция может быть болью. Синтаксические ошибки, которые выдает компилятор CoffeeScript, часто расплывчаты. Я ожидаю прогресса в этом направлении в будущем. (В защиту компилятора он часто улавливает вещи, которые - если вы написали их в JavaScript - вы не обнаружите как ошибку, пока не запустится эта строка кода. Лучше ловить эти ошибки раньше, чем позже.)
  2. Относительно отладки может быть боль. Пока еще нет способа сопоставить скомпилированные строки JS с оригинальным CoffeeScript (хотя люди из Firefox обещали, что это произойдет).
  3. Это склонно к изменениям. Ваш код может работать иначе или вообще не работать в будущей версии CoffeeScript. Конечно, так обстоит дело с большинством языков - переход на новую версию Ruby или Python аналогичен - но это не относится к JavaScript, где можно разумно ожидать, что код, который хорошо работает в основных браузерах сегодня, будет нормально работать во всех основных браузеры столько времени, сколько существует сеть.
  4. Это не так хорошо известно. JavaScript является языком общения . CoffeeScript стал очень популярным за короткое время, но маловероятно, что он когда-либо будет пользоваться таким большим сообществом, как JavaScript.

Очевидно, я думаю, что плюсы перевешивают минусы лично для меня, но это не будет иметь место для каждого человека, команды или проекта. (Даже Джереми Ашкенас пишет много JavaScript.) CoffeeScript лучше всего рассматривать как прекрасное дополнение к JavaScript, а не замена.

Тревор Бернхэм
источник
2
Воу, воу, воу, как в мире я пропустил =>документацию? Это круто . (Другие моменты тоже были хорошими - очень хороший непредвзятый ответ с честным списком минусов. :)
Мишель Тилли
Спасибо за ваш подробный ответ. Хотя я немного подожду, чтобы принять это, было бы интересно иметь плюсы и минусы с учетом различных подходов ООП.
Филипп
2
Я бы сказал, что модель классов CoffeeScript более доступна для новичков, чем модель прототипов JavaScript, и поддерживает передовой опыт (в частности, определение ваших прототипов в одном месте, а не разбрасывание Foo.prototype.bar = ...линий по всему, что является безумием!). Это отличный способ аккуратно организовать код. С другой стороны, это может заставить людей использовать ООП, даже если функциональный подход намного элегантнее.
Тревор Бёрнхем
Некоторая часть логики отступов ведет себя не совсем так, как ожидалось, вы должны взглянуть на базовый JS, чтобы убедиться, что он сделал что-то странное. Это может быть частью набора правил tbh, но это не всегда очевидно по сравнению с другими отступными сентиментальными языками, такими как Py, и я обнаружил, что это может генерировать более тонкие ошибки, чем те, которые он призван предотвратить. Я все еще использую CoffeeScript, хотя
sa93
1
Пункты 1 и 2 нуждаются в деталях. Я думаю, что ответ Эндрю дает хороший пример № 3 в виде смешанной сумки. Я не согласен с пулями: забывать о var - это глупо, и вам не нужно сталкиваться с большим количеством глобальных переменных, во-первых, «функция» не сложная - заранее заданные именованные методы даже меньше, «if (! X») ) «является коротким и приятным и« если »делает его более многословным (см. свой предыдущий пункт и пункт 3), и сходство человеческого языка на самом деле не является целью проектирования, которая исторически имела большой успех в языках программирования. Нам нужно быть на связи с человеком и машиной.
Эрик Реппен
30

У нас есть довольно большая кодовая база JavaScript, и около месяца назад мы решили попробовать CoffeeScript. Один из наших разработчиков начал с миграции одного из наших модулей с JS на CS с использованием http://js2coffee.org/ . Этот инструмент был довольно удобен, и портирование более чем 1000 строк JavaScript заняло около двух-трех часов. Некоторые наблюдения, которые мы заметили в этот момент:

  1. Полученный код CoffeeScript был вполне читабельным.

  2. Мы скомпилировали его обратно в JavaScript, и было довольно легко ориентироваться и отлаживать. Пока мы переносили этот модуль, другой разработчик из нашей команды обнаружил в нем ошибку. Эти два разработчика исправили эту ошибку в нашем старом коде JavaScript и в новом коде JavaScript, который вышел из компилятора CS. Они работали независимо, и это заняло у них примерно одинаковое количество времени (15-20 минут).

  3. Из-за того, что это был порт, полученный код не использовал специфичные для Coffee функции, которые были бы уместны или желательны. Если бы мы писали на CoffeeScript с нуля, код был бы более идиоматичным. Из-за этого позже мы решили, что не будем переносить существующий код.

  4. В целом читаемость более короткой функции и меньшего объекта увеличилась до некоторой степени. Однако, для более длинных методов это не имело место вообще. Самая большая экономия на вздор поступила ->явно и явно return, но кроме этого наш код не стал значительно короче или проще. Некоторые части синтаксиса казались довольно запутанными, особенно объектные литералы. CS опускает фигурные скобки вокруг определений членов и объединяется с «все-что-выражением» и подразумевается, returnчто делает некоторые фрагменты кода довольно трудными для чтения.

    Вот JavaScript:

    var rabbitGenerator = {
        makeRabbit: function(rabbitName, growCarrots) {
            if (growCarrots) {
                carrots.growMore(10);
            } else {
                carrots.ensureSupply();
            }
            return {
                name: rabbitName, 
                height: 0,
                actions: {
                    jump: function (height) {
                        this.height += height;
                    },
                    eatCarrot: function () {
                        // etc
                    }
                }
            };
        },
        // more members
    }

    А вот как будет выглядеть соответствующий код CoffeeScript:

    rabbitGenerator = 
      makeRabbit: (rabbitName, growCarrots) ->
        if growCarrots
          carrots.growMore 10
        else
          carrots.ensureSupply()
        name: rabbitName // (*)
        height: 0
        actions: 
          jump: (height) ->
            @height += height
    
          eatCarrot: ->

    Поскольку сейчас довольно сложно понять, что оператор return начинается со (*)строки. В нашем проекте мы сильно полагаемся на объектные литералы: мы передаем их в качестве параметров функции и возвращаем их из других функций. Во многих случаях эти объекты имеют тенденцию быть довольно сложными: с членами разных типов и несколькими уровнями вложенности. В нашем случае общее ощущение заключалось в том, что код CoffeeScript на самом деле труднее читать, чем простой код JavaScript.

  5. Хотя отладка CoffeeScript оказалась проще, чем мы ожидали, опыт редактирования несколько ухудшился. Мы не смогли найти хорошего редактора / IDE для этого языка. Мы не стандартизировали редактор / IDE для клиентского кода для нашего проекта, и на самом деле мы все используем разные инструменты. Фактически, все в команде согласны с тем, что когда они переключаются на CoffeeScript, они получают довольно слабую поддержку от своего инструмента. Плагины IDE и редактора находятся в очень ранней форме, а в некоторых случаях они даже не могут дать нам правильную подсветку синтаксиса или поддержку отступов. Не говорю о фрагментах кода или рефакторинге. Мы используем WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ и SublimeText2.

  6. Говоря об инструментах, я должен упомянуть, что сам компилятор CoffeScript поставляется как пакет Node JS. Мы являемся в первую очередь магазином Java / .NET, поэтому все занимаются разработкой под Windows. До недавнего времени поддержка Windows в Node практически отсутствовала. Мы не могли заставить компилятор CoffeeScript работать под Windows, поэтому в настоящее время мы решили использовать <script type="text/coffeescript">тэги и браузерный компилятор «на лету».

    Компилятор довольно быстрый и не сильно увеличивает время запуска. Недостатком является то, что полученный JavaScript становится evalредактируемым, и немного сложно установить в нем контрольные точки в инструментах разработчика браузеров (особенно в IE8). Если у нас возникают трудности с отладкой, мы предварительно скомпилируем код CoffeeScript с помощью того же инструмента миграции, который я перечислил выше, но это все же не очень удобно.

  7. Другие обещания CoffeeScript, такие как автоматическая varвставка или полупрозрачное управление thisоператором с толстой стрелкой ( =>), не дали такого большого эффекта, как мы надеялись. Мы уже используем JSLint как часть нашего процесса сборки и пишем код в ES3 x ES5-Strictподмножестве языка. В любом случае, тот факт, что Coffee производит такой же «чистый» код, - это хорошо . Желаю, чтобы каждая серверная среда тоже создавала корректную разметку HTML5 и CSS3!

    Тем не менее, я бы не сказал, что CoffeeScript экономит много времени, помещая varдля меня ключевые слова. Пропавшие без вести varлегко распознаются JSLint и легко исправимы. Более того, как только вы это исправите в течение некоторого времени, вы все равно автоматически начнете писать хороший JavaScript . Таким образом , я бы не сказал , Кофе действительно , что полезен в этом отношении.

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

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

Андрей Андрей Листочкин
источник
10

Pros

просмотреть ответ Тревора Бернхэма .

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

Cons

CoffeeScript - это не что иное, как синтаксические сахарные и розовые очки.

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

Для тяжелых вещей - вы должны понимать свою среду. И ваш носитель - HTML, DOM и CSS, Javascript - это просто инструмент для их соединения, но все API написаны специально для Javascript. Использование другого языка, который затем будет скомпилирован в «настоящий», - довольно рискованно, будь то Java (GWT), Dart или CoffeeScript.

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

Поддержка IDE для Coffeescript еще хуже, чем для JS.

C69
источник
JavaScript - это нечто большее, чем просто «инструмент для их соединения» в крупномасштабных, высокодинамичных веб-приложениях. Количество JS в библиотеках, таких как React или Angular, даже jQuery, является тому примером.
Энди
6

Самым большим профессионалом, на мой взгляд, является:

Прямой coffescript компилируется в javascript, который вы должны были написать, но не сделали, потому что он не был простым.

Есть некоторые неприятные углы javascript, которых следует избегать только с бдительностью - примеры из головы:

  • правильная установка прототипа
  • используя === вместо ==
  • проверка на ноль
  • объявляя все переменные с помощью var
  • оборачивая все в самозапускающуюся анонимную функцию.

Если вы пишете coffeescript, все это обрабатывается для вас автоматически .

Минусы, ИМО, в основном незначительные:

  • Отладка это боль
  • Есть меньше программистов Coffeescript
  • Вы должны перевести документацию с javascript на coffeescript.
Шон Макмиллан
источник
3

профи

  1. CoffeeScript помог мне узнать больше о JavaScript
  2. довольно легко читается, даже для сложных вложенных обратных вызовов
  3. обеспечивает безопасность в некоторых трудных для JavaScript проблемах с языком

Приведенный выше пример работы Андрея, который я нашел, был поучительным. Я полагаю, что удобочитаемость их существенных объектных литеральных возвращений была бы улучшена, просто вручную идентифицируя возвращаемый результат

вернуть

// объектный литерал здесь

Инструменты IDE были улучшены, TextMate и Cloud9 поддерживают CoffeeScript. По общему признанию поддержка Windows отстает (разве это не верно для веб-разработки вообще?)

минусы

Интерпретированный браузером CoffeeScript может быть сложным для отладки.

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

user38265
источник
0

профи

  1. они действительно оптимизировали типичные случаи синтетически, фактически, CoffeeScript является одним из, если не самым лаконичным языком, который «обычно» используется http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- по-выразительности /
  2. скрывает плохие части JavaScript (автоматическое приведение ==, неявные глобальные переменные, более традиционная система классов облегчает общие вещи)
  3. очень легко выучить для программистов на Python / Ruby
  4. многострочные анонимные функции + синтаксис пробелов

минусы

  1. удаление var означает, что вы не можете изменить переменную внешней области во внутренней области, не используя объект, или `var fall_back_to_js;` hacks [почему бы не другой оператор присваивания ': =', который только переназначает значение, так что obj.naem: = 5 опечаток легче отлаживать]
  2. вы должны сообщить об этом каждому инструменту, если только вы не хотите отлаживать JavaScript :(; кстати: вы можете отлаживать CoffeeScript из Chrome, добавив поддержку исходных карт; yeoman (npm install yeoman) может помочь вам написать файл конфигурации gulp или grunt для CoffeeScript
  3. нет дополнительной статической типизации (нужно дождаться следующего стандарта EcmaScript)
  4. все еще нужны сторонние библиотеки для модульной системы
  5. Синтаксические ловушки должны быть осторожны: неявные возвраты, abgo означает a (b (g (o))) , fp, b: 2, c: 8 означает f (p, {b: 2, c: 8}), а не f (p, {b: 2}, {c: 8})
  6. не меняет сломанную систему счисления / тип JavaScript
aoeu256
источник