Рубрика «Веб-разработка» - 117

Доброго времени суток уважаемые читатели. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Awesome Awesomeness

В прошедшие несколько недель мне регулярно попадались Awesome-* проекты, о которых я упоминал в последних подборках. Началось все с Awesome-PHP, потом появились «живые списки» полезностей для сисадминов и питонистов. Все заметили положительную тенденцию и как по желанаю это переросло в целый тренд. Сейчас есть коллекции инструментов для языков Ruby, Go, NodeJS, JavaScript, Java, Scala, Bash и др. Уже даже существуют подобные наборы для целых направлениям в ИТ, к примеру Big Data. Awesome Awesomeness — это живой список живых списков всего самого необходимого для разработчика из той или иной сферы.

Breach — полноценный браузер на JavaScript

Несколько интересностей и полезностей для веб разработчика #22

Читать полностью »

Перевод статьи «Pub/Sub JavaScript Object», David Walsh

Есть три техники написания AJAX веб-сайтов: делегация событий, управление историей и коммуникация pub/sub на уровне приложения. Я использую все три техники и я хотел бы поделиться с вами самой простой из них: крошечным pub/sub модулем, который я использую на своем веб-сайте.

Если вы не знаете, что такое pub/sub, то суть в том, что вы публикуете в некую тему(topic), и кто угодно может на нее подписываться. Это похоже на то, как работает радио: радиостанция вещает (публикует) и каждый может слушать (подписываться). Это превосходный подход для модульных веб-приложений; это способ глобальной коммуникации без привязки к какому-то конкретному объекту.
Читать полностью »

Материалы MoscowJS 12Двенадцатый митап MoscowJS прошёл 26 июня в офисе компании mailru. На встрече выступили ребята из Яндекса, Mail.ru и Tai.st. Говорили об облаках, оптимизациях мобильного веба и, конечно, расчёсках! Мы собрали видео и другие материалы события в одном посте.

Вот как это было…
Читать полностью »

Какие платформы для веб проектов чаще требуют заказчики
Не утихают войны о том какая CMS лучше, какой framework выбрать и прочие войны между технологиями и платформами разработки. Однако думаю все поставит на свои места рынок. Отталкиваясь от этой мысли было решено провести маленькое исследование, которое может отчасти выразить существующее положение вещей в сфере веб разработки.
Читать полностью »

Введение

В прошлом году произошло революционное событие в разработке веб-приложений: компания Facebook выпустила React — библиотеку для создания пользовательских интерфейсов в браузере, использующую радикально отличающийся подход к структурированию кода и написанию графических компонентов. Вместо того, чтобы, имея размётку, «цепляться» к ней из JavaScript, т.е. работать напрямую с DOM, вводится понятие компонента — самодостаточной единицы, которая представляет собой легковесное описание DOM. Когда «реакт» определяет, что необходимо перерисовать что-либо на странице, он рассматривает дельту изменений этого виртуального DOM и перерисовывает только изменённые части. Благодаря тому, что при таком подходе обращение к DOM происходит гораздо реже, возрастает отзывчивость интерфейса и скорость работы: работа JIT не прерывается тяжеловесными обращениями к нативному коду.

React предоставляет возможность сохранения состояния для каждого компонента, при изменении этого состояния он запускает «перерисовку». Таким образом, состояние вашего приложения может оказаться «размазанным» по дереву компонентов. Это не является недостатком React: наоборот, библиотека обеспечивает базовые необходимые блоки и не навязывает лишних правил, когда это возможно. Кто пробовал строить приложение по такой схеме, когда каждый компонент имеет своё изменяемое состояние, рано или поздно столкнулся с возрастающей неуправляемостью кода и сложностью понимания происходящего в приложении. В связи с этим начали появляться библиотеки-надстройки над React, наиболее известной из которых является Om на ClojureScript от David Nolen. Почитать подробнее про Om можно в его блоге.

Каждый React-компонент имеет возможность переопределить метод shouldComponentUpdate, чтобы помочь библиотеке узнать, необходима ли его перерисовка. По умолчанию React возвращает true, и это значит, что «перерисовке» подвергаются все компоненты. Под перерисовкой в данном контексте понимается вызов метода render каждого компонента для построения виртуального DOM, который впоследствии сравнивается с предыдущим значением, после чего перерисовываются в реальном DOM только затронутые части.

В Om был использован централизированный подход к управлению состоянием: оно хранится в ClojureScript атоме на самом верху иерархии компонентов. Дочерние же компоненты получают «указатели» на подразделы этого состояния, которое является иммутабельным значением. Это довольно очевидное решение с точки зрения функционального программирования. Таким образом это позволяет определить метод shouldComponentUpdate так, чтобы он сравнивал текущее состояние с предыдущим с помощью оператора ===, а также хранить всё состояние в одном месте, что значительно упрощает понимание работы приложения.

В компании, в которой я работаю, для проекта было принято решение создать концептуально похожую надстройку над React с нуля и на чистом JavaScript, т.к. использовать ClojureScript не было возможности и желания. Так было положено начало Morearty.js — «more» + «react» + «art» (от названия компании).Читать полностью »

Однажды автор этого поста работал над одним заказом по разработке простенько сайта и тогда появилась идея — придать всем страницам некой уникальности и запоминаемости — использовать уникальные фоновые текстуры или элементы дизайна (активно использовался parallax-scrolling). Так как в тот момент дедлайн был довольно близок, а идея — в зачаточном состоянии, было реализовано намного проще — простыми заготовками, но идея выброшена не была.

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

Псевдо случайное изображение (на примере страницы 404 й ошибки)

Читать полностью »

Перевод статьи «JavaScript Modules», из сайта jsmodules.io

В новой версии JavaScript появится модульная система, главным образом вдохновленная идеей модулей Node.js.
В этой статье я расскажу, как это будет работать.

Создание модуля

В качестве упражнения, мы построим простой asap модуль, который позволит назначать выполнение действий «как только так сразу» асинхронным образом. В Node.js, вы можете сделать это при помощи process.nextTick, есть и разные подходы, которые работают во многих браузерах. Мы создадим модуль, который будет работать в любом окружении.1Читать полностью »

Думаю очень многие знают о информерах для сайта от Яндекс.Погоды. Но не всегда нам нужно такое отображение данных, которое даёт нам сам Яндекс. В этом посте я расскажу, как сделать отображение погоды без официальных информеров. Кроме этого, погода будет показываться посетителю Вашего сайта в зависимости от его региона.
Читать полностью »

Немного предыстории, как родился этот проект.

Печальная история социалочки “Уберлов”
Во всем виноват kashey. Шесть лет назад от него на хабре было несколько статей о гуглокартах. А потом, так вообще, еще и сайт сделал e-sosedi. Смотрел я на это все безобразие, истекал слюной и решил — хочу тоже “что-то с картами” и, конечно, модное в то время, социальное!
Идеи не было, а вот желание было большое, и я начал потихоньку писать и придумывать по вечерам. Все идеи, которые были на поверхности были уже реализованы или появлялись в ближайшее время, точки вайфая, банкоматы, шино-автосервисы…
И делал я абстрактный сервис с картами метаясь от одной идеи к другой. Пока, мне отец не рассказал, как он съездил, в очередной раз на рыбалку. На словах объясниться не удалось, куда он и как попал и пошли смотреть на гуглокарте, как он ехал. Тут я и понял, куда мои абстрактные карты придут.Читать полностью »

О размере экрана, пикселя и элемента

Привет, username. Свой первый пост я хочу посвятить актуальной проблеме, связанной с появлением большого количества новых форматов дисплеев и непрекращающейся гонкой за плотностью пикселей. В свете появления таких устройств, как очки дополненной реальности, смартчасов, 4к-мониторов и еще более широкого спектра планшетов и ноутбуков, возникает вопрос: какой размер графического элемента/текста следует считать оптимальным и в чем его измерять. Android-разработчики, несомненно, тут же воскликнут: «Да, конечно, в dp!». Но практика показывает, что дела обстоят несколько сложнее.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js