У нас есть довольно большая кодовая база JavaScript, и около месяца назад мы решили попробовать CoffeeScript. Один из наших разработчиков начал с миграции одного из наших модулей с JS на CS с использованием http://js2coffee.org/ . Этот инструмент был довольно удобен, и портирование более чем 1000 строк JavaScript заняло около двух-трех часов. Некоторые наблюдения, которые мы заметили в этот момент:
Полученный код CoffeeScript был вполне читабельным.
Мы скомпилировали его обратно в JavaScript, и было довольно легко ориентироваться и отлаживать. Пока мы переносили этот модуль, другой разработчик из нашей команды обнаружил в нем ошибку. Эти два разработчика исправили эту ошибку в нашем старом коде JavaScript и в новом коде JavaScript, который вышел из компилятора CS. Они работали независимо, и это заняло у них примерно одинаковое количество времени (15-20 минут).
Из-за того, что это был порт, полученный код не использовал специфичные для Coffee функции, которые были бы уместны или желательны. Если бы мы писали на CoffeeScript с нуля, код был бы более идиоматичным. Из-за этого позже мы решили, что не будем переносить существующий код.
В целом читаемость более короткой функции и меньшего объекта увеличилась до некоторой степени. Однако, для более длинных методов это не имело место вообще. Самая большая экономия на вздор поступила ->явно и явно 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.
Хотя отладка CoffeeScript оказалась проще, чем мы ожидали, опыт редактирования несколько ухудшился. Мы не смогли найти хорошего редактора / IDE для этого языка. Мы не стандартизировали редактор / IDE для клиентского кода для нашего проекта, и на самом деле мы все используем разные инструменты. Фактически, все в команде согласны с тем, что когда они переключаются на CoffeeScript, они получают довольно слабую поддержку от своего инструмента. Плагины IDE и редактора находятся в очень ранней форме, а в некоторых случаях они даже не могут дать нам правильную подсветку синтаксиса или поддержку отступов. Не говорю о фрагментах кода или рефакторинге. Мы используем WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ и SublimeText2.
Говоря об инструментах, я должен упомянуть, что сам компилятор CoffeScript поставляется как пакет Node JS. Мы являемся в первую очередь магазином Java / .NET, поэтому все занимаются разработкой под Windows. До недавнего времени поддержка Windows в Node практически отсутствовала. Мы не могли заставить компилятор CoffeeScript работать под Windows, поэтому в настоящее время мы решили использовать <script type="text/coffeescript">тэги и браузерный компилятор «на лету».
Компилятор довольно быстрый и не сильно увеличивает время запуска. Недостатком является то, что полученный JavaScript становится evalредактируемым, и немного сложно установить в нем контрольные точки в инструментах разработчика браузеров (особенно в IE8). Если у нас возникают трудности с отладкой, мы предварительно скомпилируем код CoffeeScript с помощью того же инструмента миграции, который я перечислил выше, но это все же не очень удобно.
Другие обещания CoffeeScript, такие как автоматическая varвставка или полупрозрачное управление thisоператором с толстой стрелкой ( =>), не дали такого большого эффекта, как мы надеялись. Мы уже используем JSLint как часть нашего процесса сборки и пишем код в ES3 x ES5-Strictподмножестве языка. В любом случае, тот факт, что Coffee производит такой же «чистый» код, - это хорошо . Желаю, чтобы каждая серверная среда тоже создавала корректную разметку HTML5 и CSS3!
Тем не менее, я бы не сказал, что CoffeeScript экономит много времени, помещая varдля меня ключевые слова. Пропавшие без вести varлегко распознаются JSLint и легко исправимы. Более того, как только вы это исправите в течение некоторого времени, вы все равно автоматически начнете писать хороший JavaScript . Таким образом , я бы не сказал , Кофе действительно , что полезен в этом отношении.
Мы оценивали CoffeeScript около недели. Все члены команды писали код, и мы делились друг с другом своим опытом. Мы написали новый код и портировали существующий код, когда посчитали нужным. Наши чувства по поводу языка были смешанными.
В целом, я бы сказал, что это не ускорило наше развитие, но и не замедлило нас. Некоторый прирост скорости из-за меньшего набора текста и меньшей поверхности ошибок был компенсирован замедлением в других областях, в основном с поддержкой инструментов. Через неделю мы решили, что не будем обязывать использовать CoffeeScript, но и не будем его запрещать . При наличии свободного выбора на практике никто не использует его, по крайней мере, на данный момент. Время от времени я думаю о прототипировании какой-то новой функции в нем, а затем преобразую код в JavaScript перед интеграцией с остальной частью проекта, чтобы получить более быстрое начало, но я еще не пробовал этот подход.