Вредоносное ПО (malware) - это назойливые или опасные программы,...
Сегодня речь пойдёт о JavaScript.
AngularJSОдин из самых популярных инструментов JS-разработчика увидел свет в 2009 году. Благодаря широкой функциональности (хоть и не дотягивающей до Full-stack) и поддержке своего могущественного создателя, Angular быстро взобрался на вершину рейтинга лучших JS-фреймворков, и слезать оттуда не намерен.
Что касается свежих релизов, то в конце марта официально был представлен Angular 4.0.0 (несмотря на то, что 2.0.0 выпустили всего год назад). Такая скорость обновления связана не с «сыростью» выпускаемых продуктов, а в том, что первая версия содержала много упрощений, которые в неумелых руках приводили к ошибкам, а в опытных к существенным потерям в производительности, вторая является компромиссным переходом, третью пропустили, а четвертая - это актуальный продукт, доработанный по итогам всех замечаний. Правда, есть подозрение, что еще не до конца.
А теперь подробнее о плюсах. Во-первых, это удобство. Вам не надо заботиться об описании десятка всплывающих процессов при обработке одного события, здесь действительно здорово реализована работа с шаблонами и зависимостями, да и создать строго персонализированный интерфейс не составит труда.
Во-вторых, Google постоянно выпускает всё новые и новые качественные библиотеки и плагины.
В-третьих, в Angular взаимодействие с HTML не подменяется DOM-моделью (HTML-код не смешивается со скриптами), что в конечном счете сказывается на удобстве чтения и тестирования кода. Кроме того, возможности Angular чуть шире, чем у большинства популярных JS-фреймворков.
Минусы такого подхода: невысокая производительность загруженных интерфейсов и резкая кривая обучения (легко начать работать, но чем дальше, тем тяжелее).
ReactJS
Данный фреймворк был создан в 2013 году Джорданом Волком из Facebook. Низкий порог входа и простота использования сделали из ReactJS популярный продукт среди корпоративных разработчиков, найдя отклики в сердцах офисов таких компаний, как Airbnb, Netflix Walmart и т.д. Более того, именно React сегодня считается основным инструментом JS-разработчика, ну просто потому, что Angular - это немного сложно и избыточно.
Всё дело в том, что отличии от Angular, React сильно ограничен в функциональности. Более того, некоторые хардкорные разработчики всерьез и не считают ReactJS фреймворком, предлагая более понятное, но не совсем правильное определение «ограниченная библиотека для лентяев».
Зато основные плюсы работы с этим фреймворком такое описание раскрывает достаточно точно. Здесь вы оперируете шаблонами и готовыми callback-функциями, создавая собственный front-end. Для новичка всё достаточно удобно и понятно, но, справедливости ради, в Angular дела с этим обстоят ничуть не хуже.
Главное удобство и вместе с тем основная претензия к React - JSX компоненты. Это как раз тот случай, когда скрипты плотно смешиваются с HTML-кодом, стирая границы между представлением и функциональностью компонента. Ничего страшного в этом нет, но понимание работы и «правильность» страдают. Короче говоря, с React вы экономите время и нервы, а именно это зачастую играет ключевую роль в выборе, но теряете немного самоуважения.
Основным минусом, помимо самой ограниченности подхода, считается не самая лучшая официальная документация. Но то ли её серьёзно переработали, то ли ожидания критиков изначально были сильно завышены, но я не увидел ничего принципиально отличного от тех туториалов, что обычно предлагают своим клиентам Microsoft или Google.
Vue.js
Первая версия Vue.js строилась на тех же принципах, что и React, но исключая использование JSX-компонентов. Это была неплохая альтернатива, но до появления версии 2.0 это была довольно сырая библиотека. А потом понеслось. Просто взгляните на статистику : сумасшедший рост популярности на GitHub, Google Trends и в предпочтениях разработчиков.
Если говорить просто, то Vue.js - это некий компромисс между React и Angular. Front-end код легко создать, но вместе с тем читать и править. При этом это абсолютно никак не сказывается на конечном быстродействии, точнее сказывается, но только в положительную сторону .
Но есть отрицательные стороны, и они достаточно существенные. Во-первых, это скудное количество документации и сторонних библиотек. Проект молодой, разрабатываемый по сути одним человеком, переживший скачок популярности лишь в 2016 году, поэтому о каком-то потоке вспомогательного инструментария говорить не приходится.
Кроме того, востребованность Vue.js концентрируется в основном в районе Китая, поэтому о развитости сообществ тоже говорить не приходится. Во-вторых, ещё одна проблемы роста - большое количество runtime ошибок в шаблонах. Со временем всё исправляется, но данный факт пока относится к серьёзным проблемам, а не редких недоразумениям.
Ember.js
Ещё одна вариация на тему «Больше шаблонов - больше пользы разработчику». В сущности, вы не увидите здесь чего-то революционного, Ember, по сути - упрощённый Angular. Основное сходство обеспечивают двухсторонний биндинг и возможности, лежащие за гранью создания внешнего интерфейса.
Здесь реализуется модель MVC. реализуется по строгим конфигурациям. С точки зрения освоения инструмента новичком и обеспечения быстродействия разработки - почти идеальное решение. А вот когда решите с этой проторенной разработчиками дорожки, то сразу же обнаружите все острые подводные камни. Это и сложности кастомизации, и слишком частые кардинальные изменения версии, и связанный с этим быстро устаревающий типовой FAQ на форумах и в сообществах.
Meteor
Meteor - далеко не самый популярный фреймворк, но он обладает массой преимуществ, которыми обделены ранее перечисленные претенденты. Во-первых, это настоящий Full-stack инструмент разработчика. Во-вторых, писать здесь можно на чистом JavaScript. Третье - интеграция хоть с Angular, хоть с React. Четвертое - почти идеальная реализация механизма создания веб-ресурсов реального времени (примеры - онлайн-конфигураторы Mazda и Ikea). Более того, всё это сдобрено отличной официальной документацией, в том числе и обучающей, и большим сообществом разработчиков
Минусы при этом не слишком существенны: использование Mongo в качестве БД или других, но через Mongo Queries (в Angular, например, таких ограничений нет), да вызывающая сомнения безопасность полученного продукта, что для такой функциональности вполне естественно.
При этом Meteor относительно прост для изучения новичком, а опытному разработчику хватит и одного-двух дней. Однако, к сожалению, ни это, ни усилия разработчиков, постоянно дорабатывающих свой продукт, не позволяют обогнать других сегодняшних претендентов просто потому, что full-stack для многих - всё ещё очень сложно. Но, возможно, это лишь потому, что они не пробовали на вкус Meteor.
А какими фреймворками пользуетесь вы?
JavaScript фреймворки подобны смерти и налогам - неминуемы и неизбежны. Я уверен, что если бы мог подслушать всех, кто начинает веб-проект, каждый раз первый вопрос был бы о том, какой JavaScript фреймворк в нем будет использоваться. Вот насколько укоренилась роль фреймворков в нашей отрасли. Это не так, как должно быть, пора остановиться.
Давайте оглянемся назад и постараемся понять, как мы к этому пришли.
Angular и Backbone и Ember, о божеHTML Imports, HTML шаблоны, настраиваемые элементы и Shadow DOM - все эти технологии расширяют наши возможности. Они должны позволить нам разорвать связь с фреймворками, позволяя создавать пригодные для повторного использования элементы и функционал. Для наглядного представления смотрите эти статьи и библиотеки:
Хорошо, если бы у нас была одна огромная библиотека полифиллов HTML5, но ещё лучше было бы то, что я назвал бы «html-5-polyfill-o-matic», набор инструментов, который позволил бы мне использовать Веб-компоненты минуя трясину HTML+JS, а затем анализировал мой код, или статическим анализом, или через Object.observe при работе, и выдал бы мне из всего полифилла HTML5 только то, что нужно для моего проекта.
Этот вид функциональности ещё более важен, потому что я начал пытаться совместить веб-компоненты и библиотеки из нескольких источников, т.е. от X-Tag и от Polymer, значит ли это, что мне придётся подключать обе эти библиотеки полифиллов? (Оказывается, что ответ нет.) И как именно я должен получать эти специфические элементы? И X-Tag, и Brick имеют собственные пакеты генераторов:
Если я начну создавать собственные элементы, мне нужно будет создавать и свой собственный пакет? Я не думаю, что это масштабируемая идея, я считаю, что нам нужны идиомы и инструменты, которые справлялись бы с этим гораздо лучше. Это на самом деле может означать изменение того, как пишется открытый код. «Виджет» не проект, поэтому наша работа с этими вещами должна изменится. Конечно, продолжайте хранить код в Git, но нужны ли вам накладные расходы в виде GitHub? Что-то более легковесное, ближе к Gist, чем к проекту, подошло бы лучше. А как минимизировать/вулканизировать весь этот код в подходящий для использования в моем проекте вид? Что-то вроде Asset Graph может стать хорошим началом.
И так, что нам теперь нужно?
Это то, что нам требуется для того, что бы построить будущее, в котором нам не придётся знать последнюю модель новейшего фреймворка, вместо этого мы просто будем работать напрямую с платформой, загружая элементы и библиотеки для своих нужд, и тратя своё время на написание приложений, а не на картографирование айсбергов.
Вопросы и ответыО: Я не ненавижу их. Некоторые из моих лучших друзей - авторы фрейворков. Признаюсь, я немного вдохновлялся ироничной статьёй «ты погубил JavaScript », но я ни в коем случае не высмеиваю авторов фреймворков.
В: Вы не можете сделать ____ на HTML5, для этого вам нужен фреймворк.
О: Во-первых, это не вопрос. Во-вторых, спасибо что указали на это. А теперь давайте работать вместе, чтобы добавить в HTML5 возможность делать ____ без фреймворка.
В: Но ____ не фреймворк, это библиотека!
О: Да, как я уже сказал, есть градиент от gist до фреймворка, и вы можете видеть всё немного иначе, чем я. Это нормально, я не про классификацию какой-либо конкретной части программного обеспечения, речь идет об отдалению от фреймворков.
В: Я делал это годами с помощью ____ и ____ и ____.
О: Опять же, это не вопрос, но всё равно, это хорошо, вы должны быть в хорошей форме, чтобы помочь всем остальным.
В: Таким образом, каждый должен переписать выпадающие меню, вкладки, ползунки и переключатели сам?
О: Абсолютно нет, дело в том, что должен быть способ, чтобы создать те элементы таким образом, чтобы не требовалось установки фреймворка.
В: Чувак, все эти HTML Imports скажутся на производительности сайтов
О: Если вы используете все это бездумно, то да. Вот, почему я указывал на необходимость инструментов, компилирующих и сжимающих HTML, CSS, и JS.
В: Так что я не должен использовать никакие библиотеки?
О: Нет, это не то, что я сказал. Я был очень осторожен с разграничением библиотек и фреймворков. Библиотека обеспечивает ортогональный кусок функциональности, которая может быть использована с другими библиотеками. Библиотеки - это хорошо. А вот фреймворки требуют 100% того, от чего, по моему мнению, стоит отказаться.
В: Но мне нравится связывание данных!
О: Много кому нравится, я только высказываю личные предпочтения. Я не говорю, что вы не должны использовать связывание данных, только то, что вам не нужно прикручивать весь фреймворк, чтобы получить привязку данных, для этого есть автономные библиотеки.
Оригинальная статья: No more JS frameworks Статью вычитывали:
В поисках полезных JavaScript фреймворков и библиотек? Ознакомьтесь с нашим обзором и выясните, что именно подойдет для вашего проекта.
JavaScript (JS) – один из самых популярных ЯП во всем мире. Веб-разработчики активно используют JS для проектирования, анимации и создания веб-страниц. Наряду с HTML и CSS, JavaScript может сворачивать горы, а именно делать веб-страницу интерактивной и максимально интересной для пользователей.
JavaScript не ограничивает себя. Вместо этого он продолжает развиваться. Это наиболее универсальный язык программирования, что подкреплено его способностью разрабатывать приложения для широкого спектра платформ, таких как Android, Windows и iOS.
Основные преимущества JS:
Open Source фреймворк для работы с UI, который продолжает развиваться. Заслуженно наиболее популярный JS-фреймворк по статистике GitHub. Vue.js перерисовывает минимальное количество компонентов и поддерживает интеграцию сторонних библиотек. Как и React.js, Vue.js очень быстрый, использует Virtual DOM, а также предоставляет реактивность и компонентную структуру.
Плюсы:
Минусы:
Эта разработанная Google платформа JS установила новую планку. Незаменимый фреймворк предназначен не только для разработчиков ПО, но и для дизайнеров. AngularJS, Angular 2 и Angular 4 прочно обосновались среди востребованных фреймворков. Это открытая платформа, которая поможет создавать SPA-приложения (Single Pages Applications), осуществлять двустороннее связывание для динамического изменения данных, etc.
Плюсы:
Минусы:
jQuery и JavaScript давно и прочно связаны. С лицензией MIT эта библиотека предоставляет разработчикам приложений возможность писать более короткий код, сокращая тем самым рабочую нагрузку. Поддерживает DOM-манипуляции и в тандеме с CSS может пригодиться для решения любой задачи.
Плюсы:
Минусы:
Следующей для вступления в лигу является библиотека для работы с UI React.js. Это сердце и душа IT-компаний и различных бизнес-сайтов. Данная JS-библиотека вступает в игру, когда нужно решить проблему частичного обновления содержимого веб-страницы. Идеальный инструмент для масштабных веб-проектов. Функционал React.js способствует улучшению работы UI.
Плюсы:
Минусы:
Эта серверная JS-платформа будет следующей. Отзывчивый, неблокирующий и быстрый инструмент. GoDaddy и Paypal – лишь некоторые из именитых компаний, которые используют Node.js. Он лучше всего подходит для приложений, связанных с I/O и приложений для потоковой передачи данных.
Плюсы:
Минусы:
Titanium – это и SDK, и облачная платформа для сборки/распространения ПО. Качественный, доступный и простой в освоении инструмент. Titanium предназначен для кроссплатформенной разработки, что идеально подходит для создания функционально насыщенных приложений.
Плюсы:
Минусы:
Еще один представитель JavaScript фреймворков с открытым исходным кодом. Основное преимущество заключается в массивном репозитории, который может служить в качестве словаря для разработки приложений. Упрощает создание масштабируемых одностраничников и обеспечивает двустороннюю привязку данных.
Плюсы:
Минусы:
В наши дни в области фронтенд-разработки есть множество фреймворков и библиотек. Какие-то из них хорошие, какие-то нет. Часто нам нравится только определённый принцип или определённый синтаксис. Правда в том, что универсального инструмента нет. Эта статья про будущий фреймворк - фреймворк, которого ещё не существует. Я резюмировал достоинства и недостатки некоторых популярных JavaScript-фреймворков и отважился помечтать об идеальном решении.
Абстракции опасныВсем нам нравятся простые инструменты. Сложность убивает. Она делает наши жизни сложнее, а кривую обучения - более отвесной. Программистам необходимо знать, как вещи работают. Иначе они чувствуют себя неуверенно. Если мы работаем со сложной системой, появляется большой разрыв между «я этим пользуюсь» и «я знаю, как это работает». К примеру, такой код скрывает сложность:
Var page = Framework.createPage({ "type": "home", "visible": true });
Предположим, что это реальный фреймворк. Под капотом createPage создает новый класс отображения , который загружает шаблон из home.html . В зависимости от значения параметра visible мы вставляем (или нет) созданный элемент DOM в дерево. А теперь представьте себя на месте разработчика. Мы прочитали в документации, что этот метод создаёт новую страницу с заданным шаблоном. Нам неизвестны конкретные детали, потому что это абстракция.
У некоторых из фреймворков наших дней даже не один, а несколько слоёв абстракций. Иногда чтобы пользоваться фреймворком правильно, нам нужно знать детали. Абстрагирование, вообще говоря, мощный инструмент, это обёртка для функциональности. Оно инкапсулирует конкретные реализации. Но абстрагирование следует использовать с осторожностью, иначе оно может привести к действиям, которые невозможно отследить.
А что если мы перепишем пример выше вот так:
Var page = Framework.createPage(); page .loadTemplate("home.html") .appendToDOM();
Теперь разработчик знает, что происходит. Создание шаблона и вставка в дерево теперь производятся разными методами API. Так что программист может что-то сделать между этим вызовами и контролирует ситуацию.
Function ViewModel(first, last) { this.firstName = ko.observable(first); this.lastName = ko.observable(last); } ko.applyBindings(new ViewModel("Planet", "Earth"))
Мы объявляем модель и сами же её инициализируем. А вот в AngularJS чуть по-другому:
Function TodoCtrl($scope) { $scope.todos = [ { "text": "learn angular", "done": true }, { "text": "build an angular app", "done": false } ]; }
Опять таки, мы объявляем наш класс, но мы его не запускаем. Мы только говорим, что это наш контроллер, а фреймворк решает, что с ним делать. Нас может сбить это с толку, потому что мы потеряли ключевые точки - те ключевые точки, которые нужны нам для того, чтобы нарисовать схему работы приложения.
Работа с DOMЧто бы мы ни делали, нам нужно взаимодействовать с DOM. То, как мы это делаем, очень важно, обычно каждое изменение узлов дерева на странице влечёт за собой пересчёт размеров или перерисовку, а это могут быть весьма дорогостоящие операции. Давайте в качестве примера разберём такой класс:
Var Framework = { "el": null, "setElement": function(el) { this.el = el; return this; }, "update": function(list) { var str = "
- ";
for (var i = 0; i < list.length; i++) {
var li = document.createElement("li");
li.textContent = list[i];
str += li.outerHTML;
}
str += "
Этот крошечный фреймворк генерирует ненумерованный список с нужными данными. Мы передаём элемент DOM, в котором следует поместить список, и вызываем функцию update , которая отображает данные на экране.
Framework .setElement(document.querySelector(".content")) .update(["JavaScript", "is", "awesome"]);
Вот, что у нас из этого вышло:
Чтобы продемонстрировать слабую сторону такого подхода мы добавим на страницу ссылку и назначим на ней обработчик события click . Функция снова вызовет метод update , но с другими элементами списка:
Document.querySelector("a").addEventListener("click", function() { Framework.update(["Web", "is", "awesome"]); });
Мы передаём почти те же самые данные, поменялся только первый элемент массива. Но из-за того, что мы используем innerHTML , перерисовка происходит после каждого клика. Браузер не знает, что нам надо поменять только первую строку. Он перерисовывает весь список. Давайте запустим DevTools браузера Opera и запустим профилирование. Посмотрите на этом анимированном GIF, что происходит:
Заметьте, после каждого клика весь контент перерисовывается. Это проблема, особенно, если такая техника применяется во многих местах на странице.
Гораздо лучше запоминать созданные элементы
SetElement: function(el) { this.list = document.createElement("ul"); el.appendChild(this.list); return this; }
Теперь нам больше не обязательно хранить ссылку на элемент-контейнер. Достаточно создать элемент
- и один раз его добавить в дерево.
- . Ссылки на эти элементы хранятся в массиве this.rows . А если там по определённому индексу уже находится элемент, фреймворк лишь обновляет по возможности его свойство textContent . Второй цикл удаляет элементы, если размер массива больше, чем количество переданных строк.
Вот результат:
Браузер перерисовывает только ту часть, которая изменилась.
Хорошая новость: фреймворки вроде React и так уже работают с DOM правильно. Браузеры становятся умнее и применяют хитрости для того, чтобы перерисовывать как можно меньше. Но всё равно, лучше держать это в уме и проверять, как работает выбранный вами фреймворк.
Я надеюсь, в ближайшем будущем мы сможем больше не задумываться о таких вещах, и фреймворки будут заботиться об этом сами.
Обработка событий DOMПриложения на JavaScript обычно взаимодействуют с пользователем через события DOM. Элементы на странице посылают события, а наш код их обрабатывает. Вот отрывок кода на Backbone.js, который выполняет действие, если пользователь взаимодействует со страницей:
Var Navigation = Backbone.View.extend({ "events": { "click .header.menu": "toggleMenu" }, "toggleMenu": function() { // … } });
Итак, должен быть элемент, соответствующий селектору.header.menu , и когда пользователь на нём кликнет, мы должны показать или скрыть меню. Проблема такого подхода в том, что мы привязываем объект JavaScript к конкретному элементу DOM. Если мы захотим подредактировать разметку и заменить.menu на.main-menu , нам придётся поправить и JavaScript. Я считаю, что контроллеры должны быть независимыми, и не следует их жёстко сцеплять с DOM.
Определяя функции, мы делегируем задачи класса JavaScript. Если эти задачи - обработчики событий DOM, есть смысл создавать их из HTML.
Мне нравится, как AngularJS обрабатывает события.
click me
go - это функция, зарегистрированная в нашем контроллере. Если следовать такому принципу, нам не нужно задумываться о селекторах DOM. Мы просто применяем поведение непосредственно к узлам HTML. Такой подход хорош тем, что он спасает от скучной возни с DOM.
В целом, я был бы рад, если бы такая логика была внутри HTML. Интересно, что мы потратили кучу времени на то, чтобы убедить разработчиков разделять содержимое (HTML) и поведение (JavaScript), мы отучили их встраивать стили и скрипты прямо в HTML. Но теперь я вижу, что это может сберечь наше время и сделать наши компоненты более гибкими. Разумеется, я не имею в виду что-то такое:
banner text
Я говорю о наглядных атрибутах, которые управляют поведением элемента. Например:
…
Это не должно выглядеть, как программирование на JavaScript в HTML, скорее это должно быть похоже на установку конфигурации.
Управление зависимостямиУправление зависимостями - важная задача в процессе разработки. Обычно мы зависим от внешних функций, модулей или библиотек. Фактически, мы всё время создаём зависимости. Мы не пишем всё в одном методе. Мы разносим задачи приложения в различные функции, а затем их соединяем. В идеале мы хотим инкапсулировать логику в модули, которые ведут себя как чёрные ящики. Они знают только те детали, которые касаются их работы, и больше ничего.
RequireJS - один из популярных инструментов разрешения зависимостей. Идея состоит в том, что код оборачивается в замыкание, в которое передаются необходимые модули:
Require(["ajax", "router"], function(ajax, router) { // … });
В этом примере функции требуется два модуля: ajax и router . Магический метод require читает переданный массив и вызывает нашу функцию с нужными аргументами. Определение router выглядит примерно так:
// router.js define(["jquery"], function($) { return { "apiMethod": function() { // … } } });
Заметьте, тут ещё одна зависимость - jQuery. Ещё важная деталь: мы должны вернуть публичное API нашего модуля. Иначе код, запросивший наш модуль, не сможет получить доступ к самой функциональности.
AngularJS идёт немного дальше и предоставляет нам нечто под названием фабрика . Мы регистрируем там свои зависимости, и они волшебным образом становятся доступными в контроллерах. Например:
MyModule.factory("greeter", function($window) { return { "greet": function(text) { $window.alert(text); } }; }); function MyController($scope, greeter) { $scope.sayHello = function() { greeter.greet("Hello World"); }; }
Вообще говоря, такой подход облегчает работу. Нам не надо использовать функций вроде require для того чтобы добраться до зависимости. Всё, что требуется, - напечатать правильные слова в списке аргументов.
Ладно, оба эти способа внедрения зависимостей работают, но каждый из них требует своего стиля написания кода. В будущем я хотел бы увидеть фреймворки, в которых это ограничение снято. Было бы значительно изящнее применять метаданные при создании переменных. Сейчас язык не даёт возможности это сделать. Но было бы круто, если бы можно было делать так:
Var router:;
Если зависимость будет находиться рядом с определением переменной, то мы можем быть уверены, что внедрение этой зависимости производится, только если она нужна. RequireJS и AngularJS, к примеру, работают на функциональном уровне. То есть, может случиться так, что вы используете модуль только в определённых случаях, но его инициализация и внедрение будут происходить всегда. К тому же, мы можем определять зависимости только в строго определённом месте. Мы к этому привязаны.
ШаблоныМы часто пользуемся шаблонами. И мы делаем это из-за необходимости разделять данные и разметку HTML. Как же современные фреймворки работают с шаблонами? Вот самые распространённые подходы:
Шаблон определён в Hello, !Такой подход часто используется, потому что шаблоны находятся в HTML. Это выглядит естественно и не лишено смысла, раз уж в HTML есть теги. Браузер не отрисовывает содержимое элементов , и покорёжить внешний вид страницы это не может.
Шаблон загружается через AJAX Backbone.View.extend({ "template": "my-view-template", "render": function() { $.get("/templates/" + this.template + ".html", function(template) { var html = $(template).tmpl(); }); } });Мы положили свой код во внешние файлы HTML и избежали использования дополнительных тегов . Но теперь нам нужно больше запросов HTTP, а это не всегда уместно (по крайней мере, пока поддержка HTTP2 не станет шире).
Шаблон является частью разметки - фреймворк получает его из DOM-дерева. Этот метод опирается на уже сгенерированный HTML. Нам не нужно делать дополнительных HTTP запросов, создавать новые файлы или дополнительные элементы .
Шаблон - часть разметки страницы var HelloMessage = React.createClass({ render: function() { // Обратите внимание: следующая строка кода // не является корректным JavaScript. return Hello {this.props.name}; } });Такой подход был введён в React, там используется собственный парсер, который превращает невалидную часть JavaScript в валидный код.
Шаблон - не HTMLНекоторые фреймворки вообще не используют HTML напрямую. Вместо этого шаблоны хранятся в виде JSON или YAML.
Напоследок о шаблонахХорошо, а что дальше? Я ожидаю, что с фреймворком будущего мы будем рассматривать данные отдельно, а разметку отдельно. Чтобы они не пересекались. Мы не хотим иметь дело с загрузкой строк в HTML или с передачей данных в специальные функции. Мы хотим присваивать значения переменным, а DOM чтобы обновлялся сам. Распространённое двустороннее связывание не должно быть чем-то дополнительным, это должно быть обязательной базовой функциональностью.
Вообще, поведение AngularJS ближе всего к желаемому. Он считывает шаблон из содержимого предоставленной страницы, и в нём реализовано волшебное двустороннее связывание. Впрочем, оно ещё не идеально. Иногда наблюдается мерцание. Это происходит, когда браузер отрисовывает HTML, но загрузочные механизмы AngularJS ещё не запустились. К тому же, в AngularJS применяется грязная проверка того, поменялось ли что-нибудь. Такой подход порой очень затратен. Надеюсь, скоро во всех браузерах будет поддерживаться Object.observe , и связывание будет лучше.
Рано или поздно каждый разработчик сталкивается с вопросом динамических шаблонов. Наверняка, в наших приложениях есть части, которые появляются после загрузки. С фреймворком это должно быть просто. Мы не должны задумываться об AJAX-запросах, а API должно быть таким, чтобы процесс выглядел синхронным.
МодульностьМне нравится, когда возможности можно включать и выключать. A если мы чем-то не пользуемся, зачем держать это в коде проекта? Было бы хорошо, если у фреймворка был бы сборщик, который генерирует версию с только необходимыми модулями. Как, например YUI , у которого есть конфигуратор. Мы выбираем те модули, которые хотим, и получаем минифицированный и готовый к использованию файл JavaScript.
Даже так, существуют фреймворки, у которых есть нечто, называемое ядром . Вдобавок к нему мы можем использовать пачку плагинов (или модулей). Но мы могли бы это улучшить. Процесс выбора нужных возможностей не должен включать в себя загрузку файлов. Мы не должны их вручную подключать на странице. Это каким-то образом должно быть частью кода фреймворка.
Помимо адекватных возможностей при установке, идеальная среда должна предусматривать расширяемость. У нас должна быть возможность писать собственные плагины и делиться ими с другими разработчиками. Другими словами, среда должна быть благоприятной для написания модулей. Не получится создать сильное сообщество без существования подходящих условий для разработчиков.
Открытое APIБольшая часть фреймворков предоставляют API к своей базовой функциональности. Но при помощи этих API можно добраться только к тем частям, которые поставщики посчитали нужными для нас. И вот тут могут понадобиться хаки. Мы хотим что-то получить, но для этого нет подходящих инструментов. И приходится идти на хитрости и двигаться в обход. Рассмотрим такой пример:
Var Framework = function() { var router = new Router(); var factory = new ControllerFactory(); return { "addRoute": function(path) { var rData = router.resolve(path); var controller = factory.get(rData.controllerType); router.register(path, controller.handler); return controller; } } }; var AboutCtrl = Framework.addRoute("/about");
У такого фреймворка есть встроенный маршрутизатор. Мы определяем путь, и контроллер инициализируется автоматически. Когда пользователь посещает определённый URL, маршрутизатор вызывает у конструктора метод handler . Это здорово, но что если нам нужно выполнять небольшую функцию JavaScript при совпадении URL? По какой-то причине, мы не хотим создавать дополнительный контроллер. С текущим API такое не получится.
Мы могли бы сделать по-другому, например, вот так:
Var Framework = function() { var router = new Router(); var factory = new ControllerFactory(); return { "createController": function(path) { var rData = router.resolve(path); return factory.get(rData.controllerType); } "addRoute": function(path, handler) { router.register(path, handler); } } } var AboutCtrl = Framework.createController({ "type": "about" }); Framework.addRoute("/about", AboutCtrl.handler);
Заметьте, маршрутизатор не торчит наружу. Его не видно, но теперь мы можем управлять как созданием контроллера, так и регистрацией пути в маршрутизаторе. Разумеется, предложенный вариант подходит для нашей конкретной задачи. Но он может оказаться излишне сложным, потому что контроллеры тут приходится создавать вручную. При разработке API мы руководствуемся принципом единственной обязанности и рассуждением делай что-то одно, и делай это хорошо . Я вижу, как всё больше и больше фреймворков децентрализуют свою функциональность. В них сложные методы делятся на более мелкие части. И это хороший признак, я надеюсь, в будущем больше фреймворков будет так делать.
ТестируемостьНет нужды убеждать вас в необходимости писать тесты для кода. Дело даже не только в том, что надо писать тесты, а в том, что надо писать код, который возможно покрыть тестами. Иногда это невероятно сложно и занимает много времени. Я убеждён, что если мы на что-то не напишем тесты, даже на что-то очень маленькое, то именно в этом месте в приложении начнут плодиться баги. Это в особенности касается JavaScript на клиентской стороне. Несколько браузеров, несколько операционных систем, новые спецификации, новые возможности и их полифилы - да куча причин начать практиковать разработку через тестирование.
Есть ещё кое-что, что мы получим от тестов. Мы не только убеждаемся в том, что наш фреймворк (приложение) работает сегодня. Мы убеждаемся, что он будет работать завтра и послезавтра. Если есть какая-то новая возможность, которую мы привносим в код, мы пишем для неё тесты. И очень важно, что мы делаем так, чтобы эти тесты проходились. Но так же важно, чтобы проходились и предыдущие тесты. Именно так мы гарантируем, что ничего не сломалось.
Я с радостью бы увидел больше стандартизованных утилит и методов для тестирования. Мне хотелось бы использовать одну утилиту для тестирования всех фреймворков. Было бы ещё хорошо, если бы тестирование было как-то включено в процесс разработки. Следует обратить больше внимания на сервисы вроде Travis CI . Они работают как индикатор не только для того программиста, который вносит изменения, но также и для других контрибьюторов.
Я всё ещё работаю с PHP. Мне приходилось иметь дело с фреймворками вроде WordPress. И множество людей спрашивало меня, как я тестирую свои приложения: какой фреймворк я использую, как я запускаю тесты, есть ли у меня вообще компоненты. Правда в том, что я ничего не тестирую. И всё потому у меня нет компонентов. То же самое относится и некоторым фреймворкам на JavaScript. Некоторые их части тяжело тестировать, потому что они не дробятся на компоненты. Разработчикам следует подумать и в этом направлении. Да, они предоставляют нам умный, изящный и рабочий код. Но код должен быть ещё и тестируемым.
ДокументацияЯ уверен, что без хорошей документации любой проект рано или поздно загнётся. Каждую неделю выходит куча фреймворков и библиотек. Документация - это первое, что видит разработчик. Никто не хочет тратить часы на то, что узнать, что делает определённая утилита, и какие у неё возможности. Недостаточно простого перечисления основной функциональности. Особенно для большого фреймворка.
Я бы разделил хорошую документацию на три части:
- Что я могу сделать - документация должна учить пользователя и должна делать это правильно. Неважно, насколько крутой или мощный у нас фреймворк, он нуждается в объяснении. Кто-то предпочитает смотреть видео, кто-то читать статьи. В любом случае, разработчику нужно показать всё, начиная с самых основ и заканчивая сложными частями фреймворка.
- Документация API - это обычно есть везде. Полный список всех публичных методов API, того, какие у них параметры и что они возвращают. Может быть, примеры использования.
- Как это работает - обычно этого раздела в документациях нет. Хорошо, если бы кто-нибудь разъяснил структуру фреймворка, даже простая схема базовой функциональности и её взаимосвязи уже бы помогла. Это сделало бы код прозрачным. Это помогло бы тем разработчикам, которые хотят внести свои изменения.
Будущее, конечно, тяжело предугадать. Но зато мы можем о нём помечтать! Важно говорить о том, что мы ожидаем и что мы хотим от фреймворков на JavaScript! Если у вас есть замечания, предложения или вы хотите поделится своими мыслями, пишите в Твитер с хештегом
Алины Архиповой “JavaScript Frameworks: How To Make Your Choice”.
JavaScript это одна из базовых технологий во всемирной паутине. Как следует из результатов опроса , JavaScript является топовым языком среди фронтенд-разработчиков, и не похоже, чтобы он терял популярность. Вот почему сегодня существует так много фреймворков JavaScript, что сложно понять, какой из них самый эффективный.
Чем больше появляется фреймворков, тем больше вокруг них споров. В сообществе разработчиков много говорится о том, какие фреймворки наиболее эффективны для фронтенд-разработки. Основываясь на нашем исследовании, мы определили пятерку самых обсуждаемых фреймворков JavaScript. Их мы и описали в этой статье. Также в ней мы поделимся опытом Yalantis: расскажем о том, какие фреймворки предпочитают наши фронтенд-разработчики.
Обзор популярных фреймворков JavaScriptКаждый месяц выходит новый JavaScript-фреймворк. У собственников продуктов могут возникнуть сложности с выбором. Фреймворки это необходимые . Их задача состоит в ускорении и облегчении рабочего процесса, а также в повышении его продуктивности. Поэтому выбор фреймворка сильно влияет на эффективность и производительность процесса разработки. Давайте сравним топовые фреймворки JavaScript.
AngularAngular это полнофункциональный фреймворк, выпущенный в 2010 году Google. Компания продолжает регулярный выпуск обновлений. Например, в марте 2018 последняя версия, Angular 6, принесла много улучшений, включая новый движок рендеринга для более быстрых и меньших по размеру приложений.
Сегодня Angular это один из самых популярных фронтенд-фреймворков. Многие разработчики выбирают Angular, поскольку рассматривают его как ключ к упрощению разработки. Благодаря его шаблонам специалисты по фронтенду могут с легкостью использовать Angular для создания динамических одностраничных веб-приложений со множеством изменяемых данных. Кроме того, в Angular есть Model-View-Controller (MVC, «Модель-Представление-Контроллер»), делающий тестирование более простым и доступным.
React.jsReact.js это фреймворк, выпущенный командой Facebook в 2013 году. Крупные компании, включая Dropbox, PayPal, BBC, Atlassian и Instagram используют React в качестве основного инструмента фронтенда.
React прекрасно подходит для приложений и сайтов со сложной логикой представления. React также позволяет повторное использование компонентов в рамках приложения, благодаря чему разработчикам не приходится снова и снова создавать похожие компоненты. С помощью React разработчики могут фокусироваться на создании сложного функционала. Благодаря специальному алгоритму согласования под названием Virtual DOM, фронтенд-разработчики получают значительное увеличение производительности. Они могут разрабатывать быстрее, поскольку им не нужно обновлять представления после каждого небольшого изменения.
Vue.jsVue.js это довольно новый фреймворк JavaScript, созданный Эваном Ю. Его главная цель – сделать разработку пользовательского интерфейса более организованной.
Многие специалисты по фронтенду утверждают, что это превосходный инструмент для новичков. Он очень прост для понимания, поскольку фокусируется на слоях представления. Vue.js работает без Babel – транспилятора, конвертирующего код JavaScript в старую версию ES5, которая запускается во всех браузерах. Отказ от использования Babel ускоряет разработку. Шаблоны Vue.js это валидный HTML, поэтому интеграция проходит легко. Этот фреймворк является хорошим решением для разработки легковесных приложений.
Ember.jsФреймворк Ember.js был создан в 2011 году. Он был использован при создании сайтов многих хорошо известных компаний, включая Kickstarter, Heroku и LinkedIn.
Ember.js регулярно обновляется и обеспечивает полный пакет функций. Этот фреймворк эффективен для разработки сложных веб-приложений, а его система шаблонов, основанная на строках, способствует ускорению загрузки. Ember.js сконцентрирован на масштабируемости, поэтому разработчики могут с легкостью работать как с мобильными, так и с веб-проектами.
Next.jsNext.js это необычный JavaScript-фреймворк. Он был разработан командой React в качестве дополнительного инструмента для рендеринга на стороне сервера. При работе с React и Next.js процесс разработки становится проще, как при использовании Vue.js.
Next.js имеет такие достойные упоминания особенности как автоматическое разделение кода и маршрутизация на основе страницы на стороне клиента. Кроме того, Next.js имеет полную поддержку CSS (под названием styled-jsx) для значительного облегчения стилизации интерфейса пользователя.
У этих пяти популярных библиотек и фреймворков JavaScript есть много общего. Например, все они имеют эффективную компонентную архитектуру и систему документации. Обеспечиваемый ими функционал нацелен на уменьшение времени разработки, что выгодно как собственникам продукта, так и разработчикам.
Выбор лучшего фреймворка для построения UI всегда должен зависеть от спецификации проекта, а также от навыков разработчика. Сейчас мы расскажем, что выбирают разработчики в Yalantis.
Какие фреймворки выбирают фронтенд-разработчики YalantisКоманда по фронтенд-разработке в Yalantis часто работает с JavaScript-фреймворками. За последние несколько лет мы испытали разнообразные фреймворки, чтобы найти наиболее эффективный и выгодный инструмент.
Сегодня мы предпочитаем работать с двумя хорошо известными фреймворками JavaScript – Angular и React. Но почему именно с этими двумя? Давайте рассмотрим подробнее функционал, который они предлагают фронтенд-разработчикам.
AngularКоманда Google разработала один из наиболее востребованных на сегодняшний день фреймворков JavaScript. Angular приобрел заметную популярность благодаря поддержке двустороннего связывания данных, эффективным шаблонам и простой документации.
Эффективная система, основанная на компонентах. Компоненты и директивы заменили контроллеры и области применения в качестве основных блоков приложений. Классы компонентов это отдельные блоки, что делает их многоразовыми и легко добавляемыми в существующие приложения.
Двустороннее связывание данных. Эта особенность уменьшает количество времени, необходимого для написания кода. Разработчики могут вносить изменения в модели и представления одновременно, без ожидания, пока произойдет рендеринг UI-элементов.
TypeScript. Обучающие ресурсы и документация по Angular основаны на TypeScript, поэтому его трудно избежать. TypeScript некоторым разработчикам может показаться сложным, но ничего плохого в нем нет. Многие новые фичи становятся гораздо быстрее доступны для TypeScript, чем для других языков. Больше того, TypeScript обеспечивает шаблоны объектно-ориентированного программирования и опциональную статическую проверку типов, что полезно для больших приложений.
Удобные шаблоны. Шаблоны в Angular представлены в HTML, так что разработчики могут создавать функциональные приложения даже если они не слишком хорошо знают JavaScript. Браузер обрабатывает шаблоны и генерирует инструкции рендеринга, также известные как директивы.
Простая документация. Вся официальная документация по Angular короткая и простая, поэтому даже не слишком опытные разработчики могут быстро освоить основы.
Поддержка сильного сообщества. Фреймворк Angular это продукт Google, поэтому естественно, что у него много поклонников и людей, которые его поддерживают. Разработчики могут с легкостью найти множество советов в блогах и на форумах.
Подобьем итоги. Фреймворк Angular это топовый инструмент для фронтенд-разработки, предоставляющий много разных функций. Создание приложений с помощью Angular выгодно и бизнесу, и разработчикам. Прежде всего, Angular поддерживается Google, так что этот фреймворк регулярно обновляется, а его функционал постоянно совершенствуется. Во-вторых, в отличие от многих других фреймворков, Angular доступен под лицензией MIT. Для бизнеса и разработчиков важно использовать лицензированные инструменты, поскольку они более надежны.
ReactReact это революционный JavaScript-фреймворк, который занимает лидирующие позиции в рейтингах фреймворков JavaScript. Он очень популярен среди пользователей GitHub, которые дали ему больше 95 тысяч звезд. Но что делает React таким особенным?
Повышенная производительность. В React есть уникальная особенность под названием Virtual DOM, которая повышает эффективность написания кода. Когда разработчики делают небольшие изменения, им не нужно обновлять представление полностью. Изменения проходят через Virtual DOM, который делает повторный рендеринг только нужной части страницы. Такой подход занимает меньше времени и сохраняет силы разработчиков.
JSX. Декларативный синтаксис JavaScript, который помогает создавать аккуратный и читаемый код. JSX также помогает комбинировать компоненты в один исполняемый файл.
Легкость изучения. Если разработчики знают JavaScript, они могут сразу приступать к использованию React. Разработчики могут пропустить мануалы, поскольку React прост и хорошо организован. Чтобы стать специалистом по React, вам нужно будет познакомиться с JSX.
Компоненты, которые можно использовать повторно. React, как и Angular, имеет основанную на компонентах архитектуру. Это означает, что при использовании фреймворка React разработчики могут рассматривать компоненты как строительные блоки для приложения. Самое большое преимущество этого в том, что готовые компоненты могут быть использованы в различных частях приложения. Это повышает скорость разработки.
Поддержка Facebook и сообщества. React курируется одним их технологических гигантов – Facebook. Команда Facebook знает, как работать со сложными веб-приложениями, поэтому фреймворк React ориентирован на увеличении производительности. Сообщество React одно из самых больших (если сравнивать с сообществами других популярных фреймворков для фронтенд-разработки). Есть много блогов, плагинов и SDK, имеющих отношение к React. Поэтому, если у разработчика возникнут какие-либо проблемы с этим фреймворком, он может с легкостью найти ответы в интернете.
В общем, фреймворк React это эффективный инструмент для разработки интерфейса пользователя. Его функционал улучшает разработку путем снижения времени, нужного для написания кода, а это большое преимущество для бизнеса и разработчиков. Кроме того, React легок в изучении, так что разработчики могут начинать использовать его без предварительной подготовки. Наконец, у него есть отличная поддержка сообщества и Facebook, поэтому у этого фреймворка точно будут обновления и новые интересные функции.
Мы описали пять топовых фреймворков JavaScript, но выбор за вами. При принятии решения сравнивайте производительность, архитектуру, кривую обучения, документацию, организацию и поддержку сообщества.
Логика, улучшающая быстродействие, находится внутри метода update:
"update": function(list) { for (var i = 0; i < list.length; i++) { if (!this.rows[i]) { var row = document.createElement("LI"); row.textContent = list[i]; this.rows[i] = row; this.list.appendChild(row); } else if (this.rows[i].textContent !== list[i]) { this.rows[i].textContent = list[i]; } } if (list.length < this.rows.length) { for (var i = list.length; i < this.rows.length; i++) { if (this.rows[i] !== false) { this.list.removeChild(this.rows[i]); this.rows[i] = false; } } } return this; }
Первый цикл for проходит по всем переданным строкам и создаёт при необходимости элементы
