Там проблема не столько в 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, двигая мышкой и листая открытый файл, делая вид что исполнитель просматривает код. Ну т.е. работодатели требующие жёсткий контроль всё-равно в ответ получали обман, только они ещё и своё время тратили на изучение отчётов об активности.
Этот подход - не работает. Единственный реальный эффект от этого шпионажа - психологический комфорт заказчика, но никак не экономия денег или защита от вранья исполнителей.
С позиции трудового - не знаю, может Вы и правы. Меня сбило с толку, что Вы всё время оперируете часами, а по трудовому обычно работают за зарплату. Я последний раз работал по трудовому в середине 90-х, так что этот вариант просто вылетел из головы. А потом я работал только как ИП, самостоятельно заключая уникальный (доработанный с учётом моих замечаний) договор с компанией.
Иногда в договоре прописана оплата в часах, иногда ежемесячная - но в любом случае я выступаю самостоятельным контрактором и могу решать поставленные задачи так, как считаю нужным. Если прописана оплата в часах, то это значит, что оплата пропорциональна выполненному объёму работы - бывали месяцы, когда я под 300 продуктивных часов нарабатывал совершенно честно, но бывали месяцы и когда было часов 50 - на одной и той же работе в одной и той же компании. Если прописана фиксированная зарплата, то я это трактую как 160 часов, которые мне нужно наработать за месяц в среднем. И да, я не вижу проблемы в том, чтобы часть работы кому-то делегировать, а потом выставить заказчику столько часов, за сколько я бы сам эту часть работы сделал.
Делал я так крайне редко и очень давно, но никакого обмана я в этом не вижу - качество я контролирую сам, заказчику эта работа стоит столько же как если бы её сделал я, а кто мне помогает в работе - ИИ, знакомый или резиновая уточка, и сколько я плачу этому своему помощнику - это моё личное дело как ИП.
Заказчик готов платить исключительно за те часы которые фактически были затрачены, а не за те которые придумали и вписали в счет.
На мой взгляд это зависит от того, что именно продаётся и покупается - время или результат. Я своё время не продаю в принципе, я продаю только результат работы (причём исключительно такой, которой я готов заниматься). Часы используются только как удобный способ оценки средней стоимости результата и примерного объёма работы, который реально выполнить за месяц. Т.е. если, например, кто-то мне предложит $100/час за то, что я ничего не буду делать, просто буду сидеть перед камерой чтобы он видел, что я ничего не делаю - я его пошлю далеко-далеко. Я лучше бесплатно опенсорс какой-нибудь попишу, чем буду так "зарабатывать". И, на мой взгляд, это единственно адекватный подход (продавать результат, а не время) в областях вроде IT, где речь об интеллектуальном труде и творчестве. А время нормально продавать если ты грузчик или охранник.
Как вы вообще софтом пользуетесь, если любой из них может за вами шпионить?
Ну, лично я тут не показатель, но раз уж Вы спросили… На телефоне у меня LineageOS, рут, XPrivacyLua (блокирует доступ приложений к камере/микрофону/контактам/геолокации/etc. даже если у них есть на это права), AFWall+ (блокирует доступ приложений в инет), AdAway, WireGuard. На компе недоверенные приложения (напр. AI-ассистенты) запускаю под firejail, ограничив их доступ к файлам каталогом с теми проектами, на которых их можно и нужно использовать, браузер с uBlock Origin, uMatrix и не только, VPN…
А для мобильных банковских/правительственных приложений, которые не захотят работать на таком рутованном телефоне под XPrivacyLua - будет использоваться отдельный телефон, где других приложений просто не будет (так что шпионить они смогут только друг за другом), и который будет 99% времени лежать выключенным дома.
Вы ведь знаете истории что Google, Microsoft, Apple много раз уличали в сборе слишком большого количества информации?
Ну, насколько я в состоянии это проверить (запрашивая дампы данных о себе), Google про меня знает только то, что я ему добровольно сообщил при использовании его сервисов. Microsoft знает только то, что я добровольно сообщил при использовании GitHub и LinkedIn. Apple не знает ничего.
В целом, конечно, это борьба с ветряными мельницами, и я это понимаю - любую защиту не так уж и сложно обойти, плюс нередко добровольно предоставленной информации более чем достаточно и шпионить необходимости нет. Тем не менее, это не повод добровольно позволять собирать о себе лишнюю информацию всяким гуглам, в частности - позволять посторонним людям в лице начальства на текущей работе подсматривать в мой экран (пока это требуется не во всех компаниях лично я буду работать в тех, которые этого не требуют).
По вашему, у Facebook не должно быть претензий к разработчику который на свою зарплату нанимает 4х индусов вместо себя и не работает? Соотношение X/Y ведь устраивает?
Всё верно, не должно быть. Это вообще-то абсолютно типичный бизнес-приём, который активно практикует множество компаний - получить контракт но не выполнять его самим а полностью или частично передать субподрядчикам, обычно не уведомляя своего заказчика о том, какие конкретно субподрядчики и почём делают его заказ. И это считается нормальным, потому что во-первых компания всё-равно сама отвечает перед своим заказчиком за результат, и во-вторых управление субподрядчиками это тоже работа и её делает именно данная компания. Или, по-вашему, "это другое", и "что дозволено Юпитеру то не дозволено быку"?
Вы не ответили на вопрос о том как лично вы собираетесь это проверять? Поставьте себя на его место, и ответьте, как лично вы собираетесь контролировать то что человек работал 2 часа, а в счете написал 8? Вы ведь понимаете что с учетом времени переплата будет существенной?
Лично я никак это никогда не проверял и не собираюсь начинать. Я сужу исключительно по количеству и качеству выданного результата в обмен на запрошенную оплату. Если меня это устраивает - я работаю дальше с этим исполнителем, если нет - больше с ним не работаю. По какой причине получился неудовлетворительный результат - исполнитель завысил часы или просто недостаточно продуктивно трудился - меня не интересует, это его личные сложности.
Если представить что все ваши разработчики врут, то ничего страшного что вы им переплачиваете, ведь X/Y устроил?
Всё верно. Ваш подход подразумевает необходимость максимизировать прибыль любой ценой. Он довольно распространён, но у него так же полно недостатков, из-за которых он не может считаться единственно верным и самым крутым из всех.
Где та грань, когда вы предьявите автосервису, что они берут деньги и не работают?
Вы сейчас считаете чужие деньги - а это общепринято считается плохим делом. Неизвестно по какой причине Вы решили, что можете диктовать сторонней компании, какая у неё должна быть норма прибыли, как много и усердно они должны работать, и в каком порядке выполнять текущие заказы.
Отвечая на вопрос, для меня эта грань проходит там, где они нарушат условия (не в мою пользу, разумеется), на которые мы договорились. Какая у них себестоимость выполнения моего заказа меня абсолютно не интересует, если меня устраивает конечная стоимость и сроки.
А задумайтесь также: почему многие сотрудники сопротивляются использованию такого ПО?
Помимо того, что часто это неконтролируемый шпионский софт, который может сливать намного больше инфы чем я ожидаю? В основном потому, что работа не физическая, а голова не может без переключений весь рабочий день думать только о рабочей задаче. А даже если и думает о работе, то это часто не выглядит так внешне - кто-то бегает по комнате разговаривая сам с собой (но на экране при этом ничего не меняется), кто-то отвлекается на хабр или мессенджер пока задача варится в голове. Не бывает такого, чтобы в процессе абсолютно честной и активной работы на экране ничего кроме IDE и документации в браузере не мелькало. Соответственно, либо шпионский софт ставится исключительно на рабочий комп, на котором ничего не относящегося к работе не устанавливается в принципе (но тогда абсолютное большинство просто поставит рядом личный ноут и половину времени будет сидеть в нём), либо через этот шпионский софт начинает утекать куча личной информации - от контактов в мессенджере и кусков личных переписок до личных документов с заметками и т.п.
Кроме того, такой шпионаж и недоверие оскорбительны сами по себе.
Тут, как везде, работает вполне стандартная схема: исполнитель даёт X продукта в месяц за Y денег - и работодателя соотношение X/Y либо устраивает, либо нет. Добавление в эту схему шпионажа, микроменеджмента и прочего сверх-контроля - ведёт исключительно к снижению X и параллельному увеличению дополнительных расходов времени менеджеров (т.е. косвенному увеличению Y). Да, в психологическом плане эти меры помогают неуверенным начальникам, но бизнес от этого только страдает - поэтому психологические проблемы намного дешевле решать с психологом, чем установкой шпионского софта.
Более того. Врёт о затраченном времени достаточно небольшой процент исполнителей. И не все из них врут в сторону раздувания часов - многие наоборот, занижают часы. И, в целом, пока соотношение X/Y приемлемое, то начальство вообще не должно волновать врут им или нет. Равно как их не волнует честно ли им сказали часы если соотношение неприемлемое - тут честного уволят ровно так же, как вруна.
Эстимировать можно абсолютно всё. Просто не всё - сразу. Чем больше разбираешься - тем яснее картина и точнее оценка. Поэтому сначала выделяется фиксированное время на оценку, получаем тот результат который можно получить за это время, и решаем что с ним делать дальше - выделить ещё время на дополнительное уточнение оценки или снять задачу или начать её делать по текущей оценке. А если уже во время работы над задачей внезапно вскрылись новые детали, которые явно делают текущую оценку нереалистичной - эту ситуацию нужно сразу эскалировать (чтобы дать начальству возможность оперативно принять решение об остановке работы) и провести переоценку задачи.
Там проблема не столько в 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, двигая мышкой и листая открытый файл, делая вид что исполнитель просматривает код. Ну т.е. работодатели требующие жёсткий контроль всё-равно в ответ получали обман, только они ещё и своё время тратили на изучение отчётов об активности.
Этот подход - не работает. Единственный реальный эффект от этого шпионажа - психологический комфорт заказчика, но никак не экономия денег или защита от вранья исполнителей.
С позиции трудового - не знаю, может Вы и правы. Меня сбило с толку, что Вы всё время оперируете часами, а по трудовому обычно работают за зарплату. Я последний раз работал по трудовому в середине 90-х, так что этот вариант просто вылетел из головы. А потом я работал только как ИП, самостоятельно заключая уникальный (доработанный с учётом моих замечаний) договор с компанией.
Иногда в договоре прописана оплата в часах, иногда ежемесячная - но в любом случае я выступаю самостоятельным контрактором и могу решать поставленные задачи так, как считаю нужным. Если прописана оплата в часах, то это значит, что оплата пропорциональна выполненному объёму работы - бывали месяцы, когда я под 300 продуктивных часов нарабатывал совершенно честно, но бывали месяцы и когда было часов 50 - на одной и той же работе в одной и той же компании. Если прописана фиксированная зарплата, то я это трактую как 160 часов, которые мне нужно наработать за месяц в среднем. И да, я не вижу проблемы в том, чтобы часть работы кому-то делегировать, а потом выставить заказчику столько часов, за сколько я бы сам эту часть работы сделал.
Делал я так крайне редко и очень давно, но никакого обмана я в этом не вижу - качество я контролирую сам, заказчику эта работа стоит столько же как если бы её сделал я, а кто мне помогает в работе - ИИ, знакомый или резиновая уточка, и сколько я плачу этому своему помощнику - это моё личное дело как ИП.
На мой взгляд это зависит от того, что именно продаётся и покупается - время или результат. Я своё время не продаю в принципе, я продаю только результат работы (причём исключительно такой, которой я готов заниматься). Часы используются только как удобный способ оценки средней стоимости результата и примерного объёма работы, который реально выполнить за месяц. Т.е. если, например, кто-то мне предложит $100/час за то, что я ничего не буду делать, просто буду сидеть перед камерой чтобы он видел, что я ничего не делаю - я его пошлю далеко-далеко. Я лучше бесплатно опенсорс какой-нибудь попишу, чем буду так "зарабатывать". И, на мой взгляд, это единственно адекватный подход (продавать результат, а не время) в областях вроде IT, где речь об интеллектуальном труде и творчестве. А время нормально продавать если ты грузчик или охранник.
Ну, лично я тут не показатель, но раз уж Вы спросили… На телефоне у меня LineageOS, рут, XPrivacyLua (блокирует доступ приложений к камере/микрофону/контактам/геолокации/etc. даже если у них есть на это права), AFWall+ (блокирует доступ приложений в инет), AdAway, WireGuard. На компе недоверенные приложения (напр. AI-ассистенты) запускаю под firejail, ограничив их доступ к файлам каталогом с теми проектами, на которых их можно и нужно использовать, браузер с uBlock Origin, uMatrix и не только, VPN…
А для мобильных банковских/правительственных приложений, которые не захотят работать на таком рутованном телефоне под XPrivacyLua - будет использоваться отдельный телефон, где других приложений просто не будет (так что шпионить они смогут только друг за другом), и который будет 99% времени лежать выключенным дома.
Ну, насколько я в состоянии это проверить (запрашивая дампы данных о себе), Google про меня знает только то, что я ему добровольно сообщил при использовании его сервисов. Microsoft знает только то, что я добровольно сообщил при использовании GitHub и LinkedIn. Apple не знает ничего.
В целом, конечно, это борьба с ветряными мельницами, и я это понимаю - любую защиту не так уж и сложно обойти, плюс нередко добровольно предоставленной информации более чем достаточно и шпионить необходимости нет. Тем не менее, это не повод добровольно позволять собирать о себе лишнюю информацию всяким гуглам, в частности - позволять посторонним людям в лице начальства на текущей работе подсматривать в мой экран (пока это требуется не во всех компаниях лично я буду работать в тех, которые этого не требуют).
От это Вы не быстрый… Кроме того, ответ не совсем верный и не очень эффективный:
команда
touchбудет выполняться не только для файлов но и каталоговпараметр
-name "*"ничего не делаетзапуск процесса это долго и дорого, намного эффективнее запускать
touchодин раз для группы файлов чем один раз на каждый файлВсё верно, не должно быть. Это вообще-то абсолютно типичный бизнес-приём, который активно практикует множество компаний - получить контракт но не выполнять его самим а полностью или частично передать субподрядчикам, обычно не уведомляя своего заказчика о том, какие конкретно субподрядчики и почём делают его заказ. И это считается нормальным, потому что во-первых компания всё-равно сама отвечает перед своим заказчиком за результат, и во-вторых управление субподрядчиками это тоже работа и её делает именно данная компания. Или, по-вашему, "это другое", и "что дозволено Юпитеру то не дозволено быку"?
Лично я никак это никогда не проверял и не собираюсь начинать. Я сужу исключительно по количеству и качеству выданного результата в обмен на запрошенную оплату. Если меня это устраивает - я работаю дальше с этим исполнителем, если нет - больше с ним не работаю. По какой причине получился неудовлетворительный результат - исполнитель завысил часы или просто недостаточно продуктивно трудился - меня не интересует, это его личные сложности.
Всё верно. Ваш подход подразумевает необходимость максимизировать прибыль любой ценой. Он довольно распространён, но у него так же полно недостатков, из-за которых он не может считаться единственно верным и самым крутым из всех.
Вы сейчас считаете чужие деньги - а это общепринято считается плохим делом. Неизвестно по какой причине Вы решили, что можете диктовать сторонней компании, какая у неё должна быть норма прибыли, как много и усердно они должны работать, и в каком порядке выполнять текущие заказы.
Отвечая на вопрос, для меня эта грань проходит там, где они нарушат условия (не в мою пользу, разумеется), на которые мы договорились. Какая у них себестоимость выполнения моего заказа меня абсолютно не интересует, если меня устраивает конечная стоимость и сроки.
Да. Для влияния на результат войны - лучше. Но не для экономики. Просто в этих условиях что там будет с экономикой временно никого не интересует.
Помимо того, что часто это неконтролируемый шпионский софт, который может сливать намного больше инфы чем я ожидаю? В основном потому, что работа не физическая, а голова не может без переключений весь рабочий день думать только о рабочей задаче. А даже если и думает о работе, то это часто не выглядит так внешне - кто-то бегает по комнате разговаривая сам с собой (но на экране при этом ничего не меняется), кто-то отвлекается на хабр или мессенджер пока задача варится в голове. Не бывает такого, чтобы в процессе абсолютно честной и активной работы на экране ничего кроме IDE и документации в браузере не мелькало. Соответственно, либо шпионский софт ставится исключительно на рабочий комп, на котором ничего не относящегося к работе не устанавливается в принципе (но тогда абсолютное большинство просто поставит рядом личный ноут и половину времени будет сидеть в нём), либо через этот шпионский софт начинает утекать куча личной информации - от контактов в мессенджере и кусков личных переписок до личных документов с заметками и т.п.
Кроме того, такой шпионаж и недоверие оскорбительны сами по себе.
Тут, как везде, работает вполне стандартная схема: исполнитель даёт X продукта в месяц за Y денег - и работодателя соотношение X/Y либо устраивает, либо нет. Добавление в эту схему шпионажа, микроменеджмента и прочего сверх-контроля - ведёт исключительно к снижению X и параллельному увеличению дополнительных расходов времени менеджеров (т.е. косвенному увеличению Y). Да, в психологическом плане эти меры помогают неуверенным начальникам, но бизнес от этого только страдает - поэтому психологические проблемы намного дешевле решать с психологом, чем установкой шпионского софта.
Более того. Врёт о затраченном времени достаточно небольшой процент исполнителей. И не все из них врут в сторону раздувания часов - многие наоборот, занижают часы. И, в целом, пока соотношение X/Y приемлемое, то начальство вообще не должно волновать врут им или нет. Равно как их не волнует честно ли им сказали часы если соотношение неприемлемое - тут честного уволят ровно так же, как вруна.
Эстимировать можно абсолютно всё. Просто не всё - сразу. Чем больше разбираешься - тем яснее картина и точнее оценка. Поэтому сначала выделяется фиксированное время на оценку, получаем тот результат который можно получить за это время, и решаем что с ним делать дальше - выделить ещё время на дополнительное уточнение оценки или снять задачу или начать её делать по текущей оценке. А если уже во время работы над задачей внезапно вскрылись новые детали, которые явно делают текущую оценку нереалистичной - эту ситуацию нужно сразу эскалировать (чтобы дать начальству возможность оперативно принять решение об остановке работы) и провести переоценку задачи.