lodas

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

Говорить о том, что некие фичи устарели - крайне глупо, если знать, что они ведут себя иначе, чем более модные альтернативы. Предлагаю немного разобраться и начать с того что на поверхности:
- getElementById и querySelector возвращают конкретную ноду в единственном экземпляре
- querySelectorAll и getElementsByName возвращает статичную коллекцию NodeList
- getElementsByClassName, getElementsByTagName и getElementsByTagNameNS возвращают динамическую коллекцию HTMLCollection
Как видим результат у разного апи различен, а значит и говорить, что некоторые из них устарели - глупо.
С устареванием вроде разобрались, но в вопросе еще есть часть "чем лучше". И тут есть теория, что getElementsBy* быстрее querySelector*. Чисто теоретически звучит логично, querySelector* должен делать полный поиск по дереву со сложностью O(n), а getElementsBy* могут использовать индексы на базе HashMap и получать данные со сложностью O(1), тут и особенности HTMLCollection будут кстати, так как можно не копировать коллекцию, а отдавать одну и ту же (и браузеры действительно так делают). Но без пруфов теория так и останется теорией.Гораздо лучше тут выглядят исходники. И я выбрал исходники chromium, как самого распространенного:
- getElementsBy* методы все как один обращаются к некой шаблонной функции EnsureCachedCollection, которая в свою очередь обращается к некоему NodeLists кэшу, устроенному внутри действительно как HashMap или что-то наподобие. Никакого поиска тут нет, просто берутся готовые значения, сложность у всего этого действительно константная O(1).
- querySelector* используют абстракцию SelectorQuery, которая и в самом деле делает поиск по DOM. Но данный поиск неплохо оптимизирован и обвешан кэшами. Притом CSSOM использует абсолютно тот же алгоритм поиска DOM нод для каждого селектора в css.

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

asyncData принимает контекст, смотрите что в нем есть и ищите axios

asyncData(ctx) {
  console.log(ctx)
}

Так должно работать

async asyncData({app}) {
      const ip = await app.$axios.$get('https://jsonplaceholder.typicode.com/todos/1')
      return { ip }
}

Полуторные и прочие колонки реализуются на раз-два-три, наверху правильно подсказали. Другое дело, что может понадобиться и например, 2,125))) Тогда только выбрасывать бутстрап, так как придется добавлять еще по пачке стилевых условия для каждого медиа-запроса!
На практике использую бутсnрап - для 12-grid-макетов и еще пару, не буду озвучивать, выбери сам, вобщем 14-grid есть и себе наляпал 24-grid!!)) покрывает 90% приходящих макетов...
По сути сама сетка - это 40 строчек css, все остальное уже от лукавого, таже не забывать, что в бутстрапе миллион встроенных штучек - слайдеры, табы и т.д. лучше грузануть один bs.js, чем ляпать на каждый эффект по библиотеке.
А вообще рисовальщик (сиречь дизайнер), который не может уложиться в 24-grid - крайне паршив! Если вписывается в 12-grid - рисовака идеален!!))

Держите codepen.io/delphinpro/pen/BWJEgG
Простая линейная структура. В определенных пределах можно менять положение плиток, не меняя css код.
Если еще помозговать, можно расширить эти пределы, добавить другие размеры плиток. Но на это нужно время, которого у меня нет.

Левый блок col по ширине может быть равен 2.5(два с половиной стандартных столбца)

И что здесь не вписывается?

.col {
  @include make-col-ready();
  @include make-col(2.5);
}

аналогично популярная тема с пятью столбиками

.col-1-of-5 {
  @include make-col-ready();
  @include make-col(1, 5);
}

Bootstrap — это не только ценный мех скаченный bootstrap.min.css, это еще и куча полезных миксинов.

сайты не нарисованные под сетку bootstrap

нет «сетки bootstrap», есть «сетка в бутстрапе». И с этой сеткой можно творить всё что угодно.
Отсюда вывод: если дизайн нарисован по сетке (неважно как), то его можно сверстать в том числе и с помощью сетки из состава бутстрапа.

Сразу оговорюсь - если что то пишется то фронт отдельно бег отдельно, общение по API.
Если все вместе, то такое дерьмо даже близко не возьму в руки.

1) Писали с нуля под нужды бизнеса, букинг направления.
2) Установка из докера одной командой, инсталлер это 90е начало нулевых
3) Готовые пакеты для angular2 + свои доработки
4) hotelbook.ru и др.
5) Вы опять смотрите в торону дерьмовых топовых систем. Нет конечно. Есть архитектурные решение в частности DDD
6) Как я уже сказал, фронт отдельным проектом (можно шкуры менять как хочется), бек отдельно. Для реализации сообщений и др. вещей, где шаблон в PHP необходим (а это редкость), используется twig.

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

P.S.
Вы не верно задали вопрос.
Стоило уточнить - Писали ли вы OpenSource CMS и др. системы для общего пользования.

Вопрос вам kot-samolet: Для чего вы интересуетесь данными вопросами ?
Если хотите для себя реализовать CMS, то это пустая трата сил и времени.
Лучше зайти немного с другой стороны.

$('html, body').animate({
    scrollTop: he1
}, 1500);