Начнем с начала

Фотография: "Любопытный" Liliana Saeb (CC BY 2.0)

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

Динамическое связывание

При динамическом связывании определение метода для вызова происходит во время выполнения, а не во время компиляции. JavaScript выполняет это с помощью this и цепочки прототипов. В частности, внутри метода this определяется во время вызова, и значение this будет разным в зависимости от того, как метод был определен.

Давайте сыграем в игру. Я называю её "Какой здесь this?"

Наше положение, как владельцев популярного веб-сайта — и наша работа в поддержке популярной платформы React — дают нам уникальные возможности и понимание работы с браузером, которые мы хотим использовать для решения проблемы "очередей". Являясь активным участником сообщества веб-стандартов(W3C), мы принимали участие в обсуждении многих инноваций, включая service workers и CSS-overscroll, но до недавнего времени мы никогда не создавали собственные инициативы для улучшения веб-браузера. С целью добиться значительных увеличения производительности, был предложен новый API, который в результате тесного сотрудничества с нашими коллегами из Google Chrome, был предоставлен для ознакомительной версии. Chrome v74 будет включать в себя isInputPending API, и может быть использован для улучшения как общего времени выполнения JavaScript, так и времени отклика на события. Это лишь первый шаг к улучшению планирования JavaScript в вебе. Мы надеемся получить отзывы разработчиков и использовать их для создания финальной версии API.

В отличие от распространенной "клиент-серверной" архитектуры, для децентрализованных приложений характерно:

• Отсутствие необходимости хранить базу данных с логинами и паролями пользователя. Информация для доступа хранится исключительно у самих пользователей, а подтверждение их достоверности происходит на уровне протокола.
• Отсутствие необходимости использовать сервер. Логика приложения может выполняться в блокчейн-сети, где возможно и хранение необходимого количества данных.

Существует 2 относительно безопасных хранилища для ключей пользователей — хардверные кошельки и браузерные расширения. Хардверные кошельки в большинстве своем максимально безопасны, однако сложны в использовании и далеко не бесплатны, а вот браузерные расширения являются идеальным сочетанием безопасности и простоты в использовании, а еще могут быть совершенно бесплатны для конечных пользователей.

Учитывая все это, мы захотели сделать максимально безопасное расширение, которое упрощает разработку децентрализованных приложений, предоставляя простой API для работы с транзакциями и подписями.
Об этом опыте мы вам и расскажем ниже.

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

Введение

Когда-то давно я смеха ради решил доказать обратимость процесса и научиться генерировать JavaScript (а точнее, Asm.js) из машинного кода. Для эксперимента был выбран QEMU, некоторое время спустя была написана статья на Хабр. В комментариях мне посоветовали переделать проект на WebAssembly, да и самому бросать почти законченный проект как-то не хотелось… Работа шла, но уж очень медленно, и вот, недавно в той статье появился комментарий на тему «Так и чем всё закончилось?». На мой развёрнутый ответ я услышал «Это тянет на статью». Ну, раз тянет, то будет статья. Может, кому пригодится. Из неё читатель узнает некоторые факты про устройство бекендов кодогенерации QEMU, а также как написать Just-in-Time компилятор для веб-приложения.

Хайп по Svelte после недавнего релиза 3 версии фреймворка всё-таки имеет место быть, чему свидетельствуют сильно возросшее комьюнити и огромное количество вопросов как в официальном чате, так и в нашем рускоязычном telegram-канале. Всё больше разработчиков украдкой или всерьёз присматриваются к этой технологии и задумываются о её применении в своих новых проектах. Для этих разработчиков и всех прочих интересующихся темой максимально эффективного написания кода, Rich Harris, автор и идеолог фреймворка, опубликовал статью о том, как Svelte помогает разработчику минимизировать усилия при создании современных реактивных web-приложений, перевод которой я и предлагаю ниже.

По мере того как ваше приложение развивается и растёт, увеличивается и время его сборки — от нескольких минут при пересборке в development-режиме до десятков минут при «холодной» production-сборке. Это совершенно неприемлемо. Мы, разработчики, не любим переключать контекст в ожидании готовности бандла и хотим получать фидбек от приложения как можно раньше — в идеале за то время, пока переключаемся с IDE на браузер.

Как этого достичь? Что мы можем сделать, чтобы оптимизировать время сборки?

Эта статья — обзор существующих в экосистеме webpack инструментов для ускорения сборки, опыт их применения и советы.

Оптимизации размера бандла и производительности самого приложения в этой статье не рассматриваются.

При разработке сайтов, выходящих за рамки условного бутстрапа, рано или поздно возникают вопросы, связанные с производительностью анимаций. Особенно важными они являются в дизайнерских сайтах, вроде тех, что попадают в каталоги Awwwards, FWA, CSS Design Awards и.т.д. При этом часто задача создания анимаций и последующей оптимизации, если она будет нужна, ложится на плечи не очень опытных разработчиков, которые даже не знают с чего начать. Обычно все это выливается в тормозящие сайты, которыми невозможно пользоваться, и последующее негативное отношение ко всему классу таких проектов. В этой статье мы постараемся разобрать, где находится граница приемлемой производительности анимаций, какие узкие места часто встречаются и куда смотреть в инструментах разработчика в первую очередь.

Я написал эту статью по мотивам выступления, которое я делал на встрече Berlin.js. В последнее время выходит мало русскоязычных материалов об этом довольно популярном и стабильном фреймворке и я решил немного исправить эту ситуацию.

Вы учите Ember.js один раз, а потом применяете эти знания на всех Ember.js проектах. Этот тезис я попытаюсь раскрыть под катом.