Pull to refresh

Comments 34

И правда, выглядит лучше, чем CoffeeScript. Даже возникло желание написать что-нибудь на ES6 :)
Это же дело вкуса, ANSI-шникам скобки, точки с запятыми подавай, Питон-подобным (как кофе) скобки уберите, отступы наше всё, линейные функции и записи это круто

Если хотите писать на ES6 то радость могут доставить неупомянутые генераторы, так же WeakMap и WeakSet и итераторы и «протокол итераторов» =) (благо вроде поддерживаются в ноде и последних мажорных браузерах нативно)
Я считаю очень удобным отсутствие в CoffeeScript скобок. Было бы неплохо иметь возможность также писать и на ES6. В этих примерах везде присутствуют правильные отступы и скобки одновременно. Надеюсь CoffeeScript не загнется… очень бы хотелось поддержки await из ES7, хотя давно есть форк IcedCoffeeScript.
UFO just landed and posted this here
Парсер коффескрипта прекрасно знает где начало и конец функции, так что это скорее вопрос поддержки языка со стороны редактора или IDE. Было бы очень классно если бы разработчики языка сразу создавали библиотеки для такого рода вещей. Имея стандартизованный API для таких библиотек можно осуществить поддержку в редакторе любого языка. Боюсь такое если и появится, то появится не скоро…
Но даже без таких библиотек (в случае с CoffeeScript, TypeScript и т.д.) через SourceMaps можно использовать весь инструментарий для яваскрипта. Не знаю применяют ли это на практике, но теоретически можно)
Пишу в atom.io, пока плагина linter-coffeescript мне хватает.
Давно не писал на кофе, но учитывая его синтаксис async / await реализуется в нём элементарно. Реализация асинхронных функций с нативными генераторами в babel работает по этом моему предложению. С месяц назад в кофе добавили поддержку синтаксиса генераторов. Нам даже не нужен новый синтаксис, достаточно хелпера async, использовать вместо await yield — и получаем полностью ES7 совместимые асинхронные функции, рабочий пример:

delay = (time)-> new Promise (resolve)-> setTimeout resolve, time

sleepRandom = async (time)->
  yield delay time * 1e3
  0 | Math.random() * 1e3
sleepError = async (time, msg)->
  yield delay time * 1e3
  throw Error msg

(async ()->
  try
    console.log 'Run'               # Run
    console.log yield sleepRandom 5 # 936, after 5 sec.
    [a, b, c] = yield Promise.all [
      sleepRandom 5
      sleepRandom 15
      sleepRandom 10
    ]
    console.log a, b, c             # 210 445 71, after 15 sec.
    yield sleepError 5, 'Irror!'
    log 'Will not be displayed'
  catch e
    console.log e                   # Error: 'Irror!', after 5 sec.
)()

Хотя для старых браузеров нам нужен полифил Promise и прогонять результат через регенератор.
А что насчет yield? Насколько я помню это мало где поддерживается в полной мере.
Ну так я и написал — для IEбраузеров, не поддерживающих генераторы, можно прогонять конечный код через regenerator. Babel, например, для генераторов тоже его использует.
Извините, однако от этого перевода я заплакал кровью на первой трети и ушел читать оригинал. Живые человеки таким языком не разговаривают, серьезно.
Однако, за ссылку на последний — спасибо.
Прошу прощения за ваши глаза. Любые замечания/поправки можно написать в ЛС, я это справлю.
Присоединяюсь к Matrosked, переводу не помешала бы основательная вычитка. И еще вот это:
Как только функция была объявлена, она будет существовать до тех пор, пока код не будет интерпретирован.
Что тут имелось в виду?
трудности перевода:)

Оригинал:
"One just to assume the function will exist prior to the code’s interpretation."

Подозреваю, что переводится как:
"Остаётся только надеяться, что эта функция будет существовать до момента интерпретации кода".
Сейчас браузеры поддерживают не достаточное кол-во фич из ES6, для меня ключевыми для перехода являются for… of loops и arrow functions, если с первым ещё более менее (Firefox и Chrome), то последний пока что только в Firefox есть и то не полностью, а это значит что нужно использовать «трансформацию» в ES5 для всех браузеров.

Дак вот эта «трансформация» не такая уж и незаметная — результирующий код не слабо разбухает и становится медленее, чем если писать сразу в ES5. (Я использовал google traceur для «компиляции»).
Если сравнивать с CoffeScript, я не давно переписал кусок кода на ES6, мне пришлось добавить много «мусора» (,{}:") в «чистый» CS, в итоге код разбух и стал не такой «чистый», хотя это мелочи.

С учетом этих факторов: разбухание кода, использовать трансформацию для всех браузеров и более медленное исполнение кода, считаю что нужно подождать хотя бы когда в мажорных браузерах появятся ключевые фичи, что-б медленный транформированный код использовать только для старых браузеров. В результате откатил код обратно на CS.

А такие вещи как Map/Set уже использую во всю, т.к. они не вносят нового синтаксиса, (а для старых браузеров самодельные аналоги либо es6-shim).
Быстрее работает WeakMap и WeakSet. К тому же, если на ключ все ссылки исчезают, (и доступ по ключу невозможен) сборщик это якобы понимает и (по стандарту) удаляет данный ключ-значение.

Вообще ES6 это убийца следующих вещей:
IE8 (хорошо, вроде)
Аккумуляторов смартфонов (хорошо для продавцов внешних аккумов, а так лучи ненависти всем, кто так бодро «мощности компов выросли, мы можем юзать тяжеловесные функции без проблем»)
Работы по стандартам (ибо черновик, не стандарт)

С другой стороны это созидатель:
классов и ООП в нормальном виде
работы и дисциплины с перечислениями
Позитивных классов

В итоге использовать или нет зависит сильно от целевой «аудитории» (браузеры и устройства))
Я использовал google traceur для «компиляции»

В этом все и дело. Возьмите babel
Нет, с ним не легче — кода в 3,5 больше и работает в 10 раз медленнее у меня на Chrome, вот тест.
Исходный код такой:
ES6:
function run() {
  var s = '';
  for(v of ['a', 'b', 'c', 'd', 'e']) {
    s += v;
  }
}

CS:
run = ->
  s = ''
  for v in ['a', 'b', 'c', 'd', 'e']
    s += v
  null

const run = () => ['a', 'b', 'c', 'd', 'e'].join();

Какая-то фигня оторванная от реальности, если честно.
Не корректно. Вы сравниваете обход array-like объекта через обычный цикл for с обходом объекта через протокол итераторов. Попробуйте loose mode.
Вы сравниваете обход array-like объекта...

Я просто написал код «обхода» массива, это babel выдал мне такой код. По сути эти 2 кода делаю одно и тоже, так что все честно.
Добавил в тест «loose mode», да, он быстр, но почему он не включен по умолчанию?
for-of это не код обхода массива, а цикл для обхода объекта по протоколу итераторов. С помощью цикла for-in из кофе не обойти Map или Set, с помощью for-of из ES6 / babel — без проблем.

Почему не включен по умолчанию? По ссылке что дал вроде написано. Он работает не совсем по спецификации ES6 и в ооочень редких случаях результат может не совпадать. Можно подменить итератор массива и цикл будет работать не совсем корректно. В случае преждевременного завершения (ошибки) должен быть вызван метод return итератора, если такой имеется (правда это пока нигде больше не поддерживается).

А по поводу верхнего комментария треда — странно писать про нежелание использовать медленный код код и использовать Map / Set из es6-shim, почему — см. тут., да и es6-shim заменяет нативные коллекции абсолютно везде.
странно писать про нежелание использовать медленный код код и использовать Map / Set из es6-shim
Я не использую map из shim, я использую «самодельные аналоги» которые не плохи по скорости.

Кстати ваша модификация map с symbol не имеет смысла, по крайней мере сейчас, т.к. map и set имеют больше поддержки браузерами чем symbol, и перекрывают его.
А вы пролистайте чуть выше и увидите как реализованы символы :) Хотя символов как таковых в реализации коллекций никогда и не было, упрощение. Текущая реализация серьёзно отличается от описанной в статье, но основные принципы те же.
Грустная шутка, конечно, но потом появятся новые кавычки, для экранирования этих кавычек.
Шта? 0_o Кривые кавычки статье автора, а не в JS.
Так и есть. Но присмотритесь еще раз к кавычкам в статье:
‘/users’ 
А! Простите, я не понял вас. Я думал, что ваш комментарий относится к новому синтаксису языка.
>Promise — по-настоящему интересен как самостоятельный блок, который предлагает решение проблемы callback hell раз и навсегда.
Иногда требуется обрабатывать события многократно. Promise не очень тут помогает,
Например, вызвать функцию, если события е1 и е2 произошли раньше е3, которое произошло в течение 5 секунд после события е4, которое предшествовало е1 и е2.
Интересно, предусмотрен ли какой-нибудь агрегатор для подобных ситуаций в будущем стандарте. Когда-то давно видел подобное на флеше.
Для многократной обработки событий есть общепринятый паттерн EventEmitter. Реализации есть и для браузеров и для серверных платформ. nodejs.org/api/events.html
Даже псевдокода получается слишком много:
listen(e4)
on(e4){
  listen(e1)
  listen(e2)
  on(e5)
    unlisten(e1, e2, e3, e5)
  delay_emit(e5, 5000)
  on(e1 and e2)
    listen(e3)
     call(func)

Имелось ввиду какое-то подобие логики событий:
if(e4 before (e1 and e2) before e3
 and e4 before timeout(0..5000) before e3) call(func)
А в каком языке есть встроенная реализация подобной логики?
Sign up to leave a comment.

Articles