Я не хочу изобретать велосипед, но должен признать тот факт, что некоторые из самых основных вещей не известны разработчикам. Я чувствую, что требуется небольшое резюме.

1)
не делайте:
document.createElement ('div')
вместо этого:
‹ div ›
Каким бы ни был контент, он должен быть подготовлен на стороне сервера.
Я понимаю, что создание div« всего »занимает 0,01 миллисекунды, но
- это необходимо разработать, так что кому-то где-то придется написать document.createElement ('div'). Даже если вы используете красивый фреймворк! Разработка
дорогостоящая - это займет где-то место
- этот код создателя должен быть загружен браузером на клиентскую машину
- этот код создателя должен выполняться миллион раз когда на веб-странице миллион посещений

2)
не делать:
‹link rel =” stylesheet ”href =”… ”›
‹link rel =” stylesheet ”href =”… ”›
‹link rel =” stylesheet ”href =”… ”›
‹link rel =” stylesheet ”href =”… ”›
‹link rel =” stylesheet ”href =” … ”›
‹script src =”… ”› ‹/script›
‹script src =”… ”› ‹/script›
‹script src =”… ”› ‹/ script ›
‹ script src = ”…” ›‹/script›
‹ script src = ”…” ›‹/script›
‹ script src = ”…” ›‹/script› < br />…
do:
‹script src =”… ”› ‹/script›
‹link rel =” stylesheet ”href =”… ”›
Отличная идея - разбить функциональные части страницы на крошечные модули и использовать для них кеширование браузера. Но на самом деле все это просто заглушает сеть и заставляет запросы блокировать друг друга.

3)
не делать:
json = {en: {key1: ”value1 ', key2:” value2'}, ”de”: {key1: ”othervalue1 ', key2: ”othervalue2'}}
do:
‹p› значение1 ‹/p›
‹p› значение2 ‹/p›
Разработчики Javascript могут посчитать следующую строку немного болезненной для чтения, но мы должны признать:
Люди приходят на веб-сайт не для того, чтобы менять язык каждую минуту, а для того, чтобы потреблять контент. Таким образом, нет необходимости делегировать управление языком клиентской стороне. Конечно, здесь действует и первый пункт.

4)
не делайте:
‹body› ‹div id =” app ”› ‹/div› ‹/body›
делайте:
‹body› ‹div› СОДЕРЖАНИЕ ‹/div› ‹/body›
Сначала поймите, почему: браузер изначально отправляет запрос GET на сервер. Если запрос будет успешным, он ответит исходным кодом html. Это нужно интерпретировать. Добавьте несколько дополнительных запросов на дополнительные ресурсы, такие как файлы javascript, таблицы стилей или изображения, на основе внешних ссылок внутри него. После их загрузки (больше времени) они должны быть обработаны (больше времени), интерпретированы (больше времени), выполнены (больше времени) и повторно отрисованы страницы (больше времени). Если вы используете другой домен (например, cdn), вам, возможно, придется пройти еще несколько раундов, выполнив дополнительные SSL-рукопожатия и т. Д.
В чем смысл рендеринга, а затем изменения html, когда это можно сделать в один раз, подготовив все это на стороне сервера и отрендерив за один раз?

Динамические веб-страницы

Они действительно такие динамичные? Хорошо, чат похож на это, но давайте посмотрим на отображение текущего имени / свободного места / обменного курса / и т.д. нужно было изменить? Давайте еще раз посмотрим, что нужно пользователям. Никто не хочет запускать дополнительные программы только для того, чтобы разработчики чувствовали себя лучше. Люди хотят, чтобы контент читался, а не запускались программы. Не забывай этого!

Мы живем в 21 веке, а интернет по-прежнему медленный ?! Сегодня у нас есть машины с невероятной скоростью, сети с такой скоростью, о которой мы даже не мечтали. Серверы обслуживают контент с такой скоростью, которая была доступна только для военных несколько лет назад.
Причина медленного интернета в том, что мы делаем ненужные вещи. Создание или размещение html-контента с помощью css или javascript. Запуск большого количества JavaScript. Я не шучу над следующим: у меня никогда не было таких быстрых ноутбуков, как тот, который у меня есть сейчас, но когда дело доходит до просмотра веб-страниц, у него проблемы. Он не борется из-за пропускной способности, но он борется, потому что ему приходится снова и снова отображать страницу с помощью javascript. У него проблемы, потому что контент не вычисляется только один раз на стороне сервера (на другой масштабируемой машине), а потому, что он должен снова вычисляться моим ноутбуком (который не масштабируется). И это не только мой компьютер, но и все остальные. Твое тоже.

Заключение?

Я работаю разработчиком javascript более 12 лет и убежден, что javascript - это хорошо. Но в последнее время дело идет в плохом направлении. Почему-то соображения разработчика стали важнее, чем то, что хорошо для конечных пользователей. Например, скорость оборудования или скорость первой загрузки и скорость первого значимого контента. Помните, зачем мы создаем сайты. Для людей. Они не хотят запускать программы. Они хотят быстро потреблять контент.