Когда у вас на странице есть тяжелые компоненты (например, интерактивные графики или карты), их рендеринг на сервере может существенно замедлить ответ.
Такие вещи вообще не работают на сервере, о чем вообще речь?
И еще: есть более лаконичный вариант заставить работать компонент только на клиенте: *.client.vue
По поводу удаленного стримминга не понятно: у меня зашарена библиотека с женой. Мне, как «владельцу» сервера, стримминг остается бесплатным вне домашней сети если я правильно интерпретировал новость. А что с другими аккаунтами (в т.ч. семейные, которые доступны к выбору при включении приложения)?
Пусть и являюсь владельцем пожизненной подписки к плексу уже 5+ лет, нововведения не выглядят чем-то хорошим в перспективе. Главная фишка плекса — шеринг с другими пользователями — прячется под пейволом.
Накст несет с собой, помимо удобных модулей, еще и собственные болячки, которые не исправляются достаточно долгое время (потеря реактивности useRoute() как пример). А разработчики еще и распыляются на попытку создания fullstack-фреймворка, из-за чего, собственно, баги такие «долгоиграющие»
Предпочтительней все-таки использовать чистый Vue на проекты, где SSR вообще не должен появляться.
Тут очень просто понять, в каких случаях можно "причесывать", а в каких -- нельзя: просто представить к чему приведет классический форс-пуш в ветку, в которую "прихорашиваем".
В конце концов, все эти "причесывания" делаются сквошем на этапе мержа в целевую ветку. Не серебряная пуля, но взвешенный средний вариант
Как минимум потому, что в средних и крупных командах в разные периоды времени разработчики "отпочковываются" от мастера и пилят таску в своей ветке. Если начать шатать мастер -- MR с обычными конфликтами слияния покажутся детским лепетом.
Так или иначе, все равно решает удобство: кому-то подавай красивый гуй, кому-то просто автозапуск движка. MacOS не является средой для массового запуска «кровавого ентерпрайза». Особенно в широтах восточной Европы. Тут скорее вопрос DX
Замер скорости запуска софта на маке вообще вызывает улыбку.
А можно подробнее про AGPL? Есть просто непонимание как она в действительности работает если используется ПО "as is" (развернут инстанс).
Например: есть объектное хранилище minio. Оно распространяется по лицензиям AGPL и коммерческой. Согласно написаного на их сайте, если инстанс является составной частью продукта (возьмем, например, самописный блог: фото и видео с его мы зачем-то будем хранить в minio) и не используется коммерческая лицензия -- весь продукт должен быть опубликован под лицензией AGPL. Я правильно трактовал их требования, или нет?
Такие вещи вообще не работают на сервере, о чем вообще речь?
И еще: есть более лаконичный вариант заставить работать компонент только на клиенте: *.client.vue
Не вижу в этом ничего плохого, преобщается к прекрасному :)
Но вот называние композабла хуком — напрягло.
По поводу удаленного стримминга не понятно: у меня зашарена библиотека с женой. Мне, как «владельцу» сервера, стримминг остается бесплатным вне домашней сети если я правильно интерпретировал новость. А что с другими аккаунтами (в т.ч. семейные, которые доступны к выбору при включении приложения)?
Пусть и являюсь владельцем пожизненной подписки к плексу уже 5+ лет, нововведения не выглядят чем-то хорошим в перспективе. Главная фишка плекса — шеринг с другими пользователями — прячется под пейволом.
Накст несет с собой, помимо удобных модулей, еще и собственные болячки, которые не исправляются достаточно долгое время (потеря реактивности useRoute() как пример). А разработчики еще и распыляются на попытку создания fullstack-фреймворка, из-за чего, собственно, баги такие «долгоиграющие»
Предпочтительней все-таки использовать чистый Vue на проекты, где SSR вообще не должен появляться.
Тут очень просто понять, в каких случаях можно "причесывать", а в каких -- нельзя: просто представить к чему приведет классический форс-пуш в ветку, в которую "прихорашиваем".
В конце концов, все эти "причесывания" делаются сквошем на этапе мержа в целевую ветку. Не серебряная пуля, но взвешенный средний вариант
Как минимум потому, что в средних и крупных командах в разные периоды времени разработчики "отпочковываются" от мастера и пилят таску в своей ветке. Если начать шатать мастер -- MR с обычными конфликтами слияния покажутся детским лепетом.
При чем тут вообще JSON во всех приведенных проблемах? Давайте разберем заключение:
1-2 -- JSON вообще не при чем. В XML будут те-же проблемы. Да даже со стрингой.
3 -- проблемы большого объема данных, актуально для любого формата.
4 -- максимально капитанское объяснение, которое, опять таки, не проблема конкретно JSONа как формата данных. Не сжимает данные нынче только ленивый
5 -- альтернативы есть. Ну хорошо.
Подведя собственное "заключение" :а
был липри чем тут JSON?Там есть дурацкая настройка автоматического уровня звука, ее стоит выключить (тоже столкнулся, но с беспроводной гарнитурой)
Так или иначе, все равно решает удобство: кому-то подавай красивый гуй, кому-то просто автозапуск движка. MacOS не является средой для массового запуска «кровавого ентерпрайза». Особенно в широтах восточной Европы. Тут скорее вопрос DX
Замер скорости запуска софта на маке вообще вызывает улыбку.
GitHub Actions, к примеру, не работают с IPv6 (self-hosted воркеры). И это технологическая компания. А тут в масштабах страны нужно внедрить.
КМК, пока будет хватать портов для NATа на серых адресах — так и будем ползуче двигаться. Лишь на инициативе провайдеров
А можно подробнее про AGPL? Есть просто непонимание как она в действительности работает если используется ПО "as is" (развернут инстанс).
Например: есть объектное хранилище minio. Оно распространяется по лицензиям AGPL и коммерческой. Согласно написаного на их сайте, если инстанс является составной частью продукта (возьмем, например, самописный блог: фото и видео с его мы зачем-то будем хранить в minio) и не используется коммерческая лицензия -- весь продукт должен быть опубликован под лицензией AGPL. Я правильно трактовал их требования, или нет?