Анонс WebAssembly состоялся в 2015-м — но сейчас, спустя годы, всё ещё немногие могут похвастаться им в продакшне. Тем ценнее материалы о подобном опыте: информация из первых рук о том, каково с этим жить на практике, пока что в дефиците.

На конференции HolyJS доклад об опыте использования WebAssembly получил высокие оценки зрителей, и теперь специально для Хабра подготовлена текстовая версия этого доклада (видеозапись также приложена).

Предисловие

Мое веб-приложение хранит данные в localStorage. Это было удобно, пока не захотелось, чтобы пользователь, заходя на сайт с разных устройств, видел одно и то же. То есть, понадобилось удаленное хранилище.

Но приложение «хостится» на GitHub Pages и не имеет серверной части. Я решил не делать сервер, а данные хранить у третьей стороны. Это дает существенные преимущества:

1. Не нужно платить за сервер, не болит голова о его стабильности и доступности.
2. Меньше кода, меньше ошибок.
3. Пользователю не нужно регистрироваться в моем приложении (это многих раздражает).
4. Приватность выше, и пользователь знает, что его данные хранятся в месте, которому он, скорее всего, доверяет больше, чем мне.

Сначала выбор пал на remoteStorage.js. Они предлагают открытый протокол обмена данными, достаточно приятное API, возможность интеграции с Google Drive и Dropbox, а также свои сервера. Но этот путь оказался тупиковым (почему — отдельная история).

В итоге решил использовать Google Drive напрямую, и Google API Client Library (далее GAPI) как библиотеку для доступа к нему.

К сожалению, документация Google разочаровывает, а библиотека GAPI выглядит недоработанной, к тому же имеет несколько версий, и не всегда понятно, о какой из них идет речь. Поэтому решение моих задач пришлось собирать по кусочкам из документации, вопросов и ответов на StackOverflow и случайных постов в интернете.

Надеюсь, данная статья сэкономит вам время, если вы решите использовать Google Drive в вашем приложении.

Меня зовут Илья Гольдфарб, я разработчик интерфейсов Яндекса. Мне интересно следить за тем, как развиваются инструменты для сборки фронтенда, поэтому я стараюсь изучать изменения в каждом релизе популярных решений.

В преддверии выхода пятой версии webpack я хочу рассказать о его, казалось бы, минорном релизе 4.26.0 от 19 ноября 2018 года, где неожиданно и без объявления войны изменилась версия минификатора по умолчанию. Раньше это был пакет UglifyJS, теперь же используется Terser, форк UglifyES — ветки UglifyJS, которая может сжимать и ES5, и ES6 код. Terser появился, когда основной майнтейнер отказался поддерживать и развивать UglifyES. Впрочем, UglifyJS тоже прекратил свое развитие с августа 2018 года, когда был выпущен последний релиз. В новом форке исправили некоторые баги и немного отрефакторили код.

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

Вся эта история подвигла меня провести маленькое личное исследование сжатия. Вот вопросы, которые я задал:

• Что лучше сжимает ES5, Terser или UglifyJS?
• Что быстрее загружается: сжатая версия ES5 от Terser или от UglifyJS?
• Какая версия весит больше: ES5 или ES6? И как на это влияет TypeScript?
• Большая ли разница между настройками по умолчанию и ручной настройкой?
• А если не webpack? Кто выдаёт сборку меньшего размера, Rollup или webpack?

Не так давно JavaScript похвастался новым примитивным типом данных BigInt для работы с числами произвольной точности. Про мотивацию и варианты использования уже рассказан/переведен необходимый минимум информации. А мне бы хотелось обратить чуть больше внимания на превнесенную локальную «явность» в приведении типов и неожиданный TypeError. Будем ругать или поймем и простим (опять)?

TL;DR Привет. Меня зовут Богдан и я изучаю проблемы чтения кода. Я только что закочнил первую рабочую версию «codecrumbs» — визуального инструмента для изучения исходного кода с помощью «хлебных крошек». Гитхаб репозиторий можно посмотреть тут.

Проблема

Недавно я проводил опрос о главных проблемах с которыми мы сталкиваемся когда начинаем изучать исходный код большого проекта (если вы ещё не участвовали, то пройти опрос всё ещё можно тут).

В этой статье мы рассмотрим, как писать чистый, легко тестируемый код в функциональном стиле, используя паттерн программирования Dependency Injection. Бонусом идет 100% юнит-тест coverage.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

JS-приложения, сайты и другие ресурсы становятся сложнее и инструменты сборки — это реальность веб-разработки. Бандлеры помогают упаковывать, компилировать и организовывать библиотеки. Один из мощных и гибких инструментов с открытым исходным кодом, который можно идеально настроить для сборки клиентского приложения — Webpack.

Максим Соснов (crazymax11) — Frontend Lead в N1.RU внедрил Webpack в несколько больших проектов, на которых до этого была своя кастомная сборка, и контрибьютил с ним несколько проектов. Максим знает, как с Webpack собрать бандл мечты, сделать это быстро и конфигурировать так, чтобы конфиг оставался чистым, поддерживаемым и модульным.


Расшифровка отличается от доклада — это сильно усовершенствованная пруфлинками версия. По всей расшифровке рассыпаны пасхалочки на статьи, плагины, минификаторы, опции, транспайлеры и пруфы слов докладчика, ссылки на которые просто не поставить в выступление. Если собрать все, то откроется бонусный уровень в Webpack :-)

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

Давайте рассмотрим команды, которые действительно способны упростить жизнь любому программисту.

В сегодняшней части перевода учебного курса по React мы продолжим работу над Todo-приложением и поговорим о том, как в React обрабатывают события.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

Возникает такое ощущение, что буквально каждую неделю появляется новый «веб-фреймворк» для Node.js, который называют чем-то таким, что работает быстрее, чем всё, что было до него. Всем известно, что Express — это медленно, но способен ли очередной фреймворк по-настоящему улучшить производительность подсистемы ввода-вывода Node.js? Единственное, что он может — это устранить чрезмерную нагрузку на систему, создаваемую Express. Об улучшении чего-то фундаментального речи не идёт. Собственно говоря, для того, чтобы кардинальным образом улучшить ситуацию, нужно работать на более глубоком уровне, а не добавлять новые абстракции поверх Node.js.



Что нужно для того, чтобы на платформе Node.js можно было бы создавать серверные приложения, работающие гораздо быстрее чем всё то, что есть сегодня?

JavaScript нередко называют «самым популярным языком», но, кажется, никто не отзывается о JS-разработке как о «самой безопасной», и количество подстерегающих проблем в экосистеме велико. Как эффективно их обходить?



Илья Климов задумался об этом, когда ошибка обошлась очень дорого (в буквальном смысле) — и в итоге сделал доклад на HolyJS. А поскольку зрительские отзывы оказались отличными, мы теперь подготовили для Хабра текстовую версию этого доклада. Под катом — и текст, и видеозапись.

Автор материала, перевод которого мы сегодня публикуем, веб-разработчик, говорит, что он старается регулярно пересматривать набор инструментов, которыми пользуется. Делает он это для того, чтобы понять, может ли он без некоторых из них обойтись, решая свои обычные задачи. Недавно он решил провести эксперимент и создать сложное фронтенд-приложение без использования JavaScript-фреймворков.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Привет. 21 февраля в офисе Авито пройдёт Moscow JS 44, неформальная встреча JavaScript-разработчиков. Обсудим инструменты для бойлерплейтинга, форматы сжатия протокольного уровня в http, а также Acceptance testing и BDD. Регистрируйтесь на встречу и приглашайте коллег. Под катом — тезисы выступлений, ссылки на регистрацию (upd: завершена, закончились места) и видеотрансляцию митапа.

Автор материала, перевод которого мы сегодня публикуем, говорит, что в JavaScript-объектах содержится много такого, о существовании чего можно и не подозревать, пользуясь ими в повседневной работе. Объекты в JavaScript очень легко создавать, с ними удобно работать, они кажутся понятными и гибкими сущностями, и многие программисты попросту не задумываются о том, что на самом деле устроены объекты не так уж и просто.

NB: Информацию из публикации на практике следует применять крайне аккуратно и под присмотром более опытных коллег.

За время своей работы, я периодически сталкивался с тем, что разработчики не всегда четко представляют, каким образом работает механизм передачи данных через props, в частности колбеков, и почему их PureComponents обновляется так часто.

Поэтому в данной статье мы разберемся, как передаются callbacks в React, а также обсудим особенности работы event handlers.

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

TL;DR: базовая логика redux помещается в 7 строк JS кода.

О redux вкратце (вольный перевод заголовка на гитхабе):

Redux — библиотека управления состоянием для приложений, написанных на JavaScript.

Она помогает писать приложения, которые ведут себя стабильно/предсказуемо, работают на разных окружениях (клиент/сервер/нативный код) и легко тестируемы.

Я склонировал репозиторий redux, открыл в редакторе папку с исходниками (игнорируя docs, examples и прочее) и взялся за ножницы клавишу Delete:

• Удалил все комментарии из кода
  Каждый метод библиотеки задокументирован с помощью JSDoc весьма подробно
  
• Убрал валидацию и логирование ошибок
  В каждом методе жёстко контролируются входные параметры с выведением очень приятных глазу подробных комментариев в консоль
  
• Убрал методы bindActionCreators, subscribe, replaceReducer и observable.
  
  … потому что мог. Ну или потому что поленился писать для них примеры. Но без корнер-кейсов они ещё менее интересны, чем то, что ждёт вас впереди.
  

А теперь давайте разберём то, что осталось

Перед вами история интегрирования БЭМ-методологии в React-вселенную. Материал, который вы прочитаете, построен на опыте разработчиков Яндекса, развивающих самый масштабный и нагруженный сервис в России — Яндекс.Поиск. Мы никогда раньше не рассказывали настолько подробно и глубоко о том, почему делали так, а не иначе, что нами двигало и чего мы действительно хотели. Внешнему человеку доставались сухие релизы и обзоры на конференциях. Лишь в кулуарах можно было услышать нечто подобное. Я как соавтор негодовал из-за скудности информации снаружи каждый раз, когда рассказывал о новых версиях библиотек. Но в этот раз мы поделимся всеми подробностями.

Все слышали о методологии БЭМ. CSS-селекторы с подчёркиваниями. Компонентный подход, о котором говорят, имея в виду способ написания CSS-селекторов. Но про CSS в статье не будет ни слова. Только JS, только хардкор!

Нововведения в ECMAScript

Здравствуйте читатели Хабр. Предлагаю вашему вниманию интересную штуку которая в скором времени появится уже появилась в стандарте ECMAScript. Она уже доступна почти во всех браузерах и весь функционал тоже. Это нововведение всего лишь сахар-обертка и ее можно решить своими средствами и это я вам тоже покажу. Но этот сахар позволит нам писать кода меньше, ведь мы это так любим. Итак, добавляется базовые функции к массиву, в данном случае их 2, которые позволят нам разворачивать многоуровневые массивы в один или более уровней вложенности. Да да и все это как говориться из коробки