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

https://www.skype.com/en/new/

Введение в кодсплиттинг (по мотивам доклада с React Conf 2017)

Склеивать весь JS в один большой бандл — плохой тон. Если код приложения немного изменился,
пользователю придётся заново скачивать не только обновлённый код самого приложения,
но и все его зависимости (например, React, Angular и другие довольно тяжёлые библиотеки
и фреймворки).

Большой бандл нужно разделять как минимум на две части: первый файл — все зависимости
приложения, они меняются редко; второй файл — сам код приложения, он меняется
гораздо чаще. Подключаемые файлы нужно кешировать, чтобы пользователь
скачивал только изменённые файлы. При таком подходе после каждого обновления приложения
пользователю не придётся заново скачивать все те же зависимости.

Можно пойти ещё дальше и разделить приложение на файлы, содержащие логику
отдельных частей приложения. Для этого в будущем появится нативный механизм
асинхронной загрузки ES-модулей, который, тем не менее, можно использовать уже
сейчас. Это динамический import(), его особенности:
— на текущий момент stage 3;
— работает со вторым Вебпаком;
— возвращает промис;
— позволяет использовать динамические имена модулей;
– требует babel-плагин syntax-dynamic-import.

Открытие дня: оказывается, языки Ruby, PHP и Perl определяются не спецификацией (как другие нормальные языки), а «эталонным» интерпретатором, от поведения которого все пляшут. Если фактическое поведение интепретатора расходится с документацией, значит врёт документация.

Почему в проектах 2017 года не нужна Джейквери?

Потому что:
— для работы с DOM есть, как ни странно, спецификация DOM4 с .closest(), .append(), .prepend() и другими удобными методами (https://dom.spec.whatwg.org, полифил: http://webreflection.github.io/dom4/);
— для анимаций есть CSS и Web Animations API (https://w3c.github.io/web-animations, полифил: https://github.com/web-animations/web-animations-js);
— для общения с сервером есть fetch (https://fetch.spec.whatwg.org, полифил: https://github.com/github/fetch);
— готовых библиотек на чистом JS предостаточно (https://plainjs.com, http://microjs.com), и чаще всего они легковеснее и качественнее Джейквери-плагинов.

Оказывается, несколько лет назад (не знаю насчёт сейчас) в Фейсбуке вместо Вебпака использовали собственную систему сборки, использующую машинное обучение для максимально эффективной упаковки зависимостей о_О

На днях выбирал решение для интернационализации интерфейса. Нагуглил три на первый взгляд приличные библиотеки: Polyglot от Airbnb, FormatJS от Yahoo и i18next.

Polyglot оказался крайне примитивен. Его возможности ограничиваются выводом локализованных фраз с плюрализацией, сделанной очень странно:

polyglot.extend({
  "num_cars": "%{smart_count} car |||| %{smart_count} cars",
});

polyglot.t("num_cars", {smart_count: 0});
=> "0 cars"

polyglot.t("num_cars", {smart_count: 1});
=> "1 car"

Загадочные четыре чёрточки, как написано на Гитхабе, это «специфика Airbnb» (читай, «так сложилось исторически»).

FormatJS оказался крайне продвинутым и в то же время неудобным. Помимо локализации фраз умеет форматировать числа/даты, причём даты можно получать в относительном виде, например «5 минут назад». Работает на основе Internationalization API, Unicode CLDR и синтаксиса сообщений ICU. Не монолитен, он состоит из нескольких базовых библиотек и предоставляет библиотеки для интеграции с React, Ember, Handlebars и Dust. В плане возможностей круто, но API очень громоздкий и неюзабельный.

В итоге я остановился на i18next. Помимо базовых фич в ней поддерживаются автоматическое определение локали, загрузка и кеширование текстов, расширение возможностей через плагины. Фразы можно выделять в отдельные пространства имён, например по страницам или по фичам. API не вызывает вопросов и пользоваться им просто и приятно. Жаль, что вместо стандартов вроде синтаксиса сообщений ICU в i18next используются велосипеды.

Про ICU и то, как правильно должна работать плюрализация, можно почитать в статье на A List Apart — https://alistapart.com/article/pluralization-for-javascript

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

Хороший фронтендер должен разбираться не только в веб-технологиях, но и в дизайне — без этого он не сможет сделать хороший интерфейс. Каждый день фронтендеру приходится принимать решения, связанные с дизайном. Дизайнер не нарисовал hover-состояния для кнопок и ушёл в отпуск; нужно что-то показать пользователю, если произошла ошибка; нужно добавить пару разделов на страничку «О компании», а дизайнера привлекать не хотят, потому что задача простая; а тут вообще задача по админке, для которой никогда специально дизайн не рисовали.

Даже если говорить о технической стороне, написание кода — тоже дизайн. Интерфейсы ведь бывают не только графические, но и программные. Мало кто станет использовать библиотеку с плохо спроектированным API (всякие OpenGL, Windows API и прочие ужасы не в счёт, там выбора нет).

С чего разработчику интерфейсов начать погружение в дизайн? Рекомендую начать с доклада Артёма Поликарпова «Технолог — тоже дизайнер» о дизайнерских решениях проблем, с которыми может столкнуться любой фронтендер: https://events.yandex.ru/lib/talks/460/