Честно говоря маловероятно, т.к. внутрення тулза и опенсор-продукт — разные вещи по степени приложения усилий.
Щас пилим активно Angular 2 вместо React.
Нет, цель экономии была, но совершенно в другом — перестать параллельно разрабатывать на зоопарке технологий, т.к. это постоянно жрало кучу ресурсов у каждого отдела в отдельности, и при этом качественного скачка вида «вот эти трое делают ядро продукта, а эти трое — UI» быть не могло. Специализация, и более специлиализированные рзработчики, шаринг знаний, шаринг ресурсов — вот, что хотел менеджмент.
Мы долго пытались жить с immutable.js, но в итоге это был оверкилл, вместо него сформировали одно простое правило — не изменять данные во View-слое, и immutable.js был смело выпилен.
Честое слово, это всё всё равно вкусовщина, но основных причин было три:
Крайне редко бывают вещи в которых я не могу разобраться за день — и это был именно такой случай — трудно понять быстро с высоты птичьего полета как что работает, и как сделать быстро какое-нть тестовое одностраничное приложение
Никто из команды ничего про него не знал, и энтузиазмом изучать не горел
Шаблонизатор был так себе — как делать анимации или локализацию было непонятно
Посмотрел, очень похоже на внутренние документы которые я делал.
Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
И в итоге все равно все это было задвинуто в 2016-м когда появился стабильный Angular 2.
Как я и писал выше — количество самодельных вещей всегда должно регулироваться наличием ресурсов у команды на их поддержку и развитие.
Knockout UI library — плохо… React тоже UI library c ваших слов — но это хорошо. В чем же тогда по-вашему разница между феймворком и библиотекой?
То, что это фрейворк или UI-библиотека — не имеет отношения к «понравилось» или «не понравилось».
Я в самом начале доклада написал, что не буду подробно останавливаться на том, почему не подошло, потому что это будет война религий и закидают помидорами.
Одним из важных моментов был тот, что технология не популярна.
Фактически кодер может лепить html почти также как статику, притом добавить байндинг разработчику несложно и позднее и кодеру этот байндинг не мешает во время последующего редактирования.
На текущий момент звезды сложились так, что верстальщика и не появилось, верстает самый опытный в этом чел из команды, и он же и пишет код для UI-виджетов, с которыми работает эта верстка.
А html темплейт в JS-коде в React приложениях меня например как-то удручает…
Меня он удручает еще больше, про это в докладе много рассказано. Как могли, боролись с этим, но партизаны там толстые, особенно с переводами и окончаниями фраз содержащих пол или число.
Angular будет вечно пытаться заткнуть магией недостатки JS и DOM.
Это тоже меня сильно расстраивает, т.к. в версии 2 появилась еще самодельная реализация Shadow DOM, и с CSS это дает кучу геморроя. Внятного способа создать застилизировать вложенный компонент из родительского так и нет. В общем, костылей стало больше.
Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.
Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
Все зависит от степени генерализации вопроса. С точки зрения владельцев бизнеса вопрос «на какой технологии делать веб-продукты компании, если наши программисты, в принципе, могут разобраться в любой из них?» вполне резонен и адекватен.
Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.
Задача любого фреймворка — в первую очередь упрощать жизнь разработчикам, делать работу более быстрой, простой, и менее бажной. И именно на вопрос — а как же будет лучше, купить станок или двуручной пилой мы и пытались разобраться.
Ведь в реальной жизни купить станок не всегда экономически выгоднее.
К сожалению, есть и печальная тенденция с пакетами, я ее замечал в среде javascript и python-разработчиков, когда у любого мало-мальски простого проекта 15 зависимостей, и среди них юмор типа «debug»: "~2.1.1", «serve-favicon»: "~2.2.0" (реальнй пример из Kibana4).
Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
В общем случае — нет, не стоит, именно для этого придумана модуляризация и package-менеджеры.
Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.
Щас пилим активно Angular 2 вместо React.
Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
Как я и писал выше — количество самодельных вещей всегда должно регулироваться наличием ресурсов у команды на их поддержку и развитие.
То, что это фрейворк или UI-библиотека — не имеет отношения к «понравилось» или «не понравилось».
Я в самом начале доклада написал, что не буду подробно останавливаться на том, почему не подошло, потому что это будет война религий и закидают помидорами.
Одним из важных моментов был тот, что технология не популярна.
На текущий момент звезды сложились так, что верстальщика и не появилось, верстает самый опытный в этом чел из команды, и он же и пишет код для UI-виджетов, с которыми работает эта верстка.
Меня он удручает еще больше, про это в докладе много рассказано. Как могли, боролись с этим, но партизаны там толстые, особенно с переводами и окончаниями фраз содержащих пол или число.
Это тоже меня сильно расстраивает, т.к. в версии 2 появилась еще самодельная реализация Shadow DOM, и с CSS это дает кучу геморроя. Внятного способа создать застилизировать вложенный компонент из родительского так и нет. В общем, костылей стало больше.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.
Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.
Задача любого фреймворка — в первую очередь упрощать жизнь разработчикам, делать работу более быстрой, простой, и менее бажной. И именно на вопрос — а как же будет лучше, купить станок или двуручной пилой мы и пытались разобраться.
Ведь в реальной жизни купить станок не всегда экономически выгоднее.
Так что есть и тенденция в работе предпринимать усилия по избавлению от такой «лапши».
Но как только возникает или потребность переделки(доделки) чужого кода или жесткие бизнес-требования, что «должно работать из коробки в любой момент, мы не можем что-то скачивать из инета» и все такое — тогда да, стоит хранить рядом.
Как и у любой более-менее серьезной инженерной задачи решения есть разные, зависящие от обстоятельств.