Рендер страницы в JavaScript

Вместо var теперь рекомендуется использовать let для переопределяемых значений и const для привязанных навсегда.

Константу const a=5 или const b={amount:3} нельзя позже переопределить на новое значение a=6 или b={amount:7}. В константе будет постоянно храниться указатель на первоначальный объект. Но на сам объект при этом никакое ограничение не накладывается, поэтому можно поменять любое его поле напрямую через b.amount=7.

Это противоречит сути констант из классических компилируемых языков, в которых константе можно присвоить только скалярное значение и потом компилятор везде в код подставляет напрямую это значение вместо константы.

В JS в константу можно присвоить что угодно. Даже изменяемый объект. Поэтому и получаем, что константа по сути остаётся константой, храня неизменяемую ссылку на объект, но сам этот объект можно модифицировать.

Левая часть (меню) статическая, а правая динамическая.

Да, все фронтенд-приложения Single Page Application (SPA) используют History API вместо реальной смены адреса с переоткрытием страницы. То есть навешиваются на onCLick всех ссылок и просто меняют адрес. И в зависимости от текущего пути уже выводят разные компоненты внутри шаблона. Например, у нас мы можем внутри 'App' под вызовом Header() вызывать некую функцию вроде:

function Content ({ path }) {
  if (path === '/') {
      return Home()
  } else if (path === '/lots') {
      return Lots()
  }
}

в которую передавать window.location.pathname. Она будет работать как маршрутизатор и в итоге на странице будет заменяться только контент.

И каждый компонент-страница вроде Lots уже будет запрашивать нужный ему JSON по API.

Если вместо json фрагмент html отправить /api/news это будет не быстрее чем на клиенте рендерить?

Браузеру почти нет разницы, откуда он всё берёт. Хоть с HTML, хоть из JS. Всё равно он сначала парсит тэги из HTML в дерево элементов и только после этого их рендерит.

Как раз в следующем эпизоде мы добавим динамическую загрузку и подгрузку данных. И там увидим, что основное неудобство будет не в первой загрузке данных, а в последующем обновлении. И там уже на JavaScript будет удобнее манипулировать элементами.

Они идут от разных сторон. React из JS, а Vue из HTML.

React использует нативный JS с React.createElement. И просто через примитивный JSX позволяет заменять вызов React.createElement на HTML-подобный синтаксис.

А Vue изначально имеет полноценный отдельный HTML-шаблонизатор с <template>, куда уже нужно вписывать нужные ему управляющие конструкции вроде v-if и v-for.

простым верстальщиком который знает html+css

Верно. React с JSX удобнее и привычнее JS-программисту, но меньше понятен HTML-верстальщику.

А Vue своим HTML-шаблонизатором <template> удобен верстальщику, но неудобен программисту.

1. Компонент в React можно сделать в виде функции или в виде класса. Поэтому удобно их всегда именовать по смыслу существительным Header вместо названия-глагола renderHeader для функции и Header для класса. Ещё такое особое именование компонентов-виджетов удобно, чтобы не путать их с другими обычными функциями-глаголами.

2. Избегать стоит только прямых зависимостей от "грязных" функций, чтобы их можно было подменять в тестах на чистые заглушки. А используемые чистые функции тестированию никак не мешают.

3. Да, некоторым более читаемо классическое многословное написание:

function (name) {
  return { name: name }
}

вместо нового короткого аналога:

(name) => ({ name })

Синтаксический сахар практически всегда придумывается для укорачивания кода. Со временем он становится привычным.

Я по поводу деструктуризации. Она теряет смысл, когда в объявлении функции и при её вызове используется один объект.

Сейчас многие функции-компоненты принимают только один аргумент. Пока мы вызываем функции вручную мы можем передавать его просто без деструктуризации.

Но вскоре мы перейдём на JSON-формат описания виртуального дерева и синтаксис JSX. Там мы со всеми компонентами будем работать уже универсально атоматически, а не вручную. И там будет удобнее передавать один объект props, чтобы не путаться в числе параметров и их порядке.

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