Меня тут попросили рассказать о том, как создать и продвигать свой пропозал в 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/

Между тем, вышел Babel 7 RC. До релиза осталось совсем недолго.
https://github.com/babel/babel/releases

Думаю, что можно не переводить. Ну и фолловьте меня в твиттере заодно.

https://twitter.com/chicoxyzzy/status/1027881659998371841

upd: заслал пулл реквест Surma, и он уже даже задеплоил изменения на https://ishoudinireadyyet.com

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

W3C CSS Working Group опубликовала 2 новых Candidate Recommendation (https://www.w3.org/TR/2018/CR-css-scroll-snap-1-20180814/ и https://www.w3.org/TR/2018/CR-css-values-3-20180814/), а также First Public Working Draft новой версии последней (https://www.w3.org/TR/2018/WD-css-values-4-20180814/)

Также W3C опубликовала Candidate Recommendation TTML2 для синхронизации текста во времени
https://www.w3.org/blog/news/archives/7243

Кросс-платформенный игровой движок Unity переключился с asm.js на WebAssembly при компиляции в WebGL.
https://blogs.unity3d.com/2018/08/15/webassembly-is-here/

ничоси
https://twitter.com/chicoxyzzy/status/1029952016225853440

Девненько ничего не писал, да и до середины сентября вообще с этим будет сложно. Тем не менее, какие-то новости буду пытаться писать время от времени не смотря ни на что. И вот очень горячая новость: релиз Babel 7 запланирован на пятницу, но я вам ничего не рассказывал 🙊

Интересный API для координации ресурсов между контекстами (табами, воркерами)
https://github.com/WICG/web-locks/blob/master/EXPLAINER.md
Там же другие ссылки и объяснение почему нельзя было зареюзать Atomics, которые используются в SharedArrayBuffer.

В данный момент Web Locks API находится на этапе Editor’s Draft в Web Platform Incubator Community Group (это инкубатор предложений для w3c). API позволяет “захватить” ресурс в одном из контекстов и запланировать доступ к ресурсу из других контекстов.

Пример использования API
async function get_lock_then_write() {
await navigator.locks.request('resource', async lock => {
await async_write_func();
});
}

async function get_lock_then_read() {
await navigator.locks.request('resource', {mode: 'shared'}, async lock => {
await async_read_func();
});
}

Интересно, что текущий пропозал Web Locks упоминает AbortSignal, который используется в данный момент для отмены fetch-запроса в современных браузерах. Explaner пропозала предостерегает о возможных дедлоках. Наконец-то дедлоки в вебе! JavaScript, ты теперь совсем взрослый 😄

За подробными примерами, юзкейсами, альтернативными пропозалами и FAQ проходите по ссылке в начале этого сообщения.

А в WebKit сегодня попал вот такой вот патч:
https://bugs.webkit.org/attachment.cgi?id=347525&action=diff

Это Web Share API, который тоже продвигается WICG (Web Platform Incubator Community Group) и описывается вот здесь https://github.com/WICG/web-share/blob/master/docs/explainer.md

Это предложение стандарта позволяет делиться контентом не только с системными сервисами операционных систем и нативными приложениями, но и с другими веб приложениями. Для того, чтобы последние могли принимать шейры, существует отдельный пропозал, спека, которого разрабатывается отдельно, а explaner лежит вот тут https://github.com/WICG/web-share-target/blob/master/docs/explainer.md

В хроме для Android этот API поддерживается с версии 61 и был анонсирован 2 года назад https://developers.google.com/web/updates/2016/09/navigator-share