JavaScript *

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

В этом посте я хотел бы рассказать и показать процесс создания небольшого API с помощью Deno. Deno — новейшая среда для запуска Javascript и Typescript, разработанная создателем Node.js — Райаном Далем.

… и опоздал на 3 года. В идеале должно быть так: пользователь запускает браузер, и браузер показывает то, что нужно пользователю. Но пока такого не реализовали приходится пользоваться поисковыми системами. В идеале должно быть так: пользователь открывает поисковую систему, вводит поисковый запрос, и она показывает то, что нужно пользователю. Но пока кнопка «I feel lucky» не так хорошо работает (хотя в последнее время ощутимо движение в этом направлении), приходится иногда переходить по нескольким адресам со страницы поисковой выдачи.

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

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

Мне всегда нужна была кнопка «Нашел», которая бы подчищала за мной последствия поиска (назовём её «I was lucky»). После того, как окунулся в мир расширений для браузеров, я подумал, что это то, что может помочь в данном случае. Так смутно начало появляться желание написать расширение, которое бы решало мои задачи.

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

Кеширование и серверный пререндеринг (SSR)

Приложение на Next.js (React) имеет из коробки серверный пререндеринг страниц. Это очень хорошо для SEO, и для FMP метрики — время от открытия страницы до первого значимого контента.



Казалось бы, фреймворк умеет в SSR из коробки, зачем вообще писать статью? Есть один нюанс, мы рендерим страницу дважды: сначала на сервере, потом на клиенте, и общее время загрузки неизбежно увеличивается.

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

Доброго времени суток, друзья!

Хочу поделиться опытом работы с аудио. Под «аудио» я подразумеваю HTMLAudioElement и Web Audio API.

Что будем делать?

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

Условия:

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

В сети полно материалов как по HTMLAudioElement, так и по WAAPI, поэтому я сделаю акцент на практической составляющей. Кроме аудио, мы будем работать с drag-drop и canvas.

Без дальнейших предисловий…

Доброго времени суток, друзья!

Надеюсь, эта статья будет полезна как начинающим разработчикам, так и опытным.

В вопросах, которые показались мне сложнее прочих, приведены ссылки на дополнительную литературу.

Буду признателен за развернутые комментарии. Все замечания будут учтены при редактировании статьи.

Итак, поехали.

Я — начинающий front-end разработчик. Сейчас я учусь и стажируюсь в одной минской IT компании. Изучение основ web-ui проходит на примере JS библиотеки Webix и я хочу поделиться своим скромным опытом и сохранить его в виде небольшого учебного пособия по этой интересной UI библиотеке.

ЧЕТВЕРТАЯ ЗАДАЧА

В работе с данными важно иметь возможность выполнить несколько типов операций. В web разработке за это отвечает CRUD — четыре базовые функции. У библиотеки Webix есть все средства для реализации CRUD. Основой для решения новых задач мне послужит материал из предыдущих публикаций: создание интерфейса приложения, модулей проекта и работа с формами.

Привет, Хабр!

За последнее время я заметил целый ряд статей с разного рода критикой веб-компонентов. Порой, эта критика весьма жесткая и даже попахивает хейтерством. На мой взгляд, основной проблемой тут является отсутствие наработанной практики работы с этой группой стандартов у сообщества разработчиков. Многие привычные модели не всегда органично вписываются в проекты с участием Custom Elements и Shadow DOM, на многие вещи приходится смотреть под новым углом и не всем это нравится. Я вполне успешно работаю с веб-компонентами уже несколько лет и даже разрабатываю собственную библиотеку на их основе, поэтому считаю такую ситуацию не очень справедливой. Постараюсь, хотя бы частично, это исправить, по мере моих скромных сил. Я решил сделать серию компактных публикаций, в каждой из которых я планирую затронуть один из частых аспектов критики, а так-же продемонстрировать ряд технических приемов, которые могут оказаться интересными тем, кто еще не определился с тем, на какой стороне баррикад ему быть. Сегодня я хотел бы рассказать о том, как создавать компоненты без Shadow DOM.

Я десять лет тестирую и пишу код, а последние четыре года — тестирую доклады в программном комитете конференции Heisenbug. Сегодня расскажу о сквозных тестах, кросс-браузерности и ощущениях от использования Playwright версии 0.10.0.

Из конца в конец

Зачем нужны сквозные (end-to-end) тесты? Они управляют браузером и имитируют действия пользователя. Например, я описал пользовательские сценарии и хочу, чтобы они были проверены с каждой версией продукта. Проверять все сценарии для всех версий вручную — дороже и дольше, чем автоматикой.

Есть разные инструменты: Selenium, Puppeteer, Protractor, Cypress и другие. Две недели назад вышел новый инструмент — Playwright, над которым работал Андрей Лушников, разработчик Puppeteer. Эта библиотека полностью решает проблему написания кросс-браузерных тестов.

Если вы регулярно пишете приложения на Angular и потратили на это не одну сотню часов, вы, скорее всего, знаете об этих функциях. Но, всё же, чтобы убедиться — прочтите :)

Прежде чем мы перейдем к функциям Angular, стоит упомянуть один очень полезный инструмент. Bit (Github) позволяет с легкостью работать над Angular-компонентами вместе и делиться ими. От души рекомендую его для поддержания консистентного интерфейса, ускорения разработки и минимизации количества ошибок в коде.


Пример: Круговые загрузчики для Angular с bit.dev

Доброго времени суток, друзья!

«Отзывчивый» является одним из стандартов веб-разработки. Существует большое количество разрешений экрана, и это количество все время увеличивается. Мы стремимся поддерживать все возможные размеры экранов с сохранением дружелюбного пользовательского интерфейса. Отличным решением данной задачи являются медиа-запросы (media-queries). Но что насчет веб-компонентов? Современная веб-разработка основана на компонентах, и нам нужен способ делать их отзывчивыми. Сегодня я хочу рассказать о ResizeObserver API, позволяющим следить (наблюдать) за изменениями размеров конкретного элемента, а не всей области просмотра (viewport), как в случае с медиа-запросами.

Заключительная часть статей, посвященных тому, как можно использовать принципы чистого кода в TypeScript(ps. Все эти принципы относятся не только к языку TypeScript).

Добрый день, товарищи разработчики!

Введение нового разработчика в проект практически всегда начинается с разбора codestyle'a данного проекта. Так как иногда возникает потребность в обучении разработчиков стилю написания кода, не всегда Junior-разработчики могут сразу разобрать англоязычные примеры. В результате, это привело… к переводу одного из них, о чем я и хочу рассказать в этой статье.

Фронтенд, возможное, лучшее и самое приветливое направление, чтобы войти в ИТ. Но с ним не все так просто — во фронтенде легко начать и трудно стать мастером. В нем не будет мук выбора языка программирования, но будет борьба с его недостатками. В этой сфере есть очень много инструментов, изучение каждого из которых тянет на освоение отдельной профессии.

О том, как правильно учиться, как не набить шишек и двигаться по карьере, мы расспросили у Олега Шикова, декана факультета веб-разработки в GeekBrains и у Дарьи Дьячковой, начинающей веб-разработчицы.

Всем привет.

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

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

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

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

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



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

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