Comments 69
Больше всего радует новый синтаксис строк. Решение использовать обратный апостроф просто гениально
>В ES5 мы вынуждены ссылаться на this определяя функцию:
Еще можно так(вдруг кто-нибудь еще не знает):
var self = this;
$("buttob").on("click", function() {
// do something with self
});
Еще можно так(вдруг кто-нибудь еще не знает):
$("buttob").on("click", function() {
// do something with this
}.bind(this));
Ну так никто не скрывает, что многое в ES6 — это просто сахар. Можно будет писать на чистом ES6 уже сегодня, со всем плюшками синтаксиса, а чтобы работало везде — транслировать в ES5 совместимый код. По идее, такая трансляция это такое же зло, как и с CoffeeScript, но тут все же мы пишем на нашем родном JS, и когда будет нужно, просто выключим эту самую трансляцию.
и когда будет нужно, просто выключим эту самую трансляцию
Это представляется сколько-нибудь реальным? Ведь это будет означает отказ от всех браузеров с es5 only.
Ну как сказать. Когда анонсировали WebGL я подумал, «как это круто, обязательно вернусь к этой теме лет через 10». А оно вон как все оказалось. Вся штука в том, что на ES6 можно писать уже сейчас.
А зачем? Если у вас требование писать под es5-браузеры — используете 6to5. Если нет — не используете.
Судя по тому что уже сейчас поддерживает v8, к выходу стандарта (вроде как лето 2015) chrome уже будет поддерживать если не весь, то почти весь стандарт.
Судя по тому что уже сейчас поддерживает v8, к выходу стандарта (вроде как лето 2015) chrome уже будет поддерживать если не весь, то почти весь стандарт.
и вот та самая ссылка, которую все давно ждали
kangax.github.io/compat-table/es6
пока все немного грустно. в частности с IE.
через год-полтора можно попробовать ещё раз
kangax.github.io/compat-table/es6
пока все немного грустно. в частности с IE.
через год-полтора можно попробовать ещё раз
С наследованием классов в IE10 и более ранними есть ряд проблем 6to5.org/docs/usage/caveats/
Сахарок в кофе слаще! Отступы стеной разделяют. А про пустые скобки сказано, что это плохой тон. И js2.coffee только что обновился, вот это радостная новость! Печально наблюдать фобию на CoffeeScript у некоторых пациентов.
При всей моей любви к кофе, не вижу в нём сахарка для настоящих приватных свойств, асинхронщины (ладно, хоть какая-то есть в iced кофе :)), jsx… Да хотя бы сахара для работы с протоколом итераторов (как
Map или Set обходить — через forEach? :))… мало того, даже синтаксиса для генераторов (а как без них, например, на koa писать? :)), геттеров / сеттеров нет. Потому как его развитие остановилось на IE6. Есть, конечно, LiveScript с его сахаром для многого, но и он уже не развивается. А классический кофе сейчас только для тех, кому лень больше вечера на изучение языка потратить или старый проект в рамках зажал.А нет, вру, глянул changelog — неделю назад добавили в кофе поддержку генераторов. Шел 2015й год…
Спасибо за указание фич ES6, отсутствующих в CoffeeScript. Вы забыли геттеры-сеттеры.
Я вот от CoffeeScript не могу отказаться не потому, что старые проекты написаны на нем. А потому, что он существенно экономит мое время и увеличивает продуктивность. Я бы, наверно, не стал фронтенд-разработчиком, если бы не CoffeeScript, и ушел бы в бэкенд на Ruby.
Я вот от CoffeeScript не могу отказаться не потому, что старые проекты написаны на нем. А потому, что он существенно экономит мое время и увеличивает продуктивность. Я бы, наверно, не стал фронтенд-разработчиком, если бы не CoffeeScript, и ушел бы в бэкенд на Ruby.
Не забыл :) Фичи, что указал, не только из ES6, но и из, например, ES7, что поддерживает рассматриваемый в статье 6to5. Кофе — штука хорошая, но если уж к современным реалиям адаптировать его не торопятся, нужен новый кофе-подобный язык с поддержкой возможностей ES6+.
> нужен новый кофе-подобный язык с поддержкой возможностей ES6+.
Согласен, я даже на прошлой неделе создал по этому поводу ветку обсуждения в одном CoffeeScript'овом community: github.com/coffeescript-cookbook/coffeescript-cookbook.github.io/issues/128
Пока что всё глухо.
Надо написать статью, поштучно сравнивающую фичи ES6 с таковыми у CoffeeScript. Тогда станет очевиден масштаб проблемы.
И, если уж создавать новый язык, то он должен использовать синтаксис ES6 как в ES6, а для своих фич использовать неконфликтующие конструкции.
Согласен, я даже на прошлой неделе создал по этому поводу ветку обсуждения в одном CoffeeScript'овом community: github.com/coffeescript-cookbook/coffeescript-cookbook.github.io/issues/128
Пока что всё глухо.
Надо написать статью, поштучно сравнивающую фичи ES6 с таковыми у CoffeeScript. Тогда станет очевиден масштаб проблемы.
И, если уж создавать новый язык, то он должен использовать синтаксис ES6 как в ES6, а для своих фич использовать неконфликтующие конструкции.
Про Map
Это не тот Map :) Почитайте про протокол итераторов.
Чем оно мне поможет по сравнению с генератором массивов?
Ну непонятно же :)
Ну непонятно же :)
Тем, что это — структура данных, а не операция :) Соответствующая операция, кстати, также в ES7 присутствует — с ссылочками, что выше привёл, ознакомьтесь.
Я слышу: тем, что это молоток, а не пила.
Куда его присунуть? Мне бы сравнительный пример. :)
Куда его присунуть? Мне бы сравнительный пример. :)
Вы не можете придумать кейс для ассоциативного массива? При том, что
Object не является полноценным ассоциативным массивом, Map может принимать в качестве ключей что угодно, а не только строки, имеет свойство size, метод forEach и итераторы? :)А классический кофе сейчас только для тех, кому лень больше вечера на изучение языка потратить или старый проект в рамках зажал.
Прекрасно себя чуйствую в Метеоре. Правда потихоньку перевожу-осваиваю lodash.
Lodash / underscope вроде бы существует и как js, и как npm пакет, и в метеор и то и то неплохо подключается без магии. Наверно формулировка не очень удачная, иначе не понимаю зачем его в кофе/метеор переводить.
Поясню, underscope прикручен штатно в Метеоре. Народ ноет, что давайте поменяем на lodash. Так я выкупил lodash.ru и заделался в переводчики. :)
Wanted translators: github.com/comerc/lodash-ru
Только underscore, а не underscope.
приватных нет, хотя с этим у всех (типоскрипт, кофе, дарт) кошмар из-за того, что обратная совместимость нужна.
асинхронщины — yield и генераторы ввели, как вы видели (сам в шоке о__О)
обходить через (может не лучшее решение, но если очень хочется и действительно надо, то почему нет?)
Вообще ES6 сам приватных не даёт по сути тоже. И это уже напрягает =)
Кофе дал сахар. Он работает. Радует =)
А ES6 даёт другой сахар. Но он не работает (строго говоря «частично» == «не»). Дали компилятор в ES5. Не работает. Дали core.js. Заработало. Но мееееедлено. Выходит фатальная ситуация: чем старше браузер, тем медленнее в квадрате (не оптимизированная JVM + тьма кода)
Так зачем учить язык, от которого сейчас больше вреда, чем пользы? =) Перспектива, скорость в мажорных браузерах, сахар, понимание направления развития? =)
асинхронщины — yield и генераторы ввели, как вы видели (сам в шоке о__О)
обходить через (может не лучшее решение, но если очень хочется и действительно надо, то почему нет?)
values = `[...mapObject.values]`
for value in values
yaYa value
Вообще ES6 сам приватных не даёт по сути тоже. И это уже напрягает =)
Кофе дал сахар. Он работает. Радует =)
А ES6 даёт другой сахар. Но он не работает (строго говоря «частично» == «не»). Дали компилятор в ES5. Не работает. Дали core.js. Заработало. Но мееееедлено. Выходит фатальная ситуация: чем старше браузер, тем медленнее в квадрате (не оптимизированная JVM + тьма кода)
Так зачем учить язык, от которого сейчас больше вреда, чем пользы? =) Перспектива, скорость в мажорных браузерах, сахар, понимание направления развития? =)
асинхронщины — yield и генераторы ввели
Надеюсь, вы понимаете, что добавили только поддержку синтаксиса, а не компиляцию, то есть можно использовать либо только на ноде 0.11+, либо после прогоняя через тот же 6to5 / регенератор?
обходить через...
Можно, но страшно и для этого нужна поддержка spread в JS — аналогично, только в связке с 6to5. Проще использовать сразу
Array.from, что под катом spread в 6to5, но это, опять же, core-js или другой полифил. А ещё проще обходить через forEach.Дальше довольно странная цепочка рассуждений, логики не вижу.
Но мееееедлено.
А вот тут вы, в некоторой мере, правы. Если core-js я писал так, что бы оверхеда был минимум, то у 6to5 главный приоритет — максимальное соответствие ES6 и иногда за это приходится расплачиваться прозводительностью. Это исправляет loose mode — классы на выходе аналогичны кофе,
for-of работает с массивами без итераторов.Выходит фатальная ситуация: чем старше браузер, тем медленнее в квадрате (не оптимизированная JVM + тьма кода)
Вы пишите критичный к производительности код для древних браузеров? Как по мне, скорость критична только в современных, а в древних главное, что бы хоть как-то работало. Да, и какое к этому имеет отношение JVM? :)
Так зачем учить язык, от которого сейчас больше вреда, чем пользы?
Вреда? Ну уж вреда-то от него точно нет. Зачем учить? Его через пару лет всё равно учить придётся, почему не сейчас?
Надеюсь, вы понимаете, что добавили только поддержку синтаксиса, а не компиляцию, то есть можно использовать либо только на ноде 0.11+, либо после прогоняя через тот же 6to5 / регенератор?
Так, а вы хотите, чтобы в кофе компилил это в ES5 представления? Было бы круто. Но остальная поддержка ES6, о которой говорите в целом, от этого не появится =)
А ещё проще обходить через forEach.
Вы знали, что скажу про производительность? Знали. И я скажу: forEach это жуть как долго
Как по мне, скорость критична только в современных, а в древних главное, что бы хоть как-то работало
Увы, браузер 4 андроида нельзя назвать древним. Но и нельзя назвать невостребованным. Как и 8 сафари мобильный. А там вообще нихтмихнайн! =( (про ВчМ планшетов умолчу).
Под вредом понимаю компиляцию в ES5 представления с ухудшением производительности. И эта самая компиляция нужна >50% браузеров. Интересно, есть ли хоть где готовый модуль, который по UA поймёт можно отдавать ES6 или надо отдавать ES5from6 код?)
Я лучше кофе дальше модифицировать буду =)) Проанализирую yield&generators в 6to5 может разберусь на днях)
Извините, но вы несёте откровенную чушь. Обход объекта через протокол итераторов сравним по скорости с обходом через
forEach, погоняйте тесты. Преимуществ по скорости в мобильных браузерах у кофе, по сравнению с 6to5 в loose mode, я не вижу.Антарес тоже сравним с Солнцем, почти 3 порядка дельты)
Так я про сравнение
Вообще производительность Map меня в осадок отправила…
jsperf.com/array-set-map
Так я про сравнение
for v in array (coffee) и forEach (массив ли, мап или сет, не суть). Прогонял и не раз. Год назад была от пол порядка до порядка. М.б. протокол итераторов так непрост и в принципе не быстр. Не имел возможности проверить.Вообще производительность Map меня в осадок отправила…
jsperf.com/array-set-map
Гениально! Вместо того, что бы сравнить скорость обхода через протокол итераторов и через
forEach, вы сравниваете скорость обхода массива по индексу с обходом не индексированных коллекций по протоколу итераторов, и удивляетесь, что скрытый вызов метода next итератора медленнее получения элемента по индексу. Ладно бы хоть с обходом объекта через for-in сравнили, всё ближе…В ES6 скобки требуется вне зависимости от наличия параметров:
А вот и нет.
[1, 2, 3].map(n => n * n); // неявный return
foo(a => {
console.log(a);
});
И только без аргументов нельзя опускать скобки, то есть нужно явно
() => {}
«JavaScript strings can only span a single line »
Это в ECMAScript3, если не ошибаюсь. Пятая версия позволяет определять многострочные строковые литералы, требуя, чтобы все строки в его составе, кроме последней, заканчивались обратным слешем.
Не сочтите за троллинг, но зачем отказываться от CoffeeScript?
Единственная фича ES6, которая в CS недоступна, это геттеры-сеттеры. Но это решается использованием несложного хелпера.
Все отстальные фичи либо доступны напрямую, использованием транспайлера вроде того же 6to5, полифиллов или сторонних библиотек (например, промисы), либо через экранирование (модули), либо ре либо реализованы в CS, причем, зачастую лучше (rest-spread, destructuring assignment, multiline strings, string interpolation, classes...). Некоторые фичи ES6 не имеют прямого аналога в CS, но имеют годную замену (например, do вместо let, fat arrow вместо arrow).
При этом у CoffeeScript масса преимуществ над JS: гораздо большая выразительность (на ~50% меньше писанины при том же функционале), отсутствие богомерзких скобок и запятых (что колоссально облегчает кодинг и рефакторинг), оператор "?", ranges…
После освоения CS, писать на JS становиься просто тошно: вместо того, чтобы сосредоточиться на том, ЧТО ты имеешь в виду, приходиться заботиться о том, КАК это сформулировать.
Единственная фича ES6, которая в CS недоступна, это геттеры-сеттеры. Но это решается использованием несложного хелпера.
Все отстальные фичи либо доступны напрямую, использованием транспайлера вроде того же 6to5, полифиллов или сторонних библиотек (например, промисы), либо через экранирование (модули), либо ре либо реализованы в CS, причем, зачастую лучше (rest-spread, destructuring assignment, multiline strings, string interpolation, classes...). Некоторые фичи ES6 не имеют прямого аналога в CS, но имеют годную замену (например, do вместо let, fat arrow вместо arrow).
При этом у CoffeeScript масса преимуществ над JS: гораздо большая выразительность (на ~50% меньше писанины при том же функционале), отсутствие богомерзких скобок и запятых (что колоссально облегчает кодинг и рефакторинг), оператор "?", ranges…
После освоения CS, писать на JS становиься просто тошно: вместо того, чтобы сосредоточиться на том, ЧТО ты имеешь в виду, приходиться заботиться о том, КАК это сформулировать.
Я так и не привык к вечному неявному return всего что только можно, и более того — тому как это меняет код.
Неявный return экономит мое время каждый день. Я нахожу его очень удобным.
Я могу припомнить только один случай, когда он мне помешал. jQuery UI устроен так, что если вы из метода виджета ничего не возвращаете, то на самом деле метод будет возвращать this, то есть сам виджет, что позволяет выстраивать методы в цепочки. Из-за этого приходилось каждый такой метод заканчивать на return. Небольшая цена за огромные преимущества.
Неявный return в CoffeeScript позаимствован из Ruby. Ruby — это удобный, выразительный и очень популярный язык. Поверьте, никому в голову не приходит жаловаться на неявные return в Ruby.
Так что это просто дело привычки. Если ты привык всю жизнь бриться топором, то будешь говорить, что современная бритва — отстой.
Я могу припомнить только один случай, когда он мне помешал. jQuery UI устроен так, что если вы из метода виджета ничего не возвращаете, то на самом деле метод будет возвращать this, то есть сам виджет, что позволяет выстраивать методы в цепочки. Из-за этого приходилось каждый такой метод заканчивать на return. Небольшая цена за огромные преимущества.
Неявный return в CoffeeScript позаимствован из Ruby. Ruby — это удобный, выразительный и очень популярный язык. Поверьте, никому в голову не приходит жаловаться на неявные return в Ruby.
Так что это просто дело привычки. Если ты привык всю жизнь бриться топором, то будешь говорить, что современная бритва — отстой.
Это все вкусовщина.
Как человек, который пишет на руби и es6 — es6 ощущается более структурированным. Я уже давно с трудом читаю чужой код на кофе, руби и питоне — он выглядит для меня слишком «плотным», а подсвеченные в IDE фигурные скобки и точки с запятой позволяют увидеть, где заканчивается чейнинг команды.
Есть буквально пара вещей, которые действительно хотелось бы перетащить из руби — пара особенностей синтаксиса для большей выразительности и читаемости (def вместо function, do ...end в дополнение к обычным стрелочным функциям), честные геттеры и сеттеры (да, они только в паре могут обновляться, а это свинство — мне порой надо только сеттер, например, обновить, а есть только Object.defineProperty) и что-то еще, примерно такого же уровня, вот только что из головы вылетело, к сожалению.
Но в качестве «преимущественно функционального» языка — JS (окей, JS в ближайшем будущем) делает руби. Да, в руби есть Lambda и block, но в реальности ими не так удобно пользоваться, если ты сторонник именно функциональной парадигмы, а не объектной. Напишите простенький пример на руби, который будет делать примерно то же самое:
Да, в ES6 можно абсолютно спокойно писать именно так.
А классы в руби крутые, даже очень. С этим не поспоришь.
Как человек, который пишет на руби и es6 — es6 ощущается более структурированным. Я уже давно с трудом читаю чужой код на кофе, руби и питоне — он выглядит для меня слишком «плотным», а подсвеченные в IDE фигурные скобки и точки с запятой позволяют увидеть, где заканчивается чейнинг команды.
Есть буквально пара вещей, которые действительно хотелось бы перетащить из руби — пара особенностей синтаксиса для большей выразительности и читаемости (def вместо function, do ...end в дополнение к обычным стрелочным функциям), честные геттеры и сеттеры (да, они только в паре могут обновляться, а это свинство — мне порой надо только сеттер, например, обновить, а есть только Object.defineProperty) и что-то еще, примерно такого же уровня, вот только что из головы вылетело, к сожалению.
Но в качестве «преимущественно функционального» языка — JS (окей, JS в ближайшем будущем) делает руби. Да, в руби есть Lambda и block, но в реальности ими не так удобно пользоваться, если ты сторонник именно функциональной парадигмы, а не объектной. Напишите простенький пример на руби, который будет делать примерно то же самое:
initRemoteStrategy({
next: ({idx, array}) => idx + 1,
prev: ({idx, array}) => idx - 1
},
err => err ? reject() : resolve())
Да, в ES6 можно абсолютно спокойно писать именно так.
А классы в руби крутые, даже очень. С этим не поспоришь.
Да вообще не парит. Когда оно надо, то смотришь-корректируешь return.
Только вот такой финт маленько смущает:
Только вот такой финт маленько смущает:
f = ->
if a
b
else
c
var f;
f = function() {
if (a) {
return b;
} else {
return c;
}
};
foo = (arr) =>
for i in arr
console.log(i)
var foo;
foo = (function(_this) {
return function(arr) {
var i, _i, _len, _results;
_results = [];
for (_i = 0, _len = arr.length; _i < _len; _i++) {
i = arr[_i];
_results.push(console.log(i));
}
return _results;
};
})(this);
Вот это только одна из тех веселых вещей, о которой я говорю.
Приведу один пример из одного проекта, написанного на ES6.
Исходный код:
Как бы это выглядело на CoffeeScript:
Разница в объеме кода более чем двукратная при абсолютно идентичном функционале.
Исходный код:
for (var key in props) {
if (!props.hasOwnProperty(key)) {
continue;
}
style[key] = props[key];
}
Как бы это выглядело на CoffeeScript:
for own key, value of props
style[key] = value
Разница в объеме кода более чем двукратная при абсолютно идентичном функционале.
Простите, но вы говорите так, будто теперь вообще не стоит развивать язык, раз у нас есть coffeeScript.
Преимущество ES6, в то что, рано или поздно все браузеры будут его поддерживать, CoffeScript — нет.
А вообще я думаю, что как только ES6 немного освоится в нашем мире, трансляторы CoffeScript перепишут, так чтобы он выдавал ES6 на выходе, а не ES5.
Преимущество ES6, в то что, рано или поздно все браузеры будут его поддерживать, CoffeScript — нет.
А вообще я думаю, что как только ES6 немного освоится в нашем мире, трансляторы CoffeScript перепишут, так чтобы он выдавал ES6 на выходе, а не ES5.
> Простите, но вы говорите так, будто теперь вообще не стоит развивать язык, раз у нас есть coffeeScript.
Ничего подобного я не говорил.
Посыл сабжа — «Меняем CoffeeScript на ES6». Мой тезис заключается в том, что если у вас проект на CoffeeScript, то нет смысла переводить его на ES6 — вы потеряете больше, чем получите. И если вы любите CS и понимаете, сколько пользы он вам приносит, то опять же переходить на ES6 неоправданно.
Как из этого вы вывели «вообще не стоит развивать язык», я не знаю. Конечно же, я считаю, что язык развивать нужно.
> Преимущество ES6, в то что, рано или поздно все браузеры будут его поддерживать, CoffeScript — нет.
Простите, но вы какую-то глупость сказали. CS — это ПРЕпроцессор. Никакие браузеры его не поддерживали, не поддерживают и поддерживать не будут. Зато они поддерживают JS, который получается у CS на выходе. И браузеры никогда-никогда не перестанут поддерживать JS, сгенерированынй CoffeeScript'ом.
> А вообще я думаю, что как только ES6 немного освоится в нашем мире, трансляторы CoffeScript перепишут, так чтобы он выдавал ES6 на выходе, а не ES5.
Эту надежду я полностью разделяю. Однако на данный момент движения в этом направлении нет. :( Я бы предпочел язык с фишками CS (отступы вместо фигурных скобок, необязательные круглые скобки и запятые, оператор `?`, диапазоны и т. д.), но при этом компилирующий в ES6 и использующий синтаксис ES6. То есть backticks, стрелки и т. д. в новом языке должны значить то же самое, что и в ES6, а для уникальных фич языка нужно задействовать другие синтаксические конструкции, которые не заняты ES6.
Ничего подобного я не говорил.
Посыл сабжа — «Меняем CoffeeScript на ES6». Мой тезис заключается в том, что если у вас проект на CoffeeScript, то нет смысла переводить его на ES6 — вы потеряете больше, чем получите. И если вы любите CS и понимаете, сколько пользы он вам приносит, то опять же переходить на ES6 неоправданно.
Как из этого вы вывели «вообще не стоит развивать язык», я не знаю. Конечно же, я считаю, что язык развивать нужно.
> Преимущество ES6, в то что, рано или поздно все браузеры будут его поддерживать, CoffeScript — нет.
Простите, но вы какую-то глупость сказали. CS — это ПРЕпроцессор. Никакие браузеры его не поддерживали, не поддерживают и поддерживать не будут. Зато они поддерживают JS, который получается у CS на выходе. И браузеры никогда-никогда не перестанут поддерживать JS, сгенерированынй CoffeeScript'ом.
> А вообще я думаю, что как только ES6 немного освоится в нашем мире, трансляторы CoffeScript перепишут, так чтобы он выдавал ES6 на выходе, а не ES5.
Эту надежду я полностью разделяю. Однако на данный момент движения в этом направлении нет. :( Я бы предпочел язык с фишками CS (отступы вместо фигурных скобок, необязательные круглые скобки и запятые, оператор `?`, диапазоны и т. д.), но при этом компилирующий в ES6 и использующий синтаксис ES6. То есть backticks, стрелки и т. д. в новом языке должны значить то же самое, что и в ES6, а для уникальных фич языка нужно задействовать другие синтаксические конструкции, которые не заняты ES6.
Затем, что есть язык программирования javascript и есть надстройка над ним coffeescript. Соотвественно на первом пишут все javascript-программисты, а на втором — лишь малая часть. Javascript это язык, стандарт если хотите, когда coffeescript это лишь какой-то инструмент, но не самостоятельная единица.
Смысл во многом в том, чтобы не перенастраивать лексический анализатор в голове каждый раз когда смотришь на js файл после coffee
НЛО прилетело и украло этот комментарий.
return там обязательно писать? С моей привычкой к коротким функциям он очень раздражает, синтаксис CoffeeScript в этом месте мне на много более приятен.
если однострочная arrow function (без фигурных скобок) — то необязательно.
[1, 2, 3].filter(i => i % 2 === 0).map(i => i * i)
Вот так можно, если более строчки — обязательны фигурные скобки и return.
Однострочные — хорошо. Но 2-3 строки тоже не помешало бы…
У вас реально батхерт от конструкции return?
По моему es6 дает необходимую свободу и упрощение, учитывая функциональный стиль, но вместе с тем не дает ухудшать читаемость кода.
По моему es6 дает необходимую свободу и упрощение, учитывая функциональный стиль, но вместе с тем не дает ухудшать читаемость кода.
Так у таких функций есть ограниченная область применения, там явно видно, нахрена они нужны.
Они не создают новый this, они красивее всего выглядят с одним аргументом и одним действием… В общем-то придумали их, как я понимаю, чтобы чейнинг делать там красивый, ну например
Они не создают новый this, они красивее всего выглядят с одним аргументом и одним действием… В общем-то придумали их, как я понимаю, чтобы чейнинг делать там красивый, ну например
arr
.map( entry => entry.length)
.filter( len => len > 10)
.sort()
Помимо всего прочего — печальна тупизна coffee. У его компилятора совершенно нет мозгов. Например, если используется arrow-function, обязательно будет обертка в this, даже если this внутри не используется.
Веселуха с не верно расставленными запятыми, пробелами, переносами, ну и выше описанными неявными return.
Веселуха с не верно расставленными запятыми, пробелами, переносами, ну и выше описанными неявными return.
Например, если используется arrow-function, обязательно будет обертка в this, даже если this внутри не используется.Да, при использовании fat arrow (=>), которую вы скорее всего имеете в виду, всегда появляется обёртка для this. Для этого и придумана fat arrow. Не надо использовать её везде. Обычно хватает обычной arrow, при которой в this ничего не заворачивается:
f = (x) -> x+1
f = (x) => x+1
Кстати, думаю, что возможность встраивать JavaScript не позволяет компилятору определить в общем случае, нужна ли обертка для this. Например:
f = (x) => `this.foo()`
А неявный return (и everything is expression) — это фича :-)
Есть фичи, которые мешают.
Чем мешает неявный return? (Кстати, в ES6 у arrow функций тоже неявный return.)
habrahabr.ru/post/249751/#comment_8265555
У arrow-function неявный return в вполне ясном случае —
У arrow-function неявный return в вполне ясном случае —
[1, 2, 3].map(i => i * i), то есть для коротких колбеков, которые можно прочитать на одной строке.
Например, если используется arrow-function, обязательно будет обертка в this, даже если this внутри не используется.
Стоит заметить, что для этого есть www.coffeelint.org
Disallows defining functions with fat arrows when `this` is not used within the function.
default level: warn
Спасибо, запросил для Meteor-а.
Воу. 6to5 теперь обозвали Babel.
Хороший, годный проект. Когда ES6 начнут использовать, для более глубокой поддержки можно будет транслировать в ES5, так что проект не придется закапывать, как кажется на первый взгляд.
Аффтар, почему же это мы должны менять CoffeeScript на ES6? cs манит, в первую очередь тем, что повышает продуктивность разработки, читабельность (при неком привыкании к синтаксису, довольно низком). Даже моя любимая типизация — TypeScript с привычным ООП не смогли удержать, я перешел к CoffeeScript. А тут непонятно что. Ни тайпскрип, ни кофескрипт. Ничем не примечательный вовсе. Еще один шаг EcmaScript — да, но не прыжок.
Простите, но уже есть хорошее, так зачем переходить на среднее?
Хороший, годный проект. Когда ES6 начнут использовать, для более глубокой поддержки можно будет транслировать в ES5, так что проект не придется закапывать, как кажется на первый взгляд.
Аффтар, почему же это мы должны менять CoffeeScript на ES6? cs манит, в первую очередь тем, что повышает продуктивность разработки, читабельность (при неком привыкании к синтаксису, довольно низком). Даже моя любимая типизация — TypeScript с привычным ООП не смогли удержать, я перешел к CoffeeScript. А тут непонятно что. Ни тайпскрип, ни кофескрипт. Ничем не примечательный вовсе. Еще один шаг EcmaScript — да, но не прыжок.
Простите, но уже есть хорошее, так зачем переходить на среднее?
существует ли какой то препроцессор для es6 с синтаксисом как у cs? я использовал cs изза его синтаксиса, возвращение к js-style когда кучи скобок лезут в глаза не хочется
А какие вы бонусы от es6 хотите получить в таком препроцессоре? Я кроме того факта, что вакансий на cs практически нет, что конечно тоже аргумент, не нашел повода переходить на es6 с cs.
Ну, я просто к тому, что если написать такой препроцессор для es6 то cs и получится, без отличий. Как мне кажется.
Sign up to leave a comment.
Меняем CoffeeScript на ES6