JavaScript *

Я понимаю, возможно, есть ощущение, что статья опоздала года этак на 2, сейчас модно писать про es6, react, redux или другие модные в мире фронтенда штуки.

Однако, я думаю, у многих до сих пор есть проекты, которые используют jQuery + jQuery UI. И вот в одном из проектов, используя именно jQuery UI для сортировки элементов списка, мне потребовалась анимация сортировки, которой в jQuery UI «из коробки» нет. Гугление и поиск по stackoverflow привели только к странным решениям через стандартные jquery-ui колбэки, а так как мест, где сортировка использовалась было несколько, такие решения мне не подходили.

К тому же в проекте использовалась библиотека jQuery UI Touch Punch, которая позволяет элегантным образом заставить jQuery UI работать на touch-устройствах, я подумал, почему бы не сделать так же.

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

Идея данной статьи родилась после нескольких мучительных недель изучения WebGL. На личном примере выяснилось, что люди, не сталкивающиеся до этого с 3D-графикой, имеют в основном ошибочные представления о работе данной технологии. К тому же была проблема с поиском информации в интернете.

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

Этой статьёй хочется облегчить порог вхождения в чистый WebGL, дать начальное представление и подсказать, куда двигаться дальше.

* Это шутка.


(картинка позаимствована где-то в интернете)

[ Репозиторий ]

Всем привет.

Уже давно прошли времена обязательной поддержки 6, 7, 8 Ослов и неизбежного использования jQuery, DOM API постепенно приводится к единому виду, но я всё так же часто встречаю на просторах интернета утверждения о том, что VanillaJS — это длинная колбаса.

Мол, зачем мне писать вот так:

document.querySelector('.selector');

Если я могу написать вот так:

$('.selector');

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

// selects one node matched given selector
function $(selector, ctx) {
	return (ctx || document).querySelector(selector);
}

// selects all nodes matched given selector
function $$(selector, ctx) {
	return [].slice.call((ctx || document).querySelectorAll(selector));
}

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

Введение

Наверное, вам, как и мне, в течение последних лет, приходилось задумываться o, или осуществлять смену места работы. Скорее всего, как и мне, вам иногда приходилось иметь дело с, так называемыми, сервисами «измерения таланта». Будь то Codility или CEB, в целом суть которых сводится к одному и том уже — проверить ваши навыки в той или иной сфере деятельности. Но выполняют ли они эту задачу и насколько хорошо?.. Давайте рассмотрим несколько доводов и примеров.

Не так давно мне довелось выступать на конференции FFConf с докладом «Вам следует использовать <впишите нужную библиотеку/фреймворк>, это самое лучшее!». И основные мысли я решил изложить в публикации, в надежде, что это спровоцирует в профессиональной среде более широкую дискуссию о «стоимости» современных фреймворков на мобильных устройствах.

Для желающих обратиться к оригиналу моего выступления вот видео:



и слайды презентации: speakerdeck.com/paullewis/framework-here-its-the-bestestest.

Прошло уже некоторое время, как я впервые познакомился и подружился с TypeScript. В те времена версия еще не перевалила за единицу. А недавно вышел релиз 1.7. За это время мы привыкли друг к другу и пережили много успехов и разочарований. Мне хочется немного поделиться своими впечатлениями и размышлениями по поводу этого диалекта JavaScript как самостоятельного языка. Идея подобного поста возникла у меня спонтанно при обсуждении очередного холивара с коллегами.

Итак, что же такое собственно TypeScript — наверно уже ни для кого не секрет. Но все же, хочу упомянуть, что это попытка Microsoft принести в JavaScript статическую типизацию. Примеры кода и задачи, которые он позволяет решать, можно посмотреть на официальном сайте или здесь на хабре, благо статей написано уже не мало. На хабре уже есть статья подобного рода TypeScript: общие впечатления, поэтому, чтобы не повторяться, я решил выделить плюсы и минусы работы с языком, опираясь на свой личный опыт. Вспомнить и перечислить плюсы и минусы языка оказалось довольно непросто.

Данная статья содержит в себе описание основных возможностей шаблонизатора Handlebars и является свободным переводом его официальной документации. Итак, поехали…

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

На схеме изображено место комет сервера в процессе работы.

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

Пролог

В данном цикле статей я намерен провести объективное сравнение css-фреймворков на основе живых примеров, как в TodoMVC для js решений.

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

Мы продолжаем нашу колонку по теме ASP.NET 5 публикацией от Дмитрия Сикорского ( DmitrySikorsky) — руководителя компании «Юбрейнианс» из Украины. В этой статье Дмитрий подробнее рассказывает о сценариях применения с ASP.NET 5 популярного средства Gulp. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

До появления ASP.NET 5 я никогда не использовал такие инструменты, как Gulp, поэтому пришлось уделить некоторое время и разобраться, что же это такое, когда я создал свой первый проект на этой платформе (правда, тогда там еще был Grunt, но это не важно). Не стану вдаваться в базовые вещи, которые уже и так везде достаточно подробно описаны (подразумеваю, что в вашем проекте уже есть Gulpfile.js и вы можете выполнять задания из него, используя диспетчер выполнения задач Visual Studio 2015), а сразу перейду к делу и на практике покажу, как можно использовать Gulp для автоматизации всего-всего в вашем проекте на ASP.NET 5.


В статье будут приведены фрагменты файла Gulpfile.js тестового проекта AspNet5Gulpization, который целиком лежит тут: https://github.com/DmitrySikorsky/AspNet5Gulpization.

Вступление

Вы наверняка знаете, для чего используется новая папка wwwroot. На самом деле, с ее появлением я немного по-новому взглянул на скрипты, стили и картинки. А именно, как и серверный код сайта, теперь я разделяю их на исходники и готовые к публикации объекты.

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

Мы счастливы поделиться с вами новостью, что проект Angular 2 достиг бета-версии. О том множестве нововведений, что принесла вторая версия по сравнению с первой, вы можете узнать из предыдущего поста. Изучение Angular 2 можно начать на сайте angular.io.

Что означает «бета»?

«Бета» означает, что теперь мы уверены в том, что большая часть разработчиков имеет возможность успешно создавать крупные приложения с помощью Angular 2.

У меня, как у художницы и web-разработчика, со временем появилась необходимость в собственной галерее. Обычно, у галерей две основные функции: показ витрины — всех (или некоторых) картин — и детальный показ одной. Реализация обеих функций есть практически в любой готовой галерее. Но «заношенный» внешний вид готовых галерей и, ставший стандартом, пользовательский интерфейс не годятся для художника :). А нестандартный — требует особой архитектуры и реализации кода, осуществляющего загрузку и показ картин. Сам показ и пользовательский интерфейс я в этой статье опущу. Основное внимание будет отдано загрузке картин с сервера. Об итоговой организации контролируемой загрузки с использованием очередей, асинхронного загрузчика, обработки блоб-объектов, каскадов выполнения обещаний и с возможностью приостановки и пойдет речь.



Примеры кода записаны на coffeeScript

Изучая любой язык программирования, полезно знать о его особенностях и уметь эффективно использовать языковые конструкции. Хочу поделиться с вами шорткатами для JS. Эти сокращения в некоторых случаях могут облегчить чтение кода, а также существенно уменьшить его количество. Однако следует помнить, что они могут сыграть с вами злую шутку и, если использовать их повсеместно, ваш код перестанет быть читаемым и поддерживаемым.

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

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

Анализируя исходные коды прошлых проектов, рейтинг популярности прямых вызовов функций показал, что прямой вызов require() встречается в коде node-модулей почти так же часто, как Array#forEach(). Самое обидное, что чаще всего мы подключаем модули "util", "fs" и "path", чуть реже "url". Наличие других подключенных модулей зависит уже от задачи модуля. Причем, говоря о модуле "util", загружается в память node-процесса даже если вы ни разу его не подключали.

В прошлой статье Node.JS Загрузка модулей по требованию я поведал о возможности автоматической загрузкой модуля при первом обращении к его именованной ссылке. Если честно, на момент написания той статьи, я не был уверен в том, что такой подход не станет причиной странного поведения node-процесса. Но, уже сегодня с гордостью могу ручаться, что demandLoad() работает уже пол года в продакшене. Как мы его только не гоняли… Это и нагрузочное тестирование конкретного процесса, и работа demandLoad() в worker-процессах кластеров, и работа процесса под небольшой нагрузкой в течении долгого времени. Результаты сравнивались с использованием demandLoad() и с использованием require(). Никаких существенных отклонений в сравнении не было замечено.

Сегодня речь пойдет уже не о стабильности demandLoad(). Если кому интересно, задавайте вопросы в комментариях, сделаю скриншоты, могу рассказать о методах и инструментах тестирования, других возможностях использования подхода. Сегодня, как следует из заголовка статьи, мы будем избавляться от успевших уже надоесть require() в шапках каждого node-модуля.

Заранее отмечу, ни в коем случае не агитирую использовать предложенный метод в продакшене. Практика изложена для ознакомления и не претендует на статус «true-практики». Громкий заголовок только для привлечения внимания.

В предверии ажиотажа вокруг 7-го эпизода Звездных Войн, Google запустил специальный тематический раздел на своем сайте www.google.com/starwars.

Особое внимание привлекает браузерная аркада Побег Джедая (eng. Lightsaber Escape), запущенная в рамках Chrome Experience.

Всем доброго здравия.
Хотел предложить концепцию JavaScript(JS) библиотеки для удобного использования Custom Elements(по-русски назову «собственные элементы»). Перед тем как предлагать Polymer, X-Tag, Bosonic и другие, прошу прочитать текст до конца.

Введение

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