1) Переносим имеющееся приложение с WPF, разработчики все тоже с опытом WPF
2) Берём максимально отличающуюся от MVVM технологию управления стейтом
3) ???????
4) Почему меня чуть не уволили?!
А ведь достаточно было не натягивать свою любимую сову на очередной глобус. WPF-разработчики прекрасно переезжают на связку React + MobX + Typescript, поскольку идеология организации кода и состояния практически 1 в 1 совпадают. Но Redux-сектанты будут упорно продавливать своё мнение, да.
Пока что тренд на две парные тенденции, на инклюзию и снижение уровня насилия — самый длинный Большой Тренд в социальном, ему скорее всего десятки тысяч лет.
И сейчас нет оснований считать, что в это месте что-то волшебным, или каким-либо еще способом поменяется.
Напротив, в последнее новом времени это только ускоряющиеся тенденции, и в целом есть понимания того, как это работает, что это закономерность, а не случайность.
Для поверхностного знакомства с темой рекомендую почитать Стивена Пинкера (недавно вышел руcский перевод (под научной редакцией Екатерины Шульман) его книги как раз про это) (Стивен Пинкер, «Лучшее в нас. Почему насилия в мире стало меньше»), для краткого знакомства можно вот эту статью прочесть: https://www.forbes.ru/forbeslife/416021-my-pereshli-ot-sazhaniya-na-kol-do-memchikov-v-twitter-stiven-pinker-i-ekaterina) или просто хотя бы посмотреть что-то вроде вот этого (примерно с 13:16):
а к вопросу про ускорение в новейшее время — подвигать ползунок вот на этой интерактивной карте политических режимов с 1900 по 2018-й год (не идеальной, там все в границах 2018 года показано, но общее представление он как раз дает!):
я приведу лишь две крайние точки на этом временном отрезке:
Причина того, что смена политических режимов, их движение по вектору «Closed autocracy->Electoral autocracy->Electoral democracy->Liberal democracy» так ускороилось в последние сто ++ лет — индустриализация.
А причина того, что направление движения именно таково в том, что это направление движения увеличения выгоды, направление движения, в котором система более устойчива. В каком-то смысле — направление в сторону «основного энергетического состояния системы». Это состояние, максимизирующее инклюзию, то есть включение в список полноправных (юридически, политически, экономически) людей все более широгого числа людей.
Вот про «направление движения в сторону увеличения выгоды»:
Вот старая (2012-го года!) статья, тем не менее неплохо отражающая суть утверждений книги (устарелость ее лишь в том, что ныне это не просто «смелая и интересная гипотеза», а State of the Art современной экономической науки):
А связано с темой насилия это очень просто, это направление общественного прогресса в срезе смены политических режимов является одновременно и направлением увеличения инклюзии и снижения насилия. Как внутреннего насилия, так и внешнего, есть даже такая максима, «демократии не воюют с демократиями» (и занятные исследования, показывающие, что демократия ведет к снижению принятия опасных решений, например на материале исследования приятия решений при восхождении на Эверест разными командами; это к слову о том, что демократии реже ввязываются в военные авантюры, а снижение военных конфликтов ведет к снижению насилия в обществе).
Именно поэтому упомянутая вами фантазия — это вовсе не «футуристическая теория», это безотсественное антинаучное фантазирование. Безответсвенным тут является выдача желаемого (апокалиптических прогнозов) за действительное, обман, рассказ о том, что это «футуристическая теория». Нет, нет реалитисчных траекторий развития из той точки, в которой находимся мы сейчас в ту, которая рисуется автором этой фантазии.
Мир работает не так.
И это стоит понимать. Это называется «адекватное мировосприятие» (вариант: современная научная картина мира), оно позволяет увеличивать качество принимаемых решений, становиться более эффективно действующим агентом в этом мире. Увеличивать свой репродуктивный успех, если так хотите на это посмотреть (т.е. если смотреть на это с точки зрения эволюции). В общем, абсолютное благо.
P.S. занятно то, что это все вещи, которые закономерно, математически следуют из простейших агентных etc моделей, это не про «именно и только человеков», это все базовые вещи про очень общий класс систем.
Развиваю на работе проект на Angular, а также создал и развиваю проект на Ember. Также есть опыт Backbone.
Разница между Angular и Ember — просто небо и земля, в пользу Ember.
***
У Angular очень низкий порог вхождения, но очень высокая сложность использования. Сложность в том смысле, что крайне сложно сделать по-настоящему качественно. Выбрав Angular, вы наступите на все возможные грабли, подложите себе множество мин замедленного действия. Рефакторинг для вас будет как ремонт в советской квартире — процесс постоянный и мучительный. Нужно пройти огромный (полагаю, многолетний) путь, чтобы достичь такого уровня владения Angular, который позволит написать приложение с действительно качественной кодовой базой с первого раза.
Angular очень низкоуровневый. В нём всё делается на коленке. Радоваться такому подходу могут только те, кто никогда не пробовал добротный высокоуровневый фрэймворк и кому не приходилось поддерживать проекты, писаные несколькими сменами говнокодеров. На самом деле это полная жопа. Чтобы писать качественный, читаемый и поддерживаемый код на Angular, надо иметь строжайшие гайдлайны и соблюдать их. На деле же всё пишется как быстрее, ведь Angular так легко позволяет срезать углы.
Сообщество Angular — это как сообщество PHP. И то, и другое — это губки, которые впитывают всех дилетантов и бесталанных разработчиков. Подчеркиваю, что я не утверждаю, что толковых и талантливых разработчиков там нет. Есть, конечно, но их процентное соотношение — самое низкое среди всех фрэймворков/языков.
Angular — это не MVC-фрэймворк. Они долгое время позиционировали себя как «MV*», потом они убрали эту аббревиатуру с сайта. Ржака в том, что в Angular нет ни View, ни Model, по сути, Angular — это голый контроллер. Вместо слоя модели можно использовать что-то свое, например, JSData, полностью слизанный с Ember Data. Но в 99% поделок на Angular модель как отдельная сущность отсутствует, данные хранятся, как бы это сказать, в ладошке. Со слоем представления всё печально, так как в Angular его нет, но и взять свой нельзя. Вместо вьюх Angular использует DOM нагорячую. То есть Angular берет существующий DOM, проходится по нему и модифицирует на лету. Вам приходится вставлять Angular-разметку прямо в HTML, и вся эта разметка попадает в браузер. HTML-код Angular-приложения в инспекторе браузера выглядит закиданным яйцами и туалетной бумагой, и у подавляющего большинства Angular-приложений HTML-код невалиден.
Логика в HTML! Это просто цирк какой-то. В принципе, Angular не обязывает вас выносить логику в HTML, но вы не найдете ни одного приложения на Angular, которое этим не грешит.
Angular трудно тестировать. Angular заявляет, что написан для удобного тестирования, но на практике вы столкнетесь с трудностями и значительную часть кода оставите непокрытой тестами.
Документация Angular — это что-то с чем-то. В разделе Services приводятся примеры использования `.factory` и нет `.service`, а примеры использования `.service` приводятся на странице Providers. Оглавлений у простыней страниц нет, найти что-то сложно. Если не верите на слово, попробуйте в официальной документации найти, какие аргументы принимает колбэк `link` у директивы (подсказка: все страницы с упоминанием `link` или `directive` в заголовках можете пропускать, там не найдете).
Я уже не говорю про проблемы с производительностью Angular. Это просто курам насмех. 2000 binding'ов — и canvas-анимации начинают подтормаживать. Становится видно, как Angular скрипит шестеренками даже когда пользователь ничего не делает. Чтобы снизить количество binding'ов, приходится прибегать к методам работы, применяемым в Backbone. Это крайне досадный шаг назад.
***
Ember — полная противоположность Angular. Освоить его сложно. Мне потребовалось два месяца, чтобы почувствовать себя в нем комфортно. Но с этого момента пользоваться им стало очень и очень просто, удивительно удобно и продуктивно.
Прежде всего скажу, что Ember очень гибок. Его «предвзятость» ни в чем вас не ограничивает. Не верьте тем, кто говорит, что Ember вас ограничивает в написании вашего приложения (так пишут только те, кто перепробовал фрэймворки для галочки, не задержавшись в каждом дольше чем на день). Всё, буквально всё в Ember расширяется и переопределяется. Более того, фрэймворк изначально построен с расчетом на то, что вы будете его расширять и переопределять.
«Жесткость» Ember проявляется только в структуре вашего проекта. Стандартизованная структура, благодаря подходу «договоренностей вместо конфигурирования» (convention over configuration), избавляет вас от необходимости писать обслуживающий код. Изначально, Ember использует дефолтные сущности для всего, что ему требуется (вьюхи там, контроллеры, шаблоны, маршруты...). Стоит вам сохранить кастомную сущность под соответствующим именем, как Ember начинает использовать ее вместо дефолтной. Таким образом, вы пишете только бизнес-логику: описываете суть вещей, без «воды». Из всего, что я писал на JS, код на Ember получается самым компактным и наиболее экспрессивным. По мере развития вашего проекта его структура не превращается в помойку. Структура, кстати, не такая уж и жесткая: можно группировать файлы по типу сущности (models/user.js, components/user.js), а можно по названию сущности (user/model.js, user/controller.js), выбирать вам.
Ember — это полноценный MVC-фрэймворк. В числе прочего, у него самый лучший в мире роутер и на редкость грамонтный слой модели.
В Ember используется свой сборщик (на основе Broccoli, это конкурент Gulp) и готовая структура проекта. Они очень качественные, очень богаты функционально и очень активно развиваются. Но самое главное, сборщик и структура проекта — стандартны. Все проекты построены на одних и тех же конвенциях, никто не изобретает убогие велосипеды с костылями.
Ember побуждает грамотно структурировать код. В Ember нужно постараться, чтобы напортачить — в отличие от Angular, где приходится постоянно тужиться, чтобы НЕ напортачить. После короткого вводного курса по Ember новобранец способен писать приличный, читаемый и поддерживаемый код.
В Ember из коробки идет поддержка ES6, можно сразу писать современный код. BabelJS обеспечивает обратную совместимость (до IE8 включительно). Используются чистые, лаконичные ES6-модули, которые, пока браузеры не обзаведутся их поддержкой, транспилируются в AMD.
В Ember очень удобная система аддонов. Аддоны можно писать как для самого Ember, так и для сборщика. Аддоны распространяются через npm, который по ряду критериев практичнее Bower'а. Например, npm позволяет лочить версии зависимостей при помощи lock-файла (shrinkwrap), хотя до практичности Ruby Bundler им обоим как до луны.
В Ember очень удобная система классов. Оставаясь интуитивно понятной для JS-кодеров, она обладает многими преимуществами более благородных языков. Классы можно расширять динамически (причем, как инстансы, так и классы), из переопределяющего метода можно вызывать переопределяемый. Есть mixin'ы. В общем-то, значительная часть функционала вынесена в mixin'ы, плюс идет процесс рефакторинга: всё больше базового функционала Ember выносится из встроенных классов в mixin'ы, облегчая переиспользование кода. Например, для типового формирования URL'а раньше надо было require'ить сериализатор, что увеличивает связность приложения, а это не очень хорошо (tight coupling). А теперь можно в любую сущность подключить mixin с методом формироавния URL'а.
Шаблонизатор Handlebars — это просто благословение, особенно после Angular'овского засирания DOM. Возможности шаблонизатора намеренно ограничены (как в Django), чтобы не допустить вынос логики во вьюхи. Движок шаблонизации в Ember активно развивается, недавно он вышел на качественно новый уровень, позаимствовав некоторые приемы из React. Вот тут React прикрутили в качестве view layer в Ember, и можно сравнить скорость рендеринга сложной вьюхи между React и чистым Ember: github.com/ghempton/ember-react На глаз, разница примерно двукратная: где-то 0.2 и 0.4 секунды. А со следующим развития шагом Ember догонит и, возможно даже, перегонит React, см. github.com/emberjs/ember.js/pull/10501. К слову, в инспекторе браузера HTML-код Ember-приложения выглядит почти полностью чистым (добавляются айдишники), и он валиден. А для любителей indendation based синтаксиса есть целых два препроцессора: один с синтаксисом по примеру Jade/Slim, другой по примеру Haml.
Вычисляемые свойства Ember позволяют писать реактивный код. За пару месяцев использования Ember в вашей голове происходит смена парадигмы с императивной на декларативную. Это очень круто и удобно. При том же объеме функионала, код становится короче и яснее. Кроме того, вычисляемые свойства ленивы: они не вычисляются до тех пор, пока не будут запрошены, а результат вычисления запоминается. Повторное вычисление происходит только при изменении свойств, от значений которых зависит значение данного вычисляемого свойства.
И никакого dirty checking, Ember использует observer'ы. Благодаря этому data binding не сказывается на производительности приложения и работают интуитивно понятно. Когда вы меняете значение свойства, Ember синхронно уведомляет все заинтересованные сущности об изменении. «Под капотом» цепочки вычислений группируются в так называемые run loops, в результате обновление DOM происходит пакетно в конце цепочки, а не на каждом шаге.
В Ember очень активное и дружелюбное сообщество. Не находясь в когтях корпорации, Ember развивается в открытую. Все планы обсуждаются сначала в RFC'ах, потом в pull-request'ах. Главные мэйнтейнеры раз в N недель слетаются на встречу, чтобы обсудить проблемы развития в реале. Все мэйнтейнеры Ember — сотрудники различных «продуктовых» компаний, использующих Ember в продакшене.
Ember развивается по принципу «стабильность без стагнации». «Стабильность» здесь означает отсутствие такой жопы, как в Angular, где новая мажорная версия фрэймворка оказывается заведомо несовместимой с предыдущей. «Без стагнации» означает отсутствие такой жопы, как в Node, где развитие проекта заморожено в угоду поддержке корпоративных клиентов и вопреки нуждам сообщества. На практике этот подход означает, что, во-первых, новые фичи вводятся по мере готовности, не откладывая до мажорного релиза. Во-вторых, breaking changes вводятся с длительным deprecation period, давая пользователям возможность без нервотрепки поддерживать кодовую базу в актуальном состоянии. Релиз мажорной версии будет означать по сути просто отключение поддержки ранее deprecate'нутых фич.
В последнее время Ember рекомендует подход, аналогичный React: data up, actions down с использованием односторонних data binding'ов. Это делает структуру приложения более плоской и упрощает отладку. Однако вы можете использовать двусторонние data binding'и там, где считаете уместным (например, для input'ов). Я свое первое приложение построил целиком на двусторонних, и структура приложения получилась очень простой (всё обновляется и пробрасывается само, не надо ничего делать руками), при этом я не столкнулся с проблемами ни в производительности, ни в отладке.
В Ember самый функциональный и удобный инструмент отладки в инспекторе браузера. Angular Batarang стыдливо прячется за спинами.
Ember очень легко тестировать. Полная инфраструктура тестирования идет из коробки: всё преднастроено и готово к использованию. Сборщик создает заготовки тестов для каждой сущности, которую вы используете. Покрыть юнит-тестами можно абсолютно любую сущность, будь то модель, маршрут или даже какой-нибудь initializer. 100%-ное покрытие риальне! Очень легко писать приемочные (acceptance aka integration) тесты благодаря удобным хелперам, позволяющим работать с асинхронными операциями в синхронном стиле. В комплекте идет QUnit, но есть аддон, добавляющий поддержку Mocha, хотя благодаря хелперам особой нужды в Mocha нет. Также есть аддон для Chai. Статус тестов можно смотреть не только в консоли, но и в браузере во время работы dev-сервера. В процессе разработки приложение на Ember компилируется инкрементально, благодаря чему ждать перезапуска тестов приходится не дольше пары секунд. В комплекте идет конфиг для Travis: публичный проект на Github можно бесплатно тестировать на CI-сервере.
Документация у Ember достаточно хорошая. Есть замечательный официальный Guide, способный заменить книгу. Доки по API пишутся прямо в исходниках соответствующих компонентов при помощи специальным образом сформированных комментариев. Благодаря этому документация для каждой версии Ember формируется автоматически и никогда не устаревает.
На builtwithember.io можете посмотреть примеры свободных и проприетарных приложений, выполненных на Ember. Там можно найти всё: разнообразные админкии, дэшборды, чаты, инструменты визуализации и анализа данных, CMS, CRM, соцсети, форумы, таск-менеджеры, трейдинговые площадки, средства рассылок, continuous integration, базы знаний, поисковики, платежные системы… Короче говоря, всё, что можно придумать. Из крупных проектов: Vine (100 млн уников в месяц), ZenDesk (их бэкенд обрабатывает 100 тысяч запросов в минуту), TravisCI, DockYard, Twitch (100 тысяч просмотров в минуту в пиковое время; был куплен Amazon'ом за миллиард долларов).
***
Backbone — это несерьезно. Это просто удобная обертка над jQuery и Underscore. Data-binding'ов нет, MVC нет и много чего нет. Чтобы сделать single-page applicaiton на Backbone, вам придется писать бескрайние простыни обслуживающего кода. Это очень утомительно (для программиста) и дорого (для работодателя). Сложность поддержки Backbone-приложения растет экспоненциально по отношению к размеру кодовой базы.
PS С удовольствием отвечу на вопросы по Ember. Общие вопросы задавайте здесь в комментах, конкретные вопросы по коду пишите на StackOverflow (с примером на JSBin.com) и кидайте ссылку в личку.
Я догадываюсь, что автор очень горд своей системой оценок (больше показателей — выше ЧСВ). Но насколько я могу судить как программист, ЛЮБАЯ попытка «измерить жизнь цифрами» превращается в маразм. Причина? Да потому что вы работаете с ЛЮДЬМИ, а не роботами. Именно поэтому нет роботов-программистов, что ни один робот не может работать в профессии, часть которой составляет ТВОРЧЕСТВО. Плюс сюда техническая интуиция, «настроение», «драйв» и т.п.
Когда я слышу о немыслимых цифрах «85% _рабочего_ времени программиста», мне хочется заржать вам в лицо — вы сами-то пробовали писать программы 85% времени??? Это как заставить шахматиста или художника «давай, твори, до обеда ещё далеко!». Ни один программист на регулярной основе не тратит даже 6 часов рабочего дня на код! Вдвойне вам позор, потому что подобные вещи даже уже описаны классиками. 2-4 часа максимум — вот мои цифры. Всё остальное — отнюдь не Counter Strike, сюда входят дебилы-сотрудники, отвлекающие от дела в самый важный момент, поиск решения, обучение, копание в справке и т.п. Ну и социум, само-собой — поболтать в сети/с коллегами, внеплановый перекус/перекур, задумчивый взгляд в окно, «не идёт мысль» — много чего.
Но главное — все ваши дюймы, часы и LOC'и летят к чертям, когда оказывается, что опытный сотрудник за час создал гибкое, расширяемое ядро, а 10 неопытных тупо неделю ваяли монолитное гуано, которое через 5 лет превратится в неповоротливого монстра на выброс. ЭТО не измерить никак — это бесценно.
Что могу сказать коррелирующего по статье — то, что программисту НАДО ХОРОШО ПЛАТИТЬ. Но категорически БЕЗ ваших смешных «писькомерок», потому что на любую вашу методику я найду 5 эксплойтов, повышающих «очки», но играющих против компании. Запомните, вы работаете с людьми! И если вы ставите людей в условия прямой гонки за деньгами, ТОЛЬКО ГОНКУ вы и получите!
Зарплата должна быть одна и такая, которая позволяет о ней не думать, а полностью сосредотачиваться над работой.
Может я не прав, но зачем люди любящие гибкость и настройки берут подобные роутеры? За немаленькие деньги (>200$ зачастую) они обладают на редкость куцым функционалом и настройками в стиле «Сделай мне спасибо». Mikrotik выгодно отличается на их фоне как производительностью, так и богатейшим функционалом. Все это за меньшую цену.
Хотя возможно автору просто нравится ковырять чужие прошивки и я чего-то не понимаю.
1) Переносим имеющееся приложение с WPF, разработчики все тоже с опытом WPF
2) Берём максимально отличающуюся от MVVM технологию управления стейтом
3) ???????
4) Почему меня чуть не уволили?!
А ведь достаточно было не натягивать свою любимую сову на очередной глобус. WPF-разработчики прекрасно переезжают на связку React + MobX + Typescript, поскольку идеология организации кода и состояния практически 1 в 1 совпадают. Но Redux-сектанты будут упорно продавливать своё мнение, да.
Пока что тренд на две парные тенденции, на инклюзию и снижение уровня насилия — самый длинный Большой Тренд в социальном, ему скорее всего десятки тысяч лет.
И сейчас нет оснований считать, что в это месте что-то волшебным, или каким-либо еще способом поменяется.
Напротив, в последнее новом времени это только ускоряющиеся тенденции, и в целом есть понимания того, как это работает, что это закономерность, а не случайность.
Для поверхностного знакомства с темой рекомендую почитать Стивена Пинкера (недавно вышел руcский перевод (под научной редакцией Екатерины Шульман) его книги как раз про это) (Стивен Пинкер, «Лучшее в нас. Почему насилия в мире стало меньше»), для краткого знакомства можно вот эту статью прочесть: https://www.forbes.ru/forbeslife/416021-my-pereshli-ot-sazhaniya-na-kol-do-memchikov-v-twitter-stiven-pinker-i-ekaterina) или просто хотя бы посмотреть что-то вроде вот этого (примерно с 13:16):
(прямая ссылка: https://youtu.be/DwKPFT-RioU?&t=796, интерактивная версия: http://www.fallen.io/),
а к вопросу про ускорение в новейшее время — подвигать ползунок вот на этой интерактивной карте политических режимов с 1900 по 2018-й год (не идеальной, там все в границах 2018 года показано, но общее представление он как раз дает!):
https://ourworldindata.org/grapher/political-regimes
я приведу лишь две крайние точки на этом временном отрезке:
Причина того, что смена политических режимов, их движение по вектору «Closed autocracy->Electoral autocracy->Electoral democracy->Liberal democracy» так ускороилось в последние сто ++ лет — индустриализация.
А причина того, что направление движения именно таково в том, что это направление движения увеличения выгоды, направление движения, в котором система более устойчива. В каком-то смысле — направление в сторону «основного энергетического состояния системы». Это состояние, максимизирующее инклюзию, то есть включение в список полноправных (юридически, политически, экономически) людей все более широгого числа людей.
Вот про «направление движения в сторону увеличения выгоды»:
https://en.wikipedia.org/wiki/Why_Nations_Fail
Вот старая (2012-го года!) статья, тем не менее неплохо отражающая суть утверждений книги (устарелость ее лишь в том, что ныне это не просто «смелая и интересная гипотеза», а State of the Art современной экономической науки):
https://elementy.ru/novosti_nauki/431872/Pochemu_odni_natsii_bogatye_a_drugie_bednye.
А связано с темой насилия это очень просто, это направление общественного прогресса в срезе смены политических режимов является одновременно и направлением увеличения инклюзии и снижения насилия. Как внутреннего насилия, так и внешнего, есть даже такая максима, «демократии не воюют с демократиями» (и занятные исследования, показывающие, что демократия ведет к снижению принятия опасных решений, например на материале исследования приятия решений при восхождении на Эверест разными командами; это к слову о том, что демократии реже ввязываются в военные авантюры, а снижение военных конфликтов ведет к снижению насилия в обществе).
Именно поэтому упомянутая вами фантазия — это вовсе не «футуристическая теория», это безотсественное антинаучное фантазирование. Безответсвенным тут является выдача желаемого (апокалиптических прогнозов) за действительное, обман, рассказ о том, что это «футуристическая теория». Нет, нет реалитисчных траекторий развития из той точки, в которой находимся мы сейчас в ту, которая рисуется автором этой фантазии.
Мир работает не так.
И это стоит понимать. Это называется «адекватное мировосприятие» (вариант: современная научная картина мира), оно позволяет увеличивать качество принимаемых решений, становиться более эффективно действующим агентом в этом мире. Увеличивать свой репродуктивный успех, если так хотите на это посмотреть (т.е. если смотреть на это с точки зрения эволюции). В общем, абсолютное благо.
P.S. занятно то, что это все вещи, которые закономерно, математически следуют из простейших агентных etc моделей, это не про «именно и только человеков», это все базовые вещи про очень общий класс систем.
У нас очень много тренингов на повышение самооценки. И нет тренингов на повышение квалификации (фактически). В итоге получаются такие вот запросы.
В итоге родился батник для разблокирования всех файлов в папке:
Разница между Angular и Ember — просто небо и земля, в пользу Ember.
***
У Angular очень низкий порог вхождения, но очень высокая сложность использования. Сложность в том смысле, что крайне сложно сделать по-настоящему качественно. Выбрав Angular, вы наступите на все возможные грабли, подложите себе множество мин замедленного действия. Рефакторинг для вас будет как ремонт в советской квартире — процесс постоянный и мучительный. Нужно пройти огромный (полагаю, многолетний) путь, чтобы достичь такого уровня владения Angular, который позволит написать приложение с действительно качественной кодовой базой с первого раза.
Angular очень низкоуровневый. В нём всё делается на коленке. Радоваться такому подходу могут только те, кто никогда не пробовал добротный высокоуровневый фрэймворк и кому не приходилось поддерживать проекты, писаные несколькими сменами говнокодеров. На самом деле это полная жопа. Чтобы писать качественный, читаемый и поддерживаемый код на Angular, надо иметь строжайшие гайдлайны и соблюдать их. На деле же всё пишется как быстрее, ведь Angular так легко позволяет срезать углы.
Сообщество Angular — это как сообщество PHP. И то, и другое — это губки, которые впитывают всех дилетантов и бесталанных разработчиков. Подчеркиваю, что я не утверждаю, что толковых и талантливых разработчиков там нет. Есть, конечно, но их процентное соотношение — самое низкое среди всех фрэймворков/языков.
Angular — это не MVC-фрэймворк. Они долгое время позиционировали себя как «MV*», потом они убрали эту аббревиатуру с сайта. Ржака в том, что в Angular нет ни View, ни Model, по сути, Angular — это голый контроллер. Вместо слоя модели можно использовать что-то свое, например, JSData, полностью слизанный с Ember Data. Но в 99% поделок на Angular модель как отдельная сущность отсутствует, данные хранятся, как бы это сказать, в ладошке. Со слоем представления всё печально, так как в Angular его нет, но и взять свой нельзя. Вместо вьюх Angular использует DOM нагорячую. То есть Angular берет существующий DOM, проходится по нему и модифицирует на лету. Вам приходится вставлять Angular-разметку прямо в HTML, и вся эта разметка попадает в браузер. HTML-код Angular-приложения в инспекторе браузера выглядит закиданным яйцами и туалетной бумагой, и у подавляющего большинства Angular-приложений HTML-код невалиден.
Логика в HTML! Это просто цирк какой-то. В принципе, Angular не обязывает вас выносить логику в HTML, но вы не найдете ни одного приложения на Angular, которое этим не грешит.
Angular трудно тестировать. Angular заявляет, что написан для удобного тестирования, но на практике вы столкнетесь с трудностями и значительную часть кода оставите непокрытой тестами.
Документация Angular — это что-то с чем-то. В разделе Services приводятся примеры использования `.factory` и нет `.service`, а примеры использования `.service` приводятся на странице Providers. Оглавлений у простыней страниц нет, найти что-то сложно. Если не верите на слово, попробуйте в официальной документации найти, какие аргументы принимает колбэк `link` у директивы (подсказка: все страницы с упоминанием `link` или `directive` в заголовках можете пропускать, там не найдете).
Я уже не говорю про проблемы с производительностью Angular. Это просто курам насмех. 2000 binding'ов — и canvas-анимации начинают подтормаживать. Становится видно, как Angular скрипит шестеренками даже когда пользователь ничего не делает. Чтобы снизить количество binding'ов, приходится прибегать к методам работы, применяемым в Backbone. Это крайне досадный шаг назад.
***
Ember — полная противоположность Angular. Освоить его сложно. Мне потребовалось два месяца, чтобы почувствовать себя в нем комфортно. Но с этого момента пользоваться им стало очень и очень просто, удивительно удобно и продуктивно.
Прежде всего скажу, что Ember очень гибок. Его «предвзятость» ни в чем вас не ограничивает. Не верьте тем, кто говорит, что Ember вас ограничивает в написании вашего приложения (так пишут только те, кто перепробовал фрэймворки для галочки, не задержавшись в каждом дольше чем на день). Всё, буквально всё в Ember расширяется и переопределяется. Более того, фрэймворк изначально построен с расчетом на то, что вы будете его расширять и переопределять.
«Жесткость» Ember проявляется только в структуре вашего проекта. Стандартизованная структура, благодаря подходу «договоренностей вместо конфигурирования» (convention over configuration), избавляет вас от необходимости писать обслуживающий код. Изначально, Ember использует дефолтные сущности для всего, что ему требуется (вьюхи там, контроллеры, шаблоны, маршруты...). Стоит вам сохранить кастомную сущность под соответствующим именем, как Ember начинает использовать ее вместо дефолтной. Таким образом, вы пишете только бизнес-логику: описываете суть вещей, без «воды». Из всего, что я писал на JS, код на Ember получается самым компактным и наиболее экспрессивным. По мере развития вашего проекта его структура не превращается в помойку. Структура, кстати, не такая уж и жесткая: можно группировать файлы по типу сущности (models/user.js, components/user.js), а можно по названию сущности (user/model.js, user/controller.js), выбирать вам.
Ember — это полноценный MVC-фрэймворк. В числе прочего, у него самый лучший в мире роутер и на редкость грамонтный слой модели.
В Ember используется свой сборщик (на основе Broccoli, это конкурент Gulp) и готовая структура проекта. Они очень качественные, очень богаты функционально и очень активно развиваются. Но самое главное, сборщик и структура проекта — стандартны. Все проекты построены на одних и тех же конвенциях, никто не изобретает убогие велосипеды с костылями.
Ember побуждает грамотно структурировать код. В Ember нужно постараться, чтобы напортачить — в отличие от Angular, где приходится постоянно тужиться, чтобы НЕ напортачить. После короткого вводного курса по Ember новобранец способен писать приличный, читаемый и поддерживаемый код.
В Ember из коробки идет поддержка ES6, можно сразу писать современный код. BabelJS обеспечивает обратную совместимость (до IE8 включительно). Используются чистые, лаконичные ES6-модули, которые, пока браузеры не обзаведутся их поддержкой, транспилируются в AMD.
В Ember очень удобная система аддонов. Аддоны можно писать как для самого Ember, так и для сборщика. Аддоны распространяются через npm, который по ряду критериев практичнее Bower'а. Например, npm позволяет лочить версии зависимостей при помощи lock-файла (shrinkwrap), хотя до практичности Ruby Bundler им обоим как до луны.
В Ember очень удобная система классов. Оставаясь интуитивно понятной для JS-кодеров, она обладает многими преимуществами более благородных языков. Классы можно расширять динамически (причем, как инстансы, так и классы), из переопределяющего метода можно вызывать переопределяемый. Есть mixin'ы. В общем-то, значительная часть функционала вынесена в mixin'ы, плюс идет процесс рефакторинга: всё больше базового функционала Ember выносится из встроенных классов в mixin'ы, облегчая переиспользование кода. Например, для типового формирования URL'а раньше надо было require'ить сериализатор, что увеличивает связность приложения, а это не очень хорошо (tight coupling). А теперь можно в любую сущность подключить mixin с методом формироавния URL'а.
Шаблонизатор Handlebars — это просто благословение, особенно после Angular'овского засирания DOM. Возможности шаблонизатора намеренно ограничены (как в Django), чтобы не допустить вынос логики во вьюхи. Движок шаблонизации в Ember активно развивается, недавно он вышел на качественно новый уровень, позаимствовав некоторые приемы из React. Вот тут React прикрутили в качестве view layer в Ember, и можно сравнить скорость рендеринга сложной вьюхи между React и чистым Ember: github.com/ghempton/ember-react На глаз, разница примерно двукратная: где-то 0.2 и 0.4 секунды. А со следующим развития шагом Ember догонит и, возможно даже, перегонит React, см. github.com/emberjs/ember.js/pull/10501. К слову, в инспекторе браузера HTML-код Ember-приложения выглядит почти полностью чистым (добавляются айдишники), и он валиден. А для любителей indendation based синтаксиса есть целых два препроцессора: один с синтаксисом по примеру Jade/Slim, другой по примеру Haml.
Вычисляемые свойства Ember позволяют писать реактивный код. За пару месяцев использования Ember в вашей голове происходит смена парадигмы с императивной на декларативную. Это очень круто и удобно. При том же объеме функионала, код становится короче и яснее. Кроме того, вычисляемые свойства ленивы: они не вычисляются до тех пор, пока не будут запрошены, а результат вычисления запоминается. Повторное вычисление происходит только при изменении свойств, от значений которых зависит значение данного вычисляемого свойства.
И никакого dirty checking, Ember использует observer'ы. Благодаря этому data binding не сказывается на производительности приложения и работают интуитивно понятно. Когда вы меняете значение свойства, Ember синхронно уведомляет все заинтересованные сущности об изменении. «Под капотом» цепочки вычислений группируются в так называемые run loops, в результате обновление DOM происходит пакетно в конце цепочки, а не на каждом шаге.
В Ember очень активное и дружелюбное сообщество. Не находясь в когтях корпорации, Ember развивается в открытую. Все планы обсуждаются сначала в RFC'ах, потом в pull-request'ах. Главные мэйнтейнеры раз в N недель слетаются на встречу, чтобы обсудить проблемы развития в реале. Все мэйнтейнеры Ember — сотрудники различных «продуктовых» компаний, использующих Ember в продакшене.
Ember развивается по принципу «стабильность без стагнации». «Стабильность» здесь означает отсутствие такой жопы, как в Angular, где новая мажорная версия фрэймворка оказывается заведомо несовместимой с предыдущей. «Без стагнации» означает отсутствие такой жопы, как в Node, где развитие проекта заморожено в угоду поддержке корпоративных клиентов и вопреки нуждам сообщества. На практике этот подход означает, что, во-первых, новые фичи вводятся по мере готовности, не откладывая до мажорного релиза. Во-вторых, breaking changes вводятся с длительным deprecation period, давая пользователям возможность без нервотрепки поддерживать кодовую базу в актуальном состоянии. Релиз мажорной версии будет означать по сути просто отключение поддержки ранее deprecate'нутых фич.
В последнее время Ember рекомендует подход, аналогичный React: data up, actions down с использованием односторонних data binding'ов. Это делает структуру приложения более плоской и упрощает отладку. Однако вы можете использовать двусторонние data binding'и там, где считаете уместным (например, для input'ов). Я свое первое приложение построил целиком на двусторонних, и структура приложения получилась очень простой (всё обновляется и пробрасывается само, не надо ничего делать руками), при этом я не столкнулся с проблемами ни в производительности, ни в отладке.
В Ember самый функциональный и удобный инструмент отладки в инспекторе браузера. Angular Batarang стыдливо прячется за спинами.
Ember очень легко тестировать. Полная инфраструктура тестирования идет из коробки: всё преднастроено и готово к использованию. Сборщик создает заготовки тестов для каждой сущности, которую вы используете. Покрыть юнит-тестами можно абсолютно любую сущность, будь то модель, маршрут или даже какой-нибудь initializer. 100%-ное покрытие риальне! Очень легко писать приемочные (acceptance aka integration) тесты благодаря удобным хелперам, позволяющим работать с асинхронными операциями в синхронном стиле. В комплекте идет QUnit, но есть аддон, добавляющий поддержку Mocha, хотя благодаря хелперам особой нужды в Mocha нет. Также есть аддон для Chai. Статус тестов можно смотреть не только в консоли, но и в браузере во время работы dev-сервера. В процессе разработки приложение на Ember компилируется инкрементально, благодаря чему ждать перезапуска тестов приходится не дольше пары секунд. В комплекте идет конфиг для Travis: публичный проект на Github можно бесплатно тестировать на CI-сервере.
Документация у Ember достаточно хорошая. Есть замечательный официальный Guide, способный заменить книгу. Доки по API пишутся прямо в исходниках соответствующих компонентов при помощи специальным образом сформированных комментариев. Благодаря этому документация для каждой версии Ember формируется автоматически и никогда не устаревает.
На builtwithember.io можете посмотреть примеры свободных и проприетарных приложений, выполненных на Ember. Там можно найти всё: разнообразные админкии, дэшборды, чаты, инструменты визуализации и анализа данных, CMS, CRM, соцсети, форумы, таск-менеджеры, трейдинговые площадки, средства рассылок, continuous integration, базы знаний, поисковики, платежные системы… Короче говоря, всё, что можно придумать. Из крупных проектов: Vine (100 млн уников в месяц), ZenDesk (их бэкенд обрабатывает 100 тысяч запросов в минуту), TravisCI, DockYard, Twitch (100 тысяч просмотров в минуту в пиковое время; был куплен Amazon'ом за миллиард долларов).
***
Backbone — это несерьезно. Это просто удобная обертка над jQuery и Underscore. Data-binding'ов нет, MVC нет и много чего нет. Чтобы сделать single-page applicaiton на Backbone, вам придется писать бескрайние простыни обслуживающего кода. Это очень утомительно (для программиста) и дорого (для работодателя). Сложность поддержки Backbone-приложения растет экспоненциально по отношению к размеру кодовой базы.
PS С удовольствием отвечу на вопросы по Ember. Общие вопросы задавайте здесь в комментах, конкретные вопросы по коду пишите на StackOverflow (с примером на JSBin.com) и кидайте ссылку в личку.
Когда я слышу о немыслимых цифрах «85% _рабочего_ времени программиста», мне хочется заржать вам в лицо — вы сами-то пробовали писать программы 85% времени??? Это как заставить шахматиста или художника «давай, твори, до обеда ещё далеко!». Ни один программист на регулярной основе не тратит даже 6 часов рабочего дня на код! Вдвойне вам позор, потому что подобные вещи даже уже описаны классиками. 2-4 часа максимум — вот мои цифры. Всё остальное — отнюдь не Counter Strike, сюда входят дебилы-сотрудники, отвлекающие от дела в самый важный момент, поиск решения, обучение, копание в справке и т.п. Ну и социум, само-собой — поболтать в сети/с коллегами, внеплановый перекус/перекур, задумчивый взгляд в окно, «не идёт мысль» — много чего.
Но главное — все ваши дюймы, часы и LOC'и летят к чертям, когда оказывается, что опытный сотрудник за час создал гибкое, расширяемое ядро, а 10 неопытных тупо неделю ваяли монолитное гуано, которое через 5 лет превратится в неповоротливого монстра на выброс. ЭТО не измерить никак — это бесценно.
Что могу сказать коррелирующего по статье — то, что программисту НАДО ХОРОШО ПЛАТИТЬ. Но категорически БЕЗ ваших смешных «писькомерок», потому что на любую вашу методику я найду 5 эксплойтов, повышающих «очки», но играющих против компании. Запомните, вы работаете с людьми! И если вы ставите людей в условия прямой гонки за деньгами, ТОЛЬКО ГОНКУ вы и получите!
Зарплата должна быть одна и такая, которая позволяет о ней не думать, а полностью сосредотачиваться над работой.
Хотя возможно автору просто нравится ковырять чужие прошивки и я чего-то не понимаю.
If Quake was done today
Взято из Википедии
Девайс
Банки