Как стать автором
Обновить

Комментарии 11

 Разрабатывать SPA приложения намного легче, комфортней (DX), они поддерживаемей и расширяемей, их разработка дешевле и быстрей. 

Неужто написать простой html сложнее, чем поставить ноду, фреймворк и вот это всё? Интернет стал быстро расти именно потому что html прост и понятен.

Нет, но на "простом html" веб-приложение не напишешь. А все ж хотят всплывашки/кнопочки/формочки/графики/уведомления и все это без перезагрузок и в реалтайме и на нескольких устройствах и в оффлайн еще желательно.

Почему не напишешь? Ванильный ES6 вам в помощь! Для "рюшечек" nodejs и реактивные фреймворки вообще без нужды! Они только мешают - с ходу доступ к DOM не так и просто получить.

Попробуйте написать несложный чат или тот же ToDo на ванильном ES6 и на Vue 3.
Сравните размер кода, его читабельность (= поддерживаемость, расширяемость, защищенность от ошибок / error prone).
Экстраполируйте рост сложности на большое приложение типа GMail или Сводку цен на акции.

Зачем мне пробовать, если я этим постоянно занимаюсь?))

И ещё мне доставляет аргументация - "а ты попробуй операционную систему на своём ES написать"... Клоунада какая-то...

Если не нужна реактивность - зачем вообще городить этот огород тогда? Или вы не выбираете подходящий инструмент под свои задачи?

Html ES6? Ну просветите, что это такое :)

Спрашивали же про "простой html". Никакого JS.

А вообще ванильный JS конечно рулит. Но что-то сложное на нем писать задолбаешься. По сути будет либо перерендеринг всего приложения на каждый чих, либо самопальный React/Svelte/Vue/etc

Спрашивали про "ноду, фреймворк и вот это всё?". Так-то товарищ и CSS не упомянул - а без него никакой HTML не поможет.

А вы и не пишете на нём что-то сложное - этот ЯП не для этого задумывался ;)

Понятно, что js нужен. Для анимаций берём gsap, 3djs для графиков, для 3Д - three.js и так далее. Не сам ведь Реакт или Вю делают анимацию. Большинство того, что делают на популярных фрон-фреймворках - это не приложение, а обычный сайт c бесшовными переходами. Кстати, barba.js.org просто и красиво это делает.

Речь про использование какого-нить htmx.org - большинство вещей рендерится на сервере и подменяется целиком или кусочками. Просто гоняете не json а куски html.

Но согласен, какую-нить систему для Трейдинга или банковское приложение удобнее делать используя js-frontend. Но ему и индексация не нужна обычно - все закрыто авторизацией.

По теме. Буквально месяц назад стоял выбор - какую архитектуру использовать для SEO. Остановился на SSG... Как будто штаны через голову натягиваешь)) А уж SSR городить... Чур меня!

А вообще забавные кульбиты прогресс вытворяет - вот вам технология, которая может полноценно отображать весь контент без перезагрузки страницы... а, стоп! вам нужна статика для поисковых ботов? Тогда держите новую технологию, которая позволяет одностраничное приложение распарсить в виде многостраничной статики. Что, опять не так? Теперь нужна технология, которая SSR будет обратно в SPA собирать?..

И после каждой такой неоднозначной технологии начинаются холивары под лозунгом "даёшь всё новое!". Что, вы собрались манипулировать DOM во Vue-приложении? Это совершенно не так работает - уясните для себя что такое "декларативная отрисовка". Вы совершенно не понимаете методологии реактивных фреймворков!

Выходит Vue3 - Держите то, о чём вы так долго просили - ref-ссылки для манипуляции DOM...

Не понимаю, в чём сложность. Нужен сайт на JavaScript есть SSR. Он хорошо дружит с SEO (сужу по опыту компаний и по своему тоже), всё индексируется и продвигается. Не хочется постоянно запекать страницы, ну используйте ISR

Ах да, Angular Universal с ним не дружит, с ISR. Ну тогда вам придётся выбирать между Next.js или Nuxt.js (Ещё конечно можно использовать VuePress или VitePress, на них можно не только документации делать, ну и вполне себе хорошие сайты с динамическими компонентами и всё это хорошо для SEO - проверял)

Кстати, это не сарказм, это опыт, я попробовал, и у меня есть результаты. Да и не только у меня, у всех кто это пробовал тоже есть положительные результаты. Для профи там ничего сложного это всё настроить.

Если title статичный, значит там что-то с промисами начудили, или забыли убрать статические данные.

SEO оптимизация - это что-то среднее между backend и frontend, поэтому фронтенд разработчику сложно настроить семантическое ядро и учесть другие фишки и инструменты SEO. Знание OpenGraph и Schema.org - это далеко не всё. Я уже молчу про генерацию robots.txt и sitemap.xml (Столько тонкостей надо знать, это кстати легче поймёт бэкендер)

Про бэкенд я услышал только про PHP/ - так, уровень знаний мне понятен, стало очевидно, почему SSR для автора проблема. Если знать как работает контекст в динамических страницах SSR, то проблемы автоматически улетучиваются, и в настройках можно явно указать что показать, если такой страницы не будет, можно показать ошибку 404 или не отображать страницу вовсе, или будет ошибка при компиляции. Жаль что не упомянули про Rust, Java, С#, Python - на них же тоже можно сделать backend

Мне на самом деле сложно судить без Code Review
(чтобы понять почему автор не возлюбил SSR)

Два комментария с Reddit по теме:

Консультант по SEO/a11y на проводе. Не могу передать, сколько раз я сталкивался с SEO-специалистами и/или клиентами, которые клялись, что вам нужен SSR, чтобы поисковые роботы правильно индексировали ваш SPA. Это не так уже почти десять лет. Есть множество гигантских Ecommerce брендов, которые используют SPA уже много лет и имеют чрезвычайно высокие показатели SEO (на ум приходит Walmart). Анекдотично, я лично руководил конверсией сайта .NET MVC Ecommerce со 100 000+ SKU на Vue 2 SPA, и мы действительно увидели улучшение наших SEO-метрических показателей. Это было 8 лет назад.

Мы обычно исходим из следующих соображений:

  • Является ли HTML семантическим и доступным (a11y)?

  • Предоставляется ли схема через JSON+LD и/или теги?

  • Соответствуют ли основные показатели сайта (core web vitals) требованиям?

  • Требует ли контент действий пользователя перед загрузкой? Например, если навигация по категориям находится в меню, который по умолчанию скрыт, то такая навигация может не индексироваться. В общем случае, если что-то может быть сделано через SSR, то это же также может быть отображено на стороне клиента и проиндексировано.

Все это Google укажет в Search Console / Lighthouse, чтобы сообщить вам о наличии проблемы.

----

I keep reading advice about how necessary it is to use SSR for SEO, but that advice does not match my personal experience. That advice was probably valid years ago, before search engines became good at running Javascript.

From what I have seen personally, Bing is pretty good at running Javascript too.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории