Если вы посмотрите на историю настольных приложений, то увидите, что она началась с мощных серверов, которые могли отправлять текстовые экраны тонким клиентам.
Тонкие клиенты выдали команду, которую сервер обработал, а затем отправил клиенту новый экран.
Со временем оборудование стало дешевле, и мы пришли к нынешней модели, в которой клиент выполняет большую часть работы и взаимодействует с сервером только для получения информации, ее хранения или выдачи команды, которую необходимо выполнить в безопасном, контролируемом месте.
среда.
Если задуматься, тогда разработка была проще из-за того, что все пользователи были одинаково ограничены аппаратным обеспечением.
К сожалению (для разработчиков), ограничения, налагаемые этой моделью, совершенно неприемлемы и для конечных пользователей.
Им нужен отзывчивый, быстрый, красивый софт, что практически невозможно в среде, где каждое маленькое действие приводит к запросу-ответу на удаленный сервер.
Ээволюция веб-интерфейсов
Вы можете увидеть аналогичную эволюцию в веб-разработке.Мы находимся в состоянии смены парадигмы, и чем дальше мы идем, тем сложнее будет приложениям, написанным в старой парадигме.
Зачем использовать что-то неадаптивное и малоинтерактивное, если у нас есть альтернативы, которые от этого избавляются? Архитектура пользовательского интерфейса — очень сложная проблема проектирования, и хотя крупные компании на протяжении многих лет вкладывали миллионы долларов в ее решение, у нас до сих пор нет «единственного правильного пути» для ее решения.
Многие фреймворки JavaScript «MVC» (это почти такой же плохой термин, как и серверные фреймворки MVC) появились за последние несколько лет и фундаментально отличаются в том, как они применяют идеи архитектуры пользовательского интерфейса за последние 50 лет в Интернете.
Выбор фреймворка
Мы попробовали множество фреймворков, но для краткости я расскажу о четырех самых популярных: Backbone, Ember, Knockout и Angular. Прежде чем начать, хочу сказать, что все это действительно потрясающие проекты, заслужившие популярность.В разработке не существует такого понятия, как «серебряная пуля», подходящая для всех ситуаций и проблем, и каждая из этих структур имеет свои сильные и слабые стороны.
Наша ситуация
У нас есть (приблизительно) 250 тысяч строк кода промышленных приложений Rails. Большую часть своей жизни он следовал «Пути Rails», и мы извлекли из него много уроков.Приложение содержит нереальное количество бизнес-логики.
Таким образом, масштабируемость и гибкость были двумя ключевыми критериями, которыми мы руководствовались при выборе платформы.
Эмбер.
js Судя по документации и разговорам Иегуда Каца (wycats) об Ember.js, по сути, это попытка сделать Rails клиентской частью.
Ember — самая амбициозная платформа, доступная на данный момент, и ее сильные стороны очевидны.
Это лишает вас выбора в ряде случаев, а это может быть весьма удобно.
В частности, мне нравится их подход к маршрутизации (StateManager), я считаю, он намного лучше других реализаций.
Слабость Эмбера является результатом его сильных сторон; Если вы не хотите идти по пути Эмбера, вас ждут трудные времена.
Если вы столкнулись с проблемой, вы имеете дело с чрезвычайно сложной структурой и, вероятно, не сможете быстро решить проблему.
Ember только что вышел на версию 1.0 и в ближайшие годы существенно изменится.
С фреймворками, которые имеют такой уровень присутствия во всех аспектах вашего кода, обновление может стать тяжелым испытанием (нам потребовалось больше года, чтобы завершить обновление Rails до версии 3).
Последней каплей для меня стало то, насколько Эмбер контролирует вашу архитектуру.
У нас достаточно навыков, чтобы сделать собственный выбор, поэтому я думаю, что работать с чем-то, что накладывает на нас столько ограничений, — это плохой выбор.
Angular.js
Angular придерживается подхода, согласно которому в HTML и JavaScript отсутствуют ключевые моменты, которые делают его более подходящим для создания сложных интерфейсов.В случае с JavaScript вам нужны наблюдаемые.
В HTML недостающим элементом является некая форма шаблонов.
Поскольку оба языка являются расширяемыми, Angular добавляет такие возможности.
Я большой поклонник Angular. Он обеспечивает прозрачное разделение между представлениями и бизнес-логикой, компонентную реализацию, сочетающую поведение и структуру — то, что действительно нужно современному Интернету.
Он также содержит структуру внедрения зависимостей, которую многие разработчики считают ненужной, но я думаю, что это хорошая идея.
Я перестал соглашаться с тем, как реализованы шаблоны.
Я занимаюсь веб-разработкой с 2000 года и за это время заметил сильную тенденцию различать три части веб-технологий: стиль, поведение и структуру.
Я видел это движение (и был его участником) и считаю, что вещи, поощряющие поведение в HTML и HTML в JavaScript, — плохой путь.
В конце концов, какая разница между
Иonclick="foo();"
ng-click="foo();"
В такой среде, как XCode, у меня нет проблем с этим стилем привязки к представлению, поскольку «представление» для меня — это не код, а поверхность проектирования.
Но поскольку мы строим веб по-другому, я считаю, что это плохое направление для развития.
Я бы даже не посчитал это слабостью, скорее разницей в подходе.
Я думаю, что слабыми сторонами Angular являются: громоздкий API, тот факт, что веб-стандарты развиваются в другом направлении, чем Angular, и тот факт, что абстракции довольно хрупкие.
Оказаться за пределами регламентированного мира Angular, когда нужно глубокое понимание того, как он работает и куда/как вернуться, довольно легко.
Решающим недостатком для меня было то, насколько сложно создать собственную директиву, что я считаю самой ценной особенностью всего фреймворка.
За всю мою карьеру единственная платформа, которая была близка к уровню боли при попытке расширения, — это серверные элементы управления в ASP.net WebForms. Это решаемая проблема, и я думаю, что если бы мы сейчас были на том этапе, когда Angular достиг второй или третьей версии, это был бы мой выбор.
Нокаут.js
Knockout использует подход, вдохновленный Microsoft MVVM, к интерфейсу.У них есть мощный язык для привязки данных и привязки HTML для просмотра моделей.
У них есть базовый роутер и все.
Knockout — это не столько «фреймворк», сколько хорошая библиотека для привязки данных.
Я думаю, что идеальное использование Knockout — это когда вы создаете «гибридное» приложение, где у вас есть взаимодействие между перезагрузками страниц, но сервер по-прежнему хранит большую часть логики.
Если это ваш случай, то у вас скромные потребности на стороне клиента, и разделение состояния и поведения, вероятно, вам нужно.
Слабость Knockout в том, что если вам понадобится значительный объем клиентской логики, это будет частью его решения.
Backbone.js
Backbone — самая популярная фронтенд-библиотека такого типа, но и самая простая.Философия Backbone заключается в предоставлении минимального набора вещей, необходимых для структурирования внешнего кода в сети.
Вы можете научиться использовать Backbone очень быстро (и прочитать кодовую базу от начала до конца за час) благодаря его простоте.
Вам следует использовать Backbone, когда ваши потребности скромны (или изначально умерены, но медленно растут).
Backbone — это скорее философия, чем фреймворк.
У Backbone также удивительно активное сообщество, а это означает, что вы можете «создать свою собственную структуру», выбирая из множества сторонних расширений и библиотек.
Backbone очень JavaScript-y, то есть если вы понимаете язык, на котором пишете, вы поймете и фреймворк, поскольку он все делает в стиле JavaScript. Слабость Backbone в том, что он сам по себе мало что делает, и вы окажете себе медвежью услугу, если не знаете, что к нему подключить.
Эта «совместимость с JavaScript» также может быть помехой, поскольку многие «веб-разработчики» мало разбираются в веб-технологиях, и если вы один из них, с Backbone можно легко запутаться.
Позвоночник.
Марионетка Марионетт утверждает, что, хотя Backbone предлагает минимум для структурирования приложений любого типа, большие приложения в конечном итоге содержат много шаблонного кода.
Marionette предоставляет структуру, необходимую для приложений такого типа, а также дает рекомендации по организации больших объемов кода.
Причина, по которой мы выбрали Marionette, — их подход к организации кода, очень похожий на наш; разделение больших блоков кода на более мелкие, которые взаимодействуют друг с другом с помощью четко определенных и простых интерфейсов.
Разделите управление и вычисления, сделайте код представления максимально декларативным, а управление кодом — максимально высокоуровневым.
А также следовать устоявшимся шаблонам работы с большими и сложными базами кода.
Marionette решает самую большую проблему Backbone — весь этот шаблонный код в представлениях.
Также легко построить собственную архитектуру компонентов (что сейчас в Angular слишком сложно) и получить минимальную структуру для всего, что вам нужно (в отличие от Knockout).
Потребуется поработать над доработкой хорошей архитектуры и созданием инфраструктуры, но, учитывая наши потребности и текущее состояние других библиотек, я думаю, что это хороший компромисс.
Пользовательский интерфейс сложен и нет серебряной пули
Это оценка конкретной ситуации и точки зрения, и я считаю, что она имеет смысл для нашего продукта и нашей команды разработчиков.Как я уже говорил вначале, все эти варианты отлично подходят для своих целей.
Если кто-то скажет вам: «Я использовал фреймворк X, и он был плох, но теперь я использую фреймворк Y, и у меня такое ощущение, будто я еду по солнечным полям на волшебном коне», вероятно, он просто сделал неправильный выбор в первый раз.
время.
Оригинал Мэтт Бриггс.
Теги: #backbone #марионетка #ember #angular #knockout #разработка сайтов #JavaScript
-
Назад К Основам 3D
19 Oct, 24 -
Дайте Пожалуйста Отзыв, Кто Понизил Карму.
19 Oct, 24 -
Взломать. Спать. Повторить
19 Oct, 24 -
Спящий Режим Для Начинающих
19 Oct, 24
