Всем привет. Я Серёжка Рубанов. Панк-разработчик из города Орла, двукратный чемпион вселенной по покеру на костях, digital nomad, член команды Babel, участник WebAssembly Community Group, нетипичный ботан, контрибьютор в разный хипстерский (и не очень) опенсорс, WebAssembly-проповедник (заходите в @webassembly_ru), JavaScript камикадзе, организатор @BeerJS Moscow и прочих спонтанных (и не очень) BeerJS в различных местах, которым приходится терпеть мое присутствие. Я буду тут рассказывать о всяких нёрдских вещах типа стандартов и спецификаций. Иногда буду рассказывать о конференциях, которых посещаю over9000 в год.

Сегодня пятница, а значит что-то первое из интересного будет скорее всего уже в понедельник. На прошлой неделе был митинг TC39 — комитета, который занимается разработкой JavaScript и около-JavaScript стандартов. Официальных записей с митинга пока еще нет, но благодаря моей ботанической (но это не точно) натуре и возможности выхватывать различные инсайды, вы узнаете об изменених в стандарте ECMAScript раньше. А пока хороших выходных и с международным днем пива! 🍻

P.S. Можете полистать мой твиттер https://twitter.com/chicoxyzzy. Может быть найдете что-то интересное.

Короткая новость: как я уже успел упомянуть в одном из жс чатов (t.me/js_ru/91979), вышла последняя бета Babel 7 под номером 56. После нее будет релиз кандидат и потом релиз. В седьмой версии бабеля ооочень много внутренних изменений и улучшений, но они не должны затронуть большинство разработчиков. Для более простой миграции с шестой на седьмую версию существует https://github.com/babel/babel-upgrade. Большинство новых пакетов бабеля теперь будет опубликовано в npm namespace @babel. Пресетов preset-stage-x больше не существует. Если хотите усложнить себе жизнь добавлением нестандартизированных фич, то можете добавить нужные proposal плагины или даже сделать себе такие пресеты самостоятельно. Также в Babel 7 будут добавлены реализации новых пропозалов, парсер Babylon будет переименован в @babel/parser (который, кстати, научится понимать TypeScript), и много-много других изменений. Так что если все пойдет хорошо, то ждем релиза и официального анонса в конце этого месяца.

С 24 по 26 июля в Редмонде, в офисе Microsoft прошла регулярная встреча (https://github.com/tc39/agendas/blob/master/2018/07.md) технического комитета 39. Официальных записей пока нет, но я вкратце расскажу что вообще там происходило.

ArrayBuffer.prototype.transfer (https://github.com/domenic/proposal-arraybuffer-transfer/) — это довольно старый пропозал. Какое-то время он находился в списке неактивных предложений, но недавно Доменик Деникола взялся за него в качестве чемпиона и продвинул его из stage 0 сразу в stage 2.

Временное выключение SharedArrayBuffer в браузерах (из-за Spectre и Meltdown) позволило провести изменение API — переименовать Atomics.await в Atomics.notify. Слайды прилагаю https://docs.google.com/presentation/d/1iiGJyVwy6YM3p8T0hfaDuj4fQ4tT0b4Oz24OzzCetAg/edit#slide=id.g397b9d4010_0_78.

Temporal Proposal (https://github.com/tc39/proposal-temporal) (замена не слишком хорошего Date) очень сильно обновился и пока остается на stage 1. Вот слайды http://htmlpreview.github.io/?https://github.com/tc39/proposal-temporal/blob/master/July2018Updates.html.

Также обсудили Realms shim security review https://github.com/tc39/agendas/blob/master/2018/realms-sec-review.pdf.

Intl.DateTimeFormat.prototype.formatRange и Intl.DateTimeFormat.prototype.formatRangeToParts (https://github.com/fabalbon/proposal-intl-DateTimeFormat-formatRange) передвинулись со stage 0 на stage 2. Слайды тут https://docs.google.com/presentation/d/e/2PACX-1vQXuKpkf-kHF4Ue-35PAez79EL2bTU-s3dGbQvj0zwOzbqnF1zJJif_RT8wV9v8VkI4agEzvBPbKOoi/pub?slide=id.p.

Explicit resource management (https://github.com/rbuckton/proposal-using-statement) — ушел на stage 1. Слайды здесь https://docs.google.com/presentation/d/1OmkXFMizf5iYME9ClERZ3C1dwUAhh7-r2YMD-rTzY-Y/edit?usp=sharing.

Do expressions немного обновились — https://github.com/tc39/agendas/blob/master/2018/do-expressions-update.pdf.

Пропозал Dynamic Modules (https://github.com/guybedford/proposal-dynamic-modules) передвинулся на stage 1. Вот слайды https://docs.google.com/presentation/d/1sqlvsiIOO0MgU6bW4TjB4RXZkjMAlEzuING_qMF1fYo/view#slide=id.p.

Object.fromEntries (https://github.com/tc39/proposal-object-from-entries) переместился со stage 2 на stage 3.

Обсудили менеджмент и инфраструктуру TC39 (https://docs.google.com/presentation/d/1eTBTMZzylhZR4v7Hgfd3UJYwLBgQZgX8q8fGvsvcNDE/edit#slide=id.p).

Оптимизировали await (https://github.com/tc39/agendas/blob/master/2018/await-change.pdf).

Еще обсудили подгруппы в TC39 (https://docs.google.com/presentation/d/1x2t8ggcpFlZ2zl1RjVgO5fmGjqXRxlkoqcGDKY5ksVg/edit#slide=id.p).

С первого на второй stage перешел пропозал RegExp Match array offsets https://github.com/rbuckton/proposal-regexp-match-offsets.

Пропозал по декораторам обновился (https://docs.google.com/presentation/d/1issTHgP5bf_FsbCSDfKAHjjoNnFa9nI0bEeCZtbh1oM/edit#slide=id.p), но остается на втором stage.

Cancellation (https://github.com/tc39/proposal-cancellation) остается на stage 1. Слайды с презентации прилагаю https://docs.google.com/presentation/d/19M7OkW8fr-HBYzgQRDSX77Pn4WmGh_5gPnBV38N3x08/edit?usp=sharing.

First-Class Protocols (https://github.com/michaelficarra/proposal-first-class-protocols) остаются на стейдже 1. Вот слайды https://docs.google.com/presentation/d/1HnxJl4Iodf3I23e-ZDkw4F1LEkMRGUBFq6xxR0a9a_k/edit?usp=sharing.

Partial Application Syntax (https://github.com/tc39/proposal-partial-application) также остаются на первом стейдже. Картинки тут https://github.com/tc39/proposal-partial-application.

Пропозал JavaScript Standard Library (https://github.com/msaboff/JavaScript-Standard-Library) переместился на stage 1.

Intl.NumberFormat (https://github.com/sffc/proposal-unified-intl-numberformat) — этот пропозал я пока так и не понял передвинулся ли на стейдж 2. Вроде бы нет. Вот слайды https://docs.google.com/presentation/d/1_1D15PWniTlbLu1BOU9aDf5H87Ecq85i0CuLl5KA4DE/edit#slide=id.g3db4b37152_0_0.

Обсудили проблемы добавления нового синтаксиса в JavaScript https://docs.google.com/presentation/d/179v41LMaEXDxaD-piSgYVi6btFJoNoeYVncXe0172GM/edit#slide=id.p. На 4 слайде внезапно мой патч в спецификацию. Вот ссылка на него на гитхабе https://github.com/tc39/ecma262/pull/1126. Может быть расскажу о нем подробнее позже.

Вроде ничего не забыл.

Хочется поблагодарить Сашу Майорова за промоушн канала и сделать ответочку. Саша ведет канал про собеседования, задачки по программированию и просто про веб-технологии. Также он сейчас главный по RadioJS. Обязательно подписывайтесь на его канал.
https://news.1rj.ru/str/prowebit

Кстати, насчет временного отключения SharedArrayBuffer в браузерах. Google без каких-либо анонсов включил его в Chrome 68. Я заметил это совершенно случайно, написав “sha” в консоли и увидев его в списке автодополнения. Включить SAB вновь позволила изоляция сайтов, которая была добавлена еще в Chrome 67. Мозилла также работает над изоляцией сайтов. Про Safari и Edge информацию найти не удалось. Если вы знаете что-то об этом, то обязательно расскажите мне.
https://twitter.com/chicoxyzzy/status/1025519923496407045

Неделю назад в ChakraCore вмержили поддержку Object rest / spread. По дефолту поддержка выключена и включается флагом ES2018ObjectRestSpread. Интересно, успеют ли зашипить эту фичу включенной подефолту к осеннему обновлению Windows, в котором приедет Edge 18? В данный момент Edge — единственный браузер, который не умеет Object rest / spread.

https://github.com/Microsoft/ChakraCore/pull/5498

Еще интересный факт о spread operator: никакого спред оператора не существует. Вот так. Бум 🤯
По спецификации спред относится к пунктуаторам и является просто синтаксисом. Забавно, но даже Jordan Harband, один из активных участников TC39 и чемпион нескольких предложений в спецификацию, кажется не знал об этом.
https://github.com/kangax/compat-table/pull/1331#discussion_r206703275

Там же по ссылке мои пояснения на эту тему, а также ссылка на SO, где также это все объясняется.

Пример того, как можно заинлайнить вебассембли прямо в JS коде.

https://github.com/dcodeIO/long.js/blob/master/src/long.js#L9-L11

long.js — библиотека, которая позволяет работать с 64-битными целыми числами. WebAssembly умеет работать с int64/uint64 из коробки, поэтому если WebAssembly доступен в браузере (или nodejs), то он будет использоваться для математических операций.

Кстати, в ECMAScript есть пропозал BigInt (https://github.com/tc39/proposal-bigint), который находится на stage 3 и уже заимплеменчен в хроме, начиная с версии 67.

Меня тут попросили рассказать о том, как создать и продвигать свой пропозал в ECMAScript. У меня как раз есть один, но надо еще найти время оформить. Пропозал довольно простой, но требует погружения в семантику. Посмотрим что из этого выйдет.

#ecmanoscriptproposal

Недавно появился вот такой пропозал:
https://github.com/jasonwilliams/proposal-promise-allSettled

Promise.allSettled — это такой аналог Promise.all, который не реджектится если один из промисов зареджектился. Я хотел бы предложить добавить еще два метода для работы с промисами — Promise.any и Promise.some. Типичный юзкейс Promise.any — у нас есть несколько разных URL и мы хотим получить ответ от быстрейшего. Может показаться, что для такой задачи подойдет Promise.race, но это не так. Promise.race возвращает любой fulfilled промис, будь он resolved или reject. Мы же хотим вернуть именно успешный, разрезолвленный промис и реджектнуть только если все промисы реджектнулись. Promise.some принимает iterable первым параметром и число вторым. Он возвращает массив разрезолвленных промисов указанной во втором параметре длины. Если зареджектилось слишком много промисов (количество оставшихся промисов меньше, чем количество требуемых), то Promise.some сразу же реджектится.

Давайте для начала разберемся с Promise.any. Как мы можем реализовать это сейчас?

function any(promises) {
return Promise.all(
promises.map(promise =>
promise.then(val => {
throw val;
}, _ => _),
),
).then(() => {
throw Error('no successful connections');
}, _ => _);
}

Используем инверсию Promise.all, который реджектится с первым же реджектом любого из промисов, которые мы передаем в any. Поэтому делаем все наоборот — если промис успешный, то реджектим его, если неуспешный, то резолвим.

В следующей серии #ecmanoscriptproposal будем разбираться как такой пропозал оформить и предложить комитету. Stay tuned.

Вот по этой ссылке можно отслеживать статусы предложений в WebAssembly: https://github.com/WebAssembly/design/issues?q=is%3Aissue+is%3Aopen+label%3A%22🛤+tracking%22

Если вы в Питере, то забегайте сегодня на дринкап от SPb Frontend. Должно быть здорово.
https://twitter.com/spb_frontend/status/1026771207167856643

А если вы в Киеве, то забегайте послезавтра на день рождения BeerJS Kyiv. Им исполняется 2 года.
t.me/beerjskyiv/247965

Если кто-то еще не в курсе, Apple прекращает поддержку OpenGL и OpenCL начиная с macOS Mojave и iOS 12. В этих версиях операционных систем данные API все еще будут работать, но не будут обновляться и впоследствии могут быть удалены. Apple предлагает вместо них использовать Metal 2. Официальной поддержки Vulkan API (пришедшему на смену OpenGL) на macOS и iOS нет, но есть опенсорс проект MoltenVK от Khronos Group (создателей OpenGL и Vulkan), который позволяет биндить Vulkan в Metal. Но как это все отразится на WebGL, который основан на OpenGL ES? Сотрудники Apple обещают, что WebGL в Safari продолжит работать (https://forums.developer.apple.com/message/314676#314676). В Chrome и Firefox (а также в Qt Framework) уже использется слой совместимости ANGLE, который позволяет транспилировать язык шейдеров GLSL (OpenGL) в HLSL (Direct3D) на платформах Windows. Вероятно им придется использовать нечто подобное на операционках от Apple. Для совместимости OpenGL ES и Metal существует MoltenGL от всё тех же Khronos Group, правда, в отличие от MoltenVK, он платный и проприетарный.

@maxgraey предложил написать также о WebGPU.
WebGPU — это новый API, предложенный Apple, который будет работать поверх DirectX 12, Metal и Vulkan.
https://webkit.org/blog/7380/next-generation-3d-graphics-on-the-web/
WebGPU публично поддерживается такими компаниями как Apple, Microsoft, Mozilla, Google, Intel, AMD, Яндекс (карты), Epic (Unreal Engine), Unity Technologies (Unity3D). В данный момент рабочая имплементация существует в виде experimental feature (включается в разделе develop) в Safari. В июне Google объявил о своем намерении заимплементить WebGPU в Chrome.
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/dxqWTSvyhDg

Основной репозиторий WebGPU находится здесь: https://github.com/gpuweb/gpuweb

А вот ANGLE-подобный слой совместимости для Chromium’ов: https://github.com/google/nxt-standalone

Если Вам интересна компиляцмя Kotlin в JS, Вы живете в Москве, Питере или Минске, то это для Ваc.

https://twitter.com/bashorov/status/1026884174823796737

16 августа пройдет встреча TC39 по спецификации ECMA402. Это спецификация интернационализации (aka Intl). Повестка дня тут.

Вчера оказывается был созвон по пропозалу декораторов. Вот стенограмма (еще не влита в мастер ветку, может незначительно меняться)
https://github.com/tc39/proposal-decorators/blob/master/meetings/2018-08-07.md

update: влили в том же виде, ссылку обновил

Object rest / spread не попадут в Edge 18. Печально ☹️
https://github.com/Microsoft/ChakraCore/pull/5268#issuecomment-411438657

Ко мне доехал мой Oculus Go. Так что возможно теперь буду еще писать про эксперименты с WebVR. Кстати, если знаете что там за браузер такой, на основе чего он, и можно ли установить туда нормальные хром / файрфокс, то напишите мне пожалуйста (@chicoxyzzy).

Если что, цены на модель 64 Гб в России доходят до 30 килорублей. Я заказывал с Амазона за ~$280 ($249 + приоритетная доставка). Шло 4 суток.

-------------------

upd: нашел вот такую инфу. Хромиум 61 (такой же как в Electron 2). Неплохо. Значит даже WebAssembly должен быть.
https://developer.oculus.com/documentation/vrweb/latest/concepts/carmel-getting-started/