Я боюсь, что в 2016 году «правильная обработка ошибок в асинхронном js» — это всё-таки уже Promises и async/await, про что в этой статье не написано почти ничего.
Что-то я не уверен, что фейсбуку это помогло.
На iOS — 18 тысяч классов, порядка сотни мегабайт, FBEventUpdateNotificationSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h.
На Android — жуёт аккумулятор жутко, воплей полный интернет.
Вот, наугад открыл — https://github.com/codemix/fast.js/blob/master/array/fill.js.
Он явно не проверяет отрицательные значения на входе (которые должны считать с конца), не конвертирует аргументы в числа.
Кстати, я не уверен что он до сих пор быстрее на свежем v8 =). Проверять надо.
WebAssembly от asm.js скоростью _работы_ отличаться не должен — они изоморфны, это два способа записи одного и того же.
Скоростью загрузки и разбора — вполне.
От чистого яваскрипта они оба по скорости работы должны отличаться одинаково.
Если вы про Promise, то дело в том, что реализация Promise в v8 сильно неоптимальна.
Про это все знают, но оптимизациями новых фич в v8 планируют заняться несколько позже, емнип.
--harmony_regexp_lookbehind — включает конкретную фичу, независимо от того, в каком она состоянии.
--es_staging — включает то, что считается готовым, но не стабильным/не оттестированым.
--harmony — уже синоним для --es-staging.
См. https://nodejs.org/en/docs/es6/ (но учтите, что конкретный список фич там для более старой версии).
Можно, используйте =). Но она основывается на последних nightly сборках, а про то, что в Node.js 6.0 ожидается всё-таки v8 5.0, а не 4.9 (как сейчас в той табличке) — было известно давно. Но без стопроцентной гарантии.
Начиная с довольно старой версии, версия v8 равна версии хрома, делённой на 10. Но это относится к стабильным в основном. То есть как только хром 50 выходит (кстати, уже) — ветка v8 5.0 считается стабильной (опять же, уже).
Её как раз несколько минут назад вмерджили в Node.js master, так что в 6.0 будет v8 5.0. Это планировалось, но до конца не было ясно, так как график релизов Chrome/v8 не жёсткий (и стабильный релиз v8 5.0 мог быть отложен), а релиз Node.js 6.0 назначен на конец этого месяца.
Честно говоря, вот так не могу сказать. Предполагаю что первые точно не готовы, а вторые не оттестированы, но я в этом не уверен. Лучше поискать какую-нибудь информацию на эту приписку, где-то может быть описано.
Но ни те ни другие в продакшне использовать не стоит. Для тестирования и разработки следующей версии — да, сколько угодно. А так накатаете в продакшн, какой-нибудь клиент пришлёт запрос на котором оно падает — будет нехорошо.
Зануда-моуд: «полноразмерная сим-карта» размером ровно с банковскую пластиковую карту. Да-да, тот самый прямоугольник, из которого выколупывается ваша симка при её получении у оператора — это не просто держатель карты для красоты, это и есть сим-карта по размеру.
То, что вы назваете «полноразмерной» — мини-sim. Ещё есть микро и нано.
Вполне возможно, что раньше кто-то так же возмущался переходу с полноразмерной сим-карты на мини-сим (тот, к которому вы привыкли).
А так — да, место, вес, лишние доли миллиметра и граммы. Мозги сим-карты занимают столько, что её ещё раз в 50 можно меньше сделать технически — только неудобно будет. А нано-сим — достаточно удобная всё ещё по размеру.
Вы ищете https://nodejs.org/api/process.html#process_event_unhandledrejection
Вопрос вот в чём — хоть кто-нибудь, кроме вас, может её понять?
Если нет — ждём других теорий.
А когда я смогу забрать готовый понипад?
А когда GitHub и Wikipedia блокировали, у вас там звоночек не прозвенел?
На iOS — 18 тысяч классов, порядка сотни мегабайт, FBEventUpdateNotificationSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h.
На Android — жуёт аккумулятор жутко, воплей полный интернет.
Тут, скорее, в руках дело.
Он явно не проверяет отрицательные значения на входе (которые должны считать с конца), не конвертирует аргументы в числа.
Кстати, я не уверен что он до сих пор быстрее на свежем v8 =). Проверять надо.
Скоростью загрузки и разбора — вполне.
От чистого яваскрипта они оба по скорости работы должны отличаться одинаково.
Про это все знают, но оптимизациями новых фич в v8 планируют заняться несколько позже, емнип.
--harmony (enable all completed harmony features)
Насколько я знаю — да.
Ещё: раньше (в Node.js 0.10/0.12) --harmony включал не только готовые фичи, а целую кучу всего совсем сырого.
Начиная с io.js 1.0 — так, как сейчас.
См. https://iojs.org/en/es6.html для истории.
--harmony_regexp_lookbehind — включает конкретную фичу, независимо от того, в каком она состоянии.
--es_staging — включает то, что считается готовым, но не стабильным/не оттестированым.
--harmony — уже синоним для --es-staging.
См. https://nodejs.org/en/docs/es6/ (но учтите, что конкретный список фич там для более старой версии).
Её как раз несколько минут назад вмерджили в Node.js master, так что в 6.0 будет v8 5.0. Это планировалось, но до конца не было ясно, так как график релизов Chrome/v8 не жёсткий (и стабильный релиз v8 5.0 мог быть отложен), а релиз Node.js 6.0 назначен на конец этого месяца.
Но ни те ни другие в продакшне использовать не стоит. Для тестирования и разработки следующей версии — да, сколько угодно. А так накатаете в продакшн, какой-нибудь клиент пришлёт запрос на котором оно падает — будет нехорошо.
То, что вы назваете «полноразмерной» — мини-sim. Ещё есть микро и нано.
Вполне возможно, что раньше кто-то так же возмущался переходу с полноразмерной сим-карты на мини-сим (тот, к которому вы привыкли).
А так — да, место, вес, лишние доли миллиметра и граммы. Мозги сим-карты занимают столько, что её ещё раз в 50 можно меньше сделать технически — только неудобно будет. А нано-сим — достаточно удобная всё ещё по размеру.