Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Что EcmaScript грядущий нам готовит?

Краткое предисловие для непосвященных:
— ECMAScript — это официальный стандарт языка JavaScript;
— Самих стандартов много. Самый популярный — ECMA-262;
— Сейчас ожидаем версию ECMAScript 6.

JavaScript «пилили» за несколько дней, и в нем было очень много минусов. Тем не менее, он пробился в Web и стал стандартом в веб-программировании. Его «косяки» решили стандартизировать с помощью EcmaScript. Сейчас используется устоявшаяся версия — EcmaScript 5, и на подходе версия 6 под кодовым названием ECMAScript.next, или Harmony. Ожидается, что в итоге она принесет гармонию в разработку.

Дальше смотрим подробнее, что изменится в 6 версии, и сравниваем с тем, что было.

Блочная область видимости

В JavaScript объявление переменных происходит через зарезервированное слово var. Эта переменная поднимает объявление сразу наверх. В стандарте EcmaScript появляется новое слово для определения переменных — let. Оно позволяет сузить видимость этой переменной до блока. У нас есть цикл for, в нем через let мы определяем переменную i, и она доступна только в этом цикле. Извне она не будет доступна, но в if — будет.Это поможет нам избавить от «замусоривания» функции переменными.

Также будут введены константы. Раньше мы создавали объект, применяли к нему Object.freeze или называли переменную в верхнем регистре, чтобы другие разработчики это не меняли. Сейчас можем не заморачиваться и использовать зарезервированное слово const. Оно работает как let, имеет блочную область видимости, а попытки изменить ее приведут к ошибке.

Строковые литералы

Для повышения читабельности мы разбивали длинную строку и использовали вот такой «ад»:

Вместо этого мы можем использовать backtip, и строка будет выглядеть так, как мы ее ввели:

Использование плейсхолдеров

Например, нам в работе нужно генерить pdf документ. Для этого есть определенный функционал, который преобразует вызов функций в элементы для наполнения документов. В работе над строками нам приходится их конкатенировать через «плюсы» или использовать сторонние бибилотеки. Теперь эта поддержка будет нативна.

Мы сможем использовать ${name}, чтобы затем использовать определенную переменную.

Объектные литералы

В своей практике часто сталкиваюсь с необходимостью объявлять plain object. В обновленном стандарте радует, что при объявлении функции say, которую мы ранее писали названием функции: снова название функции, теперь это упрощается сокращением say.

Деструктуризация

Допустим, у нас есть массив. Чтобы выделить каждый из этих элементов, мы могли пройтись по циклам или указать пару из них по индексу.

Теперь мы можем использовать квадратные скобки, чтобы получить значение этого массива:

Также можно взять первый элемент массива, а оставшиеся записать в отдельную переменную как массив — var [one, ...rest] = arr;. Это полезно применять в функциях.

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

Поменять содержимое переменных местами:

Возвращать несколько значений:

Также мы можем сами указать, какие свойства записать переменным. В таком случае name — это свойство объекта:

Spread в функциях

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

Также мы можем внутрь функции передавать значения, используя спред. У нас есть массив, мы ставим и передаем внутрь функции. Спред сам распределит этот массив по аргументам.

Лямбда-выражения

Cокращенная запись для анонимных функций. Позволяет уменьшить количество кода и, по моему субъективному мнению, повышает читабельность. У нас есть объект, массив и метод для получения значения этого массива. c в данном случае — входящий аргумент, далее мы вводим инструкции, где можем его использовать:

Функцию перевода rgb в hex можно переписать таким образом, используя лямбду:

Классы

Ранее нужно было объявлять методы через прототип. Теперь стало приятнее читать:

Появилось зарезервированное слово для создания функции-конструктора и геттеров/сеттеров, причем необязательно указывать сеттеру на вызов явно, можно использовать оператор присваивания.

Наследование

Через слово extends можно указать родителя, а слово super использовать для доступа к конструктору родителя. Через super.<METHOD_NAME> можно вызывать родительские методы.

Модули

Ранее с модулями в JS была морока, поэтому мы использовали такие решения как RequireJS. Сейчас нам предлагают нативную поддержку:

Функции, которые мы хотим вытянуть наружу, можно обозначить через слово export, затем можно подключить через import, указав путь к модулю.

Обход значений

Появилась возможность обхода значений через for..of

Структуры

Map — это структура, подобная обычному объекту, — ассоциативный массив. Отличия в том, что в качестве ключа можно использовать не только строки, а вообще любой тип. Плюс можно получить размер через свойство size.

WeakMap отличается от Map тем, что в качестве ключа используется объект, а все ссылки на значения не блокируют GC от освобождения памяти. Иными словами, если на объект умерли все ссылки кроме той, что в WeakMap — память все равно будет помечена на освобождение.

В Set можно хранить значения любых типов в том порядке, в каком мы их добавляем, также можно получить размер через size. Суть Set в том, что значения, хранимые там, уникальны. Т.е. мы не сможем впихнуть два массива с одними и теми же элементами.

WeakSet, подобно WeakMap, тоже не блокирует очищение памяти, если умерли все ссылки, кроме тех, что в WeakSet.

Итераторы

Итераторы позволяют задать свой метод обхода последовательности значений. Например, мы можем переопределить обход объекта под наши нужды:

Кстати, здесь мы используем новый тип данных «Symbol». Он уникален и неизменяем. С его помощью мы можем, например, указать собственную функцию-итератор, как показано выше.

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

Мораль

Новые возможности можно попробовать уже сейчас. Например, в сервисе repl.it/languages/Traceur. Или же можно скачать и подключить к своему приложению разработку Google.

Советую пройтись по документации от Mozilla.

Еще полезные ссылки:
— harmony:proposals
— harmony:specification_drafts
— 2ality.com

Конечно, это не все нововведения. Я не упомянул те же Proxies и Promises.

Некоторым могут не понравиться нововведения, некоторые встретят их с восторгом. Я же не могу сказать, что будущее для JS темное — язык развивается, приобретает новые фишки. JavaScript давно и прочно вошел в Web, и его не так-то просто оттуда изгнать :)

Я знаю одно: пока есть движение, есть жизнь, а значит, и будущее.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




69 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

такое впечатление, что читаю про питон, жду всеобщего внедрения)

Чем дальше в лес — тем больше синтаксиса и меньше уютных скобок. Лучше бы реализовали нативные макросы, например, или приличную сигнальную систему.

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

Функцию перевода rgb в hex можно переписать таким образом, используя лямбду:
Вы забылы упомянуть весьма важную особенность: при использовании arrow function (=>), созданная функция получает «правильный» контекст.

1. Під розділом про наслідування код такий самий як і в розділі з класами.

2. В JavaScript класів не було до цього нововведення.
Не факт, що роботу з прототипами варто співставляти з класами.
Там розбіжностей більше ніж спільного.

3. Тема наслідування дійсно не розкрита. До цього часу поняття наслідування в JS було настільки ж умовним як і поняття клас.

Дело в том, что протитипы никуда не деваются. Классы являются лишь синтаксическим сахаром, а сам механизм не затронут. С наследованием то же самое.

Приблизно так я і думав... тільки вот наслідування в JS простим цукром не вийде зробити.
Тут
github.com/...and-Debugging-JavaScript
описується штук 5 підходів до наслідування.

Подходов много, а спецификация одна: wiki.ecmascript.org/...harmony:classes&s=inherit
Вообще, JS позволяет многое — за это его ненавидят одни, любят другие. И в новой версии кому не подойдет extends, будут использовать нетипичные подходы. Я даже рад разнообразию :)

Всегда JavaScript привлекал лаконичным набором правил языка. Такое раздувание только потрит впечатление.

s.dou.ua/...torage-files/ecmascr1.png — коментарии «жива» про видимость переменных? Скриншоты нужно было менять на вменяемые.

backtip: мабуть малося на увазі backtick.

Тема наследования не раскрыта!

Почему нет? Механизм не изменился, те же протитипы. Просто в виде сахара добавились extends и возможность обращаться к паренту через super.

вот именно это и не раскрыто ;) несоответствие текста и скриншота

es6-features.org

P.S. Скриншоты кода с Ворда — Агонь!

добавили красок в монохромную статью )) зуб даем, скрины — не дело рук сотрудников Softengi :)

Проблема Javascript не в том, что в нем не хватает каких-то фич, а в том, что в нем куча фич, которые никому не нужны, непонятно как работают и только добавляют головную боль.

ИМХО:
1. Генераторы (async/yield)
Мегаполезная фича. В связке с промисами превращает nodejs код во что-то удобочитаемое. В web frontend тоже найдет свое применение.

2. Лямбды
Сильно сокращенный синтаксис для function я бы записал в плюсы.

3. for ... of
Наконец-то адекватная альтернатива for ... in

4. Классы
Здсь двойственные чувства. С одной стороны, синтаксис нормальный, с другой, за 20 лет люди очень сильно привыкли к существующему подходу объявления классов с помощью function, я вряд ли избавлюсь от чувства, что этот class — это не настоящий класс, а только надстройка над function.
К тому же, до сих пор не работают в V8 harmony, так что даже попробовать нормально не получается.

Все остальное — шлак, которым опять загрязнили язык и который нам прийдется выгребать :(

в нем куча фич, которые никому не нужны, непонятно как работают и только добавляют головную боль.
Огласите весь список ©
wtfjs — это больше демонстрация ниского уровня образования некоторых wtf-ров, чем подпадают под ваше описание.
wtfjs — это больше демонстрация ниского уровня образования некоторых wtf-ров, чем подпадают под ваше описание.
Я считаю, что, если добрая половина девелоперов не может увернно ответить, что выдаст {} + {}, то это очень хреновый язык, а не безграмотные девелоперы.
если добрая половина девелоперов не может увернно ответить, что выдаст {} + {}, то это очень хреновый язык, а не безграмотные девелоперы.
Половина «девелоперов» не знаю сколько будет «2.3+3.4» во многих языках и почему так. Это как раз проблема в девелоперах — нежелание прочитать спецификацию. А «{} + {}» — это еще и отсутствие дисциплины (не надо использовать то что не понимаешь).

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

Если приведение типов менее логично чем в других языках, возможно это как раз проблема JS.
это еще и отсутствие дисциплины (не надо использовать то что не понимаешь).
Половина «девелоперов» не знаю сколько будет «2.3+3.4» во многих языках и почему так. Это как раз проблема в девелоперах — нежелание прочитать спецификацию
Я лично не вижу ничего хорошего в том, что нужно читать спецификацию, чтоб понять, какой будет результат сложения двух чисел.

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

А «{} + {}» — это еще и отсутствие дисциплины (не надо использовать то что не понимаешь).
В этом и отличие говноязыков от нормальных языков. Там где нормальные языки или выдают результат, адекватный ситуации, или падают, говноязыки пытаются сделать что-то умное, что потом без спецификции невозможно объяснить.
Мой поинт был в том, что лучше почистить язык от таких wtf-ов (например, ввести более жесткий user strict), чем вводить константы, и деструкторы, которые в JS никому нафиг не нужны.
Я лично не вижу ничего хорошего в том, что нужно читать спецификацию, чтоб понять, какой будет результат сложения двух чисел.
А откуда вы узнаете какой вообще может быть результат какой-то операции? У всего есть спецификация, ее надо знать. Не зная спецификации вы не можете нормально работать ни с одним языком.
Там где нормальные языки или выдают результат, адекватный ситуации, или падают
Почему вы решили что ДжС выдает не адекватный результат? В движке есть набор правил, тот факт что вы (соберательны образ) не знаете (не хотите знать) что это за правила — это реальная проблема.
.
Но это все демагогия. Это все примеры которые при нормальном стиле кодирования не встречаются или встречаются очень редко.
Меня больше интересует что это за «куча фич, которые никому не нужны».
А откуда вы узнаете какой вообще может быть результат какой-то операции?
Честно говоря, не вижу смысла спорить о том, какой должен быть результат операции 2.3+3.4
Почему вы решили что ДжС выдает не адекватный результат?
Я понятия не имел какой будте результат, есть понимание, что со сложением в javascript все очень грустно.

Сейчас проверил, REPL nodejs выдает «[object Object][object Object]», REPL Chrome выдает NaN. Ну ок, будем считать, что результат на 50% адекватный.

В движке есть набор правил, тот факт что вы (соберательны образ) не знаете (не хотите знать) что это за правила — это реальная проблема.
Проблема вроде не в том, что язык работает не так, как написано в спеке (с этим в большинстве реализаций с горем пополам разобрались почти разобрались), проблема в том, что спека говно.
Но это все демагогия. Это все примеры которые при нормальном стиле кодирования не встречаются или встречаются очень редко.
Меня больше интересует что это за «куча фич, которые никому не нужны».
Я и не говорю, что это нужно вводить в повседневную практику, я говорю, что язык нужно вычистить от таких WTF-ов.
Я и не говорю, что это нужно вводить в повседневную практику, я говорю, что язык нужно вычистить от таких WTF-ов.
WTF — це коли девелопер пише в реальному коді {}+{} а не коли мова вертає з цього результат, який би він не був.

Вы очень узко смотрите на проблему

WTF — це коли девелопер пише в реальному коді {}+{} а не коли мова вертає з цього результат, який би він не був.

Коли ці {} прийшли з зовнішнього миру, і невідомо, що там — девелопер не зможе це виправити.

В одному місці, з яким я працював, було правило: для всіх значень, що прийшли ззовні, якщо воно має бути числовим, ставити +x замість x, а якщо текстовим — ""+x. Так, це було жорстко прописано у полісі кодування. Якщо мова вимагає таких правил, в ній щось не те.

Коли ці {} прийшли з зовнішнього миру, і неведомо, що там — девелопер не зможе це виправити.
Язык с динамической типизацией, поэтому должен быть соответствующий стиль программирования. Нет принципиальной разницы выбросит “язык” исключение, или вернет НаН, или даже сумму тоСрингов — в любом случае попадание объектов в метод которы на них не рассчитан — это баг который допустил программист.
Язык с динамической типизацией, поэтому должен быть соответствующий стиль программирования.

Ваша принципиальная ошибка в смешивании динамической типизации, слабой типизации и персональных особенностей языков.

В Питоне точно так же динамическая типизация, но там такие меры не приняты. И знаете почему? Потому что там нет таких проблем, что (хрестоматийный заезженный пример) 5-"3"=2, но 5+"3"=53: такая ерунда возможна при слабой типизации с неявными конверсиями между числом и строкой, а не при динамической. И там нет проблем, которые требуют рисования подробной таблицы сравнений. Последнее, как и эффекты типа a==[[[a]]], это особенности конкретного языка и его разработки на коленке за несколько часов.
А ещё только в Javascript среди распространённых языков, чтобы найти определение метода, нужно вручную пройти по цепочке прототипов, применяя на каждом шагу кошмарные hasOwnProperty и надеясь, что он не заменён в глобальном Object.

в любом случае попадание объектов в метод которы на них не рассчитан — это баг который допустил программист.

Позиция совы в воздушном замке.

В Питоне точно так же динамическая типизация, но там такие меры не приняты.
Вывод питона:
5+"3″
Traceback (most recent call last):
File «<stdin>», line 1, in <module>
TypeError: unsupported operand type(s) for +: ’int’ and ’str’
Мне как программисту не особо важно будет результат: огребу я ошибку во время выполнения или получу «неожиданное» 53. Так или иначе я не должна допустить некорректные входные дынные.
Последнее, как и эффекты типа a==[[[a]]], это особенности конкретного языка и его разработки на коленке за несколько часов.
Угу, дизайн языка довольно «детский», но зачем пользоваться багами как фичами? А если ваш код достаточно чистый, то и кода вида «a==[[[a]]]» у вас просто не получится.
Позиция совы в воздушном замке.
Не понимаю эту фразу, поясните.
Мне как программисту не особо важно будет результат: огребу я ошибку во время выполнения или получу «неожиданное» 53.

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

Так или иначе я не должна допустить некорректные входные дынные.

Мнэээ... в аватарке и в подписи явно мужчина. Какой пол мне употреблять в конструкциях типа «хотел(а) бы» в Ваш адрес?

Не понимаю эту фразу, поясните.

Простите, чуть попутал. Не воздушный замок, а башня из слоновой кости. Сова из анекдота «мышки, станьте ёжиками — а как? — не знаю, я стратегию разрабатываю», вещающая из окна такой башни.

try...catch был придуман в синхронном программировании, как ни странно, он плохо работает с асинхронным.

try...catch был придуман в синхронном программировании, как ни странно, он плохо работает с асинхронным.

На создание механизма возврата не только результата условного promise, но и его исключения, в Питоне мне потребовалось четверть часа с перекурами. В Erlang сделано то же самое из коробки. Не вижу никаких препятствий сделать то же самое для Javascript, кроме откровенно общеизвестного ламерства его создателей (у которых даже в 1678% синхронном варианте вместо нормального структурного catch — костыльное уродство).

Под JS уже тоже все запилили. Не хватало одной детали, но и она появилась — yield из Harmony, с которым асинхронный код выглядит почти как синхронный, и в нем даже можно ловить исключения с помощью try/catch.

А мне — важно. Ошибка должна показываться явно, лучше всего в виде исключения, а не прятаться языком.
Угу, а еще лучше находить ошибки на этапе компиляции. И тут как раз есть разница в скорости отклика/информирования об ошибке.
В случае с интерпритируемыми языками с динамической типизацией, подобные ошибки вы можете отловить только в рантайме. И при отлове в рантайме основной способ отлова ошибок — это тесты. А тут уж нет особой разници исключение или не корректный результат, __если у вас нормальный код__, а не лапша. В лапше исключения таки удобнее.
Мнэээ... в аватарке и в подписи явно мужчина. Какой пол мне употреблять в конструкциях типа «хотел(а) бы» в Ваш адрес?
Функция — это она. А я — он.
Сова из анекдота «мышки, станьте ёжиками — а как? — не знаю, я стратегию разрабатываю», вещающая из окна такой башни.
А с тактикой еще проще: пишешш тесты.

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

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

Сильно толсто, попробуйте потоньше

И при отлове в рантайме основной способ отлова ошибок — это тесты. А тут уж нет особой разници исключение или не корректный результат, __если у вас нормальный код__, а не лапша. В лапше исключения таки удобнее.

Разница есть, и колоссальна. Если язык маскирует явные ошибки, например, возвращая undefined при доступе к несуществующему полю, то даже имея сломанный результат теста, вы можете неделями искать ошибку.

В лапше исключения таки удобнее.

Они удобнее везде. Если где-то надо их явно замаскировать, это отлично видно в коде.

А с тактикой еще проще: пишешш тесты.

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

вы можете неделями искать ошибку.
От только
__если у вас нормальный код__, а не лапша.
то у не неделями. Подобные гуаноособенности джаваскрипта только стимулируют писать код проще и не лапшать.
.
Которые или становятся безумно дороги, поглощая всё время, или показывают рамочный факт неработы, но не конкретное место.
А с тактикой еще проще:
1) учимся писать нормальные тесты (а не просто для цифирок покрытия)
2) пишешш тесты.
Подобные гуаноособенности джаваскрипта только стимулируют писать код проще и не лапшать.

Поржал. Я работал на контору, у которой основной язык — Javascript, и на клиенте, и на сервере. Видел, как это выглядит.

1) учимся писать нормальные тесты (а не просто для цифирок покрытия)

И опять сказки про всеисцеляющий TDD (или просто тест, не так существенно)

Поржал. Я работал на контору, у которой основной язык — Javascript, и на клиенте, и на сервере. Видел, как это выглядит.
Посмотрите на асинхронное программирование в сишке.

«Кто мне писал на службу жалобы, а? Не ты? Да я же их читал!»

Я писал асинхронно «в сишке». Это ничуть не сложнее, чем писать что-то другое «в сишке», ровно те же проблемы. Если автор вообще понимает, как писать асинхронно, у него всё получится. А если есть под рукой библиотека типа ISC eventlib (далеко не высший пилотаж, но просто качественное средство), то она на себя берёт где-то 2/3 всего гимора.

Так что расскажите подробнее, к чему эта реплика была вообще. Неужели Вы хотели сказать, что на JS это будет существенно легче? «Чёта ржу» (tm)

Я писал асинхронно «в сишке». Это ничуть не сложнее, чем писать что-то другое «в сишке»
Ну все, теперь до утра не посмеюсь =) ничего смешнее еще на DOU не читал еще. Ох беда, теперь до завтра не забуду.

:down:

Мне как программисту не особо важно будет результат: огребу я ошибку во время выполнения или получу «неожиданное» 53.
Это уже было, пишем вначале ON ERROR RESUME NEXT и поехали

Ньюфаг?

Если эти 4 магических слова написать в начале BASIC программы, то все ошибки/исключения будут просто игнориться и программа будет продолжать работать дальше как ни в чем не бывало — своеобразный рай для школоты, ламеров и прочих быдлокодеров.

Щодо лямбд — я трохи завис, коли читав
var T = v => `${v < 16 ? "0" : ""}${v.toString(16)}`;
може потім і попустить, але зараз — важко таке «розпарсювати».

Тут больше не синтаксиса лямбд, а строковой интерполяции. От самой лямбды тут = v =>

Там нормальный синтаксис, очень близок к C#-у. Просто автор в примере намешал еще какую-то другую «фичу» и в итоге получилась нечитаемая хрень.

Нормальные примеры можно посмотреть тут
es6-features.org/#ExpressionBodies

коли освоївся в Haskell, починаєш такі речі читати як звичайний текст. справедливо і для пьорла.

А любителі брейнфака скажуть, що латиниця це взагалі — немов прямий інтерфейс в мозок і читати її легше-легшого :D

можно не выгребать, вроде ж старые конструкции должны работать. Насчет шлака, мне наоборот понравилось, другое дело что на фронте не скоро.

4. Классы
Здсь двойственные чувства. С одной стороны, синтаксис нормальный, с другой, за 20 лет люди очень сильно привыкли к существующему подходу объявления классов с помощью function, я вряд ли избавлюсь от чувства, что этот class — это не настоящий класс, а только надстройка над function.
Привыкли делать костыли, в которых var это приват, а this типа как паблик в классе который вроде как функция.
Все остальное — шлак, которым опять загрязнили язык и который нам прийдется выгребать :(
Да ладно вам?! Деструктуризация, спред рулит, тот же Set уже вижу где удобнее использовать в своем проекте; плейсхолдеры пусть и так странно ${}, но все-равно вполне юзабельны — тоже вижу применения в своем коде.
А касательно классов, что ж, дело привычки. Мир становится очень динамичным и мы уже не можем себе позволить к чему-то привязываться — принятые сегодня решения могут оказаться не актуальными завтра.
Деструктуризация
Сильно неочевидный syntax sugar с очень низкой ценностью.
тот же Set уже вижу где удобнее использовать в своем проекте
set и map полезные структуры, не понятно только зачем их засовывать в спецификацию языка, когда они давно реализованы в библиотеках.
Сильно неочевидный syntax sugar с очень низкой ценностью.
После питона мне не хватало :)
set и map полезные структуры, не понятно только зачем их засовывать в спецификацию языка, когда они давно реализованы в библиотеках.
Нейтив же :) Доступность «изкаробки» явно лучше необходимости подгружать библиотеки.
А вообще, все это может быть достаточно субъективным. Время покажет рациональность, ибо мнения могут расходиться разительно.

1) а где возврат multiple-value?
2) а где лямбда-аргументы, динамическая область видимости?
3) макросы где?
4) и специализация по множеству?
Вопросы риторические, список можно продолжать. JS это сегодня лучший ЯП веба, но это ещё не CL.

Насчёт for-of, введение лямбд решает проблему в корне при помощи _, что радует.

Имею ввиду, что, хотя в JS и нет управления вычислением, но уже можно будет использовать любые «управляющие» библиотечные и самописные функции без потери контекста и не передавая его явно, например так:
this.itemStatus = _.map(this.items, (item) => {
log(this); // same as outside
return item === this.currentItem;
});

Для того, чтобы заюзать уже сейчас лучше юзать babel, он легко дружит с тем же React’ом.

Отличное краткое изложение, приятно читать.

babeljs.io/docs/learn-es6 здесь есть примеры использования и Прокси и Промисов.
babeljs.io/repl песочница

Підписатись на коментарі