Где лучше рендерить? На клиенте или на сервере?
#подборка #ssr #vue
Простого ответа на этот вопрос нет, потому что нужно рассматривать каждую частную ситуацию отдельно. У меня был опыт настройки пререндера для поисковиков, чтобы повысить позиции сайта в поисковиках и улучшить SEO. Это не всегда работает так хорошо, как хотелось бы, потому что довольно часто, если у вас небольшой проект — нет достаточного количества данных, по которым можно было бы определить нужен ли SSR и где конкретно.
Чтобы лучше самому разобраться в теме, я прочитал несколько статей и сделал небольшую подборку по теме:
- Как мы ускоряли комментарии Хабра (https://habr.com/ru/company/habr/blog/590111/)
- SSR: когда, зачем и для чего. На примере Vue (https://habr.com/ru/company/umbrellaitcom/blog/425053/)
- Серверный или клиентский рендеринг на вебе: что лучше использовать у себя в проекте и почему (https://tproger.ru/translations/rendering-on-the-web/)
- Руководство по серверному рендерингу Vue.js (https://ssr.vuejs.org/ru/)
#подборка #ssr #vue
Простого ответа на этот вопрос нет, потому что нужно рассматривать каждую частную ситуацию отдельно. У меня был опыт настройки пререндера для поисковиков, чтобы повысить позиции сайта в поисковиках и улучшить SEO. Это не всегда работает так хорошо, как хотелось бы, потому что довольно часто, если у вас небольшой проект — нет достаточного количества данных, по которым можно было бы определить нужен ли SSR и где конкретно.
Чтобы лучше самому разобраться в теме, я прочитал несколько статей и сделал небольшую подборку по теме:
- Как мы ускоряли комментарии Хабра (https://habr.com/ru/company/habr/blog/590111/)
- SSR: когда, зачем и для чего. На примере Vue (https://habr.com/ru/company/umbrellaitcom/blog/425053/)
- Серверный или клиентский рендеринг на вебе: что лучше использовать у себя в проекте и почему (https://tproger.ru/translations/rendering-on-the-web/)
- Руководство по серверному рендерингу Vue.js (https://ssr.vuejs.org/ru/)
👍5
📱 Кроссплатформенная разработка. Всё плохо?
#vue #nativescript #mobile
Последние несколько месяцев мне довелось довольно тесно познакомиться с NativeScript (писал я, конечно, на Vue).
Впечатления остались смешанными. Честно признаюсь, что кроме NativeScript удалось раньше попробовать только React Native и не сказать, что мне было приятно. Слышал и интересовался Flutter, но руки так до него и не дошли. Если вдруг у вас есть опыт разработки на Flutter / React Native / NativeScript / etc. — поделитесь в комментариях, будет интересно почитать.
Сразу скажу, что моё мнение довольно субъективно, поскольку я вообще не мобильный разработчик и мои знания не уходят дальше приложения для просмотра погоды на Kotlin с корутинами и кешированием. На swift я немножко писал, но поскольку макбука у меня раньше не было — полноценным этот опыт тоже назвать нельзя.
Я считаю, что любая попытка сделать кроссплатформенное мобильное приложение на нынешних технологиях — это выстрел себе в ногу, поскольку всё равно приходится учитывать особенности платформы в некоторых случаях и писать платформоспецифичный код, что естественным образом увеличивает сроки разработки. Кто знает — возможно быстрее было бы написать нативное приложение?
Но я как фанат Vue решил, что хочу попробовать NativeScript и каково было моё разочарование, когда я начал в это погружаться, увидев насколько из рук вон плохо там работает CSS, а невозможность использования ряда привычных JS-библиотек меня вконец добила. С другой стороны — это интересный челлендж, который заставляет мозги, привыкшие к ламповому JS-зоопарку, шевелиться и пытаться найти решения в условиях жёстких ограничений. Как никогда ранее, я ощутил насколько творческим может быть программирование, если тебя оторвали от того, что есть в современных браузерах.
Да, это нелегко. И да, это заставляет думать и гуглить. А отсутствие большого количества информации по не самому популярному решению и вовсе приводит к тому, что приходится залезать во внутренности инструмента и изучать их вдоль и поперёк, чтобы найти ответы на интересующие вопросы.
Я бы точно не советовал новичкам NativeScript, да и кросстплатформу, в целом. Это очень нелегко, а когда у вас нет достаточного опыта, но есть желание «войти в IT» — это может напрочь погасить всю вашу мотивацию. Когда хотя бы годика два побарахтаетесь в JS-зоопарке и будете готовы читать исходники инструментов, потому что документация не очень подробная — тогда и можете лезть в NativeScript.
Но если хотите от меня какие-нибудь обучающие материалы по этому поводу — голосуйте в опросе ниже, возможно, я соберусь и слеплю для вас несколько простых примерчиков.
#vue #nativescript #mobile
Последние несколько месяцев мне довелось довольно тесно познакомиться с NativeScript (писал я, конечно, на Vue).
Впечатления остались смешанными. Честно признаюсь, что кроме NativeScript удалось раньше попробовать только React Native и не сказать, что мне было приятно. Слышал и интересовался Flutter, но руки так до него и не дошли. Если вдруг у вас есть опыт разработки на Flutter / React Native / NativeScript / etc. — поделитесь в комментариях, будет интересно почитать.
Сразу скажу, что моё мнение довольно субъективно, поскольку я вообще не мобильный разработчик и мои знания не уходят дальше приложения для просмотра погоды на Kotlin с корутинами и кешированием. На swift я немножко писал, но поскольку макбука у меня раньше не было — полноценным этот опыт тоже назвать нельзя.
Я считаю, что любая попытка сделать кроссплатформенное мобильное приложение на нынешних технологиях — это выстрел себе в ногу, поскольку всё равно приходится учитывать особенности платформы в некоторых случаях и писать платформоспецифичный код, что естественным образом увеличивает сроки разработки. Кто знает — возможно быстрее было бы написать нативное приложение?
Но я как фанат Vue решил, что хочу попробовать NativeScript и каково было моё разочарование, когда я начал в это погружаться, увидев насколько из рук вон плохо там работает CSS, а невозможность использования ряда привычных JS-библиотек меня вконец добила. С другой стороны — это интересный челлендж, который заставляет мозги, привыкшие к ламповому JS-зоопарку, шевелиться и пытаться найти решения в условиях жёстких ограничений. Как никогда ранее, я ощутил насколько творческим может быть программирование, если тебя оторвали от того, что есть в современных браузерах.
Да, это нелегко. И да, это заставляет думать и гуглить. А отсутствие большого количества информации по не самому популярному решению и вовсе приводит к тому, что приходится залезать во внутренности инструмента и изучать их вдоль и поперёк, чтобы найти ответы на интересующие вопросы.
Я бы точно не советовал новичкам NativeScript, да и кросстплатформу, в целом. Это очень нелегко, а когда у вас нет достаточного опыта, но есть желание «войти в IT» — это может напрочь погасить всю вашу мотивацию. Когда хотя бы годика два побарахтаетесь в JS-зоопарке и будете готовы читать исходники инструментов, потому что документация не очень подробная — тогда и можете лезть в NativeScript.
Но если хотите от меня какие-нибудь обучающие материалы по этому поводу — голосуйте в опросе ниже, возможно, я соберусь и слеплю для вас несколько простых примерчиков.
👍2🤔2🌚2
#vue #vuetify #фронтенд
Недавно сдувал пыль с некогда моего любимого UI-фреймворка и обнаружил, что Vuetify так и не смогли до конца перевести на Vue3, который вышел аж в 2020м году. И, как оказалось, заметил это не я один... Принёс вам статейку, в которой разбирается вся история некогда одного из наиболее успешных UI-фреймворков для Vue.
От себя же добавлю, что честно говоря, не особо люблю Material UI. Объяснить внятно почему — вряд ли смогу, мне по душе стандартные бутстраповские компоненты, которыми я пользуюсь уже больше пяти лет. Наверное, в этом году постараюсь вылезти куда-то, в сторону того же тейлвинда, хотя меня и довольно сильно отталкивает то, как выглядят в нём CSS-классы. Но есть такое внутреннее ощущение, что я что-то упускаю, ограничиваясь на постоянной основе одним только бутстрапом.
А вы что используете? Пользовались ли Vuetify? Если да, то смогли ли найти ему замену?
📖 Источник:
Взлет и падение Vuetify. Некролог — https://habr.com/ru/post/709492/
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Взлет и падение Vuetify. Некролог
Привет, Хабр! Этот день настал. Не переживайте за белую тему, это я для статьи Джон Лейдер - основатель и в свое время единственный разработчик Vuetify. Прежде, чем идти дальше, давайте вспомним или...
👍5🤔2
#vue #frontend
Несколько месяцев назад, в подборке от reddit мне попался довольно странный вопрос в сабреддите vue.js: "Почему я должен использовать Pinia вместо глобальных реактивных переменных?".
Странным он показался мне, в первую очередь, из-за того, что я никогда об этом всерьёз не задумывался и выбирал использовать какой-либо стейт-менеджер, вместо переменных, потому что так заведено. Как будто, это тема, в которой и так всё ясно, дополнительных исследований не требуется: хочешь реактивность и надёжность — бери стейт-менеджер, он это предоставляет.
В тексте своего сообщения автор опирается на раздел документации Vue, в котором рассказывается о том, как управление состоянием устроено в компонентах. По мнению пользователя reddit, у использования глобальных реактивных переменных есть такие плюсы, как:
1) простота;
2) нативная поддержка фреймворка;
3) нет зависимостей, что означает, не появится ситуации, как с Vuex (который прекратили развивать), в которой придётся переписывать половину кодовой базы;
4) Composition API выглядит более зрело и стабильно и вряд ли изменится в ближайшем будущем (в сравнении с переходом с Vue 2 на Vue 3);
5) возможность использования всей мощи реактивных API, вместо урезанной реактивной обёртки Pinia;
6) разница в эффективности при миллионе операций записи довольна внушительна:
Ref time: 36ms
Pinia ref time: 628ms
Reactive time: 501ms
Pinia reactive time: 809ms
В комментариях в качестве основных плюсов использования Pinia вместо глобальных реактивных переменных, приводили аргументы только про возможность использования SSR и DevTools.
Эта дискуссия действительно заставила меня задуматься, в следующем своём проекте на Vue, хочу попытаться применить подобную концепцию на практике.
P. S.
Оказалось, автор является частью русскоязычного сообщества @vuejs_ru и поддерживает и развивает ресурс Vue FAQ. Я бегло по нему прошёлся и не могу не выразить искреннее восхищение проделанной работой. Прошу обратить своё внимание на этот ресурс, в нём собрано довольно много информации по фреймворку.
Please open Telegram to view this post
VIEW IN TELEGRAM
Reddit
From the vuejs community on Reddit
Explore this post and more from the vuejs community
👍7👏3
#frontend #vue #производительность
На reddit наткнулся на пост в комьюнити Vue.JS с описанием проблемы с производительностью у вычисляемых свойств (
computed). Заключается проблема в том, что судя по тестам использованием watch + ref на 50% более эффективно, чем использованием computed.Добавим немного контекста. Тест проводился на дропдауне с 1 000 000 элементов. Задача теста состояла в том, чтобы написать функцию, которая будет конвертировать объекты (или строки) с типом
selectOption в объект selectOptionsObject.Типы выглядят так:
export type selectOption = selectOptionObject | string;
export type selectOptionObject = {
id: string | number;
render: string;
raw?: any;
};
Код функции
normaliseOptions для конвертации:const normaliseOptions = (
options?: selectOption[]
): normalisedOptionObject[] => {
if (!options) return [];
// We will use a straight for loop for performance
const normalisedOptions = [];
for (let i = 0; i < options.length; i++) {
const option = options[i];
if (typeof option === "string") {
normalisedOptions.push({
id: option,
render: option,
});
continue;
}
normalisedOptions.push({
id: option.id.toString(),
render: option.render,
disabled: option.disabled || false,
raw: option.raw,
});
}
return normalisedOptions;
};
Код, который использовался в тесте:
1) С использованием computed:
const normalisedOptions = computed(() => {
return normaliseOptions(props.options);
});2) С использованием watch + ref:
// Using the pattern below rather than a computed value gives us a 2x performance improvement
const normalisedOptions = ref(normaliseOptions(props.options));
const recomputeOptions = () => {
normalisedOptions.value = normaliseOptions(props.options);
};
watch(
() => props.options,
() => {
recomputeOptions();
}
);
Самые умные и опытные уже догадались, в чём может заключаться проблема конкретно в данном случае (а я не успел самостоятельно подумать и наткнулся на ответ в комментариях). Проблема заключается в том, что
computed отслеживает каждую вложенную зависимость. Поэтому он будет работать медленнее, если props.options не является плоской структурой, состоящей из примитивов, потому что требуется провести кратно больше вычислений. Таким образом, корректный код для данного случая выглядит так:const recomputedOptions = computed(() => normaliseOptions(toRaw(props.options)));
Метод
toRaw извлекает необработанный объект из proxy-объекта, созданного Vue, давая нам возможность поработать с оригинальным объектом. Подробнее про него можно почитать в документации.Please open Telegram to view this post
VIEW IN TELEGRAM
Reddit
From the vuejs community on Reddit
Explore this post and more from the vuejs community
👍8🤔1