Что такое vanilla javascript
Что такое VanillaJS?
У меня есть один простой вопрос, который застрял в моей голове на несколько дней: что такое VanillaJS? Некоторые люди называют это фреймворком, вы можете скачать библиотеку с официальных страниц.
Но когда я проверяю некоторые примеры или TodoMVC, они просто используют классические необработанные функции JavaScript, даже не включая библиотеку с официальных страниц или что-то еще. Также ссылка «Docs» на официальной веб-странице ведет к спецификации JavaScript в Mozilla.
Мой вопрос: является ли VanillaJS сырым JavaScript? И если да, почему люди называют его «каркасом», когда все, что вам нужно, это браузер без каких-либо специальных включенных скриптов?
Я прошу прощения за возможно глупый вопрос, но я понятия не имею, о чем говорят люди, когда говорят «VanillaJS».
Это VanillaJS (без изменений):
Использование «VanillaJS» означает использование простого JavaScript без каких-либо дополнительных библиотек, таких как jQuery.
Люди используют это как шутку, чтобы напомнить другим разработчикам, что в наше время можно многое сделать без необходимости использования дополнительных библиотек JavaScript.
Вот забавный сайт, который в шутку говорит об этом: http://vanilla-js.com/
Иногда его иронически называют библиотекой, как шуткой для людей, которых можно рассматривать как бездумно использующих разные фреймворки, особенно jQuery.
Некоторые люди зашли так далеко, чтобы выпустить эту библиотеку, обычно с пустым или только для комментариев js-файлом.
Это шутка для тех, кто увлечен фреймворками JavaScript и не знает чистого Javascript.
Ваниль в сленге означает:
неинтересный, нормальный, обычный, скучный
Вот хорошая презентация на YouTube о VanillaJS: Что такое Vanilla JS?
VanillaJS === JavaScript, т.е. VanillaJS является нативным JavaScript
Компьютерное программное обеспечение, а иногда и другие компьютерные системы, такие как компьютерное оборудование или алгоритмы, называются ванильными, если они не настроены из своей первоначальной формы, что означает, что они используются без каких-либо настроек или обновлений ( см. Эту статью ). Так что ваниль часто относится к чистому или простому.
Нашел в интернете этот каламбур относительно JS-фреймворков (хотя, чтобы не осуждать существующие JS-фреймворки, они сделают жизнь по-настоящему легкой :)), 
Так почему шутка? Это как современный ответ на рефлекс старой школы, основанный на использовании jQuery и дополнительных библиотек JS. Благодаря спецификации ECMAScript и современным возможностям браузеров необходимость обхода простого JS с внешними библиотеками для обеспечения согласованности между браузерами просто отсутствует. Вот сайт, который показывает вам, насколько это верно, на конкретных примерах: http://youmightnotneedjquery.com/
Vanilla JS vs jQuery 2.0
Статья навеяна фреймворком Vanilla.js.
Эпоха старых браузеров уходит в небытие, вряд ли сейчас найдется сознательный человек, использующий ie6,7,8, на зло разработчикам и вопреки техническому прогрессу. Возможно, только по необходимости, например корпоративная система написана под IE6, или лентяи админы издеваются над пользователями и не хотят обновлять/устанавливать новые версии. Тем не менее, статистика использования этих браузеров неумолимо стремится к нулю. Собственно и новая версия jQuery 2.0, отказалась поддерживать устаревшие браузеры(IE 6-8). И тут с релизом jQuery возник вопрос, а для чего же тогда нужен jQuery?
Мое мнение заключается в том, что люди используют jQuery лишь по привычке, или просто не знают базовых вещей javascript и API браузера, который он предоставляет. Чего таить, сам писал на jQuery до того, как освоил javascript…
Но в итоге vanilla одержал верх, на то было много причин, но о некоторых подробнее ниже.
Разберем основные возможности jQuery:
Движок кроссбраузерных CSS-селекторов Sizzle
Что же в этом случае предлагает vanilla?
Для javascript разработчиков знакомо document.querySelectorAll, встроенный в браузер и появившийся даже в IE8. can i use
Но тут кому-то может стать жалко символов, чтобы писать это каждый раз, благо javascript гибкий язык и позволяет писать различные конструкции, чем можно и воспользоваться.
Манипуляции и переход по дереву DOM
Я думаю, что многим знакома картина в проектах:
Конечно, многие скажут, что этому коду прямая дорога на одноименный сайт, и будут правы. В идеале, конечно, next(selector). Но следует задуматься, почему кто-то написал его именно так? А ведь это, типичное поведение для jQuery объектов. Но если не придираться к самому коду, ведь вместо next могли быть различные манипуляции с DOM (css,attr,find. ), записанные в цепочку вызовов, напрашивается вопрос: для чего такая обфускация кода?
Видимо, некоторые пишут код для машины… а не для людей, которым этот код достанется.
Подобно поведение существует и для методов работы с объектами jQuery (node list, array), методы: each, map и др. Необходимость в этих методах была, когда jQuery реализовывал их для старых IE. Во всех современные браузерах есть нативные методы работы с массивами, forEach, map…
Что касательно самого jQuery, пример кода:
Сразу несколько замечаний, элемент массива передается вторым аргументом, что в итерации по списку глупо и нелогично, потому как сам итератор нужен чаще чем индекс, а индекс и вовсе не нужен, но есть this который ссылается на текущий элемент, причем в данном случае, создавая новый экземпляр переменной Number… что показано во 2 примере, очевидно что this и атрибут — не одно и то же. При попытке сравнить this с числом, без преобразования, получится false.
javascript, позволяет, но если каждый будет делать так, как ему того хочется, мир от этого явно лучше не станет.
Параметры в логичном порядке, есть возможность задать контекст исполнения (this), не делая лишних замыканий.
Для манипуляции над DOM объектами существует довольно обширное API, почитать можно на MDN.
События
В случае отсутствия элемента на странице произойдет ровным счетом ничего, в процессе разработки можно ошибиться в названии класса, и jQuery успешно отработает этот случай, а вы будете дальше искать, почему же не работает событие на кнопке/линке, пока не заметите опечатку. Или аналогичная ситуация, когда элемент присутствует на разных страницах, но на первой нужно событие, а на второй нет. Вот тут уже приходится импровизировать, менять имена классов или делать условные селекты.
jQuery здесь всего лишь синтаксический сахар, не более.
В ранних версиях IE, эвенты прикреплялись с помощью attachEvent, что затрудняло работу, а jQuery в свою очередь, делал все автомагически, но теперь все браузеры поддерживают EventListener
что всегда можно переопределить, написав короткий метод или удобную обертку над эвентами(на строк 20), если хватит знаний javascript.
Визуальные эффекты
Набор простеньких утилит для эффектов которые не всегда нужны… Альтернатива? написать самостоятельно, лишь то, что Вам нужно, об этом в статье про vanilla. Конечно не повод городить велосипеды, но не тянуть же ради 1 метода всю библиотеку.
Трудно сейчас представить сайт без ajax. Но что же делает jQuery таким особенным в данном случае?
В предыдущих версиях было очевидно, что ajax запрос должен быть кроссбраузерным и реализовываться по разному, в зависимости от браузера пользователя. Но это в прошлом, теперь jQuery лишь добавляет синтаксический сахар для тех, кто в действительности просто не знает, как создать объект XMLHttpRequest. Спорить трудно, намного короче записать:
без учета самой jQuery вроде коротко, но современные браузеры поддерживают нативный XMLHttpRequest:
что само по себе не сильно выходит за рамки jQuery.ajax.
JavaScript-плагины
Обширная библиотека плагинов на jQuery, слайдеры, скролеры и тд… Клоны библиотек на любой вкус, по запросу в поиске можно найти десятки, а то и сотни идентичных плагинов, отличающихся ничемреализацией и/или автором.
$(‘selector’).сделать_все_как_надо() решает много вопросов, но кто из авторов библиотек может вам дать 100% гарантии, и если что-то пойдет не так, заказчику явно будет не интересно слушать, что виноват Вася Пупкин, зарелизивший баг.
Конечно, Vanilla это не фреймворк, а самый что ни на есть javascript, позволяющий делать все, что необходимо.
Трудно представить, чем поможет jQuery, если вам необходимо написать какой-нибудь класс на javascript или не найдется нужной либы, а вы, возможно, даже и не слышали, что такое prototype(не фреймворк) и для чего он нужен.
Резюме
В итоге нельзя сказать, что jQuery тяжелый фреймворк (33.6 KB сжатый) в наш цифровой век безлимитных интернетов и мобильных устройств с памятью большей 1Гб. Но в большинстве случаев абсолютно бесполезный довесок, замедляющий работу страницы во много раз(как показывают бенчи примерно 50), без которого можно обойтись. Совсем другая ситуация с плагинами. Складывается впечатление, что разработчики вовсе не хотят сами думать, новый таск — новый плагин в проекте. В итоге кол-во плагинов jQuery (которые могут тянуть разные версии jQuery), раздувает js до 0.5 Мб, а то и больше…
jQuery предоставляет синтаксический сахар, ко многим конструкциям клиентского javascript, но ценой производительности, видимо, каждому решать самому, чем жертвовать, временем на разработку или качеством продукта.
Известна точка зрения Никлауса Вирта, которую разделяет часть программистского сообщества: согласно ей, любое расширение языка, не вызванное необходимостью, ухудшает его, так как приводит к усложнению транслятора и, соответственно, к понижению его надёжности и производительности. Одновременно возрастает сложность изучения языка и сложность сопровождения программ. Кроме того, сам факт наличия дополнительных синтаксических средств часто играет провоцирующую роль: он побуждает программиста прибегать к различным синтаксическим трюкам вместо того, чтобы глубже анализировать задачу и реализовывать более эффективные алгоритмы.[wiki]
Порой необходимо задумываться над тем, что вы делаете, работа у программиста такая — думать, вот и постарайтесь.
Речь не идет о том чтобы отказаться от jQuery и писать на vanilla, просто не переоценивать его возможности, бездумно используя, где надо и не надо, думаю все помнят про «как сложить два числа в javascript».
Vanilla JS
понедельник, 3 сентября 2012 г.
Vanilla JS
Кто использует Vanilla JS?
Хорошо, что вы спросили, вот несколько примеров: Facebook, Google, YouTube, Yahoo, Wikipedia, Windows Live, Twitter, Amazon, LinkedIn, MSN, eBay, Microsoft, Tumblr, Apple, Pinterest, PayPal, Reddit, Netflix, Stack Overflow. Команда Vanilla JS поддерживает каждый байт кода фреймворка и каждый день много трудится, чтобы сделать его маленьким и интуитивным.
На сайте вы можете скачать фреймворк, выбрав нужную вам функциональность:
— DOM (Манипуляции / Селекторы)
— Прототипная система объектов
— AJAX
— Анимации
— Система событий
— Регулярные выражения
— Функции как объекты
— Замыкания
— Библиотеку математических методов
— Библиотеку для работы с массивами
— Библиотеку для работы со строками
Плюс можете настроить вашу сборку:
— Сжать исходники
— В кодировке UTF8
— Использовать «CRLF» переносы строк (Windows)
При максимальной комплектации фреймворк будет весить:
— несжатый: 0 байт
— сжатый: 25 байт
Установка Vanilla JS
Команда Vanilla JS гордится тем фактом, что это самый лёгкий фреймворк всех времён; используйте нашу стратегию выкладки на продакшн, и браузеры ваших пользователей загрузят Vanilla JS в память ещё даже до того, как начнут загружать ваш сайт.
Чтобы подключить Vanilla JS, просто добавьте следующую строку в ваш HTML:
Когда будете готовы выложить свой проект на продакшн, смените подключение на намного более быстрый метод:
Всё верно, совсем без кода. Vanilla JS настолько популярна, что браузеры автоматически загружают фреймворк уже лет десять.
Реактивные интерфейсы на ванильном JavaScript — Часть 1: Чистый функциональный стиль
20 апреля Крис Койер написал пост, исследуя вопрос: «При каких условиях проекту нужен React?». Другими словами, когда преимущества использования React (или другого веб-фреймворка для приложений с нетривиальной логикой), вместо серверных шаблонов и jQuery, перевешивают сложность настройки требуемого инструментария, процесса сборки, разрешения зависимостей и так далее? Через неделю Саша Грайф выразил в своей статье противоположное мнение о преимуществах постоянного использования такой структуры для каждого веб-проекта. Его аргументы состояли в том, что фреймворк обеспечивает устойчивую расширяемость, упрощенный рабочий процесс от проекта к проекту (единую архитектуру, отсутствие необходимости в сопровождении нескольких типов структур проекта) и улучшенный пользовательский интерфейс благодаря рендерингу на стороне клиента, даже если контент меняется не часто.
В этой паре статей пробуем найти золотую середину: написание пользовательского интерфейса в реактивном стиле в ванильном JavaScript — без фреймворков, без препроцессоров.
Существует два способа создания компонентов React.
Первый вариант более полезен для больших сложных приложений с динамичным интерфейсом, а второй является элегантным способом отображения информации, при отсутствии сложного динамического состояния. Если вы когда-либо использовали шаблонный движок, например Handlebars или Swig, их синтаксис довольно похож на функциональный код React.
В этой серии статей наша цель — статичные сайты, которые при использовании рендеринга на основе JavaScript получат определенные преимущества в случае отсутствия накладных расходов на создание такой структуры, как React. Блоги, форумы и так далее. Поэтому этот первый пост будет посвящен функциональному подходу к написанию пользовательского интерфейса на основе компонентов, поскольку такой интерфейс будет более практичным для такого сценария. Второй пост будет скорее экспериментом: я постараюсь расширить грани того, как далеко мы можем продвинуться без фреймворка, пытаясь максимально точно скопировать структуру компонентов на классах React, используя только ванильный JavaScript (возможно, за счет небольшой потери практичности).
О функциональном программировании
За последние пару лет функциональное программирование стремительно развивалось, по большей части в Clojure, Python и React. Полное объяснение понятия функционального программирования выходит за рамки этой публикации. Актуальная для нас часть — это концепция величин, которые являются функциями других величин.
Скажем, ваш код должен представлять концепцию прямоугольника. Прямоугольник имеет ширину и высоту, но также имеет площадь, периметр и другие атрибуты. Сначала можно представить прямоугольник следующим объектом:
Сразу видно, что есть проблема. Что произойдет, если ширина изменится? При этом мы должны изменить площадь и периметр, иначе они будут неверны. Возможно будут конфликтующие значения, которые нельзя просто изменить, не обновляя что-то еще. Это называется наличием множественных источников истины.
В примере с прямоугольником решение в функциональном стиле состоит в том, чтобы сделать область и периметр функциями прямоугольника:
Таким образом, если изменяется ширина или высота, нам не нужно вручную изменять что-либо еще, чтобы отразить этот факт. Площадь и периметр просто всегда верны. Это называется наличием единственного источника истины.
Сила этой идеи также проявляется, когда вместо длины и ширины прямоугольника — данные вашего приложения, а вместо площади и периметра — HTML. Если вы можете сделать HTML функцией от данных, заботиться нужно будет только об их изменении, а DOM отобразится на странице неявным способом.
UI компоненты как функции
Мы хотим сделать HTML функцией от наших данных. Давайте рассмотрим пример сообщения в блоге:
Хорошо. Мы создали функцию объекта сообщения, возвращающую строку HTML, которая отображает наше сообщение в блоге. На самом деле это пока не компонентно. Это — единый большой шаблон. Что делать, если мы хотим отобразить все наши сообщения в блоге последовательно на главной странице? Что делать, если мы хотим повторно использовать этот заголовок на разных страницах? К счастью, можно легко построить функции из других функций. Это называется композиция:
Так гораздо приятнее. Нам не пришлось дублировать заголовок для домашней страницы и у нас есть единственный источник истины для этого HTML-кода. Если мы захотим отобразить сообщение в другом контексте, мы сможем легко это сделать.
Достаточный синтаксис с шаблонами
Хорошо, но эти конкатенации ужасны. Их нудно печатать, и они затрудняют чтение. Должен быть лучший способ, не так ли? Люди в W3C опережают нас в этом. Они создали шаблонные литералы, которые, хотя и относительно новы, уже имеют довольно хорошую поддержку в браузерах. Просто оберните свою строку в обратные кавычки и она получит пару дополнительных сверхспособностей.
Первая суперсила — это способность охватывать несколько строк. Наш компонент BlogPost может стать таким:
Намного лучше. Сейчас это похоже на JSX. Наш полный пример с шаблонными литералами теперь выглядит так:
Больше, чем просто заполнение пробелов
Таким образом, мы можем подставить значения переменных и даже другие компоненты через функции, но иногда необходима более сложная логика. Иногда нам нужно перебирать данные или отвечать на изменение состояния. Давайте рассмотрим некоторые функции JavaScript, упрощающие выполнение более сложного рендеринга в функциональном стиле.
Тернарный оператор
Это все… не идеально. Мы добавляем много строк для несложной логики и отделяем код рендеринга от его места в остальной части HTML. Это связано с тем, что классический оператор if-else решает, какие строки кода запускать, а не какое значение вычислять. Это важное для понимания различие. Вы не можете вставить последовательность в шаблонный литерал, только одно выражение.
Array.map()
Вы возможно уже поняли, почему такой способ эффективен для нас. Ранее мы определили концепцию: значение — функция от другого значения. Array.map() позволяет нам получить целый массив, для которого каждый элемент является функцией соответствующего элемента в другом массиве. Допустим, у нас есть массив сообщений в блогах, которые мы хотим отобразить:
Перерисовка
Теперь мы можем неявно генерировать HTML из входных данных, компоновать и использовать этот код для других данных, и все это на стороне клиента. Но как обновлять HTML при изменении данных? Как вообще понять в какой момент произошли изменения? Этот вопрос является одним из самых сложных и горячо обсуждаемых в сообществе фреймворков JavaScript. Осуществление частых обновлений DOM — удивительно сложная проблема, над которой инженеры из Facebook и Google работают уже много лет.
К счастью, наш сайт — это всего лишь блог. Содержание ощутимо меняется только при просмотре другого сообщения в блоге. Нет множества взаимодействий для отслеживания, нам не нужно оптимизировать операции с DOM. Когда мы загружаем новое сообщение, мы можем просто удалить DOM и перестроить его.
Мы могли бы сделать это немного лучше, обернув в функцию:
Теперь, когда мы загружаем данные сообщения, просто вызываем update() и отображается нужный HTML. Если бы наше приложение было достаточно сложным и его нужно было бы часто перерисовывать (например, пару раз в секунду), оно быстро начало бы тормозить. Можно написать сложную логику, чтобы определять, какие части страницы действительно нуждаются в обновлении, учитывая конкретное изменение данных, и обновлять только их, но это как раз тот случай, когда надо просто использовать фреймворк.
Не только для контента
На данный момент почти весь наш код рендеринга использовался для определения фактического содержимого HTML и текста внутри элементов, но мы не должны останавливаться на достигнутом. Поскольку мы просто создаем HTML-строку, туда можно добавить кое-что еще. Классы CSS?
Сделано. Не стесняйтесь проявлять творческий подход. Подумайте о своих данных и подумайте о том, как все различные их аспекты должны быть представлены в разметке и пишите выражения, превращающие одно в другое.
Итоги
Надеюсь, что эта статья дает вам хороший набор инструментов для написания простых реактивных веб-интерфейсов, управляемых данными, без накладных расходов в лице каких-либо инструментов или фреймворков. Этот тип кода намного проще писать и поддерживать, чем jQuery лапшу, и нет никакого препятствия для использования его прямо сейчас. Все, о чем мы говорили здесь, поддерживается всеми достаточно современными браузерами, без дополнительных библиотек.
Во второй части основное внимание будет уделено классам, компонентам с состоянием, которые будут на грани сложного и разумного использования нативного JavaScript. Но мы все равно попробуем, и это будет интересно.
Пишем фронтенд-компоненты на ванильном JS
В наши дни вокруг фронтенд-фреймворков (React, Angular, Vue) много шумихи. Поразмышляем, какую проблему они решают и для чего могут быть полезны.
В качестве эксперимента создадим простой компонент исключительно с помощью браузерного JavaScript. Ряд приемов будет использоваться для того, чтобы лучше проиллюстрировать некоторые темы. Поэтому постарайтесь сосредоточиться на самих шаблонах и теме, а не на коде.
Созданная функция будет представлять собой раскрывающийся список элементов. Она должна принимать параметр, указывающий на количество элементов, отображаемых при начальной загрузке. При нажатии на “Показать больше” (Show more) будут показаны все элементы в списке. “Показать меньше” (Show less) скроет все элементы, кроме ранее выбранного числа. Фича должна быть расширяемой, чтобы добавлять на одну страницу несколько таких списков.
После создания такой фичи мы сделаем шаг назад и проанализируем полученный опыт, чтобы понять, какие преимущества предоставляют фронтенд-фреймворки.
Планирование
Прежде чем приступать, нужно рассмотреть несколько моментов.
Затем, наконец, можно приступить к созданию JS-фичи, добавляя функции в код.
1. Дизайн кода + модульность
Требования гласят, что компонент должен быть доступен для переиспользования во многих экземплярах списка. Как добиться этого в JS?
Способ заключается в создании того, что называется “модулем”. Это набор переменных и функций, которые инкапсулированы в единый контекст выполнения, поэтому переменные внутри будут частными и ограниченными. Другими словами, когда вы создаете объект или функцию в JavaScript, то назначаете границу вокруг функций и переменных внутри них, делая эти значения уникальными.
Узнать больше о шаблоне модуля JavaScript можно из главы о модулях в книге Эдди Османи “Изучение шаблонов проектирования Javascript”. В очень упрощенном виде это означает, что мы пишем код со следующей структурой:
Мы определяем компонент в области действия функции (либо внутри объекта, либо внутри функции, возвращающей объект). Такая структура позволяет написать компонент, все переменные которого ограничены только конкретным экземпляром списка. Так нам не придется больше беспокоиться о расширяемости модуля в будущем. Нет проблемы создать на одной странице один, два или пять списков. Вот модуль, который мы написали:
Важно также, что в действительности пользователю этой функции не видно никакой внутренней логики компонента. При желании вывести компонент на следующий уровень вы можете предоставить геттеры, сеттеры или другие функции. Сейчас мы возвратим только корневой элемент.
Здесь можно было бы раскрыть больше внутренних процессов:
Затем пользователь компонента вызывал бы эти действия извне функции следующим образом:
Здесь следует отметить еще одно: для обозначения элемента DOM используется $ . Это соглашение Jquery, популярной библиотеки методов расширения Javascript, но оно распространилось повсюду для определения переменных в JS, указывающих на один или несколько узлов DOM.
2. Рендеринг HTML-кода
Требования к компоненту не подразумевают существенного динамического изменения контента. Но, как и всегда при проектировании пользовательского интерфейса, вам так или иначе придется иметь дело с рендерингом. Вот разметка для компонента:
На первый взгляд, на основе пользовательского ввода придется ре-рендерить не так уж и много. Единственное, что могло бы часто меняться, — это текст “показать больше”. Что нам нужно сделать, так это отделить логику рендеринга HTML от остальной части компонента.
3. Сохранение состояния компонента
Нам понадобится способ хранить состояния компонента, чтобы потом было понятно, что нужно рендерить или какой стиль следует применять. Как уже говорилось, мы собрали компонент как модуль, так что значения переменных, определенных внутри функции, ограничиваются этой функцией и сохраняются при ее выполнении.
Определить состояние просто: let state =
4. Уничтожение элемента
Создание фичи
Наконец-то мы готовы создать необходимую фичу. Сначала нужно определить JS-функцию, которая будет модулем для компонента (опять же, термин “модуль” здесь означает часть JS-кода, который будет определять область действия и применяться только к целевому элементу). В приведенном ниже коде строка collapsible($module1, 2) говорит: “Создайте новый модуль JS-кода, который применяет функциональность свертывания только к элементу под названием module1 ”.
Здесь хорошо видны преимущества применения фреймворков даже для таких небольших компонентов.
Разработка без фронтенд-фреймворков — полезное упражнение, которое позволяет увидеть потрясающую функциональность, к которой эти инструменты дают доступ.
Весь код из примера можно посмотреть здесь.