Комментарии 43
Я так думаю, что полноценно использовать ECMAScript 2015 можно будет тогда, когда все не поддерживающие браузеры выйдут из обращения. Предположим что в 2016 году выйдут браузеры полностью поддерживающие ECMAScript 2015. Тогда года через 2-3, можно будет использовать, т.е. речь идет где то о 2018-2019 годах.
Как минимум, можно спокойно писать под транспилятор, не боясь, что в новом релизе Babel что-нибудь сломается или придется все переделывать под новые фишечки. На сервере тоже можно будет переходить — по мере того, как v8 будет все-таки реализовывать недостающее.
Если ориентироваться на сугубо нативную поддержку, то и на ES5 еще рановато писать, а на Coffee/Type/ClojureScript вообще никогда:)
Если ориентироваться на сугубо нативную поддержку, то и на ES5 еще рановато писать, а на Coffee/Type/ClojureScript вообще никогда:)
Да сейчас вроде да MicroSoft начали обновлять браузер практически во время так что думаю что раньше
Ну я еще год назад поддерживал IE8. Зависит твердолобости и ретроградности составителей ТЗ, на самом деле.
Я писал в своей публикации и вообще сейчас все сообщество идет к транспилерам. Никто не будет ждать пока все утвердится. Уже сейчас можно спокойно писать используя babel. И мир дева в js идет к фича-бай-фича, а не к версированию языка.
Зачем тогда браузерам вообще делать поддержку es2015, если всё равно большинство в браузеры будет присылать код es5 скомпилированный из es2015?
Тогда вообще стоило бы встроить в браузеры поддержку некоторого байт-кода, аля байт-код jwm, у разработчиков развязались бы руки и они получили бы возможность писать на любом языке.
Тогда вообще стоило бы встроить в браузеры поддержку некоторого байт-кода, аля байт-код jwm, у разработчиков развязались бы руки и они получили бы возможность писать на любом языке.
Вы не поверите: blog.mozilla.org/luke/2015/06/17/webassembly
Это для некоторых юз кейсов, но не решает ту проблему о которой мы сейчас говорим
Да давайте знатоки, еще минусов)))
webassebly не дает вам возможности банально работать с DOM. Эта фича для того же фронт-дева особо не нужна.
webassebly не дает вам возможности банально работать с DOM. Эта фича для того же фронт-дева особо не нужна.
В goals у проекта есть в том числе «access browser functionality through the same Web APIs that are accessible to JavaScript».
Разумеется надо поддерживать нативно, для производительности и прочих нюансов. Но так как это происходит медленно, а использовать хочется уже сейчас, у вас есть выбор. Взять и юзать тот же бабел и уже наслаждаться es6, или сидеть и ныть, о том что стоит еще чучуть подождать. Уже как года пол все пишут спокойно на es6 как на фронте так и на серваках, а вы все думаете стоит ли.
Вопрос к тем, кто использует Babel и др. подобные трансляторы.
— Насколько сильно усложняется отладка такого кода?
— Насколько сильна просадка в производительности в наиболее сложных местах (на вроде тех же генераторов)
— Кто-нибудь использует в production-е async\await? Стабильно работает?
— Насколько сильно усложняется отладка такого кода?
— Насколько сильна просадка в производительности в наиболее сложных местах (на вроде тех же генераторов)
— Кто-нибудь использует в production-е async\await? Стабильно работает?
Для отладки кода который обрабатывается пре, пост просессингом или еще чем, есть соурсмепы которые позволяют на том же клиенте дебажить написанный код
1) Соурсмапы здорово помогают, да и получившийся код не такой уж страшный.
2) На глаз незаметно, но на 2000 элементов я не тестировал:)
2) На глаз незаметно, но на 2000 элементов я не тестировал:)
Вчера на презентации ES6 выступал разработчик из DHL. Они используют ES6 в продакшн вместе с AngularJS. Показывал и отладку и код. Правда основные фичи, которые они используют — это классы, константы, локальные переменные и толстые стрелки (classes, const, let, => aka arrow functions) Генераторы и другие более продвинутые фичи пока не используют.
Код генерируемый транслятором Babel вполне читаемый и подходит для отладки. Для написания юнит тестов они тоже используют ES6. Правда охват кода тестами никогда не достигнет 100% из-за дополнительного кода генерируемого Babel
Код генерируемый транслятором Babel вполне читаемый и подходит для отладки. Для написания юнит тестов они тоже используют ES6. Правда охват кода тестами никогда не достигнет 100% из-за дополнительного кода генерируемого Babel
Правда охват кода тестами никогда не достигнет 100% из-за дополнительного кода генерируемого Babel
Ну это не совсем правда. Есть опция
auxiliaryComment
Правда охват кода тестами никогда не достигнет 100% из-за дополнительного кода генерируемого Babel
Я использую для анализа покрытия isparta, она игнорирует дополнительный код.
Используем с недавних пор в продакшене Babel + изоморфный React последний.
1. Отладка через сорсмапы делается без проблем. В браузере читаешь es6. Каких-то проблем не встречал пока.
2. Генераторы пока не используем, просадки в производительности визуально не заметили, поэтому цифры не меряли. Билд правда дольше стал в два раза :)
3. Стремно
1. Отладка через сорсмапы делается без проблем. В браузере читаешь es6. Каких-то проблем не встречал пока.
2. Генераторы пока не используем, просадки в производительности визуально не заметили, поэтому цифры не меряли. Билд правда дольше стал в два раза :)
3. Стремно
Использую babel уже около полугода и просто счатслив. Сначала с angular + node.js, сейчас react и async/await на сервере. async/await использую с помощью bluebird.couroutine , посмотрите в тесты, этот вариант самый быстрый, после коллбэков.
Спасибо за bluebird.couroutine, посмотрю. Сразу же вопрос: не возникает проблемы с отловом ошибок (в особенности непредусмотренных) при таком подходе?
нет, в стэк-трейсах все довольно понятно, раньше с этим были проблемы, сейчас вроде нет.
async/await можно дебажить без сорсмэпов спокойно, на мой взгляд. Ранее неудобства доставлял только regenerator, поэтому async/await на клиенте не использую.
// ваш код
async function foo() {
await bar();
}
// сгенерированный babel
var foo = bluebird.couroutine(function *foo() {
yield bar();
});
async/await можно дебажить без сорсмэпов спокойно, на мой взгляд. Ранее неудобства доставлял только regenerator, поэтому async/await на клиенте не использую.
Никаких проблем. Пример. С
bluebird.couroutine аналогично.
При разумном использовании генераторов скорость работы даже выше может быть :)
gist.github.com/asm0dey/0290fb111e2317f0238c
Прелесть в ленивости.
gist.github.com/asm0dey/0290fb111e2317f0238c
Прелесть в ленивости.
Вчера присутствовал на презентации ES6 с докладчиком Dr. Axel Rauschmayer(его блог) Он плотно учавствовал в разработке ES6. Ему задали вопрос насчет поддержки в браузерах и он сказал, что по плану все основные браузеры будут полностью поддерживать стандарт уже до конца этого года.
На днях он закончил книжку по ES6 и она доступна бесплатно в онлайн — Exploring ES6
На днях он закончил книжку по ES6 и она доступна бесплатно в онлайн — Exploring ES6
НЛО прилетело и опубликовало эту надпись здесь
Извините, конечно, но про развитие языка — бред. Особенно порадовало
Это версии ECMAScript. JavaScript так до версии 2 и не дожил — по идее, ей должен был стать ECMAScript 4.
- JavaScript 1.0 (1997)
- JavaScript 2.0 (1998) – с некоторыми изменениями к предыдущей версии
- JavaScript 3.0 (1999) – с некоторыми новыми возможностями
Странно, что в голосовалке нету TypeScript'а…
Поддерживаю. Ну и вообще варианта «другое»
Странно что нет LiveScript-а например, давайте ещё ClojureScript добавим.
А scala.js как же
«Это означает, что некоторые проблемы ES5, на которые разработчики жаловались годами так же никуда не денутся.» — странно, этот вопрос можно было бы решить расширением режима strict, типа strict6.
«В ES6 добавили очень нужные JavaScript-разработчикам шутки...» — абсолютно за, без чувства юмора определённого сорта программировать на JavaScript невозможно! Очень хорошо, что юмор теперь стандартизован!
«В ES6 добавили очень нужные JavaScript-разработчикам шутки...» — абсолютно за, без чувства юмора определённого сорта программировать на JavaScript невозможно! Очень хорошо, что юмор теперь стандартизован!
Поправил опечатки, которые прислало сообщество и убрал опрос. В опросе было всего 3 варианта ответа: ES5, ES6, Coffeescript, и под кофескриптом в контексте релиза ES6 можно было понимать любой другой прекомпайлер. Смысла их все перечислять нет, несмотря на это, самым интересным для меня оказался даже не вышеупомянутый кофескрипт, а lispyscript, советую попробовать всем) Насчет версий – напомню, что это не моя статья, а перевод статьи, которую r/javascript и hacker news получили первыми о релизе спецификации и я подумал, что и хабру неплохо бы было ее почитать на русском языке
Все вроде неплохо в новой спецификации, но официальное переименование это как то не очень(бедный как его уже не называли).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Одобрена спецификация ECMAScript 2015