JavaScript *

В конце мая прошла седьмая HolyJS — по нашему субъективному мнению, лучшая из всех. А теперь, когда уже собран и проанализирован весь фидбек, можно подвести итоги. Вот прошедшая конференция в числах:

• 900+ человек, 2 дня докладов, 3 потока
• 30 докладов, 2 воркшопа
• 36 спикеров
• 3 MC
• 10 lightning talks
• 3 BoF-сессии
• Конкурс «TCXX» при поддержке Daniel Ehrenberg (экс-председателя TC39)
• Премьера документального фильма про Ember.js
• Мероприятие-спутник Node.js Code+Learn (первое в своём роде в истории СНГ)

А под катом — обо всём этом подробнее.

Я пишу это в основном для себя в будущем, чтобы у меня было куда сослаться, когда кто-нибудь спросит меня, почему я скептичен в отношении веб-компонентов и почему Svelte не компилируется в веб-компоненты по умолчанию. (Тем не менее, он может компилироваться в веб-компоненты, а так же интегрироваться с ними, что подтверждается превосходной оценкой на Custom Elements Everywhere).

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

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



Здесь представлено 13 однострочников. Примеры подготовлены с использованием Node.js v11.x. Если вы будете использовать их в другой среде — это может повлиять на их выполнение.

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



ШРИ — как сервис: тоже требует разных форматов взаимодействия, автоматизации и экспериментов. Вот об этом и поговорим сегодня на Хабре. Будут и полезные ссылки для кандидатов.

Почти 60% посетителей сайта покидают его в том случае, если его загрузка занимает более 3 секунд. 80% таких посетителей на сайт уже не возвращается. Это говорит о том, что успех веб-проекта не в последнюю очередь зависит от его скорости. Автор материала, перевод которого мы сегодня публикуем, хочет рассказать о методиках повышения производительности React-приложений.

Результаты оптимизации приложения

Javascript — странный. Не верите? Ну попробуйте тогда преобразовать массив строк в целые числа с помощью map и parseInt. Запустите консоль (F12 на Chrome), вставьте код ниже и нажмите Enter

['1', '7', '11'].map(parseInt);

Вместо ожидаемого массива целых чисел [1, 7, 11] мы получаем [1, NaN, 3]. Но как так? Чтобы узнать в чём тут дело, сначала нам придётся поговорить о некоторых базовых концепциях Javascript. Если вам нужен TL;DR, пролистывайте статью до самого конца.

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

Друзья, в преддверии выходных хотим поделиться с вами еще одной интересной публикацией, которую хотим приурочить к запуску новой группы по курсу «Разработчик JavaScript».



Потратив последние несколько месяцев на разработку приложений на React и библиотек с использованием Typescript, я решил поделиться некоторыми вещами, которые узнал за это время. В этом руководстве я расскажу вам про шаблоны, которые я использую для Typescript и React в 80% случаев.

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

И если вы застряли на чем-то, помните, что вы всегда можете типизировать что- нибудь как any. Any – ваш новый друг. А теперь перейдем непосредственно к примерам.

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

В этой статье я расскажу вам, как я использовал фаззинг, чтобы найти несколько сбоев в Firefox. Обычно целью фаззинга является нахождение сбоя, указывающего на повреждение памяти, но моя цель заключается в другом: я хочу обнаружить неожиданную реакцию браузера. Это могут быть символы, которые открывают или закрывают необычный тег, или, возможно, символы, которые игнорируются парсером JavaScript. Такое неожиданная реакция часто может быть использована для проведения XSS-атак, минуя фильтры безопасности и избегая песочницы JavaScript.

Многие, когда речь заходит о jQuery, говорят так: «Просто пользуйтесь обычным JavaScript. Библиотека jQuery вам не нужна». Что тут сказать? Я не нуждаюсь во многих вещах, но, несмотря на это, хорошо, когда они есть. Так и jQuery. Я в этой библиотеке не нуждаюсь, но её, определённо, приятно иметь под рукой.

Сайты наподобие You might not need jQuery (YMNJQ) продвигают идею, в соответствии с которой от jQuery очень легко избавиться. Но самый первый пример на этом сайте демонстрирует вескую причину jQuery использовать. Там строка простого кода на jQuery заменяется на 10 строк обычного JS!

Около года назад вышла статья-манифест Никиты Прокопова о разочаровании в программном обеспечении. Судя по положительным откликам, разработчикам небезразлично качество производимых продуктов. Может быть пора начать действовать?

В этой заметке я хочу рассказать о своей разработке, которая, по моему мнению, может вылечить основные проблемы производительности современного веба и сделать пользователя немного счастливее. Проблемы такие: большой вес JS-кода, высокое время до начала работы со страницей (TTI), высокое потребление памяти и процессора.

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

Всё, что связано с JavaScript, очень быстро развивается. Это касается и того, что можно отнести к сфере веб-разработки. В наши дни те, в основе чьих проектов не лежат самые современные технологии, начинают особенно сильно ощущать разрыв между тем, чем они пользуются, и тем новым, что появляется едва ли не ежедневно. К таким технологиям можно отнести Webpack, React, Jest, Vue, Angular в их современном состоянии. В то время как «население» мира фронтенд-разработки, включающее в себя технических специалистов и программистов, постоянно растёт, этот мир стремится к стандартизации. Появление новых технологий и инструментов уже меняет ситуацию.



Можно с изрядной долей уверенности говорить о том, что общим трендом развития фронтенд-технологий будет стандартизация разработки пользовательских интерфейсов. В частности, речь идёт о композиции, основанной на компонентах, о стремлении к модульности систем. Эта тенденция воздействует практически на всё — от стилизации до тестирования и даже до управления состоянием приложений. В этот тренд можно включить технологии, построенные вокруг веб-компонентов, ES-модулей, сюда же попадают соответствующие инструменты и многое другое.

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

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



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

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

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

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

Я повесил у себя в подвале боксерскую грушу, приклеил на нее стоковое фото типичного менеджера и запихал внутрь динамик, чтобы он проигрывал фразы, которые меня злят. Например, груша говорит: «Бизнесу не нужен твой идеальный код. Ему нужно решить проблему так, чтобы прибыль покрыла затраты. Если для этого нужен говнокод, значит будет говнокод». И начинаю дубасить.

Недавно я добавил в грушу запись: «Типы — это сложно и ненужно». В этот момент я бью так сильно, что рука чуть не ломается. Потому что с меня хватит. Пару месяцев назад я пережил один из самых вопиющих кейсов в своей карьере.

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

Сегодня открылся новый набор в Школу разработки интерфейсов Яндекса в Москве. С 7 сентября по 25 октября пройдёт первый этап обучения. Студенты из других городов смогут в нём поучаствовать дистанционно или очно — компания оплатит дорогу и проживание в хостеле. Второй, он же финальный этап продлится до 3 декабря, его можно пройти только очно.

Меня зовут Юлия Середич, этот пост мы написали вместе с Сергеем Казаковым. Мы оба разработчики интерфейсов в минском офисе Яндекса и выпускники ШРИ прошлых лет.



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

Автор материала, перевод которого мы сегодня публикуем, говорит, что одна из проблем, с которыми приходится сталкиваться программистам, заключается в том, что у них их код работает, а у кого-то другого выдаёт ошибки. Эта проблема, возможно, одна из самых распространённых, возникает из-за того, что в системах создателя и пользователя программы установлены разные зависимости, которые использует программа. Для борьбы с этим явлением в менеджерах пакетов yarn и npm существуют так называемые lock-файлы. Они содержат сведения о точных версиях зависимостей. Механизм это полезный, но если некто занимается разработкой пакета, который планируется опубликовать в npm, lock-файлы ему лучше не использовать. Этот материал посвящён рассказу о том, почему это так.