Comments 52
Думаю выпиливание реакта вам сэкономт ещё 20%.)
Я даже jQuery с половины проектов выпилил. К сожалению для более менее крупных приложений это немного не выход.
Писать реально крупный проект на React — это либо обрекать себя на штат программистов (только на фронт) человек в 20 уже с первых шагов проекта, либо просто удлинить себе таким садистским образом переход на что-нибудь более вменяемое.
А что более вменяемое?
Озвучьте внятное ТЗ, мы предложим варианты реализации.
Ну Вы сказали, что крупный проект на react пилить не стоит.
Я не троллю, я правда спрашиваю, на чем лучше?
Вы без ТЗ сказали, что нужно выкинуть реакт, так что ТЗ предоставить не могу
Ну так сложный проект он на то и сложный, что там нельзя сказать «а нука сделаю я всё на jquery», но нужно чётко понимать задачи и цели, чтобы выбрать подходящий инструмент.
Собственно, мой первый коммент был скорее про ситуацию когда «всё что делает ваше приложение — это иногда обновляет данные с сервера и отображает их в таблицу», то лучше сделайте это хоть на jquery, чем на реакте.
Что касается лично моего мнения — мне очень нравится AngularJS. Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса. Часто слышу также, что дескать первая версия устарела, а вот в Angular 2+ всё уже реально круто. Ну не знаю, почитал гайд из документации, понял что делать то, что там описано я точно не хочу, плюс там заметно сильное влияние концепций, популярных в реакте. Мне симпатизирует подход Backbone, но не довелось реализовывать на нём что-то сложнее тестовых задний, поэтому судить не могу.
Собственно, мой первый коммент был скорее про ситуацию когда «всё что делает ваше приложение — это иногда обновляет данные с сервера и отображает их в таблицу», то лучше сделайте это хоть на jquery, чем на реакте.
Что касается лично моего мнения — мне очень нравится AngularJS. Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса. Часто слышу также, что дескать первая версия устарела, а вот в Angular 2+ всё уже реально круто. Ну не знаю, почитал гайд из документации, понял что делать то, что там описано я точно не хочу, плюс там заметно сильное влияние концепций, популярных в реакте. Мне симпатизирует подход Backbone, но не довелось реализовывать на нём что-то сложнее тестовых задний, поэтому судить не могу.
Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса.
Вы ж вроде реакт не любите?
… ах вы это про angularJS написали, оказывается. Извините, не заметил.
мне очень нравится AngularJS. Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса.
Не всегда, есть в приципе нерешаемые проблемы, но главное для энтерпрайза — он снят с поддержки. Тут даже не в самом ангуляре затык, а в обвязке: jQuery, UI Bootstrap, прочие зависимости, некоторые из которых могут быть заброшены, а некоторые не иметь соместимых комбинаций. Другими словами, устаревающий неподдерживаемый стек. Другие чисто технические вопросы да, как правило можно или решить, или обойти, почти все, но и этого достаточно.
Мелким или короткоживущим, или неразвивающимся проектам может быть и пофигу — на несколько лет ещё хватит.
PS ангуляр 2+ ушёл вообще не туда, по моему скромному мнению. Слишком шарахнулся в противоположную сторону, обжёгшись на первом.
Тут даже не в самом ангуляре затык, а в обвязке: jQuery, UI BootstrapНу я вместо jQuery почти везде jqlite использую, плюс несколько самописных функций.
Что касается UI Bootstrap мне он вообще никогда не нравился, не понимаю зачем его все тащат в проекты на ангуляре.
он снят с поддержкиКстати, с чего вы решили? Последняя версия вышла месяц назад всего.
Из официальных источников. Это LTS, но новых фич не будет, только секьюрити патчи и малоприоритетный багфиксинг. Всем спасибо, всех ждём в новом ангуляре.
Например, вот.
Кстати, если посмотреть на топ-100 ангуляр-приложений, то очень много из них были и остаются на ангуляржс и никогда не будут переписаны на ангуляр 2+. А вот для финансового сектора, например, поддержка актуальности стека — критична.
Например, вот.
Кстати, если посмотреть на топ-100 ангуляр-приложений, то очень много из них были и остаются на ангуляржс и никогда не будут переписаны на ангуляр 2+. А вот для финансового сектора, например, поддержка актуальности стека — критична.
Вы так говорите об этой поддержке будто в Angular нет годами не фиксящихся багов, про воркераунды для которых люди даже статьи пишут.
Это тут при чём? Я говорю о ситуации, когда нужно обосновать использование замороженой технологии с известными уязвимостями в чувствительном секторе. То, что она 99% рабочая и будет рабочая ещё долго в некоторых случаях вообще не аргумент, потому что менеджмент сразу спрашивает «что будет с платформой через пять лет? как быстро будут устраняться баги? можете ли вы пообещать, что?..»
Уязвимости там как раз фиксят.
А на счёт «что будет с платформой через пять лет» — вам и про реакт никто не даст гарантии, что завтра фэйсбук не выкатит новый фрейм, а этот не отправит на помойку.
При этом, если в одном случае через пять лет проект «99% будет работать», и во другом — «из-за возросшей сложности проект надо переписать на другой фрейм», выбор вроде бы очевиден.
А на счёт «что будет с платформой через пять лет» — вам и про реакт никто не даст гарантии, что завтра фэйсбук не выкатит новый фрейм, а этот не отправит на помойку.
При этом, если в одном случае через пять лет проект «99% будет работать», и во другом — «из-за возросшей сложности проект надо переписать на другой фрейм», выбор вроде бы очевиден.
как быстро будут устраняться баги?
Не хотелось бы вас расстраивать, но вот именно со временем неустранения багов у Angular всё очень плохо, даже хуже, чем у AngularJS. Всему виной переусложнённая архитектура и просто тонны кода, из-за чего багов в нём очень много, а чинить их крайне сложно.
но новых фич не будетТак это и не поддержка, а развитие, как по мне.
Можно и так воспринимать. Если устраивает модель работы ангуляржс, его производительность и ограничения — почему бы и нет? Народ и на jQuery пишет, и на ванилле… вопрос в цене оверхеда (поддержка, багфикс, актуализация, люди) для вас. Может, у вас на рынке полно недорогих ангулярщиков или проект меняется раз в два года — случаи разные бывают.
У ангуляражс по крайней мере очень низкий порог вхождения. В первых десяти процентах кривой =)
У ангуляражс по крайней мере очень низкий порог вхождения. В первых десяти процентах кривой =)
А на голом JS с «реально крупным проектом», конечно же, справится сын маминой подруги?
На голом JS писать вовсе не обязательно, фреймворков на любой вкус сейчас, что называет, «куры не клюют».
На проекте серьёзнее лэндинга возникает вопрос поддержки. Кто будет клевать код на фреймворке на любой вкус через год?
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует. Допустить зоопарк и хаос на уровне архитектуры не просто, а ну очень просто — в отличие от ангуляра, где за разработчика продумано чуть больше, чем всё (не то, чтобы там было нельзя, но обычно это сложно и не нужно). Зато и падает такой проект в итоге с большим грохотом, так что надо искать баланс.
Как всегда.
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует. Допустить зоопарк и хаос на уровне архитектуры не просто, а ну очень просто — в отличие от ангуляра, где за разработчика продумано чуть больше, чем всё (не то, чтобы там было нельзя, но обычно это сложно и не нужно). Зато и падает такой проект в итоге с большим грохотом, так что надо искать баланс.
Как всегда.
Кто будет клевать код на фреймворке на любой вкус через год?Посмотрите правде в глаза. «Клевать» чужой код на реакте в сложном проекте едва ли не сложнее, даже если ты сеньор.
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует.Вот тут вы абсолютно правы. На реакте можно писать хороший быстрый код, но, почему-то сейчас в «прогрессивных развивающихся» компаниях принято использовать модные практики, в первую очередь. Почему-то мало кто обращает внимание на то, что данные практики внедряют люди, работающие над чем-то реально сложным, где такие подходы могут быть оправданы.
Из-за этого то, что можно сделать на одной странице с одним единственным крошечным бандлом, собранным из одного фреймворка, превращается в дико переусложненное SPA со всеми этими SSR, Code splitting, etc…
так что надо искать балансИменно.
Ну не будет забывать:
— на первом месте бизнес. Про то как сделать фичу и заработать бабла
— на втором месте бизнес. Про то как нанять програмистов, чтобы они там все побыстрее запилили
— на третьем месте бизнес. Про поддержку и чтобы к IPO оно все еще работало
— на четвертом месте опять бизнес. Чтобы пользователи были довольны продуктом и конверсия перла!
— где-то тут те самые пользователи, что довольны.
— а где-то тут возможно девелоперы
— а где-то тут различные стандарты и альтернативные варианты.
Реакт может кому-то и не нравиться, может он и жирноват (не жирнее jQuery), но он отлично подходит для бизнеса, и результат его работы (обычно) предсказуем.
— на первом месте бизнес. Про то как сделать фичу и заработать бабла
— на втором месте бизнес. Про то как нанять програмистов, чтобы они там все побыстрее запилили
— на третьем месте бизнес. Про поддержку и чтобы к IPO оно все еще работало
— на четвертом месте опять бизнес. Чтобы пользователи были довольны продуктом и конверсия перла!
— где-то тут те самые пользователи, что довольны.
— а где-то тут возможно девелоперы
— а где-то тут различные стандарты и альтернативные варианты.
Реакт может кому-то и не нравиться, может он и жирноват (не жирнее jQuery), но он отлично подходит для бизнеса, и результат его работы (обычно) предсказуем.
Про то как нанять програмистов, чтобы они там все побыстрее запилилиЯ лично уже в текущем своём проекте столкнулся с тем, что две разные независимые команды разработчиков сначала некисло так сели в лужу, не сумев за два месяца предоставить даже первые три экрана приложения (5 человек, переделывали два раза, в итоге слились), потом другая команда (с прайсом в три раза выше первой и штатом в два раза больше) сумела за месяц на реакте сделать два первых экрана, но при этом всё равно сорвала сроки, во вторых, выкатила код, который ради двух форм с десятком селектов грузит клиенту полтора метра данных.
Это не первый проект с React, в котором я участвую, у которого есть аналогичные проблемы, другие были чуть успешнее (подозреваю в силу более опытных команд), но результат всегда был один и тот же, о котором я сказал в начале — либо там нанимали в штат пяток сеньоров и десяток джунов, либо меняли фрейм.
Причины очевидны любому, кто пытался реализовать хоть что-то сложное с компонентным подходом на реакте.
Это я даже не рассматриваю вопрос концептуальной сложности всего кода, сложности документирования, сложности развития и т.п.
Без учёта всего этого ваш «бизнес» дальше первого пункта никуда не уйдёт, ведь он ещё даже деньги приносить не начал, а уже надо вливать в него тонны денег.
может он и жирноват (не жирнее jQuery)Ой вей, вы ведь не серьёзно?
но он отлично подходит для бизнеса, и результат его работы (обычно) предсказуемЕсли у вас есть пяток сеньёров и пяток джунов им в подмастерья — безусловно!
Окей — у нас джунов вообще практически нет, а за сеньерами еще принципал/архитект присматривает, обьясняет как лучше поступить и в (вроде бы) простых и в сложных ситуациях.
На реакте достаточно легко писать просто, быстро и надежно. Надо только научиться. Но да, не у всех это получается.
На реакте достаточно легко писать просто, быстро и надежно. Надо только научиться. Но да, не у всех это получается.
у нас джунов вообще практически нет, а за сеньерами еще принципал/архитект присматриваетНу так я и написал — если есть возможность содержать свой полноценный штат кодеров — нет вопросов.
На реакте достаточно легко писать просто, быстро и надежно. Надо только научиться.Вот те две команды, которые у нас в итоге опростоволосились, вначале тоже с профессиональными лицами на эту тему весь наш отдел уверяли, спорили со мной в выборе технологий реализации, показывали красивые реализованные проекты, коих тоже было немало надо сказать. Меня они не очень убедили, но вот шефа и его компаньонов — вполне.
Собственно, мы пришли к тому же — нанимаем теперь в штат разработчиков ускоренно.
А как насчёт дальнейшей поддержки не компонентного кода? Смены требований? Расширения функционала? Замены устаревших зависимостей?
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.
А как насчёт дальнейшей поддержки не компонентного кода?А чем она кардинально отличается, если написана адекватно, м?
Смены требований? Расширения функционала? Замены устаревших зависимостей?Вот тут, как раз, ваша неправда целиком.
Если проект упирается в то, что фреймворк больше не может обеспечивать его требования, и надо его менять — появляется множество вопросов. Запилить что-то новое в цельный, грамотно написанный проект — это та ещё задачка.
А вот если у вас всё написано «на велоспидах» (я не говорю, что надо всё писать самим, просто сравниваю две ситуации) — внедрить какой-то новый фреймворк и постепенно переписывать существующую функциональность под него, отключая части велосипеда по мере готовности замены — вполне нормальная задача в большинстве случаев.
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.Это да. Мне проблема видится в том, что люди часто не умеют выбирать инструмент адекватно задаче.
А чем она кардинально отличается, если написана адекватно, м?
эээ… ну, это будет просто другая реализация всё той же компонентной модели. Всё же лучше так ничего и не придумано. Ну не будет наследования — будет композиция. Не ООП — так функциональщина. Один фиг главная идея остаётся та же: separation of concern и single responsibility, конкретные детали неважны.
Мы же тут пытаемся противопоставить монолитный/лапшекод грамотной декомпозиции, нет? Я в принципе могу себе представить организацию приложения без разбиения на компоненты, ну там глобальный стейт, шина событий, шина данных, общий рендерер (тут уже с трудом), но не очень понимаю, зачем. Разве что для совсем простых и маленьких приложений или если вся логика на сервере живёт (реальный пример, кстати). И поддержка таких архитектур неизбежно будет сложнее и дороже.
Запилить что-то новое в цельный, грамотно написанный проект — это та ещё задачка.
А вот если у вас всё написано «на велоспидах»… — вполне нормальная задача в большинстве случаев.
Ну вот не совсем, причём местами до степени инверсии. Всё зависит от реализации и новой задачи.
Если грамотный проект поддерживает расширение и задача в него укладывается — вопроса нет вообще. Если не укладывается, надо смотреть причины, фреймворк может быть виноват, а может и нет. Например, на ангуляреЖС надо компилировать в разметку некую рекурсивную вложенную структуру — задача решается; та же структура с количеством итоговых watch >2к — уже скорее всего нет. А может это красивый ангуляр 7 и нам нужно обеспечить рендеринг динамической разметки, а у нас АОТ — и упс.
И ещё бывает, что фреймворк устраивает, всё решает, но он уже умер. И что тогда?
А самое противное — фреймворк на то и фреймворк, а не библиотека, что он решает свой класс задач во всей полноте. И при этом не желает делиться.
Возьмём, к примеру, тот же ангулярЖС. Прекрасный фреймворк для своего времени. Возьмём просто ангуляр, тоже замечательная штука. Возьмём приложение на «старом» ангуляре и перепишем его по кусочкам на новый в так называемом гибридном режиме, там для этого всё есть. Во что мы упрёмся? В роутинг, который несовместим (да там почти всё несовместимо, но вот именно роутинга нельзя иметь одновременно два без реально глобальных извращений. Ну или я не знаю, как). Проблема фреймворка? Да, но не совсем. Был бы велосипед — было бы проще? А как сказать, всё зависит от реализации. И вполне может быть, что нормально подключить фреймворк к велосипеду ничуть не легче, чем переписать с нуля — я легко могу придумать не одну такую ситуацию. Могу и обратную.
И вот тут как раз у реакта/вью преимущество, потому что они изначально менее навязчивы и рассчитаны на разные альтернативные решения: их легче разобрать. Но у них оверхед размазан по управлению кодом. Тоже (по сравнению с фреймворками высокой степени интеграции типа ангуляра или, например, руби) набор велосипедов с более-менее одинаковыми колёсами и от известного производителя.
PS я немного теряю нить спора — похоже, мы во мнениях в основном сходимся, но я не могу объяснить тогда Ваше изначальное слишком резкое заявление насчёт реакта, потому что он и в Вашу концепцию велосипедостроения вписывается, и Вы сами признаёте, что всё в итоге зависит от задачи и ресурсов.
Мне не нравится реализация компонентного подхода в реакте.
Тот хаос взаимодействий, в который превращается хоть сколько-нибудь сложное приложение.
Тот хаос взаимодействий, в который превращается хоть сколько-нибудь сложное приложение.
Так а при чём тут реакт? Компонентная модель у него вполне хороша, а что при росте числа связей сложность системы растёт экспоненциально, так это проблема не реакта, а прикладной архитектуры. Для этого придумано много всякого — MVC, MVVM, Reactive streams, управление стейтом…
Компонентная модель здесь вообще никаким боком. Ну разве что можно притянуть, что простой пропагацией пропсов можно обойтись в несложных случаях — но если автор сам себе злобный буратино и не озаботился более серьёзным механизмом контроля потока данных и потока управления при росте сложности, то с тем же успехом можно и прямо на жабаскрипт пенять.
В реакте — снова скажу — что хорошо и плохо сразу так это что задачу можно решить несколькими способами. По уровню хаоса он где-то между ангуляржс и ангуляром: двустороннего байндинга уже нет, но данные можно гонять практически как бог на душу положит. С другой стороны, это совсем не его задача и для этого есть совсем другие инструменты.
Компонентная модель здесь вообще никаким боком. Ну разве что можно притянуть, что простой пропагацией пропсов можно обойтись в несложных случаях — но если автор сам себе злобный буратино и не озаботился более серьёзным механизмом контроля потока данных и потока управления при росте сложности, то с тем же успехом можно и прямо на жабаскрипт пенять.
В реакте — снова скажу — что хорошо и плохо сразу так это что задачу можно решить несколькими способами. По уровню хаоса он где-то между ангуляржс и ангуляром: двустороннего байндинга уже нет, но данные можно гонять практически как бог на душу положит. С другой стороны, это совсем не его задача и для этого есть совсем другие инструменты.
Прекрасно понимаю вашу боль. Намучавшись с популярными фреймворками мы в итоге разработали свой, ориентированный на бизнес. А именно, в фокусе было:
- Быстрая разработка продакшен-реди кода (никаких компромисов между быстрыми кривыми прототипами и медленной разработкой на чистовую).
- Качественная разработка даже малоквалифицированными разработчиками (есть даже недоделанный онлайн-конфигуратор, позволяющий редактировать компоненты далёкому от программирования человеку).
- Быстрые и компактные приложения даже без каких-либо оптимизаций (ленивый, а скоро будет ещё и прогрессивный, рендеринг; полноценные приложения зачастую меньше, чем один только голый Реакт).
- Простота дебага и обратного инженеринга.
- База готовых компонент, которые как угодно можно подстроить под себя (как визуально, так и по поведению).
- Максимальная автоматизация всей рутины.
- Разработка десятков приложений с единой кодовой базой.
- Бесшовное комбинирование нескольких приложений, разрабатываемых разными командами, в одно.
- Адекватная автоматическая адаптация под любые размеры экрана.
- Статическая типизация, рефакторинги, вот это всё.
- Простота и скорость компонентного тестирования (типично — все тесты прогоняются на лету при перезагрузке страницы).
- Открытые исходники и свободная лицензия.
Проект сейчас не коммерческий, но есть небольшое комьюнити, которое пилит приложения. Хочется расширить его, так как это основной сдерживающий фактор от массового использования фреймворка. Для этого нужны заказы. Со своей стороны мы можем обеспечить быструю разработку, поддержку и консультации. Также, если кто-то хочет присоединиться к комьюнити и, вместо борьбы с фреймфорком и написания бойлерплейта, начать более эффективно расходовать своё время, то присоединяйтесь. Подробнее тут: https://hyoo.ru/
На всякий случай: лично я никакой прибыли с этого не имею и не планирую. Вкладываю своё личное время, потому что мне это интересно. Поэтому с моей стороны будут в основном консультации и контроль качества.
Я не более чем год назад с нуля организовал проект на Реакт с выбором инфраструктуры и дополнительных библиотек компонентов и инструментов, организацией билда, е2е и юнит тестов, короче всего. При этом для проверки системы походу писал уже отдизайненые экраны. В общей сложности за менее чем 3 месяца написал 4 экрана, не считая модальных диалогов и всяких главных баров и менюшек. Все без е2е тестов, но с симуляцией серверных данных. Далее обучил одного джуна и двух синьёров, не работавших ранее с Реактом. Это заняло неделю. И в течении полутора-двух месяцев мы набросали ещё полтора десятка экранов, а также полный набор е2е тестов для всех экранов. Экраны представляли собой как сложные формы, так и более комплексные приблуды. Одной из задач, например, было внедрение редактора кода от Вижуал студио — монако.
Не очень понимаю, каким тормозом нужно быть, чтобы за два месяца не написать 3 экрана, разве, что там каждый экран это докторская диссертация.
Не очень понимаю, каким тормозом нужно быть, чтобы за два месяца не написать 3 экрана, разве, что там каждый экран это докторская диссертация.
Я вот тоже думал, что раз человек топит за технологию, значит он должен её знать. У него сложности возникли, как раз когда он начал второй или третий экран к бэкэнду привязывать. Сначала он добавил туда пару дополнительных библиотек (кажется, роутер и какую-то из библиотек компонентов, которую потом стал кастомизировать под наш UI). В итоге его команда столкнулась с необходимостью переписать часть зависимостей в уже написанном, а когда он это уже закончил, времени ушло уже слишком много и терпение у начальства уже вышло. Это всё при том, что как уже сказано выше — у нас уже был готов готовый бэкэнд и API, с которым уже работают мобильные приложения. То есть ему даже эмулировать серверные данные не надо было.
Я не говорю, что всё это невозможно, я говорю о сложности, которая в случае реакта растёт не пропорционально сложности проекта. У каждого нормального сеньёра есть готовый проект за плечами и, по хорошему, не один. Это вовсе не говорит о способности трезво оценивать новую задачу с нуля и нормально выбрать подход к её решению. В случае с реактом и подходом, когда ты ещё десяток зависимостей вынужден использовать, дать точную оценку без огромного опыта работы с ним практически нереально.
Я не говорю, что всё это невозможно, я говорю о сложности, которая в случае реакта растёт не пропорционально сложности проекта. У каждого нормального сеньёра есть готовый проект за плечами и, по хорошему, не один. Это вовсе не говорит о способности трезво оценивать новую задачу с нуля и нормально выбрать подход к её решению. В случае с реактом и подходом, когда ты ещё десяток зависимостей вынужден использовать, дать точную оценку без огромного опыта работы с ним практически нереально.
А у меня на тот момент не было настолько большого опыта с Реактом. Я тогда писал на Ангулар 1. А с реактом работал чуть больше года до этого в течении нескольких месяцев.
Реакт сам по себе очень прост и гибок. И увеличение проекта никак на это не влияет. В этом плане он ничем от других библиотек компонентов не отличается, он даже проще. А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.
Реакт сам по себе очень прост и гибок. И увеличение проекта никак на это не влияет. В этом плане он ничем от других библиотек компонентов не отличается, он даже проще. А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.
А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.Я считаю, что раз уж используешь фреймворкт, он уже из коробки должен реализовывать такие вещи как «привязка данных», иначе это не фреймворк, а модуль.
Собственно, именно поэтому подход реакта «нам нужно ядро фрейма и ещё десяток библиотек к нему чтобы реализовать систему событий, и привязку данных, и остальные хотелки» — это в большинстве случаев не плюс реакта, а минус.
А никто и не говорит, что Реакт это фреймворк. И в этом и его преимущество и недостаток в зависимости от взгляда и подхода. Я, например, выбрал для своей аппликации фрейворк для данных и состояния наиболее подходящий для её требований. Если же UI компоненты и бизнес логика засунуты в неделимый фреймворк, то заменить что-то становится сложнее.
В общем история такова:
Жил был сайт, и все было у него хорошо, кроме того что он был написан на Vue женой основателя. Вообще это не проблема, и сейчас в проде именно эта версия и торчит.
Шло время, стартап немного подрос и решил расширяться. Первым делом они наняли себе СТО. Очень умный мужик, Phd и множество регалий.
Что было дальше? Весь бэк был переписан на go и засунут в лямды, а фронт поехал на React.
Спустя 6(!!) месяцев меня попросили им немного помочь. И я помог — вытер кровь из глаз и стер 70% кода. И это был ОДИН (достаточно сложный) экран.
В HTMLAcademy жене прилетало в 10 раз более сложные задачи с оценкой в 100 часов, в которые она с большим скрипом и моей помощью да влезала.
Жил был сайт, и все было у него хорошо, кроме того что он был написан на Vue женой основателя. Вообще это не проблема, и сейчас в проде именно эта версия и торчит.
Шло время, стартап немного подрос и решил расширяться. Первым делом они наняли себе СТО. Очень умный мужик, Phd и множество регалий.
Что было дальше? Весь бэк был переписан на go и засунут в лямды, а фронт поехал на React.
Спустя 6(!!) месяцев меня попросили им немного помочь. И я помог — вытер кровь из глаз и стер 70% кода. И это был ОДИН (достаточно сложный) экран.
В HTMLAcademy жене прилетало в 10 раз более сложные задачи с оценкой в 100 часов, в которые она с большим скрипом и моей помощью да влезала.
Собственно, как по мне, ваша стори это лишь очередное подтверждение тому, что реакт это оверхед для большинства задач, грамотно использовать который могут лишь единицы разработчиков.
Наваять много дерьма можно и на Реакт и на Вью и на Ангуларе и даже на чистом JS. Я сейчас по работе переписал Ректовскую часть небольшого проекта с Реакт на Вью, вернее добавил еще одну реализацию UI для лекции по Редакс. Этот самый Редакс у них общий, и находится в отдельном пакедже, как и Реакт с Вью. Так вот, совсем не заметил какой-то принципиальной разницы в размере кода. Да подход отличается и даже привязка Редакса несколько другая. Но разницы в 70% нет даже близко. Возможно 10% и то с учетом стилей, поскольку выбранная (не мной) библиотека на Реакте проигрывает по гибкости. Если бы я выбрал другую, то не уверен, что код на Вью был бы меньше.
Ну и да, весьма забавно, как у вас пользователи, которые, по сути, обеспечивают весь этот бизнес, так лихо аж на четвёртое место скатились. Как бы вы наняли программистов из второго пункта, чтобы до четвёртого добраться?
Что было первым курица или яйцо? Утвержденный бизнес план и roadmap на два года вперед. В том и проблема — если у вас есть «продукт», а не imgboard с котиками, клиентам тоже очень важен ваш «бизнес» и его возможности расти и подстраиватся под рынок.
Если вы упираетесь в стенку и говорите клиенту — ну эээ, полгода на рефакторинг потребуется, и тут без разница что за «стенка» — колличество пользователей, фича или скорость работы — бизнес уходит в трубу.
Если вы упираетесь в стенку и говорите клиенту — ну эээ, полгода на рефакторинг потребуется, и тут без разница что за «стенка» — колличество пользователей, фича или скорость работы — бизнес уходит в трубу.
Что было первым курица или яйцо?Я считаю тут нет места этому вопросу.
Не имея какого-то продукта вы никаких пользователей вообще не увидите.
Таким образом сначала всегда будут «бизнес план и roadmap», а затем всегда будут программисты это реализующие, а уже только потом пользователи. И вот уже потом, если всё сложится хорошо, может быть, будет то что вы написали вначале.
Так вот выбор неподходящей технологии легко может сделать так, чтобы этого «потом» уже и не наступило.
Реакт может кому-то и не нравиться, может он и жирноват (не жирнее jQuery), но он отлично подходит для бизнеса, и результат его работы (обычно) предсказуем.
Это не правда.
что есть крупный проект? сколько нужно человек чтобы сделать например trello?
Впилить $Mol?
Вы что такое человеку предлагаете? Выпилить модную технологию и сделать все с использованием головы, так ведь нельзя!!!
Спасибо, коротко и по делу. Но есть один вопрос — «Мне это позволило срезать дополнительные 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 (правда, через хак и вообще это сомнительное развлечение).
В общем, нишевое, но рабочее решение.
PS ого сколько написал. Сорри, увлёкся =)
Насчёт же сплиттинга есть ещё один вариант. Немножко сильно извращённый, но не мы такие, жизнь такая (ц). Зато это действительно сплиттинг так сплиттинг =)
Итак, есть приложение, и оно сравнительно велико — сотни форм, десятки бизнес-модулей, мегабайты кода, годы легаси,
Идея состоит в том, чтоб порезать бизнес-функционал на мини-приложения, для которых в их бандле будет всё, относящееся к собственно куску доменной модели, а всё внешнее (реакт, реакт-дом, рх, момент etc.) грузится как предсобранные минифицированные бандлы (webpack externals + chunk optimization). Ну или если вы верите в тришейкинг — собираются в общем потоке сборщика в бандлы один к одному (то есть реакт идёт в бандл «реакт», момент в «момент» и т.д.) или по вкусу (всё в «вендор», например). В обоих подходах есть свои плюсы и минусы.
Затем некий небольшой скрипт на чистом незамутенённом TS/JS, которому доступны сведения о доступных прикладных бандлах, так или иначе интегрируется с остальным кодом и вешается на «внешние» события «появление компонента» и «уход компонента» и, собственно, на маппинг «что мы хотим показать, где оно лежит физически и в какой контейнер это монтировать».
Такой себе самодельный мини-роутер, который по событию разрешает зависимости, загружает конкретный прикладной скрипт (бандл) и вызывает из него нужную функцию монтирования/демонтирования. Ну и ещё много чего полезного он должен делать, например обрабатывать ошибки и предоставлять shared-интерфейсы и шину сообщений. Но в целом — ничего сложного.
Выгода в чём: мини-приложения инкапсулируют достаточно серьёзные куски приложения (и логика, и разные view) и могут быть собраны и задеплоены совершенно отдельно при условии соблюдения контрактов и если рантайм не менялся (это к вопросу тришейкинга и «как собирать рантайм»). Грузятся они по запросу, асинхронно, размер маленький, код изолирован, тесты изолированы, платформа запуска тоже компактная и легко мокается — цель code splitting + code bundling достигнута. Для полного счастья при соблюдении несложных условий мини-приложения могут быть вообще на разных технологиях. Счастье для всех даром, но это не точно.
Минусы, понятно, в общей сложности такого многокомпонентного решения. Нужен довольно продвинутый сборщик и для малых/средних проектов, или проектов с полным контролем кода оболочки оно того не стоит. Кроме того, если есть много взаимозависимостей, то придётся изобретать велосипед ещё и для продвинутого DI, ну и работает всё всё равно в едином окружении (window) и при желании или кривых руках разработчика отдельного модуля можно сильно подгадить остальным. В итоге решение выливается практически в свой фреймворк и нужно тщательно оценивать издержки на сопровождение.
Ну и мало кто из «больших» платформ позволяет нормально бутстраппить, монтировать и ре-монтировать множество sub-tree. Собственно, только React, Vue, и, сюрприз, AngularJS (правда, через хак и вообще это сомнительное развлечение).
В общем, нишевое, но рабочее решение.
PS ого сколько написал. Сорри, увлёкся =)
Webpack 4, ежели ему дать множество entry point, так и сделает. Только по умолчанию порежет все не более чем на 5 кусков.
Автоматическое создание shared chunks — это прям была фишка четвертой версии, позволившая закопать CommonChunksPlugin.
Автоматическое создание shared chunks — это прям была фишка четвертой версии, позволившая закопать CommonChunksPlugin.
Безусловно, три четверти магии именно в тюнинге вебпака. То есть, ручная настройка правил для чанков, принудительный чанк для UI библиотеки (паттерн реэкспорта), контроль утечек (чанк-ловушка), мульти-конфиги (entry point недостаточно) и тому подобное.
Но технически можно обойтись и без. И даже совсем без вебпака, и, кстати, галп на такой вид сборки ложится лучше.
Более того, я встречал и сопровождал проекты с plain-конфигами в десяток раз сложнее. Всякие там бабели, хитроумные правила, самодельные плагины и лоадеры и прочее, что с треском ломается при смене версии вебпака… или ангуляра… или ещё чего-то постороннего.
Но технически можно обойтись и без. И даже совсем без вебпака, и, кстати, галп на такой вид сборки ложится лучше.
Более того, я встречал и сопровождал проекты с plain-конфигами в десяток раз сложнее. Всякие там бабели, хитроумные правила, самодельные плагины и лоадеры и прочее, что с треском ломается при смене версии вебпака… или ангуляра… или ещё чего-то постороннего.
Sign up to leave a comment.
React.lazy? Но что если у вас не компонент?