Строить искусственные языковые заборы в областях, где особенно важно свободное международное сотрудничество и обмен знаниями - это выстрел в ногу. Именно поэтому, как международный медицинский язык принята Латынь, а как айтишный - английский. Документация и комментарии в коде популярных проектов - это все на английском.
Но почему-бы не окуклиться в своем уютном языковом загончике? Хорошая идея ведь! И в науке так-же. Все ради того, чтобы пастухам было удобнее управлять стадом, да? Ведь для этого исследование проводили?
Круто! Я использую подобный сетап для работы во время стоянок в мотопутешествиях. Только у меня очки Viture Pro (хочу новые Xreal 1S), вместо компа - Galaxy 25 Ultra с удаленным доступом к основному компу, и Starlink Mini для связи в дебрях. А вот с клавиатурой у меня полная беда, использую китайскую складную, которой, естественно очень далеко до вашей. Я называю всю эту движуху - Outdoor Programming.
Я бы вообще большинство задач, которые требуют браузера отправлял в puppeteer, через тот-же MCP. На мой взгляд, это гораздо более надежный способ, очень уж много глюков с расширениями и собственными тулзами агентов.
Если вы способны написать статью, которая осветит сразу все edge-кейсы - я вам очень завидую. Но боюсь, что это просто невозможно. Если у вас нет желания разбираться - значит оно вам не надо, тут я вам никак помочь не могу. Если вы опишите подробнее свою задачу и покажете пример кода на vue, куда нужно встроиться - я приведу вам пример оптимального кода на Symbiote.js (в разумных пределах). И да, я делал сложные виджеты для vue и строил очень сложные приложения полностью на Symbiote.js (редакторы, дэшборды с кучей живых данных и тд). AI-ref есть в репозитории по ссылке.
Никто ничего не мьютит, на клиенте изоморфный компонент читает декларации биндингов из HTML-атрибутов и привязывает к ним обработчики, оставляя пришедшие с сервера данные примитивных типов (например тексты, которые вы видите в UI) без изменений до первого явного обращения к ним. Прекращайте критиковать до того как сами разобрались как оно работает. Для того чтобы разобраться - все необходимые материалы я предоставил. Ваше желание - ваша проблема.
Пока я слабо понимаю, как ваши компоненты будут работать с реактивностью vue. Писать обертку?
А причем тут реактивность vue? У Симбиота своя реактивность. Шаблон симбиота - это просто HTML с атрибутами, вывод (чанк) для последующей гидрации - аналогично - просто HTML. Если этот HTML будет полностью сформирован на стороне vue - симбиот просто подцепит его при активации. Если вы создадите кусок HTML-документа через родной SSR симбиота - он, также, просто гидриуется на клиенте. Никакой обертки не нужно. Грубо говоря, в vue шаблоне могут быть кастомные теги, если они созданы с помощью Symbiote - они сами разберутся как себя вести. Посмотрите примеры и доки по ссылкам, там все довольно наглядно.
то в браузере все равно поймаем ошибку гидратации
Нет, никакой ошибки не будет. Обновление таймера (если это таймер) просто обновит значение прилетевшее с сервера, без каких-то дополнительных действий с вашей стороны. Если это просто статичное время (странный кейс для динамического обновления) - можно вызвать notify для поля стейта. Можно время вывести через client-only компонент, можно просто оставить серверное значение и ничего специально не делать. Ни в одном из этих случаев не будет никакой ошибки.
Как же вы задолбали... Это написано и отформатировано полностью вручную, я об этом даже соответствующий дисклеймер вставил. Даже картинка в шапке нарисована мной лично в Inkscape.
Я бы поспорил. На мой скромный взгляд, лучшие инженерные решения рождаются из пересечения компетенций, и в данном случае это именно фронт и бэк. Переносить какие-то паттерны и ментальные модели с фронта на бэк - не такая уж плохая идея, если вы знаете что делаете. И использование общей кодовой базы как и инструментов окружения - это ОЧЕНЬ ценный момент, чтобы от него просто отмахнуться. Помимо этого, бэк - это такая же сегментированная область, как и фронт и там и там вы можете встретить транзакции (как минимум IndexedDB) и большие данные летающие по вебсокетам в дэшбордах реального времени... как и генерацию статических ассетов на сервере, для которой не так важна максимальная оптимизация по IO. Развитие разработчика в сторону фуллстека - это никакая не ошибка, а самый правильный, на мой взгляд, путь для любого, кто хочет стать специалистом выше среднего.
Хм, вполне нормальная история, "медленная база / быстрый кэш" - это самый обычный паттерн для бэкэнда. О деталях, конечно, можно подискутировать, но в целом все рамках средних по больнице. А так - все лажают по неопытности, не вижу причин посыпать голову пеплом или считать что бэк - это совсем отдельная сфера. Вы так говорите, будто война за производительность - это исключительно прерогатива бэка, но и там и там применим тот-же самый асимптотический анализ сложности, а это основа вообще для любого разработчика.
Я лично делал эксперимент с целеполаганием ИИ, очень просто: по крону и нескольким другим триггерам запускал задачу определить цели, сделать ретроспективный анализ и запланировать следующие действия (PM-агент). Не думаю, что у человека все как-то сильно сложнее, тоже набор триггеров (часть из них очень примитивны) и суточные ритмы.
Вашим генам абсолютно пофигу на то, счастливы ли вы. Эволюционно, наше счастье - это как морковка перед носом осла - побочный эффект мотивационной механики. Именно такими нас создала эволюция. Поэтому "быть собой" - это самый тупой совет, который можно дать человеку в поиске счастья. Для счастья часто нужно ломать и перекраивать себя. Хотите морковку? Перестаньте быть ослом.
Считаю, что единственным смыслом написания подобной статьи, могло бы стать раскрытие темы асинхронных вызовов внутри циклов и методов массивов. Вот это реально было бы полезно для новичков.
Когда-то гугл называли корпорацией добра. Потом, так называли уже с сарказмом. Сейчас даже на сарказм заряда не хватает.
Превращение земного шара в один большой техно-концлагерь будет "ради нашей безопасности". Эй, охреневшие миллиардеры и политики-маразматики, оставьте нам немного опасности, плиз.
Потому, что на той стороне - живой человек. Ему приходит уведомление, он отвлекается и читает сообщение. Очевидно же.
Отключать все или просто ставить на паузу уведомления - далеко не всегда и не для всех вариант. Я, например, почти всегда онлайн на случай важных вопросов. Но только важных.
Настройками уведомлений вопрос полностью не решается, там, где есть какая-то ответственность за бесперебойную работу системы. Да, где-то существуют девопсы на дежурстве и прочие нюансы, но сообщение - это ВСЕГДА ответственность отправителя.
Оверхед - излишек, джуниор - юнец, коммит - зарука.
Строить искусственные языковые заборы в областях, где особенно важно свободное международное сотрудничество и обмен знаниями - это выстрел в ногу. Именно поэтому, как международный медицинский язык принята Латынь, а как айтишный - английский. Документация и комментарии в коде популярных проектов - это все на английском.
Но почему-бы не окуклиться в своем уютном языковом загончике? Хорошая идея ведь! И в науке так-же. Все ради того, чтобы пастухам было удобнее управлять стадом, да? Ведь для этого исследование проводили?
Круто! Я использую подобный сетап для работы во время стоянок в мотопутешествиях. Только у меня очки Viture Pro (хочу новые Xreal 1S), вместо компа - Galaxy 25 Ultra с удаленным доступом к основному компу, и Starlink Mini для связи в дебрях. А вот с клавиатурой у меня полная беда, использую китайскую складную, которой, естественно очень далеко до вашей. Я называю всю эту движуху - Outdoor Programming.
Я бы вообще большинство задач, которые требуют браузера отправлял в puppeteer, через тот-же MCP. На мой взгляд, это гораздо более надежный способ, очень уж много глюков с расширениями и собственными тулзами агентов.
Вы, всего лишь, делаете ложные утверждения. Про эмоции вы тоже все сами себе придумали.
Если вы способны написать статью, которая осветит сразу все edge-кейсы - я вам очень завидую. Но боюсь, что это просто невозможно. Если у вас нет желания разбираться - значит оно вам не надо, тут я вам никак помочь не могу. Если вы опишите подробнее свою задачу и покажете пример кода на vue, куда нужно встроиться - я приведу вам пример оптимального кода на Symbiote.js (в разумных пределах). И да, я делал сложные виджеты для vue и строил очень сложные приложения полностью на Symbiote.js (редакторы, дэшборды с кучей живых данных и тд). AI-ref есть в репозитории по ссылке.
Никто ничего не мьютит, на клиенте изоморфный компонент читает декларации биндингов из HTML-атрибутов и привязывает к ним обработчики, оставляя пришедшие с сервера данные примитивных типов (например тексты, которые вы видите в UI) без изменений до первого явного обращения к ним. Прекращайте критиковать до того как сами разобрались как оно работает. Для того чтобы разобраться - все необходимые материалы я предоставил. Ваше желание - ваша проблема.
А причем тут реактивность vue? У Симбиота своя реактивность. Шаблон симбиота - это просто HTML с атрибутами, вывод (чанк) для последующей гидрации - аналогично - просто HTML. Если этот HTML будет полностью сформирован на стороне vue - симбиот просто подцепит его при активации. Если вы создадите кусок HTML-документа через родной SSR симбиота - он, также, просто гидриуется на клиенте. Никакой обертки не нужно. Грубо говоря, в vue шаблоне могут быть кастомные теги, если они созданы с помощью Symbiote - они сами разберутся как себя вести. Посмотрите примеры и доки по ссылкам, там все довольно наглядно.
Нет, никакой ошибки не будет. Обновление таймера (если это таймер) просто обновит значение прилетевшее с сервера, без каких-то дополнительных действий с вашей стороны. Если это просто статичное время (странный кейс для динамического обновления) - можно вызвать notify для поля стейта. Можно время вывести через client-only компонент, можно просто оставить серверное значение и ничего специально не делать. Ни в одном из этих случаев не будет никакой ошибки.
Не уверен, что понял вас. Вы хотите пример Symbiote-компонента внутри Vue приложения?
Я и сам знаю как он "палится" - никак. Лечите свою нейро-паранойю.
Как же вы задолбали... Это написано и отформатировано полностью вручную, я об этом даже соответствующий дисклеймер вставил. Даже картинка в шапке нарисована мной лично в Inkscape.
Один раз видел такую на парковке в Москве. Подошел поближе посмотреть - а там все как-то не очень...
...лучше бы пил и курил...
Я бы поспорил. На мой скромный взгляд, лучшие инженерные решения рождаются из пересечения компетенций, и в данном случае это именно фронт и бэк. Переносить какие-то паттерны и ментальные модели с фронта на бэк - не такая уж плохая идея, если вы знаете что делаете. И использование общей кодовой базы как и инструментов окружения - это ОЧЕНЬ ценный момент, чтобы от него просто отмахнуться. Помимо этого, бэк - это такая же сегментированная область, как и фронт и там и там вы можете встретить транзакции (как минимум IndexedDB) и большие данные летающие по вебсокетам в дэшбордах реального времени... как и генерацию статических ассетов на сервере, для которой не так важна максимальная оптимизация по IO. Развитие разработчика в сторону фуллстека - это никакая не ошибка, а самый правильный, на мой взгляд, путь для любого, кто хочет стать специалистом выше среднего.
Хм, вполне нормальная история, "медленная база / быстрый кэш" - это самый обычный паттерн для бэкэнда. О деталях, конечно, можно подискутировать, но в целом все рамках средних по больнице. А так - все лажают по неопытности, не вижу причин посыпать голову пеплом или считать что бэк - это совсем отдельная сфера. Вы так говорите, будто война за производительность - это исключительно прерогатива бэка, но и там и там применим тот-же самый асимптотический анализ сложности, а это основа вообще для любого разработчика.
Я лично делал эксперимент с целеполаганием ИИ, очень просто: по крону и нескольким другим триггерам запускал задачу определить цели, сделать ретроспективный анализ и запланировать следующие действия (PM-агент). Не думаю, что у человека все как-то сильно сложнее, тоже набор триггеров (часть из них очень примитивны) и суточные ритмы.
Вашим генам абсолютно пофигу на то, счастливы ли вы. Эволюционно, наше счастье - это как морковка перед носом осла - побочный эффект мотивационной механики. Именно такими нас создала эволюция. Поэтому "быть собой" - это самый тупой совет, который можно дать человеку в поиске счастья. Для счастья часто нужно ломать и перекраивать себя. Хотите морковку? Перестаньте быть ослом.
Это я сократил простыню.
Считаю, что единственным смыслом написания подобной статьи, могло бы стать раскрытие темы асинхронных вызовов внутри циклов и методов массивов. Вот это реально было бы полезно для новичков.
Когда-то гугл называли корпорацией добра. Потом, так называли уже с сарказмом. Сейчас даже на сарказм заряда не хватает.
Превращение земного шара в один большой техно-концлагерь будет "ради нашей безопасности". Эй, охреневшие миллиардеры и политики-маразматики, оставьте нам немного опасности, плиз.
Потому, что на той стороне - живой человек. Ему приходит уведомление, он отвлекается и читает сообщение. Очевидно же.
Отключать все или просто ставить на паузу уведомления - далеко не всегда и не для всех вариант. Я, например, почти всегда онлайн на случай важных вопросов. Но только важных.
Настройками уведомлений вопрос полностью не решается, там, где есть какая-то ответственность за бесперебойную работу системы. Да, где-то существуют девопсы на дежурстве и прочие нюансы, но сообщение - это ВСЕГДА ответственность отправителя.