JavaScript *

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

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

Awesome-react

Традиционная «awesome» коллекция полезных ресурсов для завоевавшего сердца миллионов фреймворка React.js.

CSS Reference

Вероятно самый подробный справочник по CSS от авторов Codrops с их удивительными HTML/CSS/SVG реализациями. Помимо того, что данный перечень CSS описывает все самые новые свойства, псевдо-классы, функции, типы, правила, он также содержит информация по последним концептам от W3C.

Как мы избавились от JavaScript-библиотек социальных сетей, ускорили скорость загрузки страниц и использовали RESTful API для “шаринга” и “лайков”.

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

Писать тесты скорости JS не так легко, как кажется. Даже не касаясь вопросов кроссбраузерной совместимости, можно попасть во множество ловушек.

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

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

Начитавшись статей про [все что угодно] на JavaScript в 30 строк кода, я подумал: чем я хуже? Не найдя в перечне своих недостатков пункт «написание плохого кода», решил сделать что-нибудь интересное.

Лабиринты всегда веяли в мою сторону некоторой магией и загадками, поэтому поиск «чего-нибудь интересного» закончился достаточно быстро. К сожалению, создание игры затянулось на долгие часы экспериментов над консолью и моими нервами.

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

Для сторонников принципа «меньше знаешь — крепче спишь» предлагается cсылка на JSFiddle (управление стрелочками).

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

Наш прошлый перевод нетрадиционного обзора React многим понравился, и, конечно, люди стали сравнивать Реакт с популярным AngularJS. Сегодня мы публикуем перевод статьи «An Unconventional Review of AngularJS» от того же автора (Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript). Поклонникам Angular просьба сохранять спокойствие.



AngularJS это все, что я ожидаю от фреймворка. И это не хорошо.

В ноябре, декабре и январе я обозревал AngularJS для серии «front-end frameworks» в рамках проекта Let’s Code JavaScript. Суммарно я провел 40 часов изучая, программируя и решая задачи. Как обычно, моей целью было изучить AngularJS создавая приложение.

Angular это, наверное, самый популярный фронт-энд фреймворк сейчас. Его разрабатывает команда из Google, что сразу внушает доверие. Он настолько популярен, что входит в акроним. Angular это часть так называемого стека «MEAN»: MongoDB, Express, AngularJS, Node.JS. Самая что ни на есть передовая технология.

Angular описывает себя как инструмент для улучшения ХТМЛ. Он позволяет расширить ХТМЛ новыми определениями — директивами — которые превращают статичный ХТМЛ-документ в динамический шаблон. Директивы могут быть атрибутами или тегами (или даже комментариями или классами, но это уже не совсем обычная история), и они превращают статичный ХТМЛ-документ во что-то живое и дышащее, на первый взгляд без добавления JavaScript.

Спешу предположить, что вы наслышаны о ES6 и, возможно, успели попробовать её. Тогда вам наверняка покажется интересной заметка о некоторых фичах спецификации, опубликованная Блейком Уильямсом в блоге Thoughtbots. Я же, с позволения автора, публикую перевод.

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

ES6 сегодня

Вы можете начать писать на ES6 прямо сейчас, используя транслятор в ES5 6to5. 6to5 поддерживает достаточно много инструментов сборки, в их числе: Broccoli, Grunt, Gulp и Sprockets. У меня всё прекрасно работало со sprockets-es6, а 4.x Sprockets будут поддерживать 6to5 из коробки. Также вы можете попробовать ES6 прямо в браузере в 6to5 REPL.

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

Все начиналось холодным февральским вечером. Клиент написал о странной проблеме при ускорении сайта: слайд-шоу множилось и блокировало поведение сайта, страницы были недоступны. Через два дня после выяснения всех подробностей я узнал, почему Mootools и jQuery категорически нельзя использовать совместно. И подтвердился в мысли, что и «алкоголь — зло», и «eval — зло».

Но обо всем по порядку.

Сначала пару слов о себе

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

Всё время делал какие-то программы, облегчающие жизнь мне и моим коллегам. В первую очередь на C++Builder (замечу, что пользовался лицензионной версией). Некоторые из программ, типа программного комплекса по анализу качества работы базовой подсистемы 2G и 3G, используется до сих пор (PHP+JS, «фишка» там больше не в программировании, а в использовании множества алгоритмов для поиска проблемных элементов), хотя на момент написания этой статьи я уже 2 года как не работаю в сотовой связи.

Когда появился node.js, многие web-разработчики стали задумываться о возможности использовать один и тот же код как на клиенте, так и на сервере. Сейчас существует несколько фреймворков, ставящих подход «пишем код один раз, используем везде» во главу угла, время от времени появляются новые. Вот и я не смог пройти мимо, пишу подобный микро-фреймворк — bnsf. Он предназначен для тех, кто предпочитает создавать front-end своих приложений по БЭМ-методологии, пользуясь соответствующим набором технологий и инструментов.

Давайте попробуем начать писать front-end для простого одностраничного web-приложения, используя bnsf. Чтобы не отвлекаться на создание back-end части, будем использовать в качестве back-end'a API vk.com. Наше приложение будет состоять всего из двух страниц, главной — с формой поиска пользователей по идентификатору — и вторичной, на ней будем выводить информацию о выбранном пользователе.

Идея игры

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

Смысл игры – составлять слова из соприкосающихся гексагонов. В игре 3 режима:

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

Обычно, если вам требуется сделать блок с ползунком или даже что покруче — с выбором диапазона, то используем готовый плагин из набора jQuery UI — slider().



На ПК всё отлично работает, мы даже не заморачиваемся, меняем стили и радуемся функционалом.
Затык приходит в том моменте, когда проект — это мобильная версия чего-либо на html и обязательно вместо поля для ввода значений нужно использовать ползунок — ну потому что удобней или же по другим каким-то причинам.

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

Мы в Хекслете любим свой стек технологий :) Когда рассказываем другим — многие завидуют: Rails, Docker, AWS, React JS. Реакт мы используем в первую очередь для создания веб-среды для разработки Hexlet-IDE, которая позволяет нашим пользователям выполнять упражнение по разработке приложений и взаимодействию с виртуальной машиной прямо в браузере.

Сегодня мы публикуем перевод статьи «An Unconventional Review of React» Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript.



Он мне понравился. Я не ожидал такого.

Для специальных выпусков Let’s Code JavaScript в августе и сентябре я изучал Реакт.

На случай если вам не знаком Реакт: это библиотека для фронт-энд веб-разработки. С помощью него создаются компоненты: короткие, не-совсем-ХТМЛ теги, которые можно комбинировать для создания интерфейса.

Реакт знаменит своими нетрадиционными решениями: реализацией виртуального DOM’а, созданием элементов интерфейса в JavaScript вместо шаблонов, создание суперсета языка JavaScript — JSX, который позволяет вставлять не-совсем-ХТМЛ прямо в код JS.

С этими решениями разработка уходит от схемы манипуляции DOM’ом — добавить этот элемент, скрыть эффектом другой элемент, обновить это текстовое поле. Вместо этого вы описываете как сейчас должен выглядеть DOM. Реакт берет на себя сложную работу по определению необходимых действий чтобы DOM на самом деле стал выглядеть так, как вы сказали.

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

^{В статье используется библиотека Backbone.View.Elements}

Проблема первая: маловыразительные селекторы

Все мы видели лапшу, все мы знаем: лапша в JSе — наверно и в верстке не все хорошо. А раз все так, то код, скорее всего, кишит непонятными манипуляциями с домом. Читать такой код сложно, ведь надо, не упуская мысли автора о том, что здесь вообще происходит, держать в уме кучку невнятных названий для элементов. Итак, давайте придадим коду немножко выразительности:

_selectors: function () {
    return {
        elemName: '.block__elem-name'
    };
}

Сложим все селекторы в одном месте и дадим понятное название элементам, для выбора которых они нужны. Выбирать мы их, кстати, будем вот так:

this._elem('elemName');

вместо

this.$('.block__elem-name');

JavaScript может быть кошмаром при отладке: некоторые ошибки, которые он выдает, могут быть очень трудны для понимания с первого взгляда, и выдаваемые номера строк также не всегда полезны. Разве не было бы полезно иметь список, глядя на который, можно понять смысл ошибок и как исправить их? Вот он!

Ниже представлен список странных ошибок в JavaScript. Разные браузеры могут выдавать разные сообщения об одинаковых ошибках, поэтому приведено несколько примеров там, где возможно.

Пишущую машинку я расчехляю нечасто, но сегодня есть повод.

Тесты для JavaScript пишут многие, некоторые пишут много тестов. Есть несколько популярных тестовых фреймворков, таких как Jasmine, Mocha, QUnit, а также инструменты для автоматического запуска тестов. Некоторые из них даже интегрированы в некоторые редакторы кода. Например, Karma runner и Mocha прекрасно интегрированы моими коллегами в WebStorm. Словом, существуют разные способы запускать тесты автоматически и получать результаты в течении одной или нескольких секунд. Впрочем, время зависит от количества и характера тестов.

Как мы используем наши JavaScript тесты

«Свершилось! Node.js получило развитие в виде форка io.js! Привет ES6! Привет новый V8!» радовались разработчики. Полез смотреть с надеждой, что вот сейчас, начав с нуля, ребята исправили фундаментальные косяки!

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

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