JavaScript-разработчик из Франции, Себастьян Кастель, поделился мыслями о том, как на его взгляд должен выглядеть JavaScript код в 2017 году.

А вы помните те времена, когда JavaScript был языком, который использовали только для оживления страниц сайта? Это время уже прошло, так как, языки программирования развиваются вместе с методами их использования. Посмотрите на код, который вы написали один, два года назад: он вас смущает? Если да, этот пост для вас.



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

Объектное Реактивное Программирование

Дмитрий Карловский из SAPRUN представляет… ммм...

Это — текстовая версия одноимённого выступления на FrontendConf'17. Вы можете читать её как статью, либо открыть в интерфейсе проведения презентаций, либо посмотреть видео.

        Сто тринадцать раз в секунду оно тянется, и достает все дальше. Если бы пришло подтверждение, сигнал — оно могло бы остановиться, и оно не останавливается. Оно тянется и находит всё новые способы. Оно импровизирует, оно изучает. Оно не сознает, что делает…

        Джеймс Кори «Пожар Сиболы»

Вообще говоря, «сильный» игровой AI не является моим приоритетом. Глупо соревноваться со специализированными игровыми движками, занимаясь универсальным и имея лишь однопоточный JavaScript, встроенный в браузер, в качестве вычислительного ресурса. Кроме того, есть целый ряд игр, в которых потребности в сложном AI просто не возникает. Вот здесь, например, весь AI сводится к поиску кратчайшего пути, а в этой игре с задачей прекрасно справляется рандом. Увы, такие игры скорее исключение чем правило. Гораздо чаще, приходится изрядно потрудиться, чтобы программа делала ходы, которые не казались бы попросту идиотскими.

На дворе 2017 год, а это значит, что я уже как полтора года занимаюсь мазохизмом. Два года назад я был весел и жизнелюбив, сейчас не хочется ни шутить ни развлекаться. За два года redux сделал меня фаталистом. Моя уверенность в ужасном будущем так называемого “frontend” увеличивается с каждым днём. В конце концов, сбербанк сделал redux основой своего стека, а эти ребята хорошего не выберут. Шутка! Я уверен, там работают замечательные специалисты.

Здравствуйте, дорогие хабравчане! В этом посте я хочу рассказать о том, как и в какую цену я заказывал сайт у фрилансеров, в какие сроки я получил результат и что из этого сделал сам. Задача была создать “лендинг-магазин”: одностраничный сайт для двух товаров, с возможностью сразу же сделать заказ через полнофункциональную корзину.

Этот пост содержит совсем немного технических подробностей и рассказывает больше о рабочем процессе и взаимодействии с людьми.

И в чем же проблема?

Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.

Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.

Ну, я и решил — если такого решения нет, напишу-ка я его сам.

Постановка задачи

Убирая всю лирику из первого абзаца, получаю задачу — нам нужно создать инструмент, который будет:

1. Делать асинхронный GET-запрос к REST API.
2. Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
3. Складывать полученные данные в store и следить за актуальностью хранящихся данных.

По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.

Речь в данной статье пойдет о довольно необычном сочетании технологий: Vue.js + TypeScript + Webpack, в разрезе single-file компонентов. Решение данной задачи отняло у меня приличное количество времени с первого захода, поскольку исчерпывающее объяснение того, как использовать все это вместе, да и еще с рядом ограничений (NPM предоставляет нам runtime-only build Vue.js), найти в цельном виде практически невозможно. Если вас заинтересовала данная тема, то приглашаю к дальнейшему чтению.

В предыдущей статье Нативные ECMAScript модули — первый обзор я рассказал историю JavaScript модулей и текущее состояние дел реализации нативных EcmaScript модулей.

Сейчас доступны две реализации, которые мы попробуем сравнить с бандлерами модулей.

Большинство Node-объектов — вроде HTTP-запросов, ответов и потоков (streams) — реализуют модуль EventEmitter, благодаря которому они могут генерировать и прослушивать события.

const EventEmitter = require('events')

Простейшая форма управления по событиям — это callback-стиль некоторых популярных Node.js-функций, к примеру fs.readFile. По этой аналогии событие генерируется однократно (когда Node готов к вызову коллбэка), а коллбэк действует как обработчик события. Давайте сначала разберём эту базовую форму событийно-управляемой архитектуры.

Все началось с Kotlin. Случайно попалась статья про новый язык, что на нем можно писать под Android. Соприкоснувшись с темой, узнал что изначально приложения под Android пишутся на JAVA. Решил узнать на сколько трудоемко писать приложения под Android, в чем преимущества платформы на практике. Ведь по сути приложения JS и приложения Android выполняют одну и туже функцию. Заодно решил провести эксперимент. Что можно сделать за 12 часов, не зная что такое JAVA и тонкости разработки под Android, используя как помощник только Google. Пришла идея, которую развил в постановку задачи.

В апреле в Минске прошла большая IT-конференция United Dev Conf, организованная Frontend Dev Conf, Highload Dev Conf и Mobicode.

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

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

Конференция проходила в четыре потока: Frontend, Highload, Mobile и Sales. Её посетили около 700 участников, и 40 докладчиков делились своим опытом. А в перерывах компании-спонсоры разыгрывали квадрокоптеры, куда ж без них на IT-ивенте.

Нам, как фронтенд-разработчикам, в первую очередь был интересен Frontend-поток, собственно его мы и посетили в эти два дня. Все доклады были интересными, но мы выбрали самые интересные, на наш взгляд.

Если вы используете библиотеку React, то наверняка используете и jsx. Конечно, это не обязательно, и можно писать только js, используя React.createElement, но с jsx получится гораздо лаконичнее, что повышает читаемость. И всё замечательно до появления первой необходимости вывести данные в цикле. В jsx циклы не предусмотрены. Зато предусмотрена вставка js-кода. И тут вновь возникает вопрос читаемости, но теперь она значительно ухудшается. Возникает ситуация, когда в js-коде пишется html, в котором пишется js-код с html. Конечно, можно выделить html в отдельную функцию. Но тогда html будет появляться в коде то тут, то там. А хотелось бы локализовать всё в одном месте. К счастью, в современном javascript почти для любой проблемы, есть решение в виде библиотеки или плагина. Выше обозначенную проблему легко решает плагин для babel transform-react-statements.

Представьте: вы работник стартапа, сварганили по-быстрому прототип и постепенно начинаете его развивать. И вот вам уже хочется, чтобы во время очередного спешного релиза не приходилось перепроверять все разделы сайта вручную (руками директора по продукту). Конечно, можно нанять отдельного тестировщика, но на это в вашем LEAN-стартапе бюджета не дают — «лучше давайте купим наконец-то кофе-машину». Знакомо?

И тут кто-то произносит слово «автотесты».

И сразу начинается: это целая история, это очень сложно, это очень дорого, от этого будет больше вреда, чем пользы и вообще это кровавый Enterprise и СЕЛЕНИУМ.

В нашей предыдущей статье про голосовых ботов для Рокетбанка хабраюзеры возмутились, что в 2017 году примеры JavaScript для облака Voximplant написаны на ES5. У нас в облаке сильно модифицированный SpiderMonkey, специально обученный не течь и не падать. Тысячи одновременных звонков с параллельно выполняемым JavaScript как бы намекают, что нода – для нас не вариант. Тем не менее, никто не мешает использовать транспайлеры, компилировать ES2017/TypeScript/Elm/Whatever в старый добрый JavaScript и загружать результаты компиляции с помощью Continuous Integration. При таком раскладе возникает соблазн использовать все последние достижения из npmjs, собирая весь код в один ES5 бандл. И вот тут нас ждет засада: даже один метод из lodash дает на выходе бандл размером в полмегабайта. И не похоже, чтобы рекламируемый последние пару лет tree shaking работал.

Задумывались ли вы когда-нибудь, как создаются экземпляры используемых вами типов angularJS? Контроллеры, фабрики, сервисы, декораторы, значения- буквально каждый из них в конце концов передаётся на исполнение в функцию instantiate объекта $injector, где их поджидает довольно занимательная конструкция, о которой сегодня и хотелось бы поговорить.

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

8 июня на Мансарде Rambler&Co состоится первый внешний RamblerFront& meetup, на котором наши сотрудники поделятся прикладными знаниями в области frontend-разработки.

Привет Хабр! Предлагаю вам статьи Rethinking JavaScript: Replace break by going functional.

В моей предыдущей статье Rethinking JavaScript: Death of the For Loop (есть перевод: Переосмысление JavaScript: Смерть for) я пытался убедить вас отказаться от for в пользу функционального подхода. И вы задали хороший вопрос "Что на счет break?".

break это GOTO циклов и его следует избегать

Нам следует отказаться от break также, как мы когда-то отказались от GOTO.

Вы можете думать, "Да ладно, Джо, ты преувеличиваешь. Как это break это GOTO?"

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

Несколько месяцев назад один из наших конкурентов начал делать странное – предлагать нашим клиентам сравнение своей системы рекомендаций с Retail Rocket через АБ-тесты в формате «пари» с обязательством заплатить 100 000 рублей в случае проигрыша.

Подобные истории для нас не редкость — за время существования компании нашу систему сравнивали практически со всеми существующими рекомендательными системами в России и за рубежом, и мы всегда показывали отличные результаты (ни в одном тесте мы не проиграли по эффективности).

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

Мы продолжаем делиться открытыми трансляциями для желающих принять субботний поток силы! Ранее мы уже открывали трансляции с конференций DotNext 2017 Piter, Mobius 2017 Piter и JPoint 2017 (сейчас доступ к ней закрыт). В этот раз источник силы будет подпитывать JavaScript-разработчиков.

3 июня 2017 в 10 утра (по московскому времени) начнется бесплатная онлайн-трансляция из главного зала HolyJS 2017 Piter!



Первый трек (проходит в главном зале) – самый большой и популярный среди наших участников. Во второй день конференции в первом треке выступят:

• Алексей Золотых — ES2017 vs Typescript vs Dart. Сравниваем без эмоций
• Douglas Crockford — Goto There and Back Again
• Anjana Vakil — Functional Programming in JS: What? Why? How?
• Алексей Иванов — Внутреннее устройство бандла webpack
• Владимир Гриненко — Зависимости в компонентном вебе, сделанные правильно
• Lea Verou — JS UX: Writing code for humans

Помимо этого, с 10 утра и в перерывах между докладами вы сможете посмотреть live-интервью со спикерами и участниками конференции. Не переключайтесь!

Ссылка на трансляцию и подробную программу – под катом.