Pull to refresh

Comments 8

Простой блог можно сделать статическим сайтом, это понятно.


Но какую долю такие блоги составляют от общего числа сайтов? И что делать с остальными?

На мой взгляд SPA — очень даже золотая середина. Да, первичная загрузка не очень комфортная может быть (хотя SSR и правильная структура могут очень сильно улучшить ситуацию). В итоге при заходе пользователь получает сразу какой-то адекватный кусок HTML + CSS, а далее в фоне загружаются скрипты и оживляют сайт. Дальнейшая навигация по сайту происходит без перезагрузки страниц с подгрузкой только нужного контента по API. Вот вам и динамика сайта и комфортный вебсерфинг для клиента.
А если у вас пользователи не на один раз заходят, дайте им еще и PWA. Они тогда вообще должны быть довольны.

SPA — зло. Из-за долгой "первичной загрузки" я скорее всего закрою этот сайт и никогда больше не открою. Скрипты, загружающиеся в фоне, сбивают с толку, ведь вот она — страница, вроде бы загрузилась, а нет, комбобокс всё ещё не работает, скрипты ещё не очнулись. Дальнейшая навигация по сайту ничего не доставляет, кроме боли. Нажал "назад" — вернулся к поисковой выдаче. Нажал на "бутерброд" — ждёшь три секунды, ничего не происходит. "Может, промазал"? Жмёшь ещё раз и наблюдаешь, как за наносекунду до твоего второго нажатия менюшка всё-таки вылазит и кликаешь ты уже по ссылке. Рефлекторно жмешь назад — тебя радостно приветствует поисковая выдача. Телефон радостно приветствует стену.


Привет разработчикам мобильной версии хабра, которые не могут загружать картинки без JS.

Я во многом с вами согласен. Но не во всем. На нормальном современном проекте весь JS — это один сбилденный файл. Даже у немаленького проекта его размер как правило не превышает 3Мб (хотя и это совсем не мало, а нормально 1-2 метра). Даже 3Мб файл, если включить gzip на уровне веб-сервера, пережимается на 60-75%, то есть на выходе где-то метр. Даже на мобильном интернете этот файл загружается не считанные секунды (менее 10).
Навигация на том же react-router генерирует обычные теги <a .../>, и если даже пользователю захотелось куда-то срочно перейти, по клику он перейдет на другую страницу как и на обычном сайте. И это будет записано в историю браузера и здесь все ОК с переходами по стрелкам.
Уточню, что под SPA я сейчас имею ввиду не какой-нибудь лендинг с хэш-ссылками, а полноценный JS-сайт.
С чекбоксами вы тоже правы, распространенная ситуация. Но на том же реакте можно делать формы и обычные, которые без JS работают. Тут конечно все теряется в плане стейтов, но не мешает по клику на submit отправить данные формы классическим способом.
То есть вы говорите о распространенных ошибках, которые действительно очень часто встречаются, но я говорю о том, что при правильном подходе все они решаются, на сегодня есть все необходимые методики для решения этих проблем.
На нормальном современном проекте весь JS — это один сбилденный файл.

На нормальном-то, как раз, несколько файлов: одни для первоначального отображения, другие для доп.функций (логика попапов, например).


Даже 3Мб файл, если включить gzip на уровне веб-сервера, пережимается на 60-75%

3Мб — это очень много, и даже если у вас хорошая скорость, эти 3Мб надо обработать, попробуйте ноутбуки на бюджетных процессорах. А тут еще и загружаться 10 секунд оно будет.
Я сам пишу SPA, и большой сторонник этого подхода. Но их надо уметь правильно готовить, а это большой кусок времени, потраченного на разработку (что пока что детские болезни).

простой в использовании интерфейс Facebook

Што?!? Я в нем до сих пор до конца разобраться не могу… :-)

Markdown прост и удобен, но сделаь в нем картинку с подписью мне не удалось

Судя по этой картинке, количество HTML почти не меняется. Скриптов становится меньше — наверное, научились паковать правильно. Растёт количество картинок и видео.
Так где проблема и для чего переходить с того же PHP на статику?
Sign up to leave a comment.

Articles