Вы сами читали таблицу сравнения, которую приложили? Там же по всем пунктам, практически, проигрыш. Или для вас это все преимущества?
В текстовой части комментария я также не вижу особых преимуществ. JSDA-Kit еще легче засунуть в Tauri, нет никаких проблем ни с темами, ни с адаптивностью, ни с локализациями ни с бесплатным хостингом (об этом даже прямо написано в README).
Гипер-базы - нет, но не уверен что это решение уровня common purpose, скорее какая-то очень частная история. Мы юзаем обычный PostgreSQL и Indexed DB на клиенте, если нужно. Адаптер с поддержкой промисов - входит в состав пакета.
Спасибо за приглашение, но я ведь объяснил, почему выбрал стратегию "ПОСЛЕ". Не вижу смысла делать иной выбор. Почему? Я подробно объяснил тут: https://habr.com/ru/articles/1008822/ (см слабосвязанная архитектура)
Помимо этого, вы предлагаете мне бросить проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500? Масштабы несопоставимы.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js. Думаю картина особо не изменится.
Ну и, заходя на сайт $mol, первое, что я увидел - это русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта. + куча других странных моментов, от просто неаккуратностей до явных ошибок.
Вы пытаетесь переизобрести платформу, но мне такой подход не близок. Я - опираюсь на стандарты и все то, что хорошо задокументировано на MDN.
Если вы способны написать статью, которая осветит сразу все 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-агент). Не думаю, что у человека все как-то сильно сложнее, тоже набор триггеров (часть из них очень примитивны) и суточные ритмы.
Вашим генам абсолютно пофигу на то, счастливы ли вы. Эволюционно, наше счастье - это как морковка перед носом осла - побочный эффект мотивационной механики. Именно такими нас создала эволюция. Поэтому "быть собой" - это самый тупой совет, который можно дать человеку в поиске счастья. Для счастья часто нужно ломать и перекраивать себя. Хотите морковку? Перестаньте быть ослом.
Считаю, что единственным смыслом написания подобной статьи, могло бы стать раскрытие темы асинхронных вызовов внутри циклов и методов массивов. Вот это реально было бы полезно для новичков.
Когда-то гугл называли корпорацией добра. Потом, так называли уже с сарказмом. Сейчас даже на сарказм заряда не хватает.
Превращение земного шара в один большой техно-концлагерь будет "ради нашей безопасности". Эй, охреневшие миллиардеры и политики-маразматики, оставьте нам немного опасности, плиз.
Потому, что на той стороне - живой человек. Ему приходит уведомление, он отвлекается и читает сообщение. Очевидно же.
Отключать все или просто ставить на паузу уведомления - далеко не всегда и не для всех вариант. Я, например, почти всегда онлайн на случай важных вопросов. Но только важных.
Настройками уведомлений вопрос полностью не решается, там, где есть какая-то ответственность за бесперебойную работу системы. Да, где-то существуют девопсы на дежурстве и прочие нюансы, но сообщение - это ВСЕГДА ответственность отправителя.
Вы сами читали таблицу сравнения, которую приложили? Там же по всем пунктам, практически, проигрыш. Или для вас это все преимущества?
В текстовой части комментария я также не вижу особых преимуществ. JSDA-Kit еще легче засунуть в Tauri, нет никаких проблем ни с темами, ни с адаптивностью, ни с локализациями ни с бесплатным хостингом (об этом даже прямо написано в README).
Гипер-базы - нет, но не уверен что это решение уровня common purpose, скорее какая-то очень частная история. Мы юзаем обычный PostgreSQL и Indexed DB на клиенте, если нужно. Адаптер с поддержкой промисов - входит в состав пакета.
Это вы так пошутили, да?
Почитайте про стандарт Custom Elements
Спасибо за приглашение, но я ведь объяснил, почему выбрал стратегию "ПОСЛЕ". Не вижу смысла делать иной выбор. Почему? Я подробно объяснил тут: https://habr.com/ru/articles/1008822/ (см слабосвязанная архитектура)
Помимо этого, вы предлагаете мне бросить проект с +/- 60 000 еженедельных загрузок, ради чего-то с 1 500? Масштабы несопоставимы.
Кроме того, у нас есть такая экосистемная штука: https://github.com/rnd-pro/jsda-kit. Можно подставить $mol в таблицу сравнения вместо Next.js. Думаю картина особо не изменится.
Ну и, заходя на сайт $mol, первое, что я увидел - это русские тексты при включенном английском в интерфейсе. Это многое говорит о уровне проекта. + куча других странных моментов, от просто неаккуратностей до явных ошибок.
Вы пытаетесь переизобрести платформу, но мне такой подход не близок. Я - опираюсь на стандарты и все то, что хорошо задокументировано на MDN.
Вы, всего лишь, делаете ложные утверждения. Про эмоции вы тоже все сами себе придумали.
Спасибо, с вами приятно поговорить.
Если вы способны написать статью, которая осветит сразу все 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-агент). Не думаю, что у человека все как-то сильно сложнее, тоже набор триггеров (часть из них очень примитивны) и суточные ритмы.
Вашим генам абсолютно пофигу на то, счастливы ли вы. Эволюционно, наше счастье - это как морковка перед носом осла - побочный эффект мотивационной механики. Именно такими нас создала эволюция. Поэтому "быть собой" - это самый тупой совет, который можно дать человеку в поиске счастья. Для счастья часто нужно ломать и перекраивать себя. Хотите морковку? Перестаньте быть ослом.
Это я сократил простыню.
Считаю, что единственным смыслом написания подобной статьи, могло бы стать раскрытие темы асинхронных вызовов внутри циклов и методов массивов. Вот это реально было бы полезно для новичков.
Когда-то гугл называли корпорацией добра. Потом, так называли уже с сарказмом. Сейчас даже на сарказм заряда не хватает.
Превращение земного шара в один большой техно-концлагерь будет "ради нашей безопасности". Эй, охреневшие миллиардеры и политики-маразматики, оставьте нам немного опасности, плиз.
Потому, что на той стороне - живой человек. Ему приходит уведомление, он отвлекается и читает сообщение. Очевидно же.
Отключать все или просто ставить на паузу уведомления - далеко не всегда и не для всех вариант. Я, например, почти всегда онлайн на случай важных вопросов. Но только важных.
Настройками уведомлений вопрос полностью не решается, там, где есть какая-то ответственность за бесперебойную работу системы. Да, где-то существуют девопсы на дежурстве и прочие нюансы, но сообщение - это ВСЕГДА ответственность отправителя.