Прототипно-ориентированный язык программирования
До HolyJS осталось меньше месяца — пора поведать Хабру, какие именно доклады там будут. Под катом их описания, а тут отметим пару вещей:
— В этот раз шире обычного раскрыта тема производительности. Когда React.memo не ускорит, а замедлит? Почему Solid.JS такой быстрый? Что нужно знать JS-разработчику в современном многоядерном мире?
— Помимо докладов, в программе есть несколько воркшопов, так что будет не только теория со слайдами, но и практическая деятельность.
Описания мы разделили по тематическим блокам, но это деление не строгое, некоторые доклады можно причислить к разным блокам сразу.
Я уже публиковал свою точку зрения, что Progressive Web Applications - это, прежде всего, технология для мобильных устройств. Основная особенность классических web-приложений - это клиент-серверная архитектура, а основная особенность "прогрессивных" web-приложений - возможность работы в offline. Понятно, что это очень сильно разные подходы в архитектуре - "всегда на связи" и "всё своё с собой". Совместить два таких разных подхода в одном приложении "это очень дорого и ни к чему".
Отталкиваясь от этой своей точки зрения, я решил посмотреть текущую статистику по браузерами - какие на данный момент у PWA-приложения возможности стать популярным и на какие браузеры оно должно ориентироваться. Данные для публикации взяты с сайта gs.statcounter.com
Привет, друзья!
В этом небольшом туториале я хочу показать вам, как разработать простой, но довольно-таки полноценный сервер для тестирования API.
Основной функционал нашего приложения будет следующим:
GET, POST, PUT и DELETE запросов к любому существующему проекту, включая GET-запросы, содержащие параметры и строки запроса;sort, order, limit и offset;Наша админка будет выглядеть так:
Для быстрой стилизации приложения будет использоваться Bootstrap.
Разумеется, с приложением, которое мы с разработаем, сразу в продакшн не пойдешь, но при необходимости довести его до производственного уровня не составит труда.
При разработке приложения мы будет придерживаться 2 важных условий:
JSON;Обратите внимание: статья рассчитана, преимущественно, на начинающих разработчиков, хотя, смею надеяться, что и опытные найдут в ней что-нибудь интересное для себя.
Вы готовы? Тогда вперед.
Всем привет! Меня зовут Петр Солопов, я руководитель отдела фронтенд-разработки в SuperJob. Думаю, многие из вас видели популярную серию картинок в интернете про фронтенд и бэкенд: на бекенде всегда какой-то монстр, а на фронте — все мило, летают бабочки. На мой взгляд, это не соответствует действительности и все не так радужно и безоблачно: чего только стоят настройка Webpack, тона зависимостей, особенности фреймворков и многое другое. За подробностями под кат.
От переводчика: Я прототипирую интерфейсы на Ember.js. И всегда испытываю трудности, когда нужно переключиться на React и написать что-нибудь используя этот de facto выбор по-умолчанию в современной фронт-энд разработке. Каждый раз сталкиваешься с трудностями на ровном месте и вынужден думать о том, о чем привык не думать, писать велосипеды. Мне всегда хотелось это как-то выразить и на днях я нашел статью, где автор очень наглядно показывает разницу на кодовых примерах. Представляю вашему вниманию ее перевод.
Недавно я наткнулся на пост в блоге, в котором обсуждаются несколько паттернов для React-компонентов. В этом посте я хочу изучить, можно ли и как эти шаблоны компонентов применять к Ember, а также как Ember сравнивается с React при использовании этих шаблонов.
Хотя я никоим образом не являюсь экспертом по React, всегда интересно наблюдать, как другие js-сообщества решают сходные с нашими проблемы при реализации SPA-приложений. Я не могу авторитетно говорить о качестве реализаций обсуждаемых шаблонов компонентов, но, судя по тому, что я видел в открытом доступе и читал о паттернах компонентов в React, похоже, эти подходы достаточно активно используются разработчиками. А поскольку проблемы, с которыми мы сталкиваемся при разработке клиентских приложений, одинаковы для разных экосистем, идеи, лежащие в их основе, интересны разработчикам, независимо от их вероисповедания выбора фреймворка.
Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.
Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...
Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?
Развитие языка javascript переносит выполнение кодов на распределенную сеть пользователей и снимает нагрузку с сервера. Это разумный подход. Введение в js ключевых слов class, extends и static дало возможность легко моделировать классами и объектами предметную область проекта. Это замечательно. Следующий вопрос, который необходимо рассмотреть при возрастании сложности js-проекта - это пространство имен. Именно оно позволяет избежать конфликтов с ворохом разнородных js-скриптов. Как показывает практика с этим вопросом почему-то возникли большие сложности.
Даниил Шилов из DINS расскажет, как избежать уязвимостей в web-приложениях еще на этапе написания кода, а Никита Нягу из МойОфис поделится опытом использования Firebase — инструмента, помогающего содержать архитектуру всего проекта в одном месте и облегчающего работу с DevOps.
Регистрация по ссылке. Подробная программа и информация о спикерах — под катом.
Благодаря Paint API из состава Houdini можно не ждать выхода новых возможностей CSS. Шаг за шагом автор этого материала показывает, как написать новое свойство CSS для анимации с фрагментацией. Делимся материалом, пока у нас начинается курс по Frontend-разработке.
У Google появилась замечательная reCAPTCHA v3. Замечательна она тем, что освобождает пользователя от необходимости тыкать по картинкам в поисках светофоров и пожарных гидрантов, при этом вполне успешно анализирует его действия на сайте и оценивает их по шкале от 0 до 1. Чем выше балл, тем качественней наш бот выше вероятность, что пользователь реальный. Обычно выставляют порог равным 0.5.
А что делать, если хочется добра пользователям сайта, но есть у его владельца некая обеспокоенность, что не пропустит невидимая столь ценного реального пользователя, который может и ведет себя странно и подозрительно, но совсем не бот?
Ответ - последовательно использовать капчу обоих версий - не прошел невидимую проверку - появилась видимая капча!
Promise - специальный объект, который хранит своё состояние и используется для обработки результатов асинхронных операций.
Что будет в статье: основные задачи на Promsie, которые часто спрашивают на собеседованиях.
В допандемическом 2020 Брайан Браун отправился на неделю в Recurse Center и разработал Checkboxland. Эта библиотека JavaScript отображает текст и анимацию на сетке флажков.
К забавному маленькому проекту автор сделал несколько демонстраций, написал об этом, а в итоге положил проект на полку и не прикасался к нему около года. В конце концов, отчаянно захотелось развлечься с программированием, и автор снова взялся за Checkboxland. Хотелось сделать более качественную и сложную анимацию, поэтому всё началось с эффекта пульсации — и зацепило. Да, на КДПВ вы видите кадр из видео на чекбоксах.
Пока у нас начинается курс по Frontend-разработке, делимся сразу двумя материалами о чекбоксах.
Рассмотрим следующую задачу. Нам необходимо делать вызовы стороннего API, которые считаются дорогими, и, следовательно, их необходимо кешировать в Redis. Мы используем современный NodeJS (версии 14+), а значит и конструкции async / await.
Напишем сначала класс обертку над вызовом API, где сам вызов будем эмулировать 2-секундным таймаутом.
Это работа является логическим продолжением моего первого подробного текста для сообщества об актуальных подходах к верстке Как верстать веб-интерфейсы быстро, качественно и интересно. Но, если в первом трактате, внимание уделялось, прежде всего, стилю кода, его качеству и эффектным современным возможностям различных препроцессоров и фреймворков, что демонстрировалось на некоторых конкретных специфических задачах, теперь хочется сфокусироваться на архитектурных или даже организационных аспектах веб-производства. Если вы не читали мой первый текст, но собираетесь при этом прочесть этот — не поленитесь перейти по ссылке и пробежать глазами самые последние разделы каждой из двух частей первого пособия: «Готовые решения» и «Песочницы». Этот текст начинает прямо с этих мест и развивает именно эти идеи: и о пагубности применения раскрученных-популярных «на все готовых» UI-«дизайн-систем»-фреймворков для создания кастомизированных веб-морд любой сложности и, о, по сути, полезности использования хотя бы минимального документирования и явных соглашений при разработке веб-GUI на фронтенде. Но я не стану тратить время, доказывая, что «ни в коем случае нельзя использовать Vuetify или AntDesign» для создания крупных UI-систем с полностью кастомным оформлением. Вам не нужно прикручивать себе огромный геморрой непроницаемый слой плохо кастомизируемого готового GUI для того чтобы написать кнопку или поле ввода! Если вам нужен датапикер — найдите и допилите что-нибудь под себя. Это понимание может только прийти или так и не придти с годами тяжелого опыта, когда вы будете постоянно тратить непростительно много своего времени на то, чтобы написать очевидно отвратительный CSS — «кряки с !important`ами поверх стилей библиотеки», выдумывать чудные костыли на javascript чтобы изменить дефолтное поведение виджетов на кастомное и хитрое-нестандартное затребованное вашими дизайнерами... И при этом ваши шаблоны, стили и js-обвязки будут превращаться во все менее читаемые запутанные нагромождения разнообразно оформленного кода, с различным подходом к наименованию и прочими бедами… Этот текст и написанный для него проект призваны наглядно показать «а как надо?».
В некоторых современных объектно-ориентированных языках есть понятие идексаторов – свойств, позволяющих работать с экземпляром класса как с массивом, используя [] нотацию. В этой статье я хочу продемонстрировать как это сделать на современном JavaScript.
При разработке бизнес-логики приложений нужно продумать действия с множествами – с пересечением, разницей массивов или двойной разницей. Недостатки в этом алгоритме могут привести к рискам. Например, если вам нужно в реальном времени обработать объем данных, превышающий определенную границу, система может «тормозить» – до минуты и даже больше. Такие ситуации требуют лишнего расхода ресурсов, отталкивают пользователей и вызывают другие проблемы.
Рассмотрим один из способов, которым мы пользуемся в работе для устранения подобных негативных эффектов. Статья будет полезна как разработчикам с опытом, которые ищут новые способы оптимизации своих продуктов, так и новичкам, которые только погружаются в тему оптимизации.
Прочитал я хорошую статью "Обновление вашего PWA в продакшене" и задался вопросом - а как часто при обновлении PWA нужно обновлять непосредственно сам service worker? Ведь что такое service worker по сути? "Прокладка" (прокси) между приложением, работающим в браузере, и внешними серверами, с которых это приложение тянет нужные ему ресурсы. По большому счёту, функционал service worker'а сводится к некоторому набору стратегий и пониманию того, к какому ресурсу какую стратегию применять и когда (я сейчас не рассматриваю push notifications и background sync, но изложенное в какой-то степени применимо и к ним).
То есть, код service worker'а более стабилен по сравнению с кодом приложения и во многих случаях для его "обновления" достаточно программно обнулить кэш-хранилище браузера и обновить "понимание того, к какому ресурсу какую стратегию применять" - обновить конфигурацию service worker'а. А для этого нужно приложению нужно иметь возможность каким-то образом управлять состоянием service worker'а и передавать ему данные, что осложняется тем, что приложение и service worker работают в различных потоках.
Под катом пример того, каким образом можно настроить управление service worker'ом из основного приложения при помощи Channel Messaging API.