Code splitting начинался как разделение на уровне Модулей, а закончился как разделение на уровне Компонент.
И проблема тут исключительно в голове — React.lazy это хорошо, но и import никуда не делся… Так почему же code splitting только про компоненты?
React.lazy, React-Loadable, Loadable-Components, Imported-component — на свете много библиотек, которые оборачивают загрузку модуля в некий сахар, исключительно чтобы немного более user-friendly обработать загрузку компонента и показать его по готовности. Минимальный код для «async-loader».
const loadable = (loaderFunction) =>
class AsyncComponent extends React.Component {
state = { ResultComponent: null, error: false, };
componentWillMount() {
loaderFunction
.then(result => this.setState({ ResultComponent: result.default || result})) // "es6" default export
.catch(() => this.setState({ error: true });
}
render() {
const { error, ResultComponent } = this.state;
// Display loaded component
return ResultComponent
? <ResultComponent {...this.props}/>
: (error ? <ErrorComponent /> : <LoadingComponent />)
}
}
Suspense и React.lazy просто другой вариант работы со стейтом. Ничего более.
Но что делать если у вас не компонент?
Проблемы с этим вроде бы нет — import(«someStuff»).then('go-on'). Но тут опять начинаются вопросы про то как это правильно разместить в lifecycle Reactа, что делать есть промис заресолвился после смерти компонента, и так далее. И всех в голове одни компоненты.
Я провел мини опрос — НИКТО более не использует этот, самый древний, вариант code splitting. Не знает как его кушать в современных условиях. И в общем все плохо.
При этом решение есть, и опять же в 4 строчки — renderProps
Все очень просто — не смотря на то, что обьектом code splitting будет не Компонент а Модуль — местом совершения операции всеравно будет Компонент.
const loadableModule = (loaderFunction) =>
class AsyncComponent extends React.Component {
state = { ResultComponent: null, error: false, };
componentWillMount() {
loaderFunction
.then(result => this.setState({ module: result.default || result})) // "es6" default export
.catch(() => this.setState({ error: true });
}
render() {
const { error, module } = this.state;
return module
// pass it as a render prop!
? this.props.children(module)
// pass it as a render prop!
: (error ? <ErrorComponent /> : <LoadingComponent />)
}
}
Тот же самый паттерн, только повернутый в сторону загрузки кода и «предоставления» этого кода как renderProps.
Работает из коробки:
- loadable-components (loadable.lib)
import loadable from '@loadable/component' const Moment = loadable.lib(() => import('moment')) function FromNow({ date }) { return ( <div> <Moment fallback={date.toLocaleDateString()}> {({ default: moment }) => moment(date).fromNow()} </Moment> </div> ) } - react-lodable (react-loadable-library)
import {importedLibraryDefault} from 'react-loadable-library'; const Moment = importedLibraryDefault( () => import('momentjs')); <Moment> { (momentjs) => <span> {momentjs(date).format(FORMAT)}</span> } </Moment> - react-imported-component (react-imported-library)
// интерфейсно совместим с react-loadable-library, плюс поддержка Suspense
Дешево, и очень сердито. Мне это позволило срезать дополнительные 20%. Но, главное, позволило очень декларативно настроить code-splitting, который будет загружать только то, что надо, и когда надо.
Теперь твой ход, %username%.
И кто перепишет это на hooks?
Комментарии (52)
lexey111
10.03.2019 10:14+1Спасибо, коротко и по делу. Но есть один вопрос — «Мне это позволило срезать дополнительные 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 ого сколько написал. Сорри, увлёкся =)
kashey Автор
10.03.2019 10:16Webpack 4, ежели ему дать множество entry point, так и сделает. Только по умолчанию порежет все не более чем на 5 кусков.
Автоматическое создание shared chunks — это прям была фишка четвертой версии, позволившая закопать CommonChunksPlugin.lexey111
10.03.2019 10:24Безусловно, три четверти магии именно в тюнинге вебпака. То есть, ручная настройка правил для чанков, принудительный чанк для UI библиотеки (паттерн реэкспорта), контроль утечек (чанк-ловушка), мульти-конфиги (entry point недостаточно) и тому подобное.
Но технически можно обойтись и без. И даже совсем без вебпака, и, кстати, галп на такой вид сборки ложится лучше.
Более того, я встречал и сопровождал проекты с plain-конфигами в десяток раз сложнее. Всякие там бабели, хитроумные правила, самодельные плагины и лоадеры и прочее, что с треском ломается при смене версии вебпака… или ангуляра… или ещё чего-то постороннего.
vintage
Думаю выпиливание реакта вам сэкономт ещё 20%.)
kashey Автор
Я даже jQuery с половины проектов выпилил. К сожалению для более менее крупных приложений это немного не выход.
Psychosynthesis
Писать реально крупный проект на React — это либо обрекать себя на штат программистов (только на фронт) человек в 20 уже с первых шагов проекта, либо просто удлинить себе таким садистским образом переход на что-нибудь более вменяемое.
dopusteam
А что более вменяемое?
Psychosynthesis
Озвучьте внятное ТЗ, мы предложим варианты реализации.
dopusteam
Ну Вы сказали, что крупный проект на react пилить не стоит.
Я не троллю, я правда спрашиваю, на чем лучше?
Вы без ТЗ сказали, что нужно выкинуть реакт, так что ТЗ предоставить не могу
Psychosynthesis
Ну так сложный проект он на то и сложный, что там нельзя сказать «а нука сделаю я всё на jquery», но нужно чётко понимать задачи и цели, чтобы выбрать подходящий инструмент.
Собственно, мой первый коммент был скорее про ситуацию когда «всё что делает ваше приложение — это иногда обновляет данные с сервера и отображает их в таблицу», то лучше сделайте это хоть на jquery, чем на реакте.
Что касается лично моего мнения — мне очень нравится AngularJS. Я слышал про него много плохих общих слов, но мало конкретных минусов, да и те, что называются имеют +\- адекватные решения даже при масштабировании сервиса. Часто слышу также, что дескать первая версия устарела, а вот в Angular 2+ всё уже реально круто. Ну не знаю, почитал гайд из документации, понял что делать то, что там описано я точно не хочу, плюс там заметно сильное влияние концепций, популярных в реакте. Мне симпатизирует подход Backbone, но не довелось реализовывать на нём что-то сложнее тестовых задний, поэтому судить не могу.
JustDont
Вы ж вроде реакт не любите?
… ах вы это про angularJS написали, оказывается. Извините, не заметил.
lexey111
Не всегда, есть в приципе нерешаемые проблемы, но главное для энтерпрайза — он снят с поддержки. Тут даже не в самом ангуляре затык, а в обвязке: jQuery, UI Bootstrap, прочие зависимости, некоторые из которых могут быть заброшены, а некоторые не иметь соместимых комбинаций. Другими словами, устаревающий неподдерживаемый стек. Другие чисто технические вопросы да, как правило можно или решить, или обойти, почти все, но и этого достаточно.
Мелким или короткоживущим, или неразвивающимся проектам может быть и пофигу — на несколько лет ещё хватит.
PS ангуляр 2+ ушёл вообще не туда, по моему скромному мнению. Слишком шарахнулся в противоположную сторону, обжёгшись на первом.
Psychosynthesis
Что касается UI Bootstrap мне он вообще никогда не нравился, не понимаю зачем его все тащат в проекты на ангуляре.
Psychosynthesis
lexey111
Из официальных источников. Это LTS, но новых фич не будет, только секьюрити патчи и малоприоритетный багфиксинг. Всем спасибо, всех ждём в новом ангуляре.
Например, вот.
Кстати, если посмотреть на топ-100 ангуляр-приложений, то очень много из них были и остаются на ангуляржс и никогда не будут переписаны на ангуляр 2+. А вот для финансового сектора, например, поддержка актуальности стека — критична.
vintage
Вы так говорите об этой поддержке будто в Angular нет годами не фиксящихся багов, про воркераунды для которых люди даже статьи пишут.
lexey111
Это тут при чём? Я говорю о ситуации, когда нужно обосновать использование замороженой технологии с известными уязвимостями в чувствительном секторе. То, что она 99% рабочая и будет рабочая ещё долго в некоторых случаях вообще не аргумент, потому что менеджмент сразу спрашивает «что будет с платформой через пять лет? как быстро будут устраняться баги? можете ли вы пообещать, что?..»
Psychosynthesis
Уязвимости там как раз фиксят.
А на счёт «что будет с платформой через пять лет» — вам и про реакт никто не даст гарантии, что завтра фэйсбук не выкатит новый фрейм, а этот не отправит на помойку.
При этом, если в одном случае через пять лет проект «99% будет работать», и во другом — «из-за возросшей сложности проект надо переписать на другой фрейм», выбор вроде бы очевиден.
vintage
Не хотелось бы вас расстраивать, но вот именно со временем неустранения багов у Angular всё очень плохо, даже хуже, чем у AngularJS. Всему виной переусложнённая архитектура и просто тонны кода, из-за чего багов в нём очень много, а чинить их крайне сложно.
Psychosynthesis
lexey111
Можно и так воспринимать. Если устраивает модель работы ангуляржс, его производительность и ограничения — почему бы и нет? Народ и на jQuery пишет, и на ванилле… вопрос в цене оверхеда (поддержка, багфикс, актуализация, люди) для вас. Может, у вас на рынке полно недорогих ангулярщиков или проект меняется раз в два года — случаи разные бывают.
У ангуляражс по крайней мере очень низкий порог вхождения. В первых десяти процентах кривой =)
Akuma
А на голом JS с «реально крупным проектом», конечно же, справится сын маминой подруги?
Psychosynthesis
На голом JS писать вовсе не обязательно, фреймворков на любой вкус сейчас, что называет, «куры не клюют».
lexey111
На проекте серьёзнее лэндинга возникает вопрос поддержки. Кто будет клевать код на фреймворке на любой вкус через год?
Да, насчёт реакта кое-что рациональное таки есть: это библиотека, она не навязывает решение, а только рекомендует. Допустить зоопарк и хаос на уровне архитектуры не просто, а ну очень просто — в отличие от ангуляра, где за разработчика продумано чуть больше, чем всё (не то, чтобы там было нельзя, но обычно это сложно и не нужно). Зато и падает такой проект в итоге с большим грохотом, так что надо искать баланс.
Как всегда.
Psychosynthesis
Вот тут вы абсолютно правы. На реакте можно писать хороший быстрый код, но, почему-то сейчас в «прогрессивных развивающихся» компаниях принято использовать модные практики, в первую очередь. Почему-то мало кто обращает внимание на то, что данные практики внедряют люди, работающие над чем-то реально сложным, где такие подходы могут быть оправданы.
Из-за этого то, что можно сделать на одной странице с одним единственным крошечным бандлом, собранным из одного фреймворка, превращается в дико переусложненное SPA со всеми этими SSR, Code splitting, etc…
Именно.
kashey Автор
Ну не будет забывать:
— на первом месте бизнес. Про то как сделать фичу и заработать бабла
— на втором месте бизнес. Про то как нанять програмистов, чтобы они там все побыстрее запилили
— на третьем месте бизнес. Про поддержку и чтобы к IPO оно все еще работало
— на четвертом месте опять бизнес. Чтобы пользователи были довольны продуктом и конверсия перла!
— где-то тут те самые пользователи, что довольны.
— а где-то тут возможно девелоперы
— а где-то тут различные стандарты и альтернативные варианты.
Реакт может кому-то и не нравиться, может он и жирноват (не жирнее jQuery), но он отлично подходит для бизнеса, и результат его работы (обычно) предсказуем.
Psychosynthesis
Это не первый проект с React, в котором я участвую, у которого есть аналогичные проблемы, другие были чуть успешнее (подозреваю в силу более опытных команд), но результат всегда был один и тот же, о котором я сказал в начале — либо там нанимали в штат пяток сеньоров и десяток джунов, либо меняли фрейм.
Причины очевидны любому, кто пытался реализовать хоть что-то сложное с компонентным подходом на реакте.
Это я даже не рассматриваю вопрос концептуальной сложности всего кода, сложности документирования, сложности развития и т.п.
Без учёта всего этого ваш «бизнес» дальше первого пункта никуда не уйдёт, ведь он ещё даже деньги приносить не начал, а уже надо вливать в него тонны денег.
Ой вей, вы ведь не серьёзно?
Если у вас есть пяток сеньёров и пяток джунов им в подмастерья — безусловно!
kashey Автор
Окей — у нас джунов вообще практически нет, а за сеньерами еще принципал/архитект присматривает, обьясняет как лучше поступить и в (вроде бы) простых и в сложных ситуациях.
На реакте достаточно легко писать просто, быстро и надежно. Надо только научиться. Но да, не у всех это получается.
Psychosynthesis
Вот те две команды, которые у нас в итоге опростоволосились, вначале тоже с профессиональными лицами на эту тему весь наш отдел уверяли, спорили со мной в выборе технологий реализации, показывали красивые реализованные проекты, коих тоже было немало надо сказать. Меня они не очень убедили, но вот шефа и его компаньонов — вполне.
Собственно, мы пришли к тому же — нанимаем теперь в штат разработчиков ускоренно.
lexey111
А как насчёт дальнейшей поддержки не компонентного кода? Смены требований? Расширения функционала? Замены устаревших зависимостей?
Вообще начинать писать долго живущий проект без хотя бы одного человека, который понимает, что делает, почему и каковы последствия, особенно отдалённые, это очень смело. Без привязки к технологии.
Psychosynthesis
Вот тут, как раз, ваша неправда целиком.
Если проект упирается в то, что фреймворк больше не может обеспечивать его требования, и надо его менять — появляется множество вопросов. Запилить что-то новое в цельный, грамотно написанный проект — это та ещё задачка.
А вот если у вас всё написано «на велоспидах» (я не говорю, что надо всё писать самим, просто сравниваю две ситуации) — внедрить какой-то новый фреймворк и постепенно переписывать существующую функциональность под него, отключая части велосипеда по мере готовности замены — вполне нормальная задача в большинстве случаев.
Это да. Мне проблема видится в том, что люди часто не умеют выбирать инструмент адекватно задаче.
lexey111
эээ… ну, это будет просто другая реализация всё той же компонентной модели. Всё же лучше так ничего и не придумано. Ну не будет наследования — будет композиция. Не ООП — так функциональщина. Один фиг главная идея остаётся та же: separation of concern и single responsibility, конкретные детали неважны.
Мы же тут пытаемся противопоставить монолитный/лапшекод грамотной декомпозиции, нет? Я в принципе могу себе представить организацию приложения без разбиения на компоненты, ну там глобальный стейт, шина событий, шина данных, общий рендерер (тут уже с трудом), но не очень понимаю, зачем. Разве что для совсем простых и маленьких приложений или если вся логика на сервере живёт (реальный пример, кстати). И поддержка таких архитектур неизбежно будет сложнее и дороже.
Ну вот не совсем, причём местами до степени инверсии. Всё зависит от реализации и новой задачи.
Если грамотный проект поддерживает расширение и задача в него укладывается — вопроса нет вообще. Если не укладывается, надо смотреть причины, фреймворк может быть виноват, а может и нет. Например, на ангуляреЖС надо компилировать в разметку некую рекурсивную вложенную структуру — задача решается; та же структура с количеством итоговых watch >2к — уже скорее всего нет. А может это красивый ангуляр 7 и нам нужно обеспечить рендеринг динамической разметки, а у нас АОТ — и упс.
И ещё бывает, что фреймворк устраивает, всё решает, но он уже умер. И что тогда?
А самое противное — фреймворк на то и фреймворк, а не библиотека, что он решает свой класс задач во всей полноте. И при этом не желает делиться.
Возьмём, к примеру, тот же ангулярЖС. Прекрасный фреймворк для своего времени. Возьмём просто ангуляр, тоже замечательная штука. Возьмём приложение на «старом» ангуляре и перепишем его по кусочкам на новый в так называемом гибридном режиме, там для этого всё есть. Во что мы упрёмся? В роутинг, который несовместим (да там почти всё несовместимо, но вот именно роутинга нельзя иметь одновременно два без реально глобальных извращений. Ну или я не знаю, как). Проблема фреймворка? Да, но не совсем. Был бы велосипед — было бы проще? А как сказать, всё зависит от реализации. И вполне может быть, что нормально подключить фреймворк к велосипеду ничуть не легче, чем переписать с нуля — я легко могу придумать не одну такую ситуацию. Могу и обратную.
И вот тут как раз у реакта/вью преимущество, потому что они изначально менее навязчивы и рассчитаны на разные альтернативные решения: их легче разобрать. Но у них оверхед размазан по управлению кодом. Тоже (по сравнению с фреймворками высокой степени интеграции типа ангуляра или, например, руби) набор велосипедов с более-менее одинаковыми колёсами и от известного производителя.
PS я немного теряю нить спора — похоже, мы во мнениях в основном сходимся, но я не могу объяснить тогда Ваше изначальное слишком резкое заявление насчёт реакта, потому что он и в Вашу концепцию велосипедостроения вписывается, и Вы сами признаёте, что всё в итоге зависит от задачи и ресурсов.
Psychosynthesis
Мне не нравится реализация компонентного подхода в реакте.
Тот хаос взаимодействий, в который превращается хоть сколько-нибудь сложное приложение.
lexey111
Так а при чём тут реакт? Компонентная модель у него вполне хороша, а что при росте числа связей сложность системы растёт экспоненциально, так это проблема не реакта, а прикладной архитектуры. Для этого придумано много всякого — MVC, MVVM, Reactive streams, управление стейтом…
Компонентная модель здесь вообще никаким боком. Ну разве что можно притянуть, что простой пропагацией пропсов можно обойтись в несложных случаях — но если автор сам себе злобный буратино и не озаботился более серьёзным механизмом контроля потока данных и потока управления при росте сложности, то с тем же успехом можно и прямо на жабаскрипт пенять.
В реакте — снова скажу — что хорошо и плохо сразу так это что задачу можно решить несколькими способами. По уровню хаоса он где-то между ангуляржс и ангуляром: двустороннего байндинга уже нет, но данные можно гонять практически как бог на душу положит. С другой стороны, это совсем не его задача и для этого есть совсем другие инструменты.
vintage
Прекрасно понимаю вашу боль. Намучавшись с популярными фреймворками мы в итоге разработали свой, ориентированный на бизнес. А именно, в фокусе было:
Проект сейчас не коммерческий, но есть небольшое комьюнити, которое пилит приложения. Хочется расширить его, так как это основной сдерживающий фактор от массового использования фреймворка. Для этого нужны заказы. Со своей стороны мы можем обеспечить быструю разработку, поддержку и консультации. Также, если кто-то хочет присоединиться к комьюнити и, вместо борьбы с фреймфорком и написания бойлерплейта, начать более эффективно расходовать своё время, то присоединяйтесь. Подробнее тут: https://hyoo.ru/
На всякий случай: лично я никакой прибыли с этого не имею и не планирую. Вкладываю своё личное время, потому что мне это интересно. Поэтому с моей стороны будут в основном консультации и контроль качества.
urrri
Я не более чем год назад с нуля организовал проект на Реакт с выбором инфраструктуры и дополнительных библиотек компонентов и инструментов, организацией билда, е2е и юнит тестов, короче всего. При этом для проверки системы походу писал уже отдизайненые экраны. В общей сложности за менее чем 3 месяца написал 4 экрана, не считая модальных диалогов и всяких главных баров и менюшек. Все без е2е тестов, но с симуляцией серверных данных. Далее обучил одного джуна и двух синьёров, не работавших ранее с Реактом. Это заняло неделю. И в течении полутора-двух месяцев мы набросали ещё полтора десятка экранов, а также полный набор е2е тестов для всех экранов. Экраны представляли собой как сложные формы, так и более комплексные приблуды. Одной из задач, например, было внедрение редактора кода от Вижуал студио — монако.
Не очень понимаю, каким тормозом нужно быть, чтобы за два месяца не написать 3 экрана, разве, что там каждый экран это докторская диссертация.
Psychosynthesis
Я вот тоже думал, что раз человек топит за технологию, значит он должен её знать. У него сложности возникли, как раз когда он начал второй или третий экран к бэкэнду привязывать. Сначала он добавил туда пару дополнительных библиотек (кажется, роутер и какую-то из библиотек компонентов, которую потом стал кастомизировать под наш UI). В итоге его команда столкнулась с необходимостью переписать часть зависимостей в уже написанном, а когда он это уже закончил, времени ушло уже слишком много и терпение у начальства уже вышло. Это всё при том, что как уже сказано выше — у нас уже был готов готовый бэкэнд и API, с которым уже работают мобильные приложения. То есть ему даже эмулировать серверные данные не надо было.
Я не говорю, что всё это невозможно, я говорю о сложности, которая в случае реакта растёт не пропорционально сложности проекта. У каждого нормального сеньёра есть готовый проект за плечами и, по хорошему, не один. Это вовсе не говорит о способности трезво оценивать новую задачу с нуля и нормально выбрать подход к её решению. В случае с реактом и подходом, когда ты ещё десяток зависимостей вынужден использовать, дать точную оценку без огромного опыта работы с ним практически нереально.
urrri
А у меня на тот момент не было настолько большого опыта с Реактом. Я тогда писал на Ангулар 1. А с реактом работал чуть больше года до этого в течении нескольких месяцев.
Реакт сам по себе очень прост и гибок. И увеличение проекта никак на это не влияет. В этом плане он ничем от других библиотек компонентов не отличается, он даже проще. А вот какой фреймворк вы выберете для привязки данных и состояния может сильно усложнить или упростить систему в сложных проектах.
Psychosynthesis
Собственно, именно поэтому подход реакта «нам нужно ядро фрейма и ещё десяток библиотек к нему чтобы реализовать систему событий, и привязку данных, и остальные хотелки» — это в большинстве случаев не плюс реакта, а минус.
urrri
А никто и не говорит, что Реакт это фреймворк. И в этом и его преимущество и недостаток в зависимости от взгляда и подхода. Я, например, выбрал для своей аппликации фрейворк для данных и состояния наиболее подходящий для её требований. Если же UI компоненты и бизнес логика засунуты в неделимый фреймворк, то заменить что-то становится сложнее.
kashey Автор
В общем история такова:
Жил был сайт, и все было у него хорошо, кроме того что он был написан на Vue женой основателя. Вообще это не проблема, и сейчас в проде именно эта версия и торчит.
Шло время, стартап немного подрос и решил расширяться. Первым делом они наняли себе СТО. Очень умный мужик, Phd и множество регалий.
Что было дальше? Весь бэк был переписан на go и засунут в лямды, а фронт поехал на React.
Спустя 6(!!) месяцев меня попросили им немного помочь. И я помог — вытер кровь из глаз и стер 70% кода. И это был ОДИН (достаточно сложный) экран.
В HTMLAcademy жене прилетало в 10 раз более сложные задачи с оценкой в 100 часов, в которые она с большим скрипом и моей помощью да влезала.
Psychosynthesis
Собственно, как по мне, ваша стори это лишь очередное подтверждение тому, что реакт это оверхед для большинства задач, грамотно использовать который могут лишь единицы разработчиков.
urrri
Наваять много дерьма можно и на Реакт и на Вью и на Ангуларе и даже на чистом JS. Я сейчас по работе переписал Ректовскую часть небольшого проекта с Реакт на Вью, вернее добавил еще одну реализацию UI для лекции по Редакс. Этот самый Редакс у них общий, и находится в отдельном пакедже, как и Реакт с Вью. Так вот, совсем не заметил какой-то принципиальной разницы в размере кода. Да подход отличается и даже привязка Редакса несколько другая. Но разницы в 70% нет даже близко. Возможно 10% и то с учетом стилей, поскольку выбранная (не мной) библиотека на Реакте проигрывает по гибкости. Если бы я выбрал другую, то не уверен, что код на Вью был бы меньше.
Psychosynthesis
Ну и да, весьма забавно, как у вас пользователи, которые, по сути, обеспечивают весь этот бизнес, так лихо аж на четвёртое место скатились. Как бы вы наняли программистов из второго пункта, чтобы до четвёртого добраться?
kashey Автор
Что было первым курица или яйцо? Утвержденный бизнес план и roadmap на два года вперед. В том и проблема — если у вас есть «продукт», а не imgboard с котиками, клиентам тоже очень важен ваш «бизнес» и его возможности расти и подстраиватся под рынок.
Если вы упираетесь в стенку и говорите клиенту — ну эээ, полгода на рефакторинг потребуется, и тут без разница что за «стенка» — колличество пользователей, фича или скорость работы — бизнес уходит в трубу.
Psychosynthesis
Не имея какого-то продукта вы никаких пользователей вообще не увидите.
Таким образом сначала всегда будут «бизнес план и roadmap», а затем всегда будут программисты это реализующие, а уже только потом пользователи. И вот уже потом, если всё сложится хорошо, может быть, будет то что вы написали вначале.
Так вот выбор неподходящей технологии легко может сделать так, чтобы этого «потом» уже и не наступило.
kashey Автор
Я во фронтенде уже очень давно, а в програмировании так еще дольше. Видел многое, верил многим, пробовал разное.
Раскрою секрет: «подходящей» технологии не существует!
Psychosynthesis
До сих пор пишу для МК код на Си образца 99-го, без всяких библиотек (кроме драйверов и специфичных для используемых железок).
Пока что не встречался с ситуацией, когда бы мне эта технология не подходила =)
Хотя… с другой стороны, может если бы мне нужны были RTOS, я бы думал иначе.
vintage
Это не правда.
Moxa
что есть крупный проект? сколько нужно человек чтобы сделать например trello?
dopusteam
Впилить $Mol?
token
Вы что такое человеку предлагаете? Выпилить модную технологию и сделать все с использованием головы, так ведь нельзя!!!