Джастин Фуллер, автор материала, перевод которого мы сегодня публикуем, предлагает рассмотреть три новых возможности, появление которых ожидается в JavaScript в обозримом будущем. Сначала он расскажет о процессе развития JS, а после этого представит обзор этих возможностей и покажет примеры их использования. Речь пойдёт об операторах ?., ?? и |>.

О стандарте ECMAScript и развитии JavaScript

Если вы уже знакомы с особенностями деятельности рабочей группы ECMA TC39, с тем, как она осуществляет отбор и обработку предложений о совершенствовании JavaScript, вы вполне можете пропустить этот раздел. Если же вы из тех, кому интересно об этом узнать — вот краткий обзор того, чем занимается TC39.

JavaScript — это реализация стандарта, называемого ECMAScript, который был создан для стандартизации реализаций языка, которые появились в ранние годы существования веб-браузеров.

Существует восемь редакций стандарта ECMAScript и семь релизов (четвёртая редакция стандарта не выходила, после третьей сразу идёт пятая). Разработчики JavaScript-движков приступают к реализации новшеств языка после выхода стандарта. Здесь можно увидеть, что не каждый движок реализует все возможности, при этом некоторым движкам для введения новшеств требуется больше времени, чем другим. Хотя такое положение дел и не идеально, это, всё же, лучше, чем полное отсутствие стандартов.

В материале, перевод которого мы публикуем сегодня, Кент Доддс рассказывает о библиотеке собственной разработки для тестирования React-приложений, react-testing-library, в которой он видит простой инструмент, способный заменить enzyme и способствующий написанию качественных тестов с применением передовых наработок в этой области.

Автор материала говорит, что давно размышлял о чём-то подобном, и в итоге, примерно в середине прошлого месяца, решил заняться разработкой библиотеки для тестирования, которая его устраивала бы. В частности, в enzyme ему не нравилось то, что большинство возможностей этой библиотеки склоняют разработчика к не самым лучшим методам подготовки тестов, которые способны навредить проекту. В результате у него получился простой, но самодостаточный набор инструментов для тестирования React DOM.

Вышел перевод нового видео от команды hackage.tv, в котором очень доступно рассказано об использовании методов жизненного цикла в React 16.3 и getDerivedStateFromProps в частности.

Мы готовимся сделать то, что не делали вот уже два года, — 27-го апреля соберём на DevDay 150 неравнодушных к JavaScript. Научимся жить с Titanium, ускорять приложение с помощью service workers и напишем гибридное приложение на Angular.

Под катом явки, пароли и про трансляцию.

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

• Вступление
• Тесты и есть проблема!
  
  • Немного истории
  • Небольшая викторина
• Обзор TDD
  
  • Тесты — это формализованные требования
  • TDD поощряет хорошую архитектуру
  • TDD экономит время
  • Тесты — это лучшая документация
  • Немного выводов
• В чём же решение?
  
  • Несколько примеров
  • Немного про планы

Сложно уследить за новшествами различных версий ECMAScript, а ещё сложнее — найти полезные примеры их применения, не перекапывая горы информации. Поэтому сегодня мы публикуем перевод материала, автор которого проанализировал 18 новых возможностей ECMAScript, в число которых входят те, что имеются в уже вышедших стандартах ES2016 и ES2017, а также — те, которые должны появиться в стандарте ES2018. Автор этой статьи обещает, что каждый, кто её прочтёт, узнает много интересного и полезного о новых возможностях JavaScript.

(С)

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

• кэширование страниц сайта для офлайн доступа;
• ведение учета страниц, доступных офлайн, проброс необходимых данных;
• мониторинг статуса сети, онлайн или офлайн;
• общение сервис-воркера со страницами и вкладками, которые он обслуживает;
• перехват сервис-воркером запроса на открытие адреса /offline/ и генерирование новой страницы прямо на устройстве, без запроса к серверу.

Если тема сервис-воркеров и Progressive Web Apps (PWA) для вас новая, то перед чтением этой статьи необходимо познакомиться с ними поближе.

Меня зовут Рыбин Павел, я работаю во фронтенд-разработке Медиапроектов Mail.Ru Group. Это руководство мне помогали писать грабли, набитые шишки и подводные камни, попавшиеся мне при реализации PWA для мобильной версии Авто Mail.Ru.

В тексте будут встречаться небольшие примеры кода, иллюстрирующие рассказ. Расширенную же демо-версию можно посмотреть на GitHub.

Для передачи данных сервером на php клиенту можно использовать следующий алгоритм:

1. Сервер php публикует данные в канал redis.
2. Сервер node подписывается на события в соответствующем канале redis и при
   наступлении события поступления данных публикует эти данные уже в
   socket.io
3. Клиент подписывается на сообщения socket.io и обрабатывает их при поступлении

Исходный код проекта можно найти на github

Мы уже видели насколько WebAssembly быстро компилируется, ускоряет js библиотеки и генерирует более компактные бинарники. У нас даже есть общее представление как наладить взаимодействие не только между сообществами Rust и JavaScript, но и с сообществами других языков. В прошлой статье мы упоминали специальный инструмент wasm-bindgen и сейчас я бы хотел остановиться на нем более подробно.

Мы решили создать небольшой фреймворк для бессерверных веб-приложений в AWS. Может более правильно назвать это не фреймворком, а заготовкой, — я не знаю. Но суть в том, чтобы создать основу для быстрой разработки бессерверных приложений в AWS. Код выложен на GitHub и открыт для любых усовершенствований, коих предстоит немало.


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

В начале этого года я присоединилась к команде, работающей над MongoDB Compass — графическим интерфейсом для MongoDB. Пользователи Compass через Intercom запросили инструмент, позволяющий писать запросы к базе данных, используя любой удобный им язык программирования, поддерживаемый драйвером MongoDB. То есть нам нужна была возможность трансформировать (компилировать) язык Mongo Shell в другие языки и обратно.

Данная статья может стать как практическим руководством, помогающим при написании компилятора на JavaScript, так и теоретическим ресурсом, включающим основные понятия и принципы создания компиляторов. В конце приведен не только полный список всех используемых при написании материалов, а также ссылки на дополнительную литературу, направленную на более глубокое изучение вопроса. Информация в статье подается последовательно, начиная с исследования предметной области и далее постепенно усложняя функционал разрабатываемого в качестве примера приложения. Если во время прочтения вам кажется, что вы не улавливаете переход от одного шага к другому, вы можете обратиться к полной версии данной программы и возможно это поможет устранить возникший пробел.

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

Автор материала, перевод которого мы публикуем сегодня, говорит, что ему очень и очень часто приходилось видеть, как веб-разработчики бездумно пользуются современными фреймворками вроде React, Angular или Vue.js. Эти фреймворки предлагают много интересного, но, как правило, программисты, применяя их, не учитывают главнейшей причины их существования. Обычно на вопрос: «Почему вы используете фреймворк X», можно услышать следующие ответы, среди которых, однако, нет самого главного:

• Этот фреймворк основан на компонентах.
• У него имеется мощное сообщество.
• Для него разработано множество сторонних библиотек, которые помогают решать различные задачи.
• Существуют полезные дополнительные компоненты для этого фреймворка.
• Имеются расширения для браузеров, которые помогают отлаживать приложения, созданные с помощью данного фреймворка.
• Этот фреймворк хорошо подходит для создания одностраничных приложений.

На самом же деле самая главная, фундаментальная причина использования фреймворков заключается в том, что они помогают решать задачу синхронизации пользовательского интерфейса и внутреннего состояния приложения. Это — чрезвычайно сложная и важная задача, и именно о ней мы сегодня и поговорим.

Здравствуйте, меня зовут Дмитрий Карловский и это продолжение традиционной рубрики "Почему мы так не любим писать тесты?". Короткий ответ: потому, что получаемые от них бонусы не перевешивают затрачиваемых усилий. Если это так, значит мы делаем что-то не правильно. Давайте разберёмся что же могло пойти не так..

Данная заметка выросла из главы "Заблуждения" лонгрида "Концепции автоматического тестирования", посредством дополнения новыми заблужениями и аргументами.

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

Чтобы непрерывно улучшать большие клиентские интерфейсы, нужна мощная система автотестов. Разработчик Яндекса Дмитрий Андриянов dima117 кое-что про это знает — пару месяцев назад он поделился своим опытом на Я.Субботнике в Нижнем Новгороде.


— Сегодня я расскажу, как мы в Директе пишем модульные тесты на веб-интерфейс. Мы в целом посмотрим, чем тесты на интерфейс отличаются от других тестов. Рассмотрим два подхода к написанию тестов: с помощью Selenium и с помощью Headless-браузеров. И в конце покажу инструмент, который мы написали в Директе для запуска тестов в Headless Chrome.

Лень — двигатель прогресса…

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

Не хотите читать? Посмотрите демо.

Символы нулевой ширины — это непечатаемые управляющие символы, которые не отображаются большинством приложений. Н​апример, в э​то пред​ложение я вст​авил де​сять про​​белов н​улевой ширины, вы эт​о замет​или? (Подсказка: вставьте предложение в Diff Checker, чтобы увидеть местоположение символов!). Эти символы можно использовать как уникальные «отпечатки» текста для идентификации пользователей.


Безусловно, он может здесь быть. И вы никогда не догадаетесь

Зачем?

Ну, изначальная причина не слишком интересна. Несколько лет назад я с командой участвовали в соревнованиях по различным видеоиграм. У команды была приватная страничка для важных объявлений, среди прочего. Но в итоге эти объявления стали репостить в других местах, с издевательствами над командой, раскрывая конфиденциальную информацию и командную тактику.

Давным давно я посмотрел Терминатор1. Немного подрос и посмотрел немного отрефакторенный Терминатор 2. Третьей интерации пришлось ждать немного дольше.

И каждый раз бедному СкайНету не везло, и каждый раз все наперекосяк, и секрет этого невезения очень прост — СкайНет не был Subject Under Test (SUT).

Другими словами SkyNet подзабила на тестирование, и производила разведку боем. И, как это обычно бывает, падала в корку(под пресс, в лаву, далее не помню) примерно сразу после выкладки в продакшен.

И весь вопрос — как же протестировать что-то до этой выкладки, до того момента как станет поздно поворачивать назад. И убить всех человеков, конечно же.

Материал, перевод которого мы предлагаем сегодня вашему вниманию, представляет собой обновлённую, с учётом положения дел в 2018 году, версию статьи об исследовании фреймворков, которая была опубликована в декабре 2017.