Комментарии 101
React же для нас — это сборник хороших идей, но из-за отсутствия многих функций из коробки, зачастую каждый лепит из него своего «монстра»

Либо вы лепите своего монстра, либо используете из каталога.
Angular тем и хорош, что все необходимое в нем уже есть, и его архитектура не позволяет лепить что попало. Благодаря этому, те, кто приходят в проект, сразу понимают где что, и могут сразу выполнять поставленные задачи.

Если сравнивать с тем же реактом, то там для старта надо сначала изучить весь зоопарк пакетов, без которых проект на реакте не взлетит, потом изучить организацию всяких компонентов-контейнеров, компонентов-представления и всего остального.

Но как говорится, дело вкуса…

Да уж, изучить компоненты-контейнеры и компоненты-предствавления — это прям такая проблема большая. Одну страничку мануала прочитать и понять что, компоненты контейнеры могут иметь своe состояние и предопределенные обработчики, а компоненты представления только рендерят ui в зависимости от переданных им свойств.
По-поводу зоопарка — стандарт де факто это реакт + редакс. Второй при желании заменяется на любую другую имплементацию флакс. Но ведь это же плюс, а не минус, можно подобрать необходимый набор пакетов под свои нужды. Ну надо мне например управлять асинхронными экшенами — подключил redux-saga, надо эффективно кэшировать выборки из глобального состояния — подключил reselect.
Но вы правильно написали — дело вкуса.

Ну надо мне например управлять асинхронными экшенами — подключил redux-saga, надо эффективно кэшировать выборки из глобального состояния — подключил reselect.

А есть люди, которым не нужны асинхронно и эффективно?

Насчет компонентов-контейнеров и прочего согласен. Понимается за час, а дальше главное соблюдать правила. Я и в ангуляре придерживаюсь похожей практики.

Насчет зоопарка, тут не соглашусь. Популярный стек React + Redux на моей практики загубил уже немало проектов, да и сам я попался на эту удочку. Люди берут из-за популярности, а потом выпиливают с матом из проекта. Почти все мои знакомые отказались, кто-то в слез на MobX, а кто-то написал свое.

Возвращаясь к зоопраку — мой проект на реакте содержит почти полторы страницы библиотек в package.json, которые мне пришлось притащить. И это настоящий ад, так как за всем этим хозяйством надо следить, да и к тому же частенько самому фиксить баги. Это какое-то вынужденное сотрудничество с комьюнити получается.

По поводу Saga и reselect — видел, да и сам много раз напарывался, что написать хорошие saga обработчики или селекторы не так то просто. Очень просто написать селектор, который будет работать хуже чем обычный код на lodash. А документации и best practice просто нет.

Постоянно идёт сравнение Ангуляра с Реактом, хотя первый пункт "Ангуляр — это фреймворк", а, как известно, Реакт — нет :)


Грубая настройка babel ничуть не сложнее typescript, а иногда лучше их настраивать цепочкой, потому как тонко настроить target компилятор typescript не может, аналогия babel с пресетами, но без возможности брать или добавлять только отдельные плагины, если целевые браузеры лишь чуть-чуть не дотягивают до используемых в исходниках фич.


А про модули не понял. Речь про import/export или что-то другое?

От сравнений мне было не уйти, иначе не всегда можно донести в чем же плюс. Но я старался делать это как можно мягче, дабы не обидеть сторонников другого решения :)

Согласен, что babel не такой уж и страшный зверь и у меня в принципе нет проблем с его настройкой, но не могу этого сказать про некоторых своих коллег. А мне надо было сделать так чтобы процесс сборки совсем не отнимал наше время. И да, конечно код получаемый babel в некоторых местах будет лучше и быстрее, но для нас это не так важно.

Модули в Angular очень похожи на стандартные es6 модули, но имеют некоторые отличия. Так например модуль это сущность для компилятора ангуляр, а значит можно использовать его конструктор как init метод (мы в нем например инжектируем локализацию в продукт). Во вторых вы помещаете весь роутинг вашего модуля внутрь модуля и это очень удобно. Также можно поступить и с сервисами для DI. Ну и наконец, если сравнить в React, то тут с учетом специфика ангуляра, просто добавив модуль вы можете легко использовать все компоненты экспортируемые модулем и вам не надо делать деструктинг компонентов из модуля для jsx.
и привыкли

So cute ;]


P.S. За статью спасибо, читается легко, ну и всегда приятно читать чужой опыт.

До этого оооень долго использовал первую версию AngularJs, знал все его минусы и плюсы. Затем был полугодовалый опыть использования второй версии Angular, понравился, стал проще. Теперь вот работаю с ReactJs. И я как-то даже разочерован, столько было про него сказано, а в итоге.
как там сейчас со временем сборки проекта?
а то после того как angular наконец-то релизнулся, меня жутко раздражала долгая сборка проекта, при малейшем изменении на пустом проекте приходилось ждать по 8-10 секунд… да там есть прекопиляция но она как-то криво была сделана.
что сейчас не расскажите, ну или как вы решили эту проблему?
Мы уже ушли от cli ангуляра и переписали весь процесс сборки для поддержки плагинной системы. Холодный старт, при учете что vendor у нас вынесен в dll, у нас занимает около 30 секунд. При изменении пересборка по прежнему идет около 6-8 секунд. В целом для нас 8 секунд не критично и наверно поигравшись с Webpack можно ускорить процесс.

Если совсем надоест, можете посмотреть мой велосипед. Я, правда, так и не нашел времени довести до ума (там есть ветка dev и npm пакет), но если будет интересно, можно развить тему.

Наконец-то статья о том, что кто-то выбрал Angular! Столько статей про React последнее время… Как любителю Angular становилось грустно, спасибо за статью!

Статья актуальна на начало 2016 года.


Сейчас май 2017 и информация немного поменялась.


У React появился cli — create-react-app.
C 16 версии React избавится от необходимости оборачивающих тегов. Компоненты смогут возвращать массив тегов, html станет проще.
Вопрос про многообразие Flux-ов тоже уже закрыт. Если нравится функциональный код — берете Redux, если хотите классических объектов — MobX.


А насколько я знаю про выход Angular 4, то все минусы из статьи по-прежнему на месте. Документация сложная, объем кода, загружаемого в браузер, огромный.

Начну с минусов. Если сравнивать размер ангуляра на начало 2016 года и сейчас, то он довольно сильно похудел. И если раньше размер получаемого кода у меня вызывал панику, то сейчас уже я вижу, что у мня есть ряд возможностей для уменьшения размера (о них написано в статье). Да и команда гугла продолжает заниматься уменьшение размера получаемого бандла. Минус документации тоже устраняется потихоньку, так например текущий спринт команды гугла направлен как раз на улучшения сайта и документации. Но так как для нас это не критичные минусы, то я особо не слежу за этой темой. Возможно для кого-то это stop-проблема и им лучше выбрать Vue.

Теперь насчет актуальности статьи. Про cli React я писал что он есть, правда указал немного другой. Насчет 16 версии React — я такой в production не вижу, а значит для меня ее нет. Точнее я конечно же читал про нее, в особенности про их fiber-ы, но уж простите, политика Компании и клиенты обязывают не юзать то, что официально не вышло. Но как я писал это не поможет нам, так как верстальщик у нас не знает JS.

По поводу Redux — да я его не люблю, и не из-за многообразия Flux решений, отнюдь. А не люблю я его из-за огромного кол-ва шаблонного кода, нередко монструозных side effect обработчиков и тормозящих геттеров из стейта (через reselect). У меня до сих пор есть довольно крупный проект на Redux и я каждый раз с неохотой что-то вношу в него. Похожий подход на angular у меня получился в разы компактнее и понятнее. Но это моя субъективная оценка и мой опыт и если кому-то Redux позволяет сделать красивый, простой и поддерживаемый код, я с удовольствием почитаю об этом на Хабре :)
тормозящих геттеров из стейта (через reselect)

Возможно, тормозит неоптимально написанный геттер — сам сталкивался с такой проблемой, когда плохо декомпозировал Селекторы и не работала мемоизация.
Идея в том, что при повторном вызове селектора с неизменившимися параметрами результат будет выдан из кеша без повторного вычисления.

И в чём проблема? Я думаю у Гугла нет проблем с наймом хороших разработчиков.


Ребята придумали как зарабатывать больше денег. Молодцы. Но с точки зрения большой компании никакой трагедии нет.


Вы так написали как будто то что из за того что они зарабатывают на Ангуляре вне Гугл у Гугл выручка уменьшится. Прям ужос-ужос.

Не в выручке дело, а в том как Ангуляр будет развиваться без основных разработчиков

С их бюджетом я думаю у них нет проблем с привлечением и заменой основных разработчиков.

Найти новых людей не проблема.


Дело в том, что делать фреймворк — это не то же самое что продукт. Это больше как рок-группа. Ушел гитарист, взяли другого, играет нормально, а звучание все равно не то.


Вот и здесь есть шансы, что люди, пришедшие на замену, повернут развитие Ангуляра в другую сторону.

Трудно согласится с тем, что на сегодняшний день, порог вхождения в Angular большой. Раньше когда не было документации и стабильной версии, да — разобраться было трудно.
Для реакта, конечно больше материалов, причем русскоязычных, наверное поэтому он является самой популярной библиотекой для фронтенд.
Имхо, порог входа в реакт гораздо, гораздо выше чем у ангулара. Особенно если вы пришли из бекенда C#, Java.

Как по мне, то ровно наоборот — фронтендеры быстро въезжают в Ангуляр, а бэкендеры — в Реакт.

Трудно согласится с тем, что на сегодняшний день, порог вхождения в Angular большой.

Ага, т.е. когда мне вместо внятного указания ошибки в моем коде в произвольно взятом с codeproject примере выдается вот такая херня — это небольшой порог вхождения?

Так это даже не проблема ангуляра, у вас же сервер вместо js/json отдаёт html, и js-парсер ломается на первом же "<". Но тут такое дело: чтобы писать на том же ангуляре, нужно ещё знать всякие сопутствующие вещи, вроде настройки сборщиков, компиляторов и т.д. Да, это порой трудно, но за такие знания и платят очень неплохо.
Но в любом случае, для облегчения всей этой возни с конфигами есть всякие cli, и у реакта, и у ангуляра. Вы пробовали их использовать? Или пройти туториал на оф. сайте?

Проходил туториал. А толку — он про то, что проект я собираю в студии, ни ухом ни рылом. Второе — он также ни ухом ни рылом про то, что на codeproject проект был под RC4, а компонента, которую я добавил, рассчитана на RC5 (и хоть бы написала при сборке что, мол, твой ангуляр старый, мне нужен RC5 минимум). Ну и вишенкой на торте то, что в туториале ни слова про то, что компонент этот надо подключать теперь через forRoot(), а не напрямую, как десяток других, задействованых в этом балагане.

Вот такая история. И вопрос у меня ровно один — почему все занимаются изобретательством всякой херни типа Angular уже 4, React и прочие Knockout и никто при этом еще не сделал никакой внятной системы диагности при сборке этого непотребства? Сообщения типа того, что на скриншоте, я ловил пачками и на React, и еще на каких-то поделиях.
НЛО прилетело и опубликовало эту надпись здесь
У нас сложнее. Наш продукт использует плагинную систему. При старте продукта мы загружаем все известные нам плагины и кладем их в кеш SystemJS. Для показа какого-то компонента мы сначала компилируем модуль через compileModuleAndAllComponentsAsync, потом находим в нем нужную фабрику используя имя компонента, а потом уже создаем его и добавляем в DOM.

Возможно если будет время на праздниках напишу статью по всем возможным способам создания компонентов в angular и какие там есть проблемы.
НЛО прилетело и опубликовало эту надпись здесь
SystemJS нам нужен так как WebPack статически анализирует код и не умеет грузить что-то, о чем он не знал на этапе компиляции. Мы же предполагаем, что наши партнеры могу написать свой плагин к нашей системе и зарегистрировать его у нас через UI. После этого мы на старте будем грузить его с бекэнда и вставлять компоненты из него в GUI.
НЛО прилетело и опубликовало эту надпись здесь
А как? Для нас это просто JS файл, в котором собрано все что надо плагину — модули, локализация, ресурсы и прочее. И собираем его в бандл не мы, а сторонняя компания. Если бы мы рендерили все на сервере, то тогда можно было бы не тащить компилятор.
НЛО прилетело и опубликовало эту надпись здесь
А Ember не смотрели? Там есть всё, что вы хотели и давно + сообщество и документации получше. Из коробки там нет TS, это правда.
Мы с другом делаем вдвоем свой проект и столкнулись со следующим:
Написали свой проект на Angular2(django backend, по сути просто как прослойка для REST), запустили альфа версию (на своем личном мощном сервере) и ужаснулись — на мобильных устройствах с android и ios, в браузере chrom, DOM собирался 35000 миллисекунд, да вы не ослышались 35 секунд!

Есть же universal, не унывали мы, и начали писать дальше, в итоге в декабре 2016 года, мы поняли, что для того чтобы запустить наш проект, мы создаем инфраструктуру для инфраструктуры и еще потратим примерно пару месяцев, чтоб все настроить. У нас уже были задействованы: Django, Angular2, nginx, universal, nodejs.

В итоге, волевым решением, все было переписано на Django за две недели. Конечно, так быстро мы все переписали благодаря тому, что в Angular2 все очень круто со структурированием кода, автор об этом как раз таки пишет. Сейчас наш проект использует Django, nginx, VanillaJS. подумываем частично использовать React. Сейчас наш проект на мобиле открывается за 2000 миллисекунд.

Какой вывод: Angular2 крут, но как нам кажется это технология для больших команд, у которых есть ресурсы, чтобы запустить проект в обозримое время.
DOM собирался 35000 миллисекунд, да вы не ослышались 35 секунд!

Это сколько нод или элементов в доме?

Больше всего уходило именно на инициализацию ангуляра
Сейчас уточнил у коллеги, он говорит что было что-то порядка 300.

А изменения в дом дерево новый ангуляр вводит очень быстро

Ну возможно что то делали не так?


У меня минимизированная версия Ionic приложения собранная с --prod грузится около 3х секунд.

Вот эти чуваки, тоже что-то делают не так:
https://www.youtube.com/watch?v=TCj_oC3m6_U

Если бы все было так просто, universal не нужен был бы, логично?
Я не знаю что там чуваки делают, но у меня приложение каждый день используют, уже как пол года. На 35 сек. никто не жаловался. Даже на планшетах за 2500 руб. android 4.4 приложение открывается быстрее 35 сек. Повторюсь ionic 2 намного тяжелее angular 2.

Вы обжимаете перед выкладкой? Если выкладывать как есть, то 35 сек. будет.
https://debtstracker.io/ — с ленивой загрузкой на компе 2009 года грузится 2 секунды по 4G. Нет особого дискомфорта от скорости загрузки.

На мобиле с локальной файловой системы примерно такие же цифры, но там ещё Cordova грузится.

Так что какие-то надуманные или более не актуальные проблемы.
Не верю. Писал на ionic 2. Выводил 700 элементов. Да подтупливает на несколько секунд, но не 35с.
Для телефонов советую Polymer, это ОЧЕНЬ быстро
пример https://shop.polymer-project.org

Почему только для телефонов? Его для всего можно советовать.

у вас не настроена AoT компиляция и все шаблоны компилятся JiT в браузере при каждом открытии?
Размер игры doom2 в архиве — 6,8 мегабайт. Размер загружаемого кода js в dev-версии Angular2 ~7 мегабайт. Отличная штука.

Открыл ссылку, а там:


Disclaimer: This article explains a research which uses experimental tools tools which WILL change in near future. Do not use anything described here in production.

То есть, фактически, нормального решения пока нет?

Это было экспериментально на момент написания статьи, сейчас это уже вполне нормальное решение. И это не единственное решение, просто лень искать более честные методы.

Тикет о поддержке closure compiler — закрыт 3 дня назад. И это нормальное стабильное решение?
Репозиторий с примером кода — требует Brotli. То есть вместо джентельменского сравнения полученного кода нужно применять читы в виде более агрессивного сжатия, чтобы получить адекватные цифры?

НЛО прилетело и опубликовало эту надпись здесь
Так в doom2 была музыка, спрайты и куча куча всего! А в angular2 даже музыки нет.
Если его собрать в --prod, то будет несколько сотен килобайт.
В моём приложении для учёта долгов на Ionic/Angular основной модуль 289KB gzip — вполне приемлемо за предоставляемый функционал.

Заявлено что в дальнейшем только лучше будет.
Пробовал второй ангуляр — удобная разработка благодаря Typescript, хорошая документация, если читаете по английски. Но тонкие моменты освещены недостаточно широко.

Например, создание динамических компонентов, их вставка в кастомные элементы таба. Так же недостаточно информации о повторном использовании созданных компонентов для текущего роутера, у которого меняется только переменная часть типа :id.

К сожалению, не пересоздавать компоненты при переходах между разными роутерами пока невозможно.
Насколько я помню на GitHub в комментариях к issue на это тему были примеры как можно реализовать сохранение компонентов.

Не это: https://github.com/angular/angular/issues/5275#issuecomment-291757819
спасибо за ссылку, видел её… как раз для случая, когда роутер и компонент теже
меняется лишь динамическая часть URL

здесь вместо создания нового объекта компонента используется старый объект с новыми значениями внутренних полей — роутер-то остается старым, хоть и меняется URL…

а вот когда URL новый и связан с другим роутером и компонентом — тогда предыдущий разрушается
возможно я ошибаюсь, но это работает, если роутер не меняется

Прошу меня извинить, но тут всё так по пунктам разложено, что я не смог удержаться и не сравнить с тем фреймворком, что разрабатываем мы :-)


Начиная работу над проектом, мы выбрали популярный сейчас стек React + Redux + [Reselect, Redux-Saga, Redux-form, etc].

Нет ничего хуже, чем выбирать инструмент не по его практичности, а по популярности. Популярность приходит и уходит. Поэтому выбирать надо такой инструмент, который даже без популярности позволяет эффективно развивать проект, не превращая его в болото, в котором никто не может разобраться. Этим "популярный сейчас стек" и плох — он требует больших объёмов копипасты ради сомнительных целей.


Angular — это фреймворк

Стоит отметить, что Ангуляр — это низкоуровневый фреймворк. Он предоставляет архитектуру и набор инфраструктурных библиотек, но не предоставляет готовых решений. Выливается это в те же проблемы, что и с React&Co — в проект тянутся компоненты из разных источников, написанные как правило кое-как. Или велосипедятся свои компоненты даже для базовых вещей (кнопки там, формочки, графики и пр). Поэтому, разрабатывая свой фреймворк, мы сразу задались целю создать стандартную библиотеку компонент, идеально совместимых друг с другом, и которую комьюнити сможет улучшать легко и просто. Достигается это следующим образом:


  1. Все компоненты сразу выкачиваются в проект в отдельную директорию, при желании разработчик может их тут же изменить и закоммитить, предложив в дальнейшем пул-реквест.
  2. Все компоненты очень маленькие и решают свою конкретную задачу. Это упрощает их разработку, поддержку и просто исследование, показывает разработчикам "хорошие практики" и позволяет легко компоновать их с другими компонентами.
  3. Ничто не мешает разработчикам создавать свои наборы компонент и распространять их наравне с фреймворком. Достаточно воспользоваться сторонним компонентом в своём коде и он автоматически будет скачан и включён бандл.

в Angular все равно можно устроить хаос, но это сделать гораздо сложнее

Это хороший принцип. Фреймворк должен побуждать разработчика к хорошим практикам и препятствовать применению плохих. В соответствии с ним мы навязываем следующие идеи:


  1. Именование должно соответствовать расположению. По имени модуля всегда понятно где лежит его код. Это естественным образом гарантирует уникальность имён всех модулей и позволяет сборщику понимать какие файлы включать бандл просто по факту использования описанных в них модулей.
  2. У каждого компонента должно быть уникальное имя в рамках владельца. Это имя используется для стилизации и для динамического формирования интерфейса.
  3. Стилизация по БЭМ. Соответствующие атрибуты генерируются автоматически по уникальным именам. Разработчику остаётся лишь написать стили для них.
  4. Разделение логики (скрипты), структуры (шаблоны) и оформления (стили). Это позволяет программисту и верстальщику не мешать друг другу. Повышает эффективность верстальщика, не требуя от него знания программирования. Позволяет верстальщику вносить изменения в уже работающие компоненты.

Наличие cli системы

Опять же, мы сразу разработали cli, который обеспечивает все необходимые процессы: девелоперский сервер, сборка по требованию, компиляция TS, JS, CSS, шаблоны и прочее в бандлы с отдельными сорсмапами. Примечательная особенность — отсутствие "девелоперского" режима сборки — всегда собирается ровно то, что будет крутиться на проде. Тесты билдятся в отдельный бандл. Сразу билдятся бандлы под разные окружения: нода, веб, кордова.


Холодный старт, при учете что vendor у нас вынесен в dll, у нас занимает около 30 секунд. При изменении пересборка по прежнему идет около 6-8 секунд.

У нас свой реактивный сборщик, который сам отслеживает записимости. Так что при изменении, например, стилей — пересобирается только CSS бандл. А результат парсинга TS файлов кешируется (с автоматической инвалидацией, размеется).


Прогнал сейчас для всей стандартной библиотеки (включая десяток демо приложений и кучу компонент). Холодная сборка CSS, JS бандлов и бандлов с локализацией — 12с. Горячая сборка JS бандла при изменении TS файла — 6c.


Кроме этого, у консольного клиента есть огромный плюс в том, что он сразу генерирует минимальный шаблон приложения

У нас минимальный шаблон приложения — пустая директория, для этого даже не нужен никакой cli. Просто создаётся директория, в неё накидываются файлы и вложенные директории. Любую директорию можно собрать в бандлы. Это позволяет в одной кодовой базе иметь множество приложений и множество отчуждаемых библиотек. Собственно любой модуль можно собрать в независимых бандл, включающий как его, так и все его зависимости. Модуль — это директория с файлами на самых различных языках: стили, скрипты, шаблоны, картинки, тесты и пр.


Typescript
Вы можете не только создавать новые теги для html-разметки, но и изменять существующие.

Весь код у нас написан на TS, даже "шаблоны" компилируются в TS со всеми вытекающими. Любой компонент — это обычный TS-класс. При создании своего компонента достаточно просто отнаследоваться от уже существующего и расширить его своим поведением. Причём создать компонент может даже верстальщик в "шаблоне", не написав ни единой строчки скриптов, а потом уже программист может добавить компоненту поведение, не меняя "шаблона".


Вы можете настраивать поведения компонента, меняя параметры работы Change Detector или работы компонента с CSS-классами.

Наши компоненты построены по открытому принципу — у них отсутствует какое-либо приватное апи, что позволяет настраивать их извне как душе угодно, при этом не ломая их, так как взаимодействие с состоянием всегда происходит через реактивные акцессоры. У нас нет никакого change detector, вместо него у нас наиболее эффективная на сегодняшний день реализация Объектного Реактивного Программирования, которая позволяет писать простой, понятный и быстрый код. Ещё один принцип, которым мы руководствовались — написать эффективный код должно быть проще, чем неэффективный.


Можно указать какие параметры могут приходить компоненту на вход и какие события могут от него исходить.

Как уже было сказано, любое свойство у наших компонент — это одновременно и его "параметр", который можно менять при создании. Это своего рода DI. Благодаря этой идее у нас реализуется не просто настройка, но и связывание компонент между собой: односторонние (как в одну, так и в другую сторону) и двусторонние биндинги. Соответственно и событий никаких у нас нет — компонент просто меняет своё локальное свойство, но владелец может его подменить на свою реализацию.


Библиотека RxJS позволяет мне творить очень крутые вещи с обработкой данных и почти всегда мой код работает так, как я и задумал.

Достигается это очень большой ценой. Эффективный код на RxJS — крайне громоздкая штука, в которой легко накосячить. А по умолчанию RxJS работает крайне не эффективно. Сравните, например, два примерно эквивалентных кода на FRP и ORP:


FRP


const Greeting = Is_name_showing
.select( is_name_showing => {
    if( is_name_showing ) {
        return User_name
        .map( user_name => {
            return `Hello, ${ user_name }!`
        } )
    } else {
        return Rx.Observable.of( 'Hello!' )
    }
} )
.switch()
.distinctUntilChanged()
.debounce( 0 )

ORP


greeting() {
    if( this.is_name_showing() ) {
        return `Hello, ${ this.user_name() }!`
    } else {
        return 'Hello!'
    }
}

когда ваш фреймворк использует то же, что и вы, можно легко связывать свой код с фреймворком, например, используя HTTP-модуль Angular

Наша реализация ОРП позволяет писать даже такой код:


@ $mol_mem()
namesakes_message() {
    const texts = this.texts()
    const user = this.user()
    const count = this.namesakes_count( user.name )

    return texts.namesakes_message
    .replace( /\{count\}/g , count )
}

При этом texts будет загружен в параллель с user и count, но count только после загрузки user, так как зависит от него по данным.


Довольно посредственная документация

У нас она, по отзывам, тоже так себе, но это компенсируется нарочно простым и понятным кодом. Тем не менее мы работаем над её улучшением. Для всех компонент у нас уже есть демо страничка. А в скором времени мы планируем добавить к ней "конструктор", который позволит взять любую демку, посмотреть какие там у компонента свойства, какие их значения, засунуть туда что-нибудь своё и даже запрототипировать своё приложение.


Кто пробовал создавать компоненты в Angular динамически, меня поймут.
Использовать AOT-компиляцию, что исключит runtime-компилятор из вашего кода, а он немало весит.

У нас компиляция кода происходит строго на сервере и строго в бандлы. Тем не менее все компоненты у нас создаются динамически с помощью фабрик, которыми владеет компонент-владелец. То есть в рантайме перекомпоновывать компоненты можно как угодно: можно ссылку вложить в карточку, можно наоборот, а можно оставить что-то одно.


Если использовать Angular из коробки, то на выходе мы получаем здоровенные модули
Исключить те модули, которые не используете.

У нас все модули очень маленькие и включаются в бандл лишь те, что фактически используются, так что размер бандла не зависит от размера библиотеки, а зависит от объёма используемого функционала. Бандлы у нас получаются настолько маленькими, что мы их даже не минифицируем, чтобы не огребать проблем с отладкой и долгой сборкой. Вся стандартная библиотека (включая десяток демо приложений и кучу компонент) у нас сейчас занимает полторы сотни килобайт в зазипованном виде.


Использовать Lazy loading-модули.

Маленькие бандлы у нас грузятся и инициализируются быстро, так что мы просто грузим их целиком при старте приложения и далее оно работает максимально эффективно без лишних запросов к серверу. Ленивая же загрузка модулей приводит к двум хопам: сначала за модулем, а затем за данными, которые он запросит. А если у того модуля ещё и зависимости, то хопов будет пропорционально глубине. Без ленивой загрузки модулей можно сразу показать пользователю страницу, на которую он перешёл, а на ней уже индикатор загрузки данных в тех местах, для которых данных ещё нет.


И мы не предполагаем, что его кто-то станет использовать с мобильных девайсов, для этого лучше сделать отдельное native-приложение.

А мы как раз разрабатываем в расчёте в том числе и на мобильные приложения, поэтому:


  1. Разрабатываем компоненты так, чтобы они и под большой экран адаптировались и под маленький. Всё на флексах без media-queries, что позволяет адаптироваться столько к размеру экрана, сколько к размеру контейнера.
  2. Рендерим все компоненты по возможности лениво, стараясь не рендерить то, что пользователь всё-равно не видит. Это позволяет переключаться между страницами крайне быстро.

Сложный порог входа

Мы постарались сделать правила работы как можно более простыми и интуитивными, но некоторые привычки всё же придётся кардинально менять:


  1. Отказ от HTML в пользу композиции компонент. Верстальщику придётся выучить новый язык (который не сложнее HTML), но оно того стоит — код получается лаконичным, но мощным.
  2. Перестроение мышление с контроля потока (императивное программирование) на контроль данных (реактивное программирование). Опять же, оно того стоит — архитектура приложения (и не только приложения, по тем же принципам можно строить целые информационные системы) получается гораздо более простой и предсказуемой.
  3. Опять же TypeScript. Но мы намеренно не вводим сложные конструкции и тучи интерфейсов. Код у нас как правило очень поход на JS, так как мы по максимуму используем автоматическое выведение типов.

А теперь о минусах: всего 50 звёзд на гитхабе. Расходимся, ребята :-)

А ссылочку дадите на Ваш чудо фреймворк? А то я больше люблю смотреть в код, чем читать буковки.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется у вас что-то не так со структурой проекта, зашёл на github — https://github.com/eigenmethod/mol и вижу около 100 папок в корне проекта.

Мой опыт подсказывает, что широкая иерархия практичней, чем глубокая. А вы бы как сгруппировали?

Я бы на первом уровне иерархии выделил папки только под основные сущности вашего приложения: core, components, assets и т.п. На сколько я понимаю большая часть ваших папок является компонентами и если бы они были объединены в одну папку, в которой 100 других, но 100% все они являются компонентами, то не было бы вопросов.

У нас микоядерная архитектруа, так что никакого core у нас нет. assets тоже нет, ибо ресурсы кладуются рядом с кодом, который их использует. Можно было бы разделить на "визуальные компоненты" и "всё остальное", но польза сомнительна, а имена все увеличатся.

Что такое микроядерная архитектура применительно к js фреймворку?

Отсутствие какого-то общего для всего фреймворка ядра. Одни модули используют одни модули, другие — другие. В зависимости от того, какие модули вы используете — может быть загружен совершенно разный набор модулей.

Наверняка есть какие-то классы (модели) от которых наследуются ваши модули?
Я же не смогу взять отдельно какую-то папку с одним компонентом и вставить себе в проект, что бы он работал?

Некоторые модули не имеют зависимостей, но да, как правило есть зависимости, которые не сложно собрать в небольшой независимый бандл.

Верстальщику придётся выучить новый язык (который не сложнее HTML), но оно того стоит — код получается лаконичным, но мощным.

Вот это — истинный убийца вашего чудо-фреймворка.

Нельзя повысить эффективность, не меня привычки. Вот тут я попытался описать то же самое в json и xml форматах — кода получилось больше, понятней не стало.

Так вот ведь в чем дело — нет у верстальщика никакой проблемы с эффективностью.

Есть :-)


Как обычно работает верстальщик:


  1. Создаёт отдельную страничку, копипастит туда кучу хтмл, чтобы тестить компонент в различных вариациях.
  2. Руками прописывает классы.
  3. Периодически руками вносит изменения в каждую копию компонента.
  4. Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.

Далее идёт два варианта:


  1. Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.
  2. Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент. Так как верстальщик не может видеть этот компонент во всех возможных состояниях одновременно — постоянно где-то что-то ломается.

Как это происходит у нас:


  1. Верстальщик не просто фигачит хтмл, а сразу создаёт переиспользуемые компоненты, используя другие компоненты. Всё это используя простой декларативный синтаксис.
  2. Тут же он создаёт демо-компонент, для своего компонента, который выводит его компонент в различных вариациях.
  3. Этот демо-компонент автоматически появляется в библиотеке компонент, где он сможет увидеть свой компонент в различных вариациях.
  4. Ему не надо прописывать классы — нужные классы генерируются автоматически, ему остаётся лишь добавить стилей.
  5. Параллельно с ним может работать программист, который расширяет созданный верстальщиком компонент, добавляя ему поведение. При этом программисту либо не потребуется вносить изменение в "шаблон", либо эти изменения будут незначительным и понятными верстальщику.
  6. В любой момент верстальщик может вернуться к компоненту и поправить что-то в нём и даже сделать редизайн, совершенно не парясь по поводу программной логики и видя свой компонент во всех вариациях одновременно.

Ну вот возьмём компонент "карточка":


Итак, вы прекрасно объяснили почему при использовании вашего фреймворка верстальщику приходится его изучать.


Осталось объяснить почему это является достоинством фреймворка, а не его недостатком.


Для справки: в том же knockout или angular не происходит никаких


Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.

Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.

Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент.

Нет, я объяснил, что правильная организация труда и грамотная архитектура повышает эффективность работы как отдельно взятых верстальщика и программиста, так и их взаимодействия. И для этого необходимо разобраться в новых концепциях.

Вы создали соломенное чучело и разнесли его в пух и прах. Повторюсь, тех ужасов которые вы описали — не происходит.

Вот как описали вы — только без указанных мною пунктов. Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга. Верстальщик при необходимости напрямую меняет страницу, не обращая внимания на непонятные атрибуты, используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях.


В случае затруднений есть скайп.

Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга.

Хороший программист разбивает html от верстальщика на компоненты. Потом приходит верстальщик и не может найти свою копипасту.


используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях

Вручную накликивая по очереди все состояния? Ну да, очень "эффективно". Замечу, что проверять надо не только с разными состояниями самого компонента, но и различные комбинации компонент. Банально: страница с шапкой, страница с шапкой и подвалом, страница шапкой, подвалом и двумя колонками.

Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.


Ровно как и не занимается созданием компонент, состоящих из одного элемента.


И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...

Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.

Нет, который может быть использован и на других страницах. И по хорошему, это должен предусмотреть ещё верстальщик, но для этого его надо научить создавать компоненты, чтобы он не копипастил код, а переиспользовал через компонентную декомпозицию.


И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...

На разных страницах разный набор контролов, но построены из общих компонент. Я понимаю, непривычно, смотреть на приложение, не как на набор статичных страниц, а как на набор кубиков лего, и которых можно по разному составлять страницы и даже одну страницу динамически менять в зависимости от различных условий, но это позволяет быстрее создавать консистентные интерфейсы.

Не могу представить себе общий компонент для профиля пользователя и списка документов...

Почему? Вот наведите курсор на мою аватарку и увидите шапку моего профиля. А список документов тем более надо выносить в отдельный компонент, мало ли куда нужно будет приаттачивать документы — незачем изобретать велосипед.

Шапка профиля, подобная той которая там возникает, не относится к странице напрямую. Она делается в рамках отдельной задачи и верстается отдельно.

Да нет, сначала обычно делается большой профиль, а потом приходит менеджер и говорит "нам надо сделать, чтобы при наведении на аватар показывалась краткая инфа, как в шапке профиля, у вас есть пол часа".

Тоже создалось впечатление, что сначала активно преувеличили проблему, потом героически ее решили :)
А не пугают beraking changes минимум раз в год в Angular? (А скорее всего каждые пол года)
За все время что мы используем новый Angular я всего лишь раз столкнулся с проблемой от beraking changes и она решилась за час. Так что пока не пугают.
Меня вот пугает =) Но JavaScript тоже на месте не стоит =) Не успеешь выучить одно, а через год уже что то новенькое. Тяжелая ноша фронтенщика.

Новенькое без ломания старенького можно внедрять постепенно или обходиться только стареньким. А вот когда обратную совместимость ломают, то надо код переписывать. Что особенно весело, если никому толком не понятно, а что код должен делать в терминах бизнеса, UI и т. п.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

9 января 2004

Местоположение

Россия

Численность

201–500 человек

Дата регистрации

5 октября 2016

Блог на Хабре