Знакомство с CoffeeScript

[@vittore]

Вот скажите плиз, есть такой снипет

             $('div').hover(function(e){ ...}, function(e) {... })
     

Как это будет на coffeescript?

[@vasachi]

  $('div').hover(
      ((e) -> ...),((e) -> ...)
  )

[@vittore]

Ну то есть что было то и получил.

[@monolithed]

Можно проще:

$('div').hover \
  (e) -> 1,
  (e) -> 1 

[@murr]

Ну тут упрощать-то и некуда особо, разве что скобки убрать:

$('div').hover(
  (e) -> ,
  (e) ->
)

[@Mixail]

Я наоборот, обычно избавляюсь от скобок, но оставляю запятые:

$('div').hover (e) ->
        console.log 'success', e
    , (e) ->
        console.log 'err', e

[@monolithed]

Если вам нужно еще проще, то используйте LiveScript, там такая запись будет выглядеть так:

$ \div .hover (e) ->,  (e) ->

[@vittore]

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

[@bytecode_rus]

Я бы так записал:

$("div").hover (e) ->
  ...
,(e) ->
  ...

А вообще, по мне так самый полезный сайт для обучения coffee script, это вот этот — js2coffee.org/
Это конвертер из java script в coffee script и обратно

[@monolithed]

Ваш код не валиден

PS: не заметил пробел

[@bytecode_rus]

пробелы очень важны в coffee script, это да

[@vittore]

Знаю я этот сайт, как раз на моем примере он генерит неправильный код.

Хотя нет, сейчас уже правильный но лишние скобки не убирает

Исходный

$('div').hover(function(e){ $(this).find('span').show()}, function(e) { $(this).find('span').hide()})

Получилось

$("div").hover ((e) ->
  $(this).find("span").show()
), (e) ->
  $(this).find("span").hide()

И назад

$("div").hover ((e) ->
  e.find("span").show()
), (e) ->
  e.find("span").hide()

[@vittore]

И назад

$("div").hover((function(e) {
  return e.find("span").show();
}), function(e) {
  return e.find("span").hide();
});

[@bytecode_rus]

Я ввел:

$('div').hover(function(e){1}, function(e) {1})

Получил:

$("div").hover ((e) ->
  1
), (e) ->
  1

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

[@Azy]

  $('.shopping_cart').bind 'click', (event) =>
    @customer.purchase @cart

Как обратиться к свойствам обычного this?

[@ks7it]

Сам элемент можно получит как event.target. Есть ли кейсы, когда на самом деле нужен исходный this в этом примере?

[@drakmail]

  _this = @
  $('.shopping_cart').bind 'click', (event) ->
    _this.customer.purchase _this.cart
    # @ - "обычный" this. 

[@rock]

Но у CoffeeScript, есть преимущество, что ему не нужно сохранять совместимость с JavaScript...

Не нужно, но сохраняют совместимость с IE6 / ES3. В итоге получаем отсутствие поддержки нативных геттеров / сеттеров ES5 без костылей, большей части фишек ES6. Цитата:

Q: Will you add feature X where feature X depends on a platform?

A: No, implementation-specific features are not allowed as a policy. Everything that you write in CoffeeScript should be supported and runnable on any current JavaScript implementation (in practice, this means the lowest common denominator is IE6). Thus, features such as the following will not be implemented: getters & setters, yield

[@ks7it]

В IE геттеры/сеттеры появились только в 9-ке. В IE8 из ES5 реализовано крайне мало. А IE8 пока в большинстве случаев стараются поддерживать. Поэтому, если говорить про браузерный JavaScript, то ES5 можно использовать, к сожалению, далеко не везде.
Но в целом политика партии с поддержкой IE6, конечно, сдерживает сам язык, согласен.

[@ks7it]

Можно еще таким способом подключать: http://coffeescript.org/#scripts.
Но он не рекомендуется.

[@rock]

Есть.

<script src='/coffee-script.js'></script>
<script src='/app.coffee' type='text/coffeescript'></script>

Но в этом есть смысл только на этапе разработки — лишняя работа на клиенте.

[@omfg]

Зачем? Разберитесь с отдельной тулзой лучше, а лучше с командной строкой.

coffee --watch --map
будет сразу создавать source map и chrome developer tools к примеру, будет указывать ошибки именно в coffeeScript, а не в созданном из него js.

[@Waxer]

Если использовать jquery, то последнюю задачу можно решить тоже очень красиво и без coffeescript:

$(Array(5)).map(function(i) { return Math.pow(++i, 3); });

[@murr]

Я большой поклонник кофискрипта, но если вам он нужен только ради методов, вроде map, лучше обратить внимание на Underscore.js. Если вы из тех везунчиков, которым плевать на ИЕ8 и ниже, то даже библиотек никаких не нужно.

[@rock]

И нативный map, и undescore дырки в массиве, в отличии от jquery, пропускают. И правильно делают.
Это я к тому, что

_.map(Array(5),function(i){return Math.pow(++i, 3)}) //=> [undefined × 5]

[@Krovosos]

А прикольно.

Правильно ли понимаю, что конец определения класса определяется только отступом? И функции?

[@murr]

Да, как в питоне или фортране, все зависит от идентации.

[@Krovosos]

Забавно до чего доходит экономия :-)

[@murr]

На самом деле это вопрос привычки, через пару недель питона, coffe, sass/haml etc к форматированию отступами быстро привыкаешь и перестаешь обращать внимание.

[@HhyperR]

CoffeeScript очень хорошо сочетается с ExtJS, помогает бороться с большой вложенностью декларативного кода.

[@Dmitry_f]

Вот не понимаю: почему CoffeeScript так активно развивается и поддерживается, — в то время как ES6 Harmony, или, там, JS 1.7, 1.8 никому особенно не интересны? Ведь ES6 это развитие языка, тогда как CoffeeScript — странная побочная альтернатива.
Я бы с удовольствием переходил на новую версию JS с новыми фичами, чем на побочное отвтвление. Судя по описаниям возможностей, ES6 переплевывает Coffee.
Технически ведь разницы между ними нет — транслятор имеется как для Coffee, так и для ES6.

[@HhyperR]

Где есть транслятор ES6?

[@Dmitry_f]

Да вот же он

[@HhyperR]

Посмотрел. Я так понял это далеко не полный транслятор. Если тут перечислены все фичи, то в coffescript реализовано почти всё из этого, и ещё намного больше. Вряд ли все фичи ES6 можно эмулировать в ES5.

[@rock]

ES6 переплевывает Coffee.

Просто тут далеко не полное описание. В основном возможности соответствуют — arrow function (в ES6 только с лексическим this), rest/spred, генераторы, классы, деструктивное присваивание, аргументы по умолчанию, прочее… В IcedCoffeeScript await/defer сильно упрощает работу с асинхронными функциями — конечно не yield, но хоть что-то.
ES6 хорош скорее не синтаксисом, а расширением стандартной библиотеки — хотя бы Proxy чего стоит.
А вот по краткости и выразительности синтаксиса и кофе, и ES6 делает уже упомянутый в комментариях LiveScript.

[@Dmitry_f]

Посмотрел LiveScript — он невероятно хорош собой.
Игрался с Coffee, наткнулся на банальные проблемы:
1. Вызов функций теперь работает так: some_func param1, param2. Но как вызвать функцию без параметров? Приходится опускаться до JS-нотации: some_func(). В чем тогда смысл сокращенной нотации вызова функций, если можно все делать по-старинке? В LiveScript все просто: some_function!
2. Как заэкстендить объект в Coffee? — писать boilerplate code, который и в обычном JS пришлось бы писать. В LiveScript всё просто:

one = {a:1, b:2}
two = {b:3, c:4}
one <<< two

А если нужно один объект заэкстендить через прототип:

one = one with two

В остальном по мелочам в LiveScript много улучшений.
Нехватает только guards и clauses, и будет эрланг.

[@ks7it]

1. По-видимому, разработчики CoffeeScript просто хотели быть ближе к Ruby, но не получилось до конца. При вызове функции без параметров и без скобок не понятно, то ли мы вызываем функцию, то ли используем ссылку на нее. Тупик. Поэтому многие разработчики предпочитают всегда указывать скобки для консистентности.

[@homm]

Напишем простенький код на CoffeeScript:

square = (x) -> x * x
cube   = (x) -> square(x) * x

Его JavaScript-эквивалент:

(function() {
    
var cube, square;

square = function(x) {
  return x * x;
};

cube = function(x) {
  return square(x) * x;
};

}).call(this);

Неправда, это не эквивалент. Это избыточный результат компиляции. Вот эквивалент:

function square(x) { return x * x; };
function cube(x) { return square(x) * x; };

[@HhyperR]

А напишите неизбыточный эквивалент объявления по условию:

if prompt() == 'square'
  f = (x) -> x * x
else
  f = (x) -> x * x * x

[@lexazloy]

Math.pow(x, (prompt() == 'square'? 3: 2));

var map = {square: 3};

Math.pow(x, map[prompt()] || 2);

[@evil_random]

Кофескрипт, кофескрипт. Всё думал, что же он мне напоминает такое, и сейчас на ум сейчас приходит только сравнение с GUI-поделками для iptables — вроде всё есть, всё красиво показано, а как оно там скомпилируется одному богу известно.

Я считаю, что хорошему программисту javascript не нужен кофескрипт или что нибудь подобное для того чтобы писать красивый код. От лукавого это всё.

[@bytecode_rus]

Из своего опыта могу сказать, что вы не правы — все компилируется очень даже предсказуемо. Единственная, до сих пор сбивающая меня вещь — это то, что "==" заменяется на "===", а чтобы скомпилировалось в "==" надо писать «is»

[@rock]

is тоже компилируется в ===.

[@bytecode_rus]

Я же говорю, сбивающая вещь.

[@Verkholantsev]

C++, C++. Все красиво показано, а как оно там скомпилируется одному богу известно.
Я считаю, что хорошему программисту assembler не нужен C++ или что нибудь подобное для того чтобы писать красивый код. От лукавого это всё.

[@KAdot]

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

[@Verkholantsev]

Как же замечательно ваш комментарий переносится на JavaScript и CoffeeScript.

[@Ashot]

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

можете считать меня старым пердуном, но: не для одного мысли на CoffeeScript не выражаются нагляднее и не понимаются чужие?

[@bytecode_rus]

Я перечитал нсколько раз, и так и не понял вашу мысль. Если вы так же пишите на js, как по-русски в этом комментарии, вам точно стоит попробовать CoffeeScript.

[@Ashot]

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

сейчас идёт какая-то волна восхищения CoffeeScript, но как по мне — это тихий ужас: синтаксис нисколько не упрощает и не улучшает восприятие кода (сокращает количество строк да, но упрощением тут и не пахнет), все эти «->» «@» лишний визуальный мусор, отсутсвие фигурных скобок, обрамляющих тело функции, приводит к тому, что глазу не за что зацепиться и большой код превращается в кашу

теперь любители CoffeeScript могут называть меня консерватором, боящимся перемен, и закидывать помидорами :)

всё выше сказанное моё личное мнение.

[@Ashot]

конечно в IDE, просто со скобками чётче видно глазу, где функция начинается и заканчивается.

опять же, это моё мнение. я на нём не настаиваю и никому не навязываю

[@Krovosos]

Кстати, не лучше бы преобразовать в:

[«x=»,x,«y=»,y].join('')

?

[@homm]

… что даже лучше.

[@ks7it]

На первый взгляд решение с массивом строк и join должно однозначно выполнятся быстрее.
Ведь и правда, конкатенация большого количества строк в лоб, одну за другой должно создавать большое количество временных строковых объектов, которые потом надо вычищать сборщику мусора — это раз. Во-вторых, как не вспомнить легендарного маляра Шлемиэля (http://russian.joelonsoftware.com/Articles/BacktoBasics.html).

Но все дело в том, что современные JavaScript движки достаточно умные, чтобы не хило оптимизировать конкатенацию.
Подробно этот вопрос освещен здесь http://stackoverflow.com/questions/7299010/why-is-string-concatenation-faster-than-array-join.

[@VanSanblch]

Уберегает особенно начинающих разработчиков от многих ошибок.

Совсем не согласен. Возможно это мой субъективный опыт, но делал очень много ошибок когда пытался кодить на CoffeeScript. Постоянно приходилось проверять всё ли правильно сгенерировалось. А это время и рассеивание внимания.

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

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

[@ks7it]

Уберегает от ошибок именно в JavaScript. Но, конечно, открывает новые возможности — ошибиться в самом CoffeeScript. Это да. Другое дело, что возможностей выстрелить себе в ногу в чистом JavaScript гораздо больше.

Согласен, крайне важный момент — соответствие между CoffeeScript и JavaScript-кодом. Без поддержки со стороны инструментальных средств я в принципе не представляю себе серьезную разработку на CoffeeScript. Для все того же WebStrom описание здесь — http://www.jetbrains.com/webstorm/webhelp/coffeescript-support.html

[@alist]

А мы после года разработки на CoffeeScript отказались от него. Синтаксические преимущества не всегда очевидны, полно узких мест, в которых парсер выдает не то, что задумывал автор. Скорость разработки не выросла, но и с дебагом даже до сорсмэпов проблем мы не испытывали. Получилось, что в целом «шило на мыло», и при прочих равных команда предпочла остаться на JavaScript в новых проектах.

[@alist]

Естественно. WebStorm, SublimeText, GitHub, Jira, Jenkins, Confluence, Npm, LiveReload, etc.

В конце 2011 — первой половине 2012 уже была волна перехода на Coffee. Тогда многие его пробовали, кто-то бросал после недели, кто-то — после месяца, кто-то через год, а кто-то продолжает до сих пор. И те, кто бросал, соглашались в одном — плюсы и минусы примерно равны, а раз нет разницы, то зачем заморачиваться?

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

Если вам сегодня нравится Coffee, и вам он подходит, я рад за вас. Но для многих разработчиков это не шаг вперед, а шаг в сторону.

[@alist]

А JavaScript билда не требует? Конечно, можно не делать билда, но и CoffeeScript тоже можно скрипттагом подключать :) Мы так делали какое-то время, когда решали, пробовать — не пробовать. Даже @sourceUrl вставляли, чтобы в браузере заevalенные скрипты было видно, но быстро прекратили.

Так никто не делает — в последний раз фронтенд проект без билда я видел году в 2009 или раньше. Наш билд-процесс компилирует стили, собирает скрипты в бандлы, прогоняется JSHint'ом по ним, спрайты пересобирает, если нужно, тесты прогоняет. Причем мало что изменялось при переходе с JS на CS и обратно. И я думаю, у многих так.

[@alist]

Если они его не минифицируют, то почему бы комментариям не остаться? Кроме того, я вижу файл all.js — наверняка он не ручками собирается.

[@Newbilius]

Почитал, хм, создалось ощущение, что этот сахар только будет усложнять понимание.
В более многословном варианте всё-таки проще понять, что и где должно быть сделано

[@ks7it]

Добавление выразительных абстракций форсирует мышление. Синтаксические конструкции, которые делают ряд примитивных операций одним махом, позволяют лучше сфокусироваться на задаче и не раздувать код. Достаточно немного практики, чтобы привыкнуть к ним. В качестве бонуса будет легче изучать Python и Ruby. Просто потому, что CoffeeScript во многом опирался на эти языки.

[@estum]

Что ни говорите, но голый JS местами безобразный. Ну, для примера: объекты-классы без специальных оберток уродливы и нечитаемы. С чем-нибудь типа JSClass или Model.js, конечно, намного лучше, но это ведь еще одна библиотека на клиенте только ради красивого кода. А с Coffee все будут довольны: приятный глазу код у разработчика и скрипты без лишних модулей у клиента.

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

Чтобы понять как все будет компилиться, достаточно внимательно прочитать страницу справки на сайте и вики на гитхабе и потом ручками переписать какой-нибудь готовый скрипт в split-view (чтобы js был виден в процессе), подглядывая в кукбук, но не в js2coffee (он на потом; нужно понимать как выглядел бы его вывод в идеале и подправлять вручную). Скомпиленный в итоге код не обязан быть идентичным, а то я гляжу, некоторые зачем-то пытаются этого добиться.
Меня после описанных шагов настигло просветление, и я расстался с js раз и навсегда. (Ну почти навсегда — очень не хватает добротной CoffeeScript-консоли в панели разработчика, а к существующую приходится самому дописывать на досуге.)

Можно не тратить время на спор со злыми дядьками, которые угорают по всему нативному, о полезности таких инструментов. Если бы были стандарты постарше — не без костылей совместимые с современными, и чтоб построже да понажористей, — эти дядьки бы только их и считали православными, а всё остальное — шайтанскими безделушками. Нами же, подсевшими на CoffeeScript, Slim и SASS, возможно как и их авторами, движет лень и утомление от дедовских методов.

[@termi]

Попробовал я CoffeScript и пока не впечатлился. Две вещи, которые я нашел странными в CS:
1. Нету тернарного оператора, конструкция на CS получается страшнее чем на JS:

healthy = if 200 > cholesterol then 1 else 0

Даже «замена» тернарного оператора не поддерживает элементарный синтаксис, который я не часто использую, но всё же использую.

let a = 1, b = a ? (console.log("good"), true) : false;

на CS выдаёт синтактическую ошибку:

a = 1; b = if a then (console.log "good", true) else false

2. Деструктуризация не реализована полностью. Пока я натолкнулся на то, что не поддерживаются разряженные массивы в качестве шаблона для деструктуризации:

arr = [1,2,3]
[a, , b] = arr #тут ошибка

[@termi]

Поправка по первому пункту:
Так работает

a = 1; b = if a then (console.log "good"; true) else false

[@VBauer]

gist.github.com/Spaceghost/9055820