Если глянуть на историю развития десктоп приложений, видно, что она начиналась с мощных серверов, которые могли слать экраны текста тонким клиентам. Тонкие клиенты давали команду, которую обрабатывал сервер и потом слал новый экран обратно клиенту.
С течением времени, оборудование стало дешевле и мы пришли к текущей модели, когда клиент делает значительную часть работы, а общается с сервером только для того, чтобы получить информацию, сохранить информацию или дать команду, которая должна быть запущена в защищенном, контролируемом окружении.
Теперь, если подумать, в те времена разрабатывать было проще, из-за того, что все пользователи были одинаково ограничены аппаратной частью.
К несчастью (для разработчиков), ограничения, наложенные этой моделью, также полностью неприемлемы для конечных пользователей. Они хотят отзывчивое, быстрое, красивое ПО, что почти неосуществимо в условиях, когда любое небольшое действие ведет к запросу-ответу на удаленный сервер.
Вы можете увидеть похожую эволюцию в веб-разработке. Мы находимся в состоянии изменения парадигм, и чем дальше, тем сложнее будет приложениям написанным в старой парадигме. Зачем использовать то, что не отзывчиво и дает небольшую интерактивность, когда у нас есть альтернативы избавленные от этого?
UI архитектура это очень тяжелая проблема дизайна, и даже если большие компании годами вкладывали миллионы долларов в ее решение, у нас до сих пор даже близко нету “Одного правильного пути” чтобы сделать это. Много JavaScript “MVC” фреймворков (это почти такой же плохой термин как серверные MVC фреймворки) появились на протяжении последних лет и принципиально отличаются в том как применить идеи UI архитектуры последних 50 лет к вебу.
Мы попробовали множество фреймворков, но для краткости, я опишу четыре наиболее популярных: Backbone, Ember, Knockout, и Angular.
Перед тем как начать, я хочу сказать что все это действительно потрясающие проекты имеющие заслуженную популярность. Нету такой вещи как “Серебряная пуля” в разработке, которая была бы хороша во всех ситуациях и проблемах, и каждый из этих фреймворков имеет сильные и слабые стороны.
У нас (приблизительно) 250 тысяч строк кода промышленного Rails приложения. Оно провело большую часть своей жизни следуя “Пути Rails”, и мы получили из этого множество уроков. В приложении прописано нереальное количество бизнес логики. Таким образом, масштабируемость и гибкость были двумя ключевыми критериями, которыми мы руководствовались при выборе фреймворка.
Исходя из документации и разговоров Yehuda Katz (wycats) о Ember.js, это в основном попытка сделать Rails на стороне клиента.
Ember самый амбициозный из доступных сейчас фреймворков и его сильные стороны очевидны. Он лишает вас возможности выбора в ряде случаев и это бывает достаточно удобно. В частности, мне нравится их подход к роутингу (Менеджер состояний / StateManager), мне кажется это гораздо лучше остальных реализаций.
Слабая сторона Ember — это результат его преимуществ; если вы не хотите идти по пути Ember — для вас наступают тяжелые времена. Если вы сталкиваетесь с проблемой, то имеете дело с чрезвычайно комплексным фреймворком, и, скорее всего, не сможете быстро решить проблему. Ember только достиг версии 1.0 и еще значительно изменится в ближайшие годы. С фреймворками которые имеют такой уровень присутствия в каждом аспекте вашего кода, обновление может стать тяжелым испытанием (у нас ушло больше года чтоб закончить апгрейд Rails до третьей версии).
Последней каплей для меня стало то, какой контроль Ember выполняет за вашей архитектурой. У нас достаточно навыков, чтобы делать собственный выбор, поэтому я считаю, что работа с тем что накладывает на нас столько ограничений это плохой выбор.
Angular использует подход согласно которому в HTML и JavaScript отсутствуют ключевые вещи делающие его более подходящими для создания сложных интерфейсов. В случае JavaScript, то что нужно — это наблюдаемые объекты. Для HTML недостающая часть это некая форма шаблонизации. Так как оба являются расширяемыми языками, то что делает Angular — это добавляет такие возможности.
Я большой фан Angular. Он предоставляет прозрачное разделение между представлениями и бизнес логикой, компонентную реализацию, совмещающую поведение и структуру — то, в чем действительно нуждается нынешний веб. Он также содержит внедрение зависимости (Dependency Injection framework), то, что многие разработчики считают излишним, но я думаю это хорошая идея.
Место, когда я перестал соглашаться, это то, как реализована шаблонизация. Я занимаюсь веб разработкой с 2000 года, и за это время я видел устойчивую тенденцию разграничивать три части веб технологии: стиль, поведение и структура. Я видел (и был частью) этого движения и я думаю вещи, которые поощряют поведение в HTML и HTML в JavaScript — это плохой путь. В конце концов, какая разница между
и
В окружении вроде XCode, у меня нет проблем с таким стилем привязки в представлении, так как “представление” это не код для меня, а поверхность дизайна. Но с тех пор как мы по другому строим веб, я считаю это плохим направлением развития.
Я бы даже не считал это слабостью, скорее различием подходов. Я думаю слабость Angular это: громоздкое API, факт того что веб-стандарты идут в другом направлении, чем Angular, и то, что абстракции достаточно хрупкие. Достаточно легко оказаться за пределами регулируемого Angular мира, когда понадобится глубокое понимание того как это работает, и где/как вернутся обратно.
Решающим минусом для меня стало, насколько сложно сделать собственную директиву (directive), что я считаю самой ценной возможностью всего фреймворка. За всю мою карьеру, единственная платформа которая приблизилась по уровню мучений при попытке расширить ее, это серверные элементы управления в ASP.net WebForms. Это решаемая проблема, и я думаю если бы мы сейчас были в точке где Angular достиг второй или третьей версии, это был бы мой выбор.
Knockout применяет вдохновленный Microsoft MVVM подход к фронтенду. У них есть мощный язык для связывания данных (databinding), и привязки html к моделям представлений (view models). У них есть базовый роутер, и это все. Knockout не столько “фреймворк”, сколько хорошая библиотека для связывания данных.
Я думаю идеальное примение Knockout — это когда вы делаете “гибридное” приложение, когда у вас есть взаимодействие между перезагрузками страниц, но сервер по прежнему держит большинство логики. Если это ваш случай, то у вас скромные потребности в клиентской части, и разделение состояния и поведения скорее всего то, что вам нужно.
Слабость Knockout в том, что если вам нужно значительное количество клиентской логики, это станет частью ее решения.
Backbone — самая популярная фронтенд библиотека этого типа, но также и самая простая. Философия Backbone предоставить минимальный набор вещей необходимый для структурирования фронтенд кода в вебе. Вы можете очень быстро научится использовать Backbone (и прочитать кодовую базу от начала до конца за час), благодаря его простоте.
Использовать Backbone стоит когда у вас скромные потребности (или изначально умеренные, но медленно растущие). Backbone это даже больше философия, чем фреймворк. У Backbone также удивительно активное сообщество, это означает что вы можете “построить собственный фреймворк” выбрав из множества сторонних расширений и библиотек. Backbone очень JavaScript-овый, то есть если вы понимаете язык на котором пишете, вы поймете и фреймворк, так как он делает все в стиле JavaScript.
Слабость Backbone в том, что он действительно не так много делает сам по себе, и вы делаете себе плохую услугу если не знаете что бы подключить в него. Эта “JavaScript-ность” тоже может быть помехой, так как много “веб разработчиков” имеют скудные знания о веб технологии, и если вы из их числа, легко можно затеряться с Backbone.
Marionette выступает с позиции, что если Backbone предлагает необходимый минимум для структуры любого типа приложения, большие приложения заканчивают с огромным количеством шаблонного кода. Marionette предоставляет структуру необходимую такого рода приложениям, и также дает руководство как организовывать большие объемы кода.
Причина, по которой мы остановили свой выбор на Marionette, — их подход к организации кода, который во многом совпадает с нашим; разделение больших блоков кода на меньшие, которые общаются между собой с помощью хорошо заданных и простых интерфейсов. Разделение управления и вычислений, сделать код представлений как можно более декларативным, а управление кодом — как можно более высокоуровневым. И также следовать устоявшимся паттернам работы с большими и сложными кодовыми базами.
Marionette решает наибольшую проблему Backbone — весь этот шаблонный код в представлениях. Также легко построить свою собственную компонентную архитектуру (что слишком сложно сейчас в Angular), и получить минимальную структуру для всего что нужно (в отличии от Knockout). Потребуется работа чтобы допилить хорошую архитектуру и построить инфраструктуру, но учитывая наши запросы и текущее состояние других библиотек, я думаю это хороший компромисс.
Это оценка конкретной ситуации и точки зрения, и, я верю, имеющая смысл для нашего продукта и нашей команды разработки. Как я уже говорил вначале, все эти варианты прекрасны для своих целей. Если кто-то скажет вам “Я использовал фреймворк X и он плох, но сейчас я использую фреймворк Y и чувствую себя словно я путешествую по солнечным полям на волшебной лошади.”, скорее всего он просто сделал неправильный выбор в первый раз.
Оригинал Автор Мэтт Бриггс (Matt Briggs).
С течением времени, оборудование стало дешевле и мы пришли к текущей модели, когда клиент делает значительную часть работы, а общается с сервером только для того, чтобы получить информацию, сохранить информацию или дать команду, которая должна быть запущена в защищенном, контролируемом окружении.
Теперь, если подумать, в те времена разрабатывать было проще, из-за того, что все пользователи были одинаково ограничены аппаратной частью.
К несчастью (для разработчиков), ограничения, наложенные этой моделью, также полностью неприемлемы для конечных пользователей. Они хотят отзывчивое, быстрое, красивое ПО, что почти неосуществимо в условиях, когда любое небольшое действие ведет к запросу-ответу на удаленный сервер.
Эволюция веб интерфейсов
Вы можете увидеть похожую эволюцию в веб-разработке. Мы находимся в состоянии изменения парадигм, и чем дальше, тем сложнее будет приложениям написанным в старой парадигме. Зачем использовать то, что не отзывчиво и дает небольшую интерактивность, когда у нас есть альтернативы избавленные от этого?
UI архитектура это очень тяжелая проблема дизайна, и даже если большие компании годами вкладывали миллионы долларов в ее решение, у нас до сих пор даже близко нету “Одного правильного пути” чтобы сделать это. Много JavaScript “MVC” фреймворков (это почти такой же плохой термин как серверные MVC фреймворки) появились на протяжении последних лет и принципиально отличаются в том как применить идеи UI архитектуры последних 50 лет к вебу.
Выбирая фреймворк
Мы попробовали множество фреймворков, но для краткости, я опишу четыре наиболее популярных: Backbone, Ember, Knockout, и Angular.
Перед тем как начать, я хочу сказать что все это действительно потрясающие проекты имеющие заслуженную популярность. Нету такой вещи как “Серебряная пуля” в разработке, которая была бы хороша во всех ситуациях и проблемах, и каждый из этих фреймворков имеет сильные и слабые стороны.
Наша ситуация
У нас (приблизительно) 250 тысяч строк кода промышленного Rails приложения. Оно провело большую часть своей жизни следуя “Пути Rails”, и мы получили из этого множество уроков. В приложении прописано нереальное количество бизнес логики. Таким образом, масштабируемость и гибкость были двумя ключевыми критериями, которыми мы руководствовались при выборе фреймворка.
Ember.js
Исходя из документации и разговоров Yehuda Katz (wycats) о Ember.js, это в основном попытка сделать Rails на стороне клиента.
Ember самый амбициозный из доступных сейчас фреймворков и его сильные стороны очевидны. Он лишает вас возможности выбора в ряде случаев и это бывает достаточно удобно. В частности, мне нравится их подход к роутингу (Менеджер состояний / StateManager), мне кажется это гораздо лучше остальных реализаций.
Слабая сторона Ember — это результат его преимуществ; если вы не хотите идти по пути Ember — для вас наступают тяжелые времена. Если вы сталкиваетесь с проблемой, то имеете дело с чрезвычайно комплексным фреймворком, и, скорее всего, не сможете быстро решить проблему. Ember только достиг версии 1.0 и еще значительно изменится в ближайшие годы. С фреймворками которые имеют такой уровень присутствия в каждом аспекте вашего кода, обновление может стать тяжелым испытанием (у нас ушло больше года чтоб закончить апгрейд Rails до третьей версии).
Последней каплей для меня стало то, какой контроль Ember выполняет за вашей архитектурой. У нас достаточно навыков, чтобы делать собственный выбор, поэтому я считаю, что работа с тем что накладывает на нас столько ограничений это плохой выбор.
Angular.js
Angular использует подход согласно которому в HTML и JavaScript отсутствуют ключевые вещи делающие его более подходящими для создания сложных интерфейсов. В случае JavaScript, то что нужно — это наблюдаемые объекты. Для HTML недостающая часть это некая форма шаблонизации. Так как оба являются расширяемыми языками, то что делает Angular — это добавляет такие возможности.
Я большой фан Angular. Он предоставляет прозрачное разделение между представлениями и бизнес логикой, компонентную реализацию, совмещающую поведение и структуру — то, в чем действительно нуждается нынешний веб. Он также содержит внедрение зависимости (Dependency Injection framework), то, что многие разработчики считают излишним, но я думаю это хорошая идея.
Место, когда я перестал соглашаться, это то, как реализована шаблонизация. Я занимаюсь веб разработкой с 2000 года, и за это время я видел устойчивую тенденцию разграничивать три части веб технологии: стиль, поведение и структура. Я видел (и был частью) этого движения и я думаю вещи, которые поощряют поведение в HTML и HTML в JavaScript — это плохой путь. В конце концов, какая разница между
onclick="foo();"
и
ng-click="foo();"
В окружении вроде XCode, у меня нет проблем с таким стилем привязки в представлении, так как “представление” это не код для меня, а поверхность дизайна. Но с тех пор как мы по другому строим веб, я считаю это плохим направлением развития.
Я бы даже не считал это слабостью, скорее различием подходов. Я думаю слабость Angular это: громоздкое API, факт того что веб-стандарты идут в другом направлении, чем Angular, и то, что абстракции достаточно хрупкие. Достаточно легко оказаться за пределами регулируемого Angular мира, когда понадобится глубокое понимание того как это работает, и где/как вернутся обратно.
Решающим минусом для меня стало, насколько сложно сделать собственную директиву (directive), что я считаю самой ценной возможностью всего фреймворка. За всю мою карьеру, единственная платформа которая приблизилась по уровню мучений при попытке расширить ее, это серверные элементы управления в ASP.net WebForms. Это решаемая проблема, и я думаю если бы мы сейчас были в точке где Angular достиг второй или третьей версии, это был бы мой выбор.
Knockout.js
Knockout применяет вдохновленный Microsoft MVVM подход к фронтенду. У них есть мощный язык для связывания данных (databinding), и привязки html к моделям представлений (view models). У них есть базовый роутер, и это все. Knockout не столько “фреймворк”, сколько хорошая библиотека для связывания данных.
Я думаю идеальное примение Knockout — это когда вы делаете “гибридное” приложение, когда у вас есть взаимодействие между перезагрузками страниц, но сервер по прежнему держит большинство логики. Если это ваш случай, то у вас скромные потребности в клиентской части, и разделение состояния и поведения скорее всего то, что вам нужно.
Слабость Knockout в том, что если вам нужно значительное количество клиентской логики, это станет частью ее решения.
Backbone.js
Backbone — самая популярная фронтенд библиотека этого типа, но также и самая простая. Философия Backbone предоставить минимальный набор вещей необходимый для структурирования фронтенд кода в вебе. Вы можете очень быстро научится использовать Backbone (и прочитать кодовую базу от начала до конца за час), благодаря его простоте.
Использовать Backbone стоит когда у вас скромные потребности (или изначально умеренные, но медленно растущие). Backbone это даже больше философия, чем фреймворк. У Backbone также удивительно активное сообщество, это означает что вы можете “построить собственный фреймворк” выбрав из множества сторонних расширений и библиотек. Backbone очень JavaScript-овый, то есть если вы понимаете язык на котором пишете, вы поймете и фреймворк, так как он делает все в стиле JavaScript.
Слабость Backbone в том, что он действительно не так много делает сам по себе, и вы делаете себе плохую услугу если не знаете что бы подключить в него. Эта “JavaScript-ность” тоже может быть помехой, так как много “веб разработчиков” имеют скудные знания о веб технологии, и если вы из их числа, легко можно затеряться с Backbone.
Backbone.Marionette
Marionette выступает с позиции, что если Backbone предлагает необходимый минимум для структуры любого типа приложения, большие приложения заканчивают с огромным количеством шаблонного кода. Marionette предоставляет структуру необходимую такого рода приложениям, и также дает руководство как организовывать большие объемы кода.
Причина, по которой мы остановили свой выбор на Marionette, — их подход к организации кода, который во многом совпадает с нашим; разделение больших блоков кода на меньшие, которые общаются между собой с помощью хорошо заданных и простых интерфейсов. Разделение управления и вычислений, сделать код представлений как можно более декларативным, а управление кодом — как можно более высокоуровневым. И также следовать устоявшимся паттернам работы с большими и сложными кодовыми базами.
Marionette решает наибольшую проблему Backbone — весь этот шаблонный код в представлениях. Также легко построить свою собственную компонентную архитектуру (что слишком сложно сейчас в Angular), и получить минимальную структуру для всего что нужно (в отличии от Knockout). Потребуется работа чтобы допилить хорошую архитектуру и построить инфраструктуру, но учитывая наши запросы и текущее состояние других библиотек, я думаю это хороший компромисс.
UI это сложно, и нету Серебряной пули
Это оценка конкретной ситуации и точки зрения, и, я верю, имеющая смысл для нашего продукта и нашей команды разработки. Как я уже говорил вначале, все эти варианты прекрасны для своих целей. Если кто-то скажет вам “Я использовал фреймворк X и он плох, но сейчас я использую фреймворк Y и чувствую себя словно я путешествую по солнечным полям на волшебной лошади.”, скорее всего он просто сделал неправильный выбор в первый раз.
Оригинал Автор Мэтт Бриггс (Matt Briggs).
