Они даже с пониманием этого не справятся. Проблема крупных компаний в классической модели управления - тот самый пресловутый конвейр. С ним много чего не так в IT. При это все эти проблемы решаются тру extream programming. Нде каждый ответственнен за результат от и до и никаких нишевых разделений нет. Больщое IT сломано. Хотите досчтичь чегото - не делайте как они.
Так и есть. Браузер и css уже давно подросли и предлагают богатый функционал. А фреймворки пытаются решать давно не существующие задачи. На 90% сайтов они не нужны. Достаточно базы. Ну htmx на крайний случай, вместо axios, не по тому что не работает, а из-за декларативности подхода. Еще популярность набирает alpine.js - современный jquery. Далеко не всем нужны эти фреймворки. Задачи не те.
Можно суп пытаться ножом есть. Технически вы справитесь. Наедитесь ли вы? Вряд ли. Еще можно с JS сравнить - видели мем про JS Good Parts и Definitive Guide? Кубер это попытка все впихнуть в одно решение, хотя незачем было и пытаться.
Ваш опыт это лично ваш опыт в нескольких компаниях - это ошибка выжившего. Вы стали его заложником и не видите проблемы в классической модели управления с распределением ответственности в IT. Не осуждаю, чтобы понять в чем проблема надо целенаправленно интересоваться управлением проектов.
Это не проблема современных бэкендеров - это проблема индутрии, которая говорит им: "у нас тут дети Реакт, зовут себя фронтендерами - они делают фронт". Конечно никакой мотивации у людей не будет. Так что проблема не в них. Они в первую очередь разработчики. И отлично со всем разберутся.
Немножко спекуляции - возможно ваш Тимлид имел ввиду, что они не будут лезть в очередную дурно пахнущую кастрюлю с "UI Framework" лапшой. И тут он абсолютно прав. Нет никакого смысла там ковыряться и что-то чинить, да еще и выслушивать от "фронтендеров" что-то. Проще выбросить обычно.
Средства современного CSS позволяют с минимальными усилиями создавать качесственные интерфейсы. Нет уже той проблемы, что была 10-15 лет назад.
2. Инфраструктура и стоимость
Надо считать не 1 день внедрения, а все часы затупов и поиска багов которые последуют после этого. Что там с документацией? Вы сделали себя ботлнеком для этого решения. Теперь если вдруг что-то новое добавится, а вы будете в отпуске - все будут страдать. Новый валидатор не напишется или еще что.
Между монолитом и Микрофронтами есть достаточно решений не требующих больших изменений. Но то что вы это упомянули говорит о качестве процессов в вашей организации. Не мудрено что вы выбрали JSON боль. Сочувствую.
Изменения которые в долгосрочной перспективе упрощают работу гораздо важнее сиюминутной метрики. Разве что у вас там где-то бонус привязан?
3. UX и State на бэке
Да хоть космический корабль. Я писал что где надо - делается виджет на любимом фреймворке.
Есть такое подозрение
Есть встречные подозрения.
Ваш "Современный фронтенд" - это Теория оправдания системы в действии. Он сложен только по тому что "Дети" не думают, а берут самую сладкую конфету, а не брокколи. Они не видят картину целиком, где на самом деле границы ответственности, и не стараются делать проще. Типичный карго-культ.
В мобильном приложении конечно существуют ограничения платформы. Вот только там еще есть web-view, который сам покажет картинки с нужной странички. Если уж сильно захотеть - можно дать самому приложению доступ к базе и убрать все прослойки. Есть еще интересные варианты.
Удачи с развитием поделки. Искренне желаю чтобы у вас все получилось и вас за это не наказали в итоге.
htmx - это не просто транспорт. Это перенос стейта на бэк, где ему и положено быть. А это очень сильно все упрощает. Да придется чуть больше рутов добавить, но это проще чем решать решать проблему со стейтом на фронте. Simple != Easy. Там где нужно посыпать UI сахарком, можно добавить alpine.js или вообще обойтись CSS. А так-то все он решает, было бы желание покопать вглубь.
Идея то у Вас правильная. Страницы не должны быть захардкожены. Но решение очень спорное.
Это дополнительный слой, лишняя абстракция, которая только усложняет разработку. Скорее всего еще и не задокументированная. Этот конфиг должел Знания об этой поделке не переносятся на другие проекты. Просто лишняя сложность из ничего.
Раз уж критикую - буду предлагать. Есть проверенное решение - Микрофронты с виджетами. У каждого микрофронта свой бэк с htmx + alpine. Весь стейт и правила доступа там. Реактивность - через shell app.
В случаях где вам действительно без супер динамики не обойтись - сделайте только виджет на фреймворке, не надо всю страницу на них делать.
Никаких больших JSON, старые добрые проверенные технологии. И да все ваши бэк девелоперы могут и сами собрать работающий html и даже фронт за вас делать. Вам останется только предложить им коллекцию примеров(не компонентов) как это делать. Дизайн гайд бук, так сказать. И помочь где они застрянут. Ваша роль трансформируется в ментора по фронту, а их - в фулстеков. Те кто так сделают - получат отличный буст к мотивации.
Польза от ваших активностей с JSON может быть в другом. Можно преобразовать эти JSON-ы в приемочные тесты.
С незапамтных времен бэк отдавал фрон простым html и все были счастливы. Потом пришли дети с реакт и все свихнулись. Используйте htmx и будете счастливы. Не считая того что "бизнес сущность" это не про json...
Лол левел абстракции протекают - сам Грегор говорит о Абстракциях vs Иллюзии и про части пазла.
Как вы предлагаете забрать полностью манифест и дать возможность полностью все настраивать? Предоставить самописные манифест, знания о которых не переносится никуда?
То что вы описали в статье - это типичный тикет опс. Очень известный паттерн вызывающий боль у всех.
В идеале надо стремиться чтобы OPS первратились в platform team. Как по мне - это будет самое правильное решение. Про то как строить platform team правильно и без соломы - нужно смотреть что говорит Gregor Hohpe, например тут https://www.youtube.com/watch?v=_o-XHpBLSaY
Надо быть очень осторожным, чтобы не пойти на поводу у тех кто рекламирует платформу, продавая технические решения. В первую очередь это про культуру и селф-сервис.
Только Грегор говорит дело. Его лекции и книги самые полезные.
Вы суинули доку на фреймворк который диктует как должен писаться css в т.ч. с валидацией стилей в TS, разве не так? И вы продвигаете этот фреймворк, т.к. ваши знакомые дяди так делают. Т.е. вы именно это и имели ввиду.
Никакого лицемерия. Побил на составные части переносом строки и все понятно. И главное переносимо между командами, проектами, компаниями.
Я не знаю как измерить ерунду, чтобы понять как она влияет на процесс поставки. А вот знание тейлвинда можно. Могу даже на собесе спросить.
Как ни крути, а вы его или сами навелосипедите или возьмете готовый. Особенно это важно для каких-то админок, где стили можно взять чужие. Лишь бы выглядело прилично.
Они даже с пониманием этого не справятся. Проблема крупных компаний в классической модели управления - тот самый пресловутый конвейр. С ним много чего не так в IT. При это все эти проблемы решаются тру extream programming. Нде каждый ответственнен за результат от и до и никаких нишевых разделений нет. Больщое IT сломано. Хотите досчтичь чегото - не делайте как они.
Так и есть. Браузер и css уже давно подросли и предлагают богатый функционал. А фреймворки пытаются решать давно не существующие задачи. На 90% сайтов они не нужны. Достаточно базы. Ну htmx на крайний случай, вместо axios, не по тому что не работает, а из-за декларативности подхода. Еще популярность набирает alpine.js - современный jquery.
Далеко не всем нужны эти фреймворки. Задачи не те.
Можно суп пытаться ножом есть. Технически вы справитесь. Наедитесь ли вы? Вряд ли.
Еще можно с JS сравнить - видели мем про JS Good Parts и Definitive Guide?
Кубер это попытка все впихнуть в одно решение, хотя незачем было и пытаться.
Ваш опыт это лично ваш опыт в нескольких компаниях - это ошибка выжившего. Вы стали его заложником и не видите проблемы в классической модели управления с распределением ответственности в IT. Не осуждаю, чтобы понять в чем проблема надо целенаправленно интересоваться управлением проектов.
Это не проблема современных бэкендеров - это проблема индутрии, которая говорит им: "у нас тут дети Реакт, зовут себя фронтендерами - они делают фронт". Конечно никакой мотивации у людей не будет. Так что проблема не в них. Они в первую очередь разработчики. И отлично со всем разберутся.
Немножко спекуляции - возможно ваш Тимлид имел ввиду, что они не будут лезть в очередную дурно пахнущую кастрюлю с "UI Framework" лапшой. И тут он абсолютно прав. Нет никакого смысла там ковыряться и что-то чинить, да еще и выслушивать от "фронтендеров" что-то. Проще выбросить обычно.
Средства современного CSS позволяют с минимальными усилиями создавать качесственные интерфейсы. Нет уже той проблемы, что была 10-15 лет назад.
Надо считать не 1 день внедрения, а все часы затупов и поиска багов которые последуют после этого. Что там с документацией? Вы сделали себя ботлнеком для этого решения. Теперь если вдруг что-то новое добавится, а вы будете в отпуске - все будут страдать. Новый валидатор не напишется или еще что.
Между монолитом и Микрофронтами есть достаточно решений не требующих больших изменений. Но то что вы это упомянули говорит о качестве процессов в вашей организации. Не мудрено что вы выбрали JSON боль. Сочувствую.
Изменения которые в долгосрочной перспективе упрощают работу гораздо важнее сиюминутной метрики. Разве что у вас там где-то бонус привязан?
Да хоть космический корабль. Я писал что где надо - делается виджет на любимом фреймворке.
Есть встречные подозрения.
Ваш "Современный фронтенд" - это Теория оправдания системы в действии. Он сложен только по тому что "Дети" не думают, а берут самую сладкую конфету, а не брокколи. Они не видят картину целиком, где на самом деле границы ответственности, и не стараются делать проще. Типичный карго-культ.
В мобильном приложении конечно существуют ограничения платформы. Вот только там еще есть web-view, который сам покажет картинки с нужной странички. Если уж сильно захотеть - можно дать самому приложению доступ к базе и убрать все прослойки. Есть еще интересные варианты.
Удачи с развитием поделки. Искренне желаю чтобы у вас все получилось и вас за это не наказали в итоге.
htmx - это не просто транспорт. Это перенос стейта на бэк, где ему и положено быть. А это очень сильно все упрощает. Да придется чуть больше рутов добавить, но это проще чем решать решать проблему со стейтом на фронте. Simple != Easy.
Там где нужно посыпать UI сахарком, можно добавить alpine.js или вообще обойтись CSS. А так-то все он решает, было бы желание покопать вглубь.
Идея то у Вас правильная. Страницы не должны быть захардкожены. Но решение очень спорное.
Это дополнительный слой, лишняя абстракция, которая только усложняет разработку. Скорее всего еще и не задокументированная. Этот конфиг должел Знания об этой поделке не переносятся на другие проекты. Просто лишняя сложность из ничего.
Раз уж критикую - буду предлагать. Есть проверенное решение - Микрофронты с виджетами. У каждого микрофронта свой бэк с htmx + alpine. Весь стейт и правила доступа там. Реактивность - через shell app.
В случаях где вам действительно без супер динамики не обойтись - сделайте только виджет на фреймворке, не надо всю страницу на них делать.
Никаких больших JSON, старые добрые проверенные технологии. И да все ваши бэк девелоперы могут и сами собрать работающий html и даже фронт за вас делать. Вам останется только предложить им коллекцию примеров(не компонентов) как это делать. Дизайн гайд бук, так сказать. И помочь где они застрянут. Ваша роль трансформируется в ментора по фронту, а их - в фулстеков. Те кто так сделают - получат отличный буст к мотивации.
Польза от ваших активностей с JSON может быть в другом. Можно преобразовать эти JSON-ы в приемочные тесты.
С незапамтных времен бэк отдавал фрон простым html и все были счастливы. Потом пришли дети с реакт и все свихнулись. Используйте htmx и будете счастливы. Не считая того что "бизнес сущность" это не про json...
Кубер из нового добавил только баланс контейнеров по железу. Остальное существовало и без него в том или ином виде.
Великолепно все было бы. Может даже лучше. Кто нибудь придумал бы систему получше. Небыло бы Арго. И других штук решающих проблемы арго.
Откройте форточку кто-нибудь :)
Лол левел абстракции протекают - сам Грегор говорит о Абстракциях vs Иллюзии и про части пазла.
Как вы предлагаете забрать полностью манифест и дать возможность полностью все настраивать? Предоставить самописные манифест, знания о которых не переносится никуда?
Делаю так с незапамятных времен и боли ин мемори стейта не знаю. Всем рекомендую.
кажется я промазал и ответил вам ниже.
То что вы описали в статье - это типичный тикет опс. Очень известный паттерн вызывающий боль у всех.
В идеале надо стремиться чтобы OPS первратились в platform team. Как по мне - это будет самое правильное решение. Про то как строить platform team правильно и без соломы - нужно смотреть что говорит Gregor Hohpe, например тут https://www.youtube.com/watch?v=_o-XHpBLSaY
Надо быть очень осторожным, чтобы не пойти на поводу у тех кто рекламирует платформу, продавая технические решения. В первую очередь это про культуру и селф-сервис.
Только Грегор говорит дело. Его лекции и книги самые полезные.
Мы правильно распределяем работу. Если тот кто придумал ux не в состоянии его сверстать, то пусть делает проще или доучивается.
Все скриптовое поведение изначально должно быть представлено дизайнером. Оно не берется из вакуума.
UX designer в 25 году обязан уметь делать верстку. Остальные - фигма-бои не достойны этой должности. Пусть двльше презентации клепают.
Откуда у вас это желание обесценить других?
Вы суинули доку на фреймворк который диктует как должен писаться css в т.ч. с валидацией стилей в TS, разве не так? И вы продвигаете этот фреймворк, т.к. ваши знакомые дяди так делают. Т.е. вы именно это и имели ввиду.
Никакого лицемерия. Побил на составные части переносом строки и все понятно. И главное переносимо между командами, проектами, компаниями.
Но ни первое, ни второе не отменило ни одного изначального "ритуала". Т.е. скрам остался скрамом.
Про версионность поддержиыаю 100%. Так понятнее будет всем. Вдруг кто знаком со старой версией.
Вот только тут девопсом и не пахнет. Это обычная Опс команда и да - они ботлнек.
Стили в первую очкредь не должны быть привязаны к js. Вообще js вторичен в браузере.
По этому мы пишем клевый переносимый код. А не исповедуем TS. Следим за когнитивной нагрузкой и избегаем случайной сложности.
Не знаю как измерить чушь.
Не вижу дядь.
Какая то поделка очередная, которая не может в стили сама и требует тонну js. Тут же переизобретает браузер.
Знания не переносимые. Ни за что бы в проект не взял.
Нельзя дать дизайнеру задачу и получить результат который интегрируется сразу в проект копипастой. Требование знания TS - абсурд для них.
Я не знаю как измерить ерунду, чтобы понять как она влияет на процесс поставки. А вот знание тейлвинда можно. Могу даже на собесе спросить.
Как ни крути, а вы его или сами навелосипедите или возьмете готовый. Особенно это важно для каких-то админок, где стили можно взять чужие. Лишь бы выглядело прилично.
Когнитивная нагрузка с ним гораздо меньше.