А чем она кардинально отличается, если написана адекватно, м?
эээ… ну, это будет просто другая реализация всё той же компонентной модели. Всё же лучше так ничего и не придумано. Ну не будет наследования — будет композиция. Не ООП — так функциональщина. Один фиг главная идея остаётся та же: separation of concern и single responsibility, конкретные детали неважны.
Мы же тут пытаемся противопоставить монолитный/лапшекод грамотной декомпозиции, нет? Я в принципе могу себе представить организацию приложения без разбиения на компоненты, ну там глобальный стейт, шина событий, шина данных, общий рендерер (тут уже с трудом), но не очень понимаю, зачем. Разве что для совсем простых и маленьких приложений или если вся логика на сервере живёт (реальный пример, кстати). И поддержка таких архитектур неизбежно будет сложнее и дороже.
Запилить что-то новое в цельный, грамотно написанный проект — это та ещё задачка.
А вот если у вас всё написано «на велоспидах»… — вполне нормальная задача в большинстве случаев.
Ну вот не совсем, причём местами до степени инверсии. Всё зависит от реализации и новой задачи.
Если грамотный проект поддерживает расширение и задача в него укладывается — вопроса нет вообще. Если не укладывается, надо смотреть причины, фреймворк может быть виноват, а может и нет. Например, на ангуляреЖС надо компилировать в разметку некую рекурсивную вложенную структуру — задача решается; та же структура с количеством итоговых watch >2к — уже скорее всего нет. А может это красивый ангуляр 7 и нам нужно обеспечить рендеринг динамической разметки, а у нас АОТ — и упс.
И ещё бывает, что фреймворк устраивает, всё решает, но он уже умер. И что тогда?
А самое противное — фреймворк на то и фреймворк, а не библиотека, что он решает свой класс задач во всей полноте. И при этом не желает делиться.
Возьмём, к примеру, тот же ангулярЖС. Прекрасный фреймворк для своего времени. Возьмём просто ангуляр, тоже замечательная штука. Возьмём приложение на «старом» ангуляре и перепишем его по кусочкам на новый в так называемом гибридном режиме, там для этого всё есть. Во что мы упрёмся? В роутинг, который несовместим (да там почти всё несовместимо, но вот именно роутинга нельзя иметь одновременно два без реально глобальных извращений. Ну или я не знаю, как). Проблема фреймворка? Да, но не совсем. Был бы велосипед — было бы проще? А как сказать, всё зависит от реализации. И вполне может быть, что нормально подключить фреймворк к велосипеду ничуть не легче, чем переписать с нуля — я легко могу придумать не одну такую ситуацию. Могу и обратную.
И вот тут как раз у реакта/вью преимущество, потому что они изначально менее навязчивы и рассчитаны на разные альтернативные решения: их легче разобрать. Но у них оверхед размазан по управлению кодом. Тоже (по сравнению с фреймворками высокой степени интеграции типа ангуляра или, например, руби) набор велосипедов с более-менее одинаковыми колёсами и от известного производителя.
PS я немного теряю нить спора — похоже, мы во мнениях в основном сходимся, но я не могу объяснить тогда Ваше изначальное слишком резкое заявление насчёт реакта, потому что он и в Вашу концепцию велосипедостроения вписывается, и Вы сами признаёте, что всё в итоге зависит от задачи и ресурсов.
На проекте серьёзнее лэндинга возникает вопрос поддержки. Кто будет клевать код на фреймворке на любой вкус через год?
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует. Допустить зоопарк и хаос на уровне архитектуры не просто, а ну очень просто — в отличие от ангуляра, где за разработчика продумано чуть больше, чем всё (не то, чтобы там было нельзя, но обычно это сложно и не нужно). Зато и падает такой проект в итоге с большим грохотом, так что надо искать баланс.
А как насчёт дальнейшей поддержки не компонентного кода? Смены требований? Расширения функционала? Замены устаревших зависимостей?
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.
Безусловно, три четверти магии именно в тюнинге вебпака. То есть, ручная настройка правил для чанков, принудительный чанк для UI библиотеки (паттерн реэкспорта), контроль утечек (чанк-ловушка), мульти-конфиги (entry point недостаточно) и тому подобное.
Но технически можно обойтись и без. И даже совсем без вебпака, и, кстати, галп на такой вид сборки ложится лучше.
Более того, я встречал и сопровождал проекты с plain-конфигами в десяток раз сложнее. Всякие там бабели, хитроумные правила, самодельные плагины и лоадеры и прочее, что с треском ломается при смене версии вебпака… или ангуляра… или ещё чего-то постороннего.
Спасибо, коротко и по делу. Но есть один вопрос — «Мне это позволило срезать дополнительные 20%» — 20% чего? Размера, времени загрузки?
Насчёт же сплиттинга есть ещё один вариант. Немножко сильно извращённый, но не мы такие, жизнь такая (ц). Зато это действительно сплиттинг так сплиттинг =)
Итак, есть приложение, и оно сравнительно велико — сотни форм, десятки бизнес-модулей, мегабайты кода, годы легаси, сотни нефти. Сплиттить его на уровне компонентов особого смысла нет, потому что роутинг вне контроля и lazy loading я не представляю, как заставить работать с пользой. Ну то есть представляю, но не вижу смысла: тот же Moment, или RxJS, или UI кит нужны всем всё равно и в итоге — практически в полном объёме. Заворачивать их в динамический импорт можно, но свой велосипед всегда трёхколёсней и к нему можно прикрутить парус, крылья и магнитолу.
Идея состоит в том, чтоб порезать бизнес-функционал на мини-приложения, для которых в их бандле будет всё, относящееся к собственно куску доменной модели, а всё внешнее (реакт, реакт-дом, рх, момент etc.) грузится как предсобранные минифицированные бандлы (webpack externals + chunk optimization). Ну или если вы верите в тришейкинг — собираются в общем потоке сборщика в бандлы один к одному (то есть реакт идёт в бандл «реакт», момент в «момент» и т.д.) или по вкусу (всё в «вендор», например). В обоих подходах есть свои плюсы и минусы.
Затем некий небольшой скрипт на чистом незамутенённом TS/JS, которому доступны сведения о доступных прикладных бандлах, так или иначе интегрируется с остальным кодом и вешается на «внешние» события «появление компонента» и «уход компонента» и, собственно, на маппинг «что мы хотим показать, где оно лежит физически и в какой контейнер это монтировать».
Такой себе самодельный мини-роутер, который по событию разрешает зависимости, загружает конкретный прикладной скрипт (бандл) и вызывает из него нужную функцию монтирования/демонтирования. Ну и ещё много чего полезного он должен делать, например обрабатывать ошибки и предоставлять shared-интерфейсы и шину сообщений. Но в целом — ничего сложного.
Выгода в чём: мини-приложения инкапсулируют достаточно серьёзные куски приложения (и логика, и разные view) и могут быть собраны и задеплоены совершенно отдельно при условии соблюдения контрактов и если рантайм не менялся (это к вопросу тришейкинга и «как собирать рантайм»). Грузятся они по запросу, асинхронно, размер маленький, код изолирован, тесты изолированы, платформа запуска тоже компактная и легко мокается — цель code splitting + code bundling достигнута. Для полного счастья при соблюдении несложных условий мини-приложения могут быть вообще на разных технологиях. Счастье для всех даром, но это не точно.
Минусы, понятно, в общей сложности такого многокомпонентного решения. Нужен довольно продвинутый сборщик и для малых/средних проектов, или проектов с полным контролем кода оболочки оно того не стоит. Кроме того, если есть много взаимозависимостей, то придётся изобретать велосипед ещё и для продвинутого DI, ну и работает всё всё равно в едином окружении (window) и при желании или кривых руках разработчика отдельного модуля можно сильно подгадить остальным. В итоге решение выливается практически в свой фреймворк и нужно тщательно оценивать издержки на сопровождение.
Ну и мало кто из «больших» платформ позволяет нормально бутстраппить, монтировать и ре-монтировать множество sub-tree. Собственно, только React, Vue, и, сюрприз, AngularJS (правда, через хак и вообще это сомнительное развлечение).
Я мечтаю о каком-то механизме, позволяющем иметь «общее пространство», чтобы все _вкладки_ _выбранного_ окна синхронизировались на нескольких машинах. Пусть даже по кнопке — начал читать на десктопе, продолжил на ноуте, потом в дороге с телефона открываешь-закрываешь табы, и их набор и позиция везде одинаковы. И на разных платформах =)
Возвращаясь к теме с эджем: я был впечатлён, как эдж хандлит epub с флибусты. Случайно кликнул, а он открыл и показал вполне себе прекрасную встроенную читалку, получше эпловской штатной, кстати. То же для пдф, так что у меня эдж используется как книгочиталка по умолчанию.
Из синхронизированных вкладок нет (и это бесит), но пересланные как минимум открывает на том же месте. Не могу сказать за кэш, не проверял, но, думаю, маловероятно, ибо объёмы.
Синхронизация умеет, но кривовато и с непонятными задержками — смотреть «История/Синхронизированные вкладки». А послать руками ссылку можно по трём точкам в строке адреса справа, «Действия страницы», там есть «Отправить на устройство». Работает хорошо.
Четвёрка пока кривовата для перехода в продакшене. Нет, ну, в принципе, почти всё можно заставить работать… но подбор работающих плагинов/конфигураций, мягко говоря, напрягает, а сложные случаи не работают вообще. Там кривовато, там несовместимо, там ворнинги, там watch глючит… я бы с полгодика подождал ещё. Заодно ангуляр 6 выйдет, может, за это время починят набор базовых плагинов, а то пока печально.
ЗЫ на ng-europe народ шутил «это ж как надо было криво написать версию 3, чтобы получить 90+% прироста на версии 4?»
ЗЫ2 лично такого прироста не наблюдаю и близко, процентов 20 от силы, но это на сложных проектах.
эээ… ну, это будет просто другая реализация всё той же компонентной модели. Всё же лучше так ничего и не придумано. Ну не будет наследования — будет композиция. Не ООП — так функциональщина. Один фиг главная идея остаётся та же: separation of concern и single responsibility, конкретные детали неважны.
Мы же тут пытаемся противопоставить монолитный/лапшекод грамотной декомпозиции, нет? Я в принципе могу себе представить организацию приложения без разбиения на компоненты, ну там глобальный стейт, шина событий, шина данных, общий рендерер (тут уже с трудом), но не очень понимаю, зачем. Разве что для совсем простых и маленьких приложений или если вся логика на сервере живёт (реальный пример, кстати). И поддержка таких архитектур неизбежно будет сложнее и дороже.
Ну вот не совсем, причём местами до степени инверсии. Всё зависит от реализации и новой задачи.
Если грамотный проект поддерживает расширение и задача в него укладывается — вопроса нет вообще. Если не укладывается, надо смотреть причины, фреймворк может быть виноват, а может и нет. Например, на ангуляреЖС надо компилировать в разметку некую рекурсивную вложенную структуру — задача решается; та же структура с количеством итоговых watch >2к — уже скорее всего нет. А может это красивый ангуляр 7 и нам нужно обеспечить рендеринг динамической разметки, а у нас АОТ — и упс.
И ещё бывает, что фреймворк устраивает, всё решает, но он уже умер. И что тогда?
А самое противное — фреймворк на то и фреймворк, а не библиотека, что он решает свой класс задач во всей полноте. И при этом не желает делиться.
Возьмём, к примеру, тот же ангулярЖС. Прекрасный фреймворк для своего времени. Возьмём просто ангуляр, тоже замечательная штука. Возьмём приложение на «старом» ангуляре и перепишем его по кусочкам на новый в так называемом гибридном режиме, там для этого всё есть. Во что мы упрёмся? В роутинг, который несовместим (да там почти всё несовместимо, но вот именно роутинга нельзя иметь одновременно два без реально глобальных извращений. Ну или я не знаю, как). Проблема фреймворка? Да, но не совсем. Был бы велосипед — было бы проще? А как сказать, всё зависит от реализации. И вполне может быть, что нормально подключить фреймворк к велосипеду ничуть не легче, чем переписать с нуля — я легко могу придумать не одну такую ситуацию. Могу и обратную.
И вот тут как раз у реакта/вью преимущество, потому что они изначально менее навязчивы и рассчитаны на разные альтернативные решения: их легче разобрать. Но у них оверхед размазан по управлению кодом. Тоже (по сравнению с фреймворками высокой степени интеграции типа ангуляра или, например, руби) набор велосипедов с более-менее одинаковыми колёсами и от известного производителя.
PS я немного теряю нить спора — похоже, мы во мнениях в основном сходимся, но я не могу объяснить тогда Ваше изначальное слишком резкое заявление насчёт реакта, потому что он и в Вашу концепцию велосипедостроения вписывается, и Вы сами признаёте, что всё в итоге зависит от задачи и ресурсов.
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует. Допустить зоопарк и хаос на уровне архитектуры не просто, а ну очень просто — в отличие от ангуляра, где за разработчика продумано чуть больше, чем всё (не то, чтобы там было нельзя, но обычно это сложно и не нужно). Зато и падает такой проект в итоге с большим грохотом, так что надо искать баланс.
Как всегда.
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.
Но технически можно обойтись и без. И даже совсем без вебпака, и, кстати, галп на такой вид сборки ложится лучше.
Более того, я встречал и сопровождал проекты с plain-конфигами в десяток раз сложнее. Всякие там бабели, хитроумные правила, самодельные плагины и лоадеры и прочее, что с треском ломается при смене версии вебпака… или ангуляра… или ещё чего-то постороннего.
Насчёт же сплиттинга есть ещё один вариант. Немножко сильно извращённый, но не мы такие, жизнь такая (ц). Зато это действительно сплиттинг так сплиттинг =)
Итак, есть приложение, и оно сравнительно велико — сотни форм, десятки бизнес-модулей, мегабайты кода, годы легаси,
сотни нефти. Сплиттить его на уровне компонентов особого смысла нет, потому что роутинг вне контроля и lazy loading я не представляю, как заставить работать с пользой. Ну то есть представляю, но не вижу смысла: тот же Moment, или RxJS, или UI кит нужны всем всё равно и в итоге — практически в полном объёме. Заворачивать их в динамический импорт можно, но свой велосипед всегда трёхколёсней и к нему можно прикрутить парус, крылья и магнитолу.Идея состоит в том, чтоб порезать бизнес-функционал на мини-приложения, для которых в их бандле будет всё, относящееся к собственно куску доменной модели, а всё внешнее (реакт, реакт-дом, рх, момент etc.) грузится как предсобранные минифицированные бандлы (webpack externals + chunk optimization). Ну или если вы верите в тришейкинг — собираются в общем потоке сборщика в бандлы один к одному (то есть реакт идёт в бандл «реакт», момент в «момент» и т.д.) или по вкусу (всё в «вендор», например). В обоих подходах есть свои плюсы и минусы.
Затем некий небольшой скрипт на чистом незамутенённом TS/JS, которому доступны сведения о доступных прикладных бандлах, так или иначе интегрируется с остальным кодом и вешается на «внешние» события «появление компонента» и «уход компонента» и, собственно, на маппинг «что мы хотим показать, где оно лежит физически и в какой контейнер это монтировать».
Такой себе самодельный мини-роутер, который по событию разрешает зависимости, загружает конкретный прикладной скрипт (бандл) и вызывает из него нужную функцию монтирования/демонтирования. Ну и ещё много чего полезного он должен делать, например обрабатывать ошибки и предоставлять shared-интерфейсы и шину сообщений. Но в целом — ничего сложного.
Выгода в чём: мини-приложения инкапсулируют достаточно серьёзные куски приложения (и логика, и разные view) и могут быть собраны и задеплоены совершенно отдельно при условии соблюдения контрактов и если рантайм не менялся (это к вопросу тришейкинга и «как собирать рантайм»). Грузятся они по запросу, асинхронно, размер маленький, код изолирован, тесты изолированы, платформа запуска тоже компактная и легко мокается — цель code splitting + code bundling достигнута. Для полного счастья при соблюдении несложных условий мини-приложения могут быть вообще на разных технологиях. Счастье для всех даром, но это не точно.
Минусы, понятно, в общей сложности такого многокомпонентного решения. Нужен довольно продвинутый сборщик и для малых/средних проектов, или проектов с полным контролем кода оболочки оно того не стоит. Кроме того, если есть много взаимозависимостей, то придётся изобретать велосипед ещё и для продвинутого DI, ну и работает всё всё равно в едином окружении (window) и при желании или кривых руках разработчика отдельного модуля можно сильно подгадить остальным. В итоге решение выливается практически в свой фреймворк и нужно тщательно оценивать издержки на сопровождение.
Ну и мало кто из «больших» платформ позволяет нормально бутстраппить, монтировать и ре-монтировать множество sub-tree. Собственно, только React, Vue, и, сюрприз, AngularJS (правда, через хак и вообще это сомнительное развлечение).
В общем, нишевое, но рабочее решение.
PS ого сколько написал. Сорри, увлёкся =)
Возвращаясь к теме с эджем: я был впечатлён, как эдж хандлит epub с флибусты. Случайно кликнул, а он открыл и показал вполне себе прекрасную встроенную читалку, получше эпловской штатной, кстати. То же для пдф, так что у меня эдж используется как книгочиталка по умолчанию.
ЗЫ на ng-europe народ шутил «это ж как надо было криво написать версию 3, чтобы получить 90+% прироста на версии 4?»
ЗЫ2 лично такого прироста не наблюдаю и близко, процентов 20 от силы, но это на сложных проектах.