Тут есть одна ловушка. На одном проекте был похожий сетап, скрипты сборки, подключаемые как сабмодули + локальный конфиг, но не суть, идея та же. Было десятка два-три репозиториев микросервисов (условно), которые пользовались этим централизованным решением.
Так вот, после определённого порога накопленные специфические для конкретного проекта требования становятся комбинаторным взрывом. Слишком много опций сборки, поддержки специальных параметров конфига, эдж-кейсов, комбинаций настроек. Особенно когда есть просто сборки, дев-сборки, тестовые, а/б, условные фича-тоглы, экспериментальные проекты с нечеловеческими конфигами и т.п.
Ну то есть идея имеет право на жизнь, но ниша её не очень широка и обставлена дополнительными условиями, типа длительного неизменного мейнстрима.
Я для PoCов и мелких проектов ушёл на esbuild. Скорость сборки в дев-режиме оооочень приятная, как и размер зависимостей. Конечно, когда подключаешь линтинг, tsc-чек, компрессию, tailwind постпроцессинг и всё прочее, то падает, но всё равно остаётся в разы быстрее вебпака.
Тем не менее, когда уходит в прод - делаю вебпак-конфиг, из соображений, что народ уже писал: чтоб стандартный дев разобрался.
Да, согласен. Но хуки хотя бы разжёвываются в каждом утюге, на медиум зайти невозможно чтоб новую статью о хуках не увидеть, а ангуляр на 90% это магия и декораторы, и хочешь понять - лезь в исходники.
Впрочем, зависит от проекта и людей, наверное. Ко мне на собеседование приходили "ангуляр-разработчики", которые не знали чистого JS вообще (но и "реактовский" такой был тоже, для справделивости).
"Я пять проектов написал на ангуляре, зачем мне ваш жаваскрипт знать?"
(я, если что, не спрашивал сложение массивов с объектами - банальные this, замыкания, шедулер в общих чертах, передача по ссылке... народ претендовал на сеньоров/стронг мидлов).
Собственно потому мне и не особо нравится подход, когда детали реализации скрываются ради (сомнительного) удобства разработчика - рано или поздно, так или иначе, а любую систему начнут использовать не так, как задумывалось. И чем больше скрыто, тем больше неожиданных последствий можно огрести.
И это личный выбор программиста, точнее, команды. Вот меня это довольно сильно напрягает, потому что были случаи -
-- а вот тут мы пишем декоратор такой-то -- а что делает этот декоратор внутри? -- чёрт его знает, какую-то магию, в документации написано ставить декоратор и всё.
Та же фигня с CLI-тулзами (не только ангуляр, в том же реакте то же самое) - есть шаблон типового поведения - нет понимания, не говорю уже о контроле, что там происходит. Не то, что я хочу поныть в стиле "раньше на курсах вождения карбюратор на время собирали, а сейчас видосик 5 минут смотрят где какая педаль, и всё". Это, скорее, профессиональный перекос, потому что меня постоянно зовут то ng-eject делать, то просто руками новый бандлер написать, когда задача перерастает возможности стандартного тулчейна.
Но таки - и именно в ангуляре это очень заметно - у многих, особенно мидлов, есть перекос в сторону магического сознания, ну или стековерфловного, если угодно. Есть какая-то конструкция, внутри магия, делай как в примере. И смотрят как на странного, когда предлагаешь разобраться, а как вообще декораторы работают и что конкретно этот вот Inject делает в общей архитектуре.
Не холивара для, но я лично именно из-за этого ангуляр недолюбливаю (хотя это однозначно не проблема самого фреймворка, а его использования) - в реакте и прочих либах пользователь хотя бы в теории должен понимать композицию и общую картину что где происходит, как, и, главное, зачем.
Сорри за офтопик, просто как раз сижу разгребаю один проект-переросток на ангуляре.
Там и стекла хватает, и всяких камешков. Но понятно, что вряд ли что-то опасное будет посреди города (хотя... недавно как раз был скандал с радиоактивными амулетами).
Drugs Museum, Amsterdam. Камни, картины, предметы, искусственная пещера - светятся в ультрафиолете. Красиво, час там проторчал. А вот сейчас стало как-то немного стрёмно =)
Да, разумеется Вы правы. Переписывать с нуля всегда риск и обычно - и даже как правило - добром не кончается, хотя иногда это единственный выход. Были нюансы - стартап, который быстро запилил прототип, а потом этот прототип стал довольно хаотично обрастать фичами и использоваться как прод без рефакторинга, и уткнулся в тупик, в том числе по производительности. Причём тупик именно архитектурный и заложенный со старта - немасштабируемое решение.
Никто не ожидал такого роста нагрузки, или думали, что как-то само по ходу разработки решится. Понятное дело, тупик расширили железом, и так несколько раз, но такой подход тоже надолго не помогает. Если техдолг не отдавать, то он имеет свойство накрывать. А тут ещё и конкурентов как таковых не было - ниша удачная, ну и слишком долго почивали на лаврах.
В мягком варианте там была предложена разбивка монолита (это не о репозитории, а о стиле кода) на модули с постепенной их горячей заменой на "правильные модули". Этот подход, кстати, самый дорогой по квалификации привлекаемых специалистов и объёму надзора и вспомогательных работ, зато приложение гарантированно продолжает работать и при этом обновляться.
Ну да. Делал анализ сайта одного недавно по заказу. Итог: "используется фреймворк А неестественным образом. Общая архитектура подразумевает Х, когда нужно бы Y, а то и Z. Рекомендуется или переделать архитектуру (оценка затрат N), или переписать правильно с более подходящим фреймворком B, оценка затрат 0.5N. Альтернативный вариант - рекомендовать клиентам отказ от использования браузеров Ж версии ниже 11 и апгрейд техники до удовлетворения требований О (большое)".
Как думаете, что выбрал заказчик? полгода работы сильно нескольких сеньоров (жирным шрифтом) даже без имплементации новых фич, или продолжение говнокодинга, но с маркетингом за цену в десятую долю от и переложением затрат на клиентов, которым всё равно некуда деться?
Я вот прямо сейчас на одном проекте с мультибилдами (не очень сложными, TS + SCSS + React + Tailwind) заиспользовал esbuild, просто для посмотреть, что изменилось. Как заиспользовал - написал параллельные вебпаку конфиги и сравнил. В дев-режиме разница больше, чем в пять раз, в вотче даже замерить не могу, мгновенно, в проде где-то в три раза лучше.
Единственное что не стал переносить с вебпака - ifdef-loader, он не критичен. Обошёлся условными define. А так - всё завелось, сборка в режиме либы работает. Мульти-энтри (entrypoints) и массив конфигов в вебпаке, конечно, на порядок мощнее, но для небольших проектов esbuild имеет смысл.
Критичное, на что несколько часов убил, это управление выходными бандлами. Ну когда запускается сборка сразу нескольких бандлов, а результат надо положить в одну папку, и бандлы должны хитро называться. Для этого пришлось писать простенький плагинчик, но работает.
far4linux заводится на маке и там, если мне не изменяет склероз, нормальная работа с архивами из коробки. Но проверить не могу, у меня макось на дев-канале и в один прекрасный момент с полгода назад фар отвалился, а мне было лень разбираться.
Да как и везде - вопрос баланса и здравого смысла.
Тут есть одна ловушка. На одном проекте был похожий сетап, скрипты сборки, подключаемые как сабмодули + локальный конфиг, но не суть, идея та же. Было десятка два-три репозиториев микросервисов (условно), которые пользовались этим централизованным решением.
Так вот, после определённого порога накопленные специфические для конкретного проекта требования становятся комбинаторным взрывом. Слишком много опций сборки, поддержки специальных параметров конфига, эдж-кейсов, комбинаций настроек. Особенно когда есть просто сборки, дев-сборки, тестовые, а/б, условные фича-тоглы, экспериментальные проекты с нечеловеческими конфигами и т.п.
Ну то есть идея имеет право на жизнь, но ниша её не очень широка и обставлена дополнительными условиями, типа длительного неизменного мейнстрима.
Я для PoCов и мелких проектов ушёл на esbuild. Скорость сборки в дев-режиме оооочень приятная, как и размер зависимостей. Конечно, когда подключаешь линтинг, tsc-чек, компрессию, tailwind постпроцессинг и всё прочее, то падает, но всё равно остаётся в разы быстрее вебпака.
Тем не менее, когда уходит в прод - делаю вебпак-конфиг, из соображений, что народ уже писал: чтоб стандартный дев разобрался.
Да, согласен. Но хуки хотя бы разжёвываются в каждом утюге, на медиум зайти невозможно чтоб новую статью о хуках не увидеть, а ангуляр на 90% это магия и декораторы, и хочешь понять - лезь в исходники.
Впрочем, зависит от проекта и людей, наверное. Ко мне на собеседование приходили "ангуляр-разработчики", которые не знали чистого JS вообще (но и "реактовский" такой был тоже, для справделивости).
"Я пять проектов написал на ангуляре, зачем мне ваш жаваскрипт знать?"
(я, если что, не спрашивал сложение массивов с объектами - банальные this, замыкания, шедулер в общих чертах, передача по ссылке... народ претендовал на сеньоров/стронг мидлов).
Собственно потому мне и не особо нравится подход, когда детали реализации скрываются ради (сомнительного) удобства разработчика - рано или поздно, так или иначе, а любую систему начнут использовать не так, как задумывалось. И чем больше скрыто, тем больше неожиданных последствий можно огрести.
И это личный выбор программиста, точнее, команды. Вот меня это довольно сильно напрягает, потому что были случаи -
-- а вот тут мы пишем декоратор такой-то
-- а что делает этот декоратор внутри?
-- чёрт его знает, какую-то магию, в документации написано ставить декоратор и всё.
Та же фигня с CLI-тулзами (не только ангуляр, в том же реакте то же самое) - есть шаблон типового поведения - нет понимания, не говорю уже о контроле, что там происходит. Не то, что я хочу поныть в стиле "раньше на курсах вождения карбюратор на время собирали, а сейчас видосик 5 минут смотрят где какая педаль, и всё". Это, скорее, профессиональный перекос, потому что меня постоянно зовут то ng-eject делать, то просто руками новый бандлер написать, когда задача перерастает возможности стандартного тулчейна.
Но таки - и именно в ангуляре это очень заметно - у многих, особенно мидлов, есть перекос в сторону магического сознания, ну или стековерфловного, если угодно. Есть какая-то конструкция, внутри магия, делай как в примере. И смотрят как на странного, когда предлагаешь разобраться, а как вообще декораторы работают и что конкретно этот вот Inject делает в общей архитектуре.
Не холивара для, но я лично именно из-за этого ангуляр недолюбливаю (хотя это однозначно не проблема самого фреймворка, а его использования) - в реакте и прочих либах пользователь хотя бы в теории должен понимать композицию и общую картину что где происходит, как, и, главное, зачем.
Сорри за офтопик, просто как раз сижу разгребаю один проект-переросток на ангуляре.
В голландской компании интересно. Мартин, Мартен, Маартен и Мартайн - это четыре разных человека.
a iLoud Micromonitor нету? очень интересная штука, хоть и нишевая.
Там и стекла хватает, и всяких камешков. Но понятно, что вряд ли что-то опасное будет посреди города (хотя... недавно как раз был скандал с радиоактивными амулетами).
Drugs Museum, Amsterdam. Камни, картины, предметы, искусственная пещера - светятся в ультрафиолете. Красиво, час там проторчал. А вот сейчас стало как-то немного стрёмно =)
Да, разумеется Вы правы. Переписывать с нуля всегда риск и обычно - и даже как правило - добром не кончается, хотя иногда это единственный выход. Были нюансы - стартап, который быстро запилил прототип, а потом этот прототип стал довольно хаотично обрастать фичами и использоваться как прод без рефакторинга, и уткнулся в тупик, в том числе по производительности. Причём тупик именно архитектурный и заложенный со старта - немасштабируемое решение.
Никто не ожидал такого роста нагрузки, или думали, что как-то само по ходу разработки решится. Понятное дело, тупик расширили железом, и так несколько раз, но такой подход тоже надолго не помогает. Если техдолг не отдавать, то он имеет свойство накрывать. А тут ещё и конкурентов как таковых не было - ниша удачная, ну и слишком долго почивали на лаврах.
В мягком варианте там была предложена разбивка монолита (это не о репозитории, а о стиле кода) на модули с постепенной их горячей заменой на "правильные модули". Этот подход, кстати, самый дорогой по квалификации привлекаемых специалистов и объёму надзора и вспомогательных работ, зато приложение гарантированно продолжает работать и при этом обновляться.
Ну да. Делал анализ сайта одного недавно по заказу. Итог: "используется фреймворк А неестественным образом. Общая архитектура подразумевает Х, когда нужно бы Y, а то и Z. Рекомендуется или переделать архитектуру (оценка затрат N), или переписать правильно с более подходящим фреймворком B, оценка затрат 0.5N. Альтернативный вариант - рекомендовать клиентам отказ от использования браузеров Ж версии ниже 11 и апгрейд техники до удовлетворения требований О (большое)".
Как думаете, что выбрал заказчик? полгода работы сильно нескольких сеньоров (жирным шрифтом) даже без имплементации новых фич, или продолжение говнокодинга, но с маркетингом за цену в десятую долю от и переложением затрат на клиентов, которым всё равно некуда деться?
Поставить из дмг, запустить с клавишей кмд/ктрл, а то не сможет проверить разработчика, всё.
А что с тачбаром не так? Вроде нормально пишет все действия, даже с модификаторами.
о! Спасибо тебе, добрый человек!
Я с год назад или около того его ставил, или тогда не было, или пропустил.
Всё установлено, всё свежее, brew актуальный. Решилось принудительной переустановкой CLT, как, собственно, прямо на экране и написано.
Всё решается - мне даже на бете из исходников удалось собрать в итоге, но с час потратить пришлось.
Об этом и речь: хочется просто перетащить в applications, а оно чтоб само работало.
HOC? https://reactjs.org/docs/higher-order-components.html
например, вот
бигсюр, всё актуальное
За статью спасибо, но... чтобы - что? Какая задача решается?
На здоровье =)
Я вот прямо сейчас на одном проекте с мультибилдами (не очень сложными, TS + SCSS + React + Tailwind) заиспользовал esbuild, просто для посмотреть, что изменилось. Как заиспользовал - написал параллельные вебпаку конфиги и сравнил. В дев-режиме разница больше, чем в пять раз, в вотче даже замерить не могу, мгновенно, в проде где-то в три раза лучше.
Единственное что не стал переносить с вебпака - ifdef-loader, он не критичен. Обошёлся условными define. А так - всё завелось, сборка в режиме либы работает. Мульти-энтри (entrypoints) и массив конфигов в вебпаке, конечно, на порядок мощнее, но для небольших проектов esbuild имеет смысл.
Критичное, на что несколько часов убил, это управление выходными бандлами. Ну когда запускается сборка сразу нескольких бандлов, а результат надо положить в одну папку, и бандлы должны хитро называться. Для этого пришлось писать простенький плагинчик, но работает.
"cache: {type: filesystem, buildDependencies: { config: [__filename]}}"
на тот момент было экспериментальное, сейчас не знаю, не проверял. Даже в консоли предупреждение писало и валилось время от времени.
far4linux заводится на маке и там, если мне не изменяет склероз, нормальная работа с архивами из коробки. Но проверить не могу, у меня макось на дев-канале и в один прекрасный момент с полгода назад фар отвалился, а мне было лень разбираться.