А смысл? Можно подумать есть примеры, когда суды позволяли решить подобные проблемы (конкретно в РФ и конкретно в последние лет 10). Тут на хабре иногда мелькают статьи пары энтузиастов, которые пытаются что-то в этом направлении делать - но прогресса у них я что-то не припомню. Т.е. писать бумажки можно, и деньги на юриста тратить тоже можно, а вот что-то получить взамен кроме формальных отписок и диких (с точки зрения здравого смысла) решений судов - нет.
А по-моему передёргиваете понятия как раз Вы. Потому что когда домашний пользователь, не ИТшник, начинает настраивать на домашнем роутере VPN, обычно по инструкции которую он толком не понимает, то делает он это исключительно для восстановления доступа к информации, которой привык пользоваться.
Иными словами, технически может Вы и правы, но практически это не имеет значения - все домашние VPN делаются как раз для обхода блокировок, поэтому все попадут под новый закон.
Конечно "хороший архитект" и тут зарешает, но на всех таких не напасёшься.
Это правда, но с этим ничего не поделаешь. Суть микросервисной архитектуры в том, что часть сложности переносится из кода в связи между микросервисами. Это позволяет снизить требования к квалификации разработчиков (которых много) за счёт повышения требований к квалификации архитектов (которых мало). Обычно такой размен бизнесу выгоден. Но только при наличии архитекта, который сможет справиться с повысившейся сложностью лично его работы.
А когда этот же UI элемент генерирует бэк что, источников данных становится меньше? Чтобы бэк мог ответить и забыть на нём много всего сделано, чтобы данные из этих разных источников попали в нужном виде в ту БД, из которой бэк "просто ответит и забудет". Всё это - вопрос архитектуры, не больше и не меньше. А когда на архитектуру забили, то и получается "всё переплетено". Это не специфика фронта, это специфика разработки без архитектуры, на бэке так тоже умеют делать.
У вас есть машинка с известной цпу и оперативкой, вот что у вас есть.
Не-а. Не "есть". Мы на бэке её себе искусственно организуем (через контейнеры докер). И делаем это как раз потому, что иначе будет куча лишних сложностей. Это как раз один из тех подходов, о которых я говорил, вместе с фиксированным набором разных типов БД и т.п.
Когда нужно на 4-м андроиде показывать бесконечную ленту
Я не понял, каким боком тут вообще андроид (вроде же веб-фронт обсуждаем). Но для веб-фронта я бесконечную ленту на бэке делал - ничего сложного, микрокод на JS который дозапрашивает ещё кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div.
На бэке от микросервисов лучше всё-таки становится, и значительно. Но для этого нужен хороший архитект, это обязательное условние. (Без него станет хуже, и тоже значительно.) После чего основная сложность остаётся там, где остаются нужны распределённые транзакции/саги в том или ином виде. На фронте транзакций вроде бы нет. Что тогда создаёт сложности в микрофронтендах?
Никакой трансформации никогда не было - законы всегда проводят интересы оного "сильного". Просто в исторические периоды, когда под "сильным" шатается кресло, и ему нужна поддержка голосов/винтовок большинства населения, законы это учитывают. А в периоды, когда "сильному" нужно поднимать экономику, для чего нужно чтобы большинство населения чувствовало себя защищёнными, законы тоже это учитывают. Для упомянутого "большинства" в такие периоды выглядит так, будто с ними считаются и их интересы учитывают - но это только так выглядит.
Там проблема не столько в WASM, сколько в удобной коммуникации между DOM/JS и "нормальным языком" во-первых, и во-вторых в том, что совершенно непонятно что делать с громадным количеством библиотек/компонент на JS, которые необходимы для формирования привычного UI - как правило попытка их использовать совместно с WASM приводит к конфликтам (оба пытаются контролировать одну и ту же часть DOM не зная друг о друге). Очевидное решение этого конфликта - переписать всё на "нормальном языке"… Но пока что-то никто не взялся столько всего переписать.
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
Любой подвиг - обычно следствие чьей-то ошибки. Если всё делать нормально, то подвиги не понадобятся. Но - всё нормально не делается почти никогда, так что место подвигу всё ещё есть.
Да, почти всё проблемы известные и относительно детские. Но не тогда, когда во-первых ты заранее не знаешь, какие из известных и детских проблем критично проявятся на конкретно этом проекте, и во-вторых когда они на тебя вываливаются внезапно и по нескольку одновременно, и времени на нормальное решение нет, потому что нужно тушить пожары и срочно масштабироваться на порядок. Да, если знать заранее что понадобится то многих проблем можно было бы избежать. Но этого не знает никто. Так что если Cursor с этим справился, значит они молодцы.
Потому что психология. Есть высокая вероятность, что продать широкой аудитории такие инструменты и подход в целом говоря "мы увидим весь ваш код ещё в процессе его написания, сохраним у себя, и будем использовать как захотим (напр. обучать на нём свои модели, которые дальше будут этот же код предлагать другим нашим клиентам)" - не получилось бы.
Но не видя код - они не предложат ничего полезного. Не сохраняя код - не предложат ничего достаточно быстро. А если они код и видят и сохраняют, и единственный способ "гарантировать" что они его не используют для собственный целей - это сказать "мамой клянус, да!". Но психологически впечатление всё ещё необходимо произвести прямо противоположное, вот и появляется где-то чисто маркетинговое "шифрование", где-то реальное, но в любом случае обычно довольно условное. И это работает, потому что не только "продавец хочет обмануть", но и "покупатель рад обманываться".
Это довольно очевидный, напрашивающийся… но, вполне возможно, некорректный ответ.
Я не буду спрашивать в чём принципиальное отличие GUI от TUI и CLI (которые на бэке есть). Я спрошу другое: а как же условный Web 1.0? Ровно тот же HTML+CSS+JS, но рендеринг полностью на бэке - чем это не GUI? И окажется, что отличие тут ровно в том, о чём я писал - в ограничениях и дисциплине. Условно можно считать, что во времена Web 1.0 мы говорили продакту "нет, мы не сделаем SPA, а будем рендерить всё на беке, и страничка у юзера будет постоянно перечитываться". И никаких сопоставимых с текущей ситуацией на фронте сложностей при этом не возникало. (Подсказка: в случае TUI и CLI всё выглядит очень похоже - и там и там есть куча ограничений, которые приходится соблюдать, которые создают кучу неудобств и для пользователей и для разработчиков этих UI, но зато код получается вполне умеренной сложности.)
Да и задачи разные, не будут те же инструменты так удобны на фронте.
Есть вероятность, что задачи просто кажутся разными. Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает? Я допускаю, что ключевое различие между задачами, из-за которого они и воспринимаются "разными", заключается как раз в дисциплине: на фронте задача "сделать что сказал продакт", а на бэке задача "сказать продакту что мы можем и чего не можем сделать".
Собственно, на бэке вполне долго и упорно пытались писать без оной дисциплины, послушно делая всё, что просил бизнес. Как правило, всегда получали в результате "большой комок грязи" и необходимость переписывать проект с нуля. Этот подход просто не работает, особенно если проект изначально сложный или его нужно много лет развивать.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Ну, я говорю о дисциплине "в среднем по индустрии". Отдельные разработчики могут значительно от этого среднего отличаться. Но и как Вы говорите тоже часто бывает: на бэке строгая типизация, линтеры и свои правила/best practices и подходы к разработке/тестированию/отладке/мониторингу, а на фронте всё это совсем другое. И один и тот же человек вполне может писать один проект чисто и соблюдая кучу ограничений и при этом параллельно писать другой на другом языке быстро-грязно.
Как человек посторонний и довольно далёкий от фронта, но много лет наблюдающий конкретно за Вами, могу дать один непрошенный совет (который Вы проигнорируете), но который ценен именно тем, что описывает впечатление "со стороны", не предвзятое.
Я вполне допускаю, что $mol это очень достойный проект, как минимум не хуже своих основных конкурентов. Но единственное, что его может спасти (точнее, сделать заметно популярнее) - это ребрендинг и полное отстранение лично Вас от общения с коммьюнити. Для коммуникации этому проекту нужен совершенно другой человек, который умеет разговаривать с разработчиками так, чтобы не агрить их на пустом месте. Софты не просто важны, они критичны - пока пользователи Вашего продукта это обычные люди. Это обидное (особенно для крутых технарей), но это факт.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке. Отговорка с "много входов/выходов" тут не очень работает, потому что практически на все ваши фронтовые входы есть соответствующие им входы в API бэка. Этот API нередко очень объёмный, и, как и на фронте, в конечном итоге влияет на некое очень большое состояние (БД), иногда разделённое между компонентами (микросервисами), иногда монолитное. В общем, параллели довольно очевидные, а вот такой боли (и заодно непрерывного мелькания инструментов/библиотек/фреймворков) как на фронте - нет. Причём этого нет вне зависимости от используемого ЯП бэка (может, за исключением ноды, там теоретически должно мелькать примерно то же, что и на фронте, но это результат того, что вы в каком-то смысле "взяли фронт и запустили его на бэке" как раз для того, чтобы не использовать штатные технологии и ЯП бэка - так что это особый кейс и его в текущем контексте обсуждения можно игнорировать).
Идея автора статьи рендерить часть UI на бэке выглядит рабочей, но он тоже не задаётся вопросом "а почему выполнить ровно эту же самую работу на бэке не является настолько же сложным, как на фронте - ведь работа-то в конечном итоге одна и та же".
Лично я предполагаю, что ключевой частью ответа на этот вопрос может быть "дисциплина". На бэке принято соблюдать длинный список ограничений, к которым мы настолько привыкли, что для многих "так было всегда" и они их даже не воспринимают как что-то особенное. Например, на бэке никто не делает свои БД. В смысле, чтобы вот у каждого проекта была своя уникальная БД - такого нет. А ведь когда-то такое было нормой, и я даже эти времена ещё немного застал. Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения. Любые глобальные переменные вызывают нервный тик, даже если это "просто" конфигурация или логгер. Чуть менее очевидные/однозначные примеры включают в себя чистую/гексагональную архитектуру (100% изоляцию бизнес-логики от внешнего мира для простой тестируемости), модульную/микросервисную архитектуру (тут фишка в том, чтобы адекватно спроектировать архитектуру, чтобы размер этих модулей был и не очень мелким и не очень крупным плюс удачно соответствовал границам транзакций и UX-ожиданиям консистентности - для этого придумали стратегические паттерны DDD). Чуть более очевидный пример - на бэке в принципе считается нормальным сначала сделать архитектуру и уделять ей много внимания, даже если это блокирует новые фичи. А ещё - на бэке считается нормальным говорить "НЕТ" в ответ на пожелания бизнеса (это примерно то же, что рекомендует автор статьи в контексте "делайте меньше кнопок"): "нет, это работать не будет", "нет, это слишком сложно реализовать и мы в этом утонем", "нет, это будет архитектурная дыра в безопасности", … много разных "нет". И хотя за некоторыми из них может скрываться "нет, мне лень это делать", сам факт что бэк умеет говорить "нет" имеет значение!
Уже не будут - этот рынок полностью сожрёт ИИ с вайб-кодингом. Собственно, он уже, просто большинство и заказчиков и исполнителей это пока не осознали.
Попросите заказчика организовать удаленное рабочее место, на котором он сможет следить за тем что вы фактически работаете а не придумываете часы. В таком случае вы готовы будете работать в таких условиях?
Теоретически - да. Вопрос только в том, зачем мне это нужно? Работать в таком стиле будет менее удобно, и этот, совершенно лишний, дискомфорт заказчик должен будет мне как-то компенсировать. Нам обоим должна быть очень-очень нужна эта совместная работа, чтобы мы оба на это согласились - я на дискомфорт, он на компенсацию (если деньгами, то это увеличит мою з/п в 1.5-2 раза).
Тут нужны компромиссы с двух сторон.
Да? И где в этой схеме Вы видите компромисс со стороны работодателя?
Я пока тут вижу исключительно надуманную проблему работодателя, которую он пытается решить создав сложности как исполнителю так и себе (дополнительная работа по контролю исполнителя). Это довольно типично на фрилансе для работодателей не-IT-шников, которые привыкли контролировать персонал в магазине (условно) и абсолютно без понятия как контролировать результаты интеллектуальной деятельности фрилансера, поэтому пытаются использовать привычные методы "сиди под камерой и потей, чтобы я видел, что ты напряжённо думаешь, когда не набираешь код".
Сами фрилансеры в этом видят ровно одну проблему: нужно искать работу среди той половины работодателей, которые более адекватны, и не требуют использовать софт для мониторинга активности. К слову говоря, я уже лет 15 не смотрел что творится на рынке фриланса, но даже в то время были распространены утилиты, которые обманывали шпионский софт Upwork, двигая мышкой и листая открытый файл, делая вид что исполнитель просматривает код. Ну т.е. работодатели требующие жёсткий контроль всё-равно в ответ получали обман, только они ещё и своё время тратили на изучение отчётов об активности.
Этот подход - не работает. Единственный реальный эффект от этого шпионажа - психологический комфорт заказчика, но никак не экономия денег или защита от вранья исполнителей.
А смысл? Можно подумать есть примеры, когда суды позволяли решить подобные проблемы (конкретно в РФ и конкретно в последние лет 10). Тут на хабре иногда мелькают статьи пары энтузиастов, которые пытаются что-то в этом направлении делать - но прогресса у них я что-то не припомню. Т.е. писать бумажки можно, и деньги на юриста тратить тоже можно, а вот что-то получить взамен кроме формальных отписок и диких (с точки зрения здравого смысла) решений судов - нет.
А по-моему передёргиваете понятия как раз Вы. Потому что когда домашний пользователь, не ИТшник, начинает настраивать на домашнем роутере VPN, обычно по инструкции которую он толком не понимает, то делает он это исключительно для восстановления доступа к информации, которой привык пользоваться.
Иными словами, технически может Вы и правы, но практически это не имеет значения - все домашние VPN делаются как раз для обхода блокировок, поэтому все попадут под новый закон.
Это правда, но с этим ничего не поделаешь. Суть микросервисной архитектуры в том, что часть сложности переносится из кода в связи между микросервисами. Это позволяет снизить требования к квалификации разработчиков (которых много) за счёт повышения требований к квалификации архитектов (которых мало). Обычно такой размен бизнесу выгоден. Но только при наличии архитекта, который сможет справиться с повысившейся сложностью лично его работы.
А когда этот же UI элемент генерирует бэк что, источников данных становится меньше? Чтобы бэк мог ответить и забыть на нём много всего сделано, чтобы данные из этих разных источников попали в нужном виде в ту БД, из которой бэк "просто ответит и забудет". Всё это - вопрос архитектуры, не больше и не меньше. А когда на архитектуру забили, то и получается "всё переплетено". Это не специфика фронта, это специфика разработки без архитектуры, на бэке так тоже умеют делать.
Не-а. Не "есть". Мы на бэке её себе искусственно организуем (через контейнеры докер). И делаем это как раз потому, что иначе будет куча лишних сложностей. Это как раз один из тех подходов, о которых я говорил, вместе с фиксированным набором разных типов БД и т.п.
Я не понял, каким боком тут вообще андроид (вроде же веб-фронт обсуждаем). Но для веб-фронта я бесконечную ленту на бэке делал - ничего сложного, микрокод на JS который дозапрашивает ещё кусок страницы когда скроллер приближается к концу и дописывает присланный бэком кусок html в нужный div.
А, кстати, почему так?
На бэке от микросервисов лучше всё-таки становится, и значительно. Но для этого нужен хороший архитект, это обязательное условние. (Без него станет хуже, и тоже значительно.) После чего основная сложность остаётся там, где остаются нужны распределённые транзакции/саги в том или ином виде. На фронте транзакций вроде бы нет. Что тогда создаёт сложности в микрофронтендах?
Никакой трансформации никогда не было - законы всегда проводят интересы оного "сильного". Просто в исторические периоды, когда под "сильным" шатается кресло, и ему нужна поддержка голосов/винтовок большинства населения, законы это учитывают. А в периоды, когда "сильному" нужно поднимать экономику, для чего нужно чтобы большинство населения чувствовало себя защищёнными, законы тоже это учитывают. Для упомянутого "большинства" в такие периоды выглядит так, будто с ними считаются и их интересы учитывают - но это только так выглядит.
Там проблема не столько в WASM, сколько в удобной коммуникации между DOM/JS и "нормальным языком" во-первых, и во-вторых в том, что совершенно непонятно что делать с громадным количеством библиотек/компонент на JS, которые необходимы для формирования привычного UI - как правило попытка их использовать совместно с WASM приводит к конфликтам (оба пытаются контролировать одну и ту же часть DOM не зная друг о друге). Очевидное решение этого конфликта - переписать всё на "нормальном языке"… Но пока что-то никто не взялся столько всего переписать.
Это, конечно, правда, но, на мой взгляд, не очень релевантная. Во-первых потому, что на бэке тьма языков но в данном вопросе принципиальной разницы между ними нет. Во-вторых потому, что вроде уже есть консенсунс по использованию TS вместо JS, его поддерживают все основные библиотеки/фреймворки и большинство новых проектов делают на TS.
Никаких противоречий нет - желающие творить фигню найдут способ. Разница в том, что является нормой. Особенности ноды для бэка - не норма, а исключение. Причём так сложилось как раз потому, что нормально ноду воспринимают в основном уже привыкшие к этому беспределу фронтендеры, которым понадобилось немного писать и бэк тоже - а для всех остальных такое на бэке скорее не норма, и они предпочитают более удобные ЯП и инструменты.
Языков без полноценного ООП на бэке полно - тот же Go. Это ничему не мешает, скорее наоборот.
Интерактивности на бэке вообще-то на порядок больше. Это на фронте юзер один, у него одна клава и одна мышка. А на бэке могут быть миллионы одновременно происходящих событий в одном многопоточном сервисе - включая как события от множества юзеров на фронте так и внутренние события бэка. И всё это льётся в общий стейт/БД, взаимодействует друг с другом, и должно обеспечивать консистентность.
Конечно. На бэке полно проблем. Именно поэтому и сформировались довольно жёсткие ограничения, которые мы стараемся соблюдать - где-то это помогает, где-то не до конца. Самое сложное сейчас - правильно определять границы между модулями/микросервисами и корректировать их при изменении бизнес-требований. Тем не менее, по сравнению с происходящим на фронте - на бэке тишина и спокойная работа, с использованием достаточно стабильного набора инструментов.
Любой подвиг - обычно следствие чьей-то ошибки. Если всё делать нормально, то подвиги не понадобятся. Но - всё нормально не делается почти никогда, так что место подвигу всё ещё есть.
Да, почти всё проблемы известные и относительно детские. Но не тогда, когда во-первых ты заранее не знаешь, какие из известных и детских проблем критично проявятся на конкретно этом проекте, и во-вторых когда они на тебя вываливаются внезапно и по нескольку одновременно, и времени на нормальное решение нет, потому что нужно тушить пожары и срочно масштабироваться на порядок. Да, если знать заранее что понадобится то многих проблем можно было бы избежать. Но этого не знает никто. Так что если Cursor с этим справился, значит они молодцы.
Потому что психология. Есть высокая вероятность, что продать широкой аудитории такие инструменты и подход в целом говоря "мы увидим весь ваш код ещё в процессе его написания, сохраним у себя, и будем использовать как захотим (напр. обучать на нём свои модели, которые дальше будут этот же код предлагать другим нашим клиентам)" - не получилось бы.
Но не видя код - они не предложат ничего полезного. Не сохраняя код - не предложат ничего достаточно быстро. А если они код и видят и сохраняют, и единственный способ "гарантировать" что они его не используют для собственный целей - это сказать "мамой клянус, да!". Но психологически впечатление всё ещё необходимо произвести прямо противоположное, вот и появляется где-то чисто маркетинговое "шифрование", где-то реальное, но в любом случае обычно довольно условное. И это работает, потому что не только "продавец хочет обмануть", но и "покупатель рад обманываться".
Это довольно очевидный, напрашивающийся… но, вполне возможно, некорректный ответ.
Я не буду спрашивать в чём принципиальное отличие GUI от TUI и CLI (которые на бэке есть). Я спрошу другое: а как же условный Web 1.0? Ровно тот же HTML+CSS+JS, но рендеринг полностью на бэке - чем это не GUI? И окажется, что отличие тут ровно в том, о чём я писал - в ограничениях и дисциплине. Условно можно считать, что во времена Web 1.0 мы говорили продакту "нет, мы не сделаем SPA, а будем рендерить всё на беке, и страничка у юзера будет постоянно перечитываться". И никаких сопоставимых с текущей ситуацией на фронте сложностей при этом не возникало. (Подсказка: в случае TUI и CLI всё выглядит очень похоже - и там и там есть куча ограничений, которые приходится соблюдать, которые создают кучу неудобств и для пользователей и для разработчиков этих UI, но зато код получается вполне умеренной сложности.)
Есть вероятность, что задачи просто кажутся разными. Иначе почему перенос рендеринга на бэк обычно всё заметно упрощает? Я допускаю, что ключевое различие между задачами, из-за которого они и воспринимаются "разными", заключается как раз в дисциплине: на фронте задача "сделать что сказал продакт", а на бэке задача "сказать продакту что мы можем и чего не можем сделать".
Собственно, на бэке вполне долго и упорно пытались писать без оной дисциплины, послушно делая всё, что просил бизнес. Как правило, всегда получали в результате "большой комок грязи" и необходимость переписывать проект с нуля. Этот подход просто не работает, особенно если проект изначально сложный или его нужно много лет развивать.
Ну, я говорю о дисциплине "в среднем по индустрии". Отдельные разработчики могут значительно от этого среднего отличаться. Но и как Вы говорите тоже часто бывает: на бэке строгая типизация, линтеры и свои правила/best practices и подходы к разработке/тестированию/отладке/мониторингу, а на фронте всё это совсем другое. И один и тот же человек вполне может писать один проект чисто и соблюдая кучу ограничений и при этом параллельно писать другой на другом языке быстро-грязно.
Как человек посторонний и довольно далёкий от фронта, но много лет наблюдающий конкретно за Вами, могу дать один непрошенный совет (который Вы проигнорируете), но который ценен именно тем, что описывает впечатление "со стороны", не предвзятое.
Я вполне допускаю, что $mol это очень достойный проект, как минимум не хуже своих основных конкурентов. Но единственное, что его может спасти (точнее, сделать заметно популярнее) - это ребрендинг и полное отстранение лично Вас от общения с коммьюнити. Для коммуникации этому проекту нужен совершенно другой человек, который умеет разговаривать с разработчиками так, чтобы не агрить их на пустом месте. Софты не просто важны, они критичны - пока пользователи Вашего продукта это обычные люди. Это обидное (особенно для крутых технарей), но это факт.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке. Отговорка с "много входов/выходов" тут не очень работает, потому что практически на все ваши фронтовые входы есть соответствующие им входы в API бэка. Этот API нередко очень объёмный, и, как и на фронте, в конечном итоге влияет на некое очень большое состояние (БД), иногда разделённое между компонентами (микросервисами), иногда монолитное. В общем, параллели довольно очевидные, а вот такой боли (и заодно непрерывного мелькания инструментов/библиотек/фреймворков) как на фронте - нет. Причём этого нет вне зависимости от используемого ЯП бэка (может, за исключением ноды, там теоретически должно мелькать примерно то же, что и на фронте, но это результат того, что вы в каком-то смысле "взяли фронт и запустили его на бэке" как раз для того, чтобы не использовать штатные технологии и ЯП бэка - так что это особый кейс и его в текущем контексте обсуждения можно игнорировать).
Идея автора статьи рендерить часть UI на бэке выглядит рабочей, но он тоже не задаётся вопросом "а почему выполнить ровно эту же самую работу на бэке не является настолько же сложным, как на фронте - ведь работа-то в конечном итоге одна и та же".
Лично я предполагаю, что ключевой частью ответа на этот вопрос может быть "дисциплина". На бэке принято соблюдать длинный список ограничений, к которым мы настолько привыкли, что для многих "так было всегда" и они их даже не воспринимают как что-то особенное. Например, на бэке никто не делает свои БД. В смысле, чтобы вот у каждого проекта была своя уникальная БД - такого нет. А ведь когда-то такое было нормой, и я даже эти времена ещё немного застал. Но уже нет. Есть SQL, есть NoSQL, есть message brokers, есть K/V кеши - все они накладывают свои ограничения, но мы всё-равно берём кого-то из них а не пишем своё хранилище состояния приложения. Любые глобальные переменные вызывают нервный тик, даже если это "просто" конфигурация или логгер. Чуть менее очевидные/однозначные примеры включают в себя чистую/гексагональную архитектуру (100% изоляцию бизнес-логики от внешнего мира для простой тестируемости), модульную/микросервисную архитектуру (тут фишка в том, чтобы адекватно спроектировать архитектуру, чтобы размер этих модулей был и не очень мелким и не очень крупным плюс удачно соответствовал границам транзакций и UX-ожиданиям консистентности - для этого придумали стратегические паттерны DDD). Чуть более очевидный пример - на бэке в принципе считается нормальным сначала сделать архитектуру и уделять ей много внимания, даже если это блокирует новые фичи. А ещё - на бэке считается нормальным говорить "НЕТ" в ответ на пожелания бизнеса (это примерно то же, что рекомендует автор статьи в контексте "делайте меньше кнопок"): "нет, это работать не будет", "нет, это слишком сложно реализовать и мы в этом утонем", "нет, это будет архитектурная дыра в безопасности", … много разных "нет". И хотя за некоторыми из них может скрываться "нет, мне лень это делать", сам факт что бэк умеет говорить "нет" имеет значение!
Уже не будут - этот рынок полностью сожрёт ИИ с вайб-кодингом. Собственно, он уже, просто большинство и заказчиков и исполнителей это пока не осознали.
А если и отправляется, то в гугл, а не майкам - а это очевидный и фатальный недостаток. :)
Второй фатальный недостаток с точки зрения майков - что штатная телеметрия opt-in, а не opt-out.
Теоретически - да. Вопрос только в том, зачем мне это нужно? Работать в таком стиле будет менее удобно, и этот, совершенно лишний, дискомфорт заказчик должен будет мне как-то компенсировать. Нам обоим должна быть очень-очень нужна эта совместная работа, чтобы мы оба на это согласились - я на дискомфорт, он на компенсацию (если деньгами, то это увеличит мою з/п в 1.5-2 раза).
Да? И где в этой схеме Вы видите компромисс со стороны работодателя?
Я пока тут вижу исключительно надуманную проблему работодателя, которую он пытается решить создав сложности как исполнителю так и себе (дополнительная работа по контролю исполнителя). Это довольно типично на фрилансе для работодателей не-IT-шников, которые привыкли контролировать персонал в магазине (условно) и абсолютно без понятия как контролировать результаты интеллектуальной деятельности фрилансера, поэтому пытаются использовать привычные методы "сиди под камерой и потей, чтобы я видел, что ты напряжённо думаешь, когда не набираешь код".
Сами фрилансеры в этом видят ровно одну проблему: нужно искать работу среди той половины работодателей, которые более адекватны, и не требуют использовать софт для мониторинга активности. К слову говоря, я уже лет 15 не смотрел что творится на рынке фриланса, но даже в то время были распространены утилиты, которые обманывали шпионский софт Upwork, двигая мышкой и листая открытый файл, делая вид что исполнитель просматривает код. Ну т.е. работодатели требующие жёсткий контроль всё-равно в ответ получали обман, только они ещё и своё время тратили на изучение отчётов об активности.
Этот подход - не работает. Единственный реальный эффект от этого шпионажа - психологический комфорт заказчика, но никак не экономия денег или защита от вранья исполнителей.