Пишем современный маршрутизатор на JavaScript

Правильно, декораторы вещь крутая и мощная, поэтому можно совмещать преимущества со всех фронтов и ни в чем себе не отказывать)

В варианте 2 память выделяется при вызове при вызове метода, в котором лежит setInterval, и освобождается после завершения работы

В данном случае время жизни интервала равно времени жизни router-а. Память не высвобождается никогда (пока жива страница).

Применимо же в некому абстрактному случаю в вакууме, вы можете получить выигрыш по памяти тогда, когда время жизни вашего callback-а заведомо меньше времени жизни объекта владельца. Но стоит отметить что и проиграть вы можете там же, если, скажем, ваш метод может использоваться сразу в нескольких местах, но вы пересоздаёте его всякий раз заново. В общем тут нужно смотреть конкретный случай под микроскопом.

Сразу отмечу, что весь этот спор обретает хоть какой-либо смысл только тогда, когда у вас большие объёмы. Скажем это ядро какой-нибудь сетевой игры, или скажем недра реактивного-фреймворка, или некий html-шаблонизатор. Если речь не идёт о десятках тысячах объектов, то это последнее место, в котором стоит обсуждать вопрос памяти.

Там уже выше faiwer показал, что в этом примере с таймерами, дополнительная копия метода создается в любом случае, как ни крути.

Понятное дело, если метод всегда вызывается с правильным this, то его можно объявить по-обычному, в прототипе. Мой основной вопрос был к этому предложению:

Автор просто не любит явный код.

class Test {
  myMethod = () => {}
}

class Test {
  constructor() {
    this.myMethod = () => {};
  }
}

Обе конструкции одинаково явные, автор просто предпочел более компактный синтаксис, не более того.

И url это удобный инструмент для фиксирования или указания состояния.

Как не ищу, всё никак не могу найти плюсы клиентского роутинга. Напротив — одни проблемы. Особеннно когда делают несколько уровней вложенности, а в особых случаях даже на попапы отдельные роуты заводят. Но при этом забывают, что пользователь может нажать f5 — и всё то, что он накликал до этого теряется и приложение падает. А потом просят исправить.

В плюсы роутинга можно отнести:
навигация средствами браузера Back/Forward
навигация по истории браузере

Чувствуете «семантику»?..)
Браузерные кнопки Back/Forward — служат для навигации по истории БРАУЗЕРА. Перебивать его клиентским роутингом — это какой-то костыль, можно сказать «несемантично».
Если нужна навигация по истории внутри ПРИЛОЖЕНИЯ — это делается кнопками в интерфейсе самого приложения. Как правило всегда есть кнопки «назад», «отменить» и т.п. Если таких кнопок в интерфейсе нет — то значит навигация этому приложению и не нужна вовсе.
SPA — ОДНОстраничное приложение, опять «семантика» ощущается..) Оно как бы за себя говорит — что должно находится на одном серверном роуте.

На самом деле для себя вижу только один кейс для клиентского роутинга — когда пользовательский сценарий приложения предусматривает сценарий «поделиться ссылкой на текущую вьюху» (тот же Zeplin онлайн допутим). Т.е. это есть в требованиях. Буду рад если подскажите ещё кейсы.

Можете сказать, что есть сценарий заполнения длинной формы/визарда, и при рефреше она должна сохранятся. Ок. Только вот как правило такие формы/визарды сохраняют промежуточные шаги на сервере. Восстановить нужный шаг не проблема, роутинг для этого не нужен.

Более того, некоторые пользователи ожидают и хотят, чтоб при рефреше странички — всё сбросилось в первоначальный вид и можно было начать заново. Например затупил где-то, или запутался где-то глубоко в интерфейсе. Да и приложению полезно — память подчистится, всё проинициализируется в правильном порядке, менее бажный код, больше надёжность вобщем.

Вобщем мой поинт в следующем:
— Роутинг — это про навигацию по истории браузера.
— Для навигации по истории приложения — лучше использовать элементы интерфейса самого приложения.
— Добавлять клиентский роутинг — только при явных требованиях, а не раньше времени, просто потому что так принято (ещё и ~+25кб тянуть).

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