Добавлю, для справки caniuse.com/#search=IntersectionObserver

> и прочих технических требований к нагруженным системам
Обычно на начальном этапе _технических_ требований почти никаких, и надо чтобы оно просто работало и не создавало геморрой.

> Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
Хехе, забавный вывод, оставлю без комментариев.

> разработка mvp затягивается на какие — то неадекватные сроки
> выбор компонентов исходя из производительности, а не удобства
а теперь вы мне доказываете что на этапе mvp надо выбирать исходя из производительности? где логика? и где логика в том, что вы критикуете выбор NATS как выбор исходя из производительности, при том, что автор указал, что и по удобству ему NATS кажется более предпочтительным

> Вы выбрали базу
Я?

> считаете допустимо для «высоконагруженных» ситстем
Возможно я излишне вольно трактую посыл автора статьи, но мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена. Я трактую примерно в духе «взять что-то, что в среднесрочной перспективе не доставит геморроя, при этом не тратя на это много времени». Честно не понимаю, где тут люди видят сложность и перенавороченность предлагаемого набора.

> lxc != docker
Я это прекрасно понимаю.

> И вы что, автор чтобы что-то там подразумевать?
Подразумевал при прочтении. Если автор имеет в виду именно голый LXC — соглашусь, зря он так.

> выбор компонентов исходя из производительности, а не удобства
> Да и кластеризуется он быстрее и легче чем RabbitMQ.
Ээээ

> мускуль кластер
это что, сложно?

> lxc вместо докера
честно говоря, я под lxc подразумевал докер. если нет — зря

> выбор компонентов исходя из производительности, а не удобства
где?

> решение несуществующих проблем, введение технологий по принципу «чтобы было»
детали плз

Скорее соглашусь, но и здесь описаны детали и в аналогии со строительством есть «типовые» для материалов подходы и архитектуры: кирпичный дом vs панельный vs современный мейнстрим (железобетонный каркас + кирпичные стены): материалы определяют архитектуру и походы.

При том, что я сильно на стороне бизнеса (в противоположной от архитектурных стронафтов), не увидел в статье явного overengineering. Нормальная архитектура, не сильно сложнее ХХИВП, но заметно стабильнее.

Надеюсь, что не придется пользоваться сайтом с такими спецэффектами.

А на основе чего у вас сложилось такое впечатление?

Лет 10 назад делали такое в проекте, только тогда localstorage был слабораспространенной фичей.

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

Хорошо что больше нет необходимости так извращаться :)

Писал под OperaTV (движок Presto, как в Opera 12) и NetCast времен 2013 года.
webOS 1.х в плане производительности казался несбыточной мечтой…

Я не настоящий сварщик, и все описанное — лишь гипотезы. Но, кажется, между «будет магниться к желобу со страшной силой» и «не будет магнититься» есть куча градаций, которые могут сработать.

Тем, что его можно включать и выключать. Например, желоб пройти с выключенным, а потом включить.

… если это не электромагнит :) но, конечно, зависит от того, что там после желоба

Прям антисовет. Почти никто не читает приветственные письма.

У меня на домру не открывается

Mazda CX-9 ещё

Если принимать как данное, что в «С» все идеально, то незачем создавать что-то новое. Вопрос «принимать или не принимать» оставим за скобкой.
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…

А вы какой вариант вычисления хотите сделать автоматическим/неявным в таком, например, случае?
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.

Купил, попробовал, повесил в подъезд. Очень неприятные ощущения. Подробнее не помню.