Веб-разработка *

Автор: Александр Кашеверов, Senior JavaScript Developer

Добро пожаловать и приятного чтения!

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

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

Для лучшего понимания — необходимо знание JavaScript и общее представление о работе веб.

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

Моя статья, вероятно, не всеобъемлющая, поэтому пишите комментарии и личные сообщения, я готов выслушать критику и дополнить материал.

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


Почему к промисам приковано столько внимания? Полагаем, всё дело в том, что технология эта весьма востребована, и в том, что в ней достаточно сложно разобраться.

Поэтому, если вы хотите лучше понять промисы, мы предлагаем вашему вниманию перевод очередной статьи, посвящённой этой теме. Её автор говорит, что он последние 10 лет занимался разработкой на Java и PHP, но всё это время с интересом поглядывал на JavaScript. Недавно он решил всерьёз заняться JS и первой заинтересовавшей его темой стали промисы.



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

Как-то так получается, что клиентская разработка, с одной стороны, захватывает территории и становится все более востребованной, с другой, — все больше обосабливается. О распространении мы судим по нескольким последним фестивалям РИТ++, на которых и докладов по фронтенду было в 2-3 раза больше, чем по бэкенду или DevOps, и слушателям это было интереснее, и даже приехавшие видеоблогеры в основном оказались фонтендерами, но об этом позже. А в ответ на тенденции разделения и углубления специализаций мы организуем Frontend Conf Moscow. О том, что будет из себя представлять эта конференция, что от неё ждать, как поучаствовать, читайте далее.

О главном

Frontend Conf Moscow пройдет 4 и 5 октября в Москве в хорошо знакомом и удобном Инфопространстве. Это будет два дня, которые мы с вами целиком посвятим технологиям разработки клиентской части веб-проектов. Доклады в несколько потоков, мастер-классы, митапы, обсуждения с экспертами за чашкой кофе или, в вечернее время, стаканом кое-чего еще, сильнейшие разработчики среди участников — все это позволит погрузиться в тему полностью, и обсудить аспекты, которые до этого оказывались слишком узкими или специфичными.

Сегодня Mislav Marohnić объявил о том, что разработчики Github избавились от jQuery на фронтенде GitHub.com. Казалось бы, в самом этом факте нет ничего примечательного, если бы не один интересный момент.

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

• querySelectorAll (который предположительно был вдохновлен когда-то именно jQuery),
• fetch для работы с AJAX,
• delegated-events для обработки событий,
• полифиллы для работы с DOM,
• пользовательские элементы (Custom Elements), которые сейчас на подъеме.

Помимо Custom Elements, ничего другого из Web Components было решено не использовать. Разработчики присматривались к Shadow DOM и были бы не против прибегнуть к нему — однако, в силу того, что на полифиллах скорость поиска в DOM оставляет желать лучшего, им пришлось пока отложить эту затею.

Зачем разработчикам в принципе потребовалось все это сделать? По их словам, для того, чтобы «отдавать» посетителям меньше килобайт, иметь возможность использовать более явно выраженный синтаксис для выполнения манипуляций с DOM, а также ради возможности использовать библиотеку Flow.JS для статического анализа типов. По словам разработчиков, процесс ухода с jQuery занял годы.

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

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

Материал, перевод которого мы публикуем сегодня, посвящён рассказу о том, как в Airbnb оптимизируют серверные части веб-приложений с прицелом на всё более широкое использование технологий серверного рендеринга. В течение нескольких лет компания постепенно переводила весь свой фронтенд на единообразную архитектуру, в соответствии с которой веб-страницы представляют собой иерархические структуры React-компонентов, наполняемые данными из их API. В частности, в ходе этого процесса шёл планомерный отказ от Ruby on Rails. На самом деле, Airbnb планирует переход на новый сервис, основанный исключительно на Node.js, благодаря которому в браузеры пользователей будут попадать полностью готовые страницы, отрендеренные на сервере. Этот сервис будет формировать большую часть HTML-кода для всех продуктов Airbnb. Движок рендеринга, о котором идёт речь, отличается от большинства используемых компанией бэкенд-сервисов в силу того, что он не написан на Ruby или Java. Однако отличается он и от традиционных высоконагруженных Node.js-сервисов, вокруг которых построены ментальные модели и вспомогательные инструменты, используемые в Airbnb.

Привет, Хабр! Представляю вашему вниманию перевод статьи "10 Tips to Designing Perfect Forms".


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

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

С ростом популярности конструкции async/await растёт и интерес к её внутренним механизмам. Порывшись в интернете, несложно выяснить, что в основе async/await лежат широко известные промисы, и генераторы, которые пользуются куда меньшей известностью и популярностью.



Материал, перевод которого мы сегодня публикуем, посвящён генераторам. А именно, тут мы поговорим о том, как они работают, и о том, как они, совместно с промисами, используются в недрах конструкции async/await. Автор этой статьи говорит, что генераторы, ради их практического применения, осваивать необязательно. Кроме того, он отмечает, что он рассчитывает на то, что читатель немного разбирается в промисах.

Как-то выдалась у меня пара выходных, и я набросал GraphQL сервер к нашей Docsvision платформе. Ниже расскажу, как все прошло.

В выпуске: PHP 7.3 alpha 4, ReactPHP 1.0 LTS и другие релизы, свежее предложение «Namespace Visiblity for Class, Interface and Trait» из PHP Internals, ведеозаписи докладов и вебинаров, порция полезных инструментов, и многое другое.
Приятного чтения!

(Art by http://www.simonstalenhag.se/)

Предыстория / Дисклеймер

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

На данный момент я Front-end разработчик в Conductor/WeWork. Мы не занимаемся разработкой редакторов, как собственно и я, по вечерам не разрабатываю такие вещи. Это больше об опыте который я получил на прошлом проекте в компании УТИ(сокращенно), утипути, ути-…. Это было достаточно давно, но как оказывается, тема актуальна и по сей день, как и косяки связанные с ней.

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

UTIEditor special for you <3

Зачем нам нужны такие редакторы?

Тут достаточно много ответов на этот вопрос, многие из вас, я уверен догадываются и так.
Я отвечу на этот вопрос с точки зрения УТИ, компании которая предоставляет услуги по разработке сайтов.

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

Вот вы сделали очередной лендинг, сайт визитку и отдали клиенту, а он прибегает через день и просит поменять текст. Через еще день, поменять цвет фона и добавить всего одну картинку. Для клиента это выглядит, как нечто простое и быстрое. С этим трудно поспорить, оно так и есть. Но для вас это означает, что вам нужно выдернуть разработчика/дизайнера с его текущих задач. Не говоря уже о работе менеджера который тратит время на коммуникации. Соответственно, вы выставляете счет и он не маленький. Клиент негодует и жалуется. В следующий раз вы уже думаете наперед о таких вещах и начинаете задавать вопросы, закладывать в ТЗ функционал редактирования.

Тут пожалуй стоит перейти к обсуждению этого функционала, ведь он очень разный.
Хотелось бы добавить, что я не буду включать в этот разговор такие CMS как WrodPress, Drupal, мы сконцентрируемся на рынке редакторов.

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

TL;DR: Тропа SPA темна и полна ужасов. Ты можешь бесстрашно сражаться с ними… или выбрать другой путь, который приведёт тебя к нужному месту: современный Rails.



Я вспоминаю, как думал, что Rails фокусируется на неправильной цели, когда DHH анонсировали Turbolinks в 2012 году. Тогда я был убеждён в том, что мгновенное время ответа во время взаимодействия с пользователем — это ключ к превосходному UX. Из-за возникающих задержек сети, такая интерактивность возможна, только если вы минимизируете зависимость от сети и вместо сетевых обращений поддерживаете большую часть состояния на клиенте.

Я думал, что это необходимо для приложений, над которыми я работал. И с таким мнением я перепробовал множество подходов и фреймворков для реализации одного и того же шаблона: Single-page applications (SPA). Я верил, что SPA — это будущее. Несколько лет спустя, я не уверен в том, каково же будущее, но я точно хочу найти альтернативу.

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

Чтобы понимать, о какой проблеме мы говорим:


400kb скрипта base.js?

Остальное даже не смотрю.
После оптимизации даже без сжатия выигрышь будет в десяки раз и составит:

Это небольшая ответная статья на публикацию «Сравнение JS-фреймворков: React, Vue и Hyperapp». Вообще я не большой фанат подобных сравнений. Однако раз уж речь зашла о таком маргинальном фреймворке, как Hyperapp, в сравнении с мастодонтами, типа React и Vue, я подумал, почему бы не рассмотреть все те же примеры на Svelte. Так сказать, для полноты картины. Тем более, это займет буквально 5 минут. Поехали!

Автор материала, перевод которого мы сегодня публикуем, полагает, что Hyperapp — это заслуживающая внимания альтернатива таким веб-фреймворкам, как React или Vue. Он говорит, что причиной такого утверждения стало то, что он выяснил, что Hyperapp легче в освоении, чем эти два фреймворка. Его идея подверглась критике, так как кажется, что основана она исключительно на его мнении, а такой подход попросту не даёт другим фреймворкам возможности показать их сильные стороны. Эта статья направлена на объективный анализ Hyperapp, React и Vue, проведённый на основе простых примеров, демонстрирующих их возможности, и на основе результатов их испытаний.

Привет, Хабр! Меня зовут Андрей Гоменюк, я тимлид одной из команд серверной разработки Badoo.

На майском Badoo Techleads Meetup, посвящённом управлению разработкой, я поделился опытом интеграции новичков в команду. А сегодня делюсь текстовым дополненным и улучшенным вариантом своего доклада.

Представьте, что сегодня ваш первый рабочий день в Badoo. Каких же знаний и умений ждёт от вас отдел и в частности я, руководитель? Как минимум таких:

Причина, по которой Блокнот (он же Notepad) постигла участь гадкого утенка, уже давно мало кого интересовала. Пока не произошло неожиданное…

В это трудно поверить, но Блокнот — одно из самых известных, древних и одновременно самых простых приложений Microsoft — ждет весьма объемное обновление. Важно отметить, что эта программа (из комплекта базовой поставки большинства всех версий Windows) почти четверть века кочевала из одного выпуска операционной системы в другой практически без каких-либо изменений.

Сложно сказать, что случилось в Microsoft, сдохли ли волки в личном зоопарке одного из топ-менеджеров или кто-то случайно встал «с той ноги»… Но после недавнего внезапного внедрения поддержки юниксового перевода строки, в корпорации видимо решили не останавливаться на достигнутом…

Сегодня очень сложно оставаться монопрофильным специалистом. И часто, делая новый сайт или внося различные правки, можно позаботиться заранее об основных вещах, которые помогут сразу сделать всё чисто и красиво не только с точки зрения программирования, но и с точки зрения SEO.


Так о чём же надо помнить, чтобы делать работу качественно, и SEO-специалисты были довольны вашей работой?

5 июля прошёл восьмой митап UralJS. Сотня уральских разработчиков собралась послушать лёгкие летние доклады — меньше теории, больше демок и лайв-кодинга.

Выступали ребята из Яндекса и Контура. Вот о чём они рассказали: