HTTP/2 многое улучшает, но во-первых, он должен быть, а во-вторых — всё-таки не всё (хотя бы то, что надо будет минимум 2 последовательных обращения вместо одного для загрузки кода, даже если глубину импортов оптимизировать).
HTTP/2 — вроде как прицел и был на то, чтобы решить проблему множественных соединений. При условии, что мы контролируем server — почему бы и не перейти на него, если проект с нуля?
Плюс необязательно всегда следовать правилу 1 класс/компонент = 1 файл при условии микро компонентов/классов.
К примеру файл buttons.mjs может экспортировать несколько разных кнопок. Но это так — мысли в слух.
Ну мне к примеру не нравится, что тривиальное приложение за счет node_modules весит 200 мегабайт. Как-то в концепцию микросервиса не укладывается :)
А вы микросервис по размеру исходников определяете?
Это размер c devDependencies или без? При деплое приложения размер зависимостей намного меньше. Кстати, я только что скачал Spring и распаковал — 297 мегабайт. Вкладывается Sping в концепцию микросервиса?
То что оно особо не рассказывает как оно упаковывает, больше про ручки написано.
А вам надо чтобы в документацию инструмента входило детальное описание процесса упаковки? Если да интересно послушать зачем.
Угу в итоге везде описывается одна и та же схема с токенами и jwt токенами.
Я даже не знаю как на это отреагировать.
В Django к примеру это никого не удивляет.
В джанго описан похожий подход как я описал выше.
Если структура папок для вас камень преткновения, и вам нужна одна конкретная, наверное действительно вам входить в web нечего.
В components лежит ровно один файл :) Как-то не похоже на структуру :)
В этом и есть смысл — вам достаточно стартовать с папкой компонент.
И 100 мегабайт в node_modules. Я так понял чтобы уменьшить бандл мне нужно будет каждую библиотеку таким образом изучить и посмотреть не напихали ли туда лишнего?
Используя vue-cli вы устанавили библиотеки для дев окружения, линтер, сборщик, вебсервер… etc. Чем так мозолят эти 100 мегабайт?
Проблема в том что сейчас, чтобы вкатиться в js разработку приходится лопатить очень много мусора
Кстати я прихожу постепенно к мнению что и упаковщики практически не нужны (после поддержки большой четверкой Chrome, Firefox, Safari, Edge нативных ES6 modules, caniuse.com/#feat=es6-module), кроме как сборки зависимостей из npm и стилей. На этом фоне даже появился на базе Rollup еще один сборщик — www.snowpack.dev
Идея отличная но у Rollup и основанных на нем сборщиках нет поддержки Hot Module Replacement из коробки (те два сторонних плагина что есть работают откровенно говоря плохо). Тем более для нативных модулей.
Поэтому в свободное время я занят написанием своего бандлера на основе rollup.
Идея проста как и у snowpack — анализируем наши зависимости из node_modules и собираем их через rollup для импорта в браузере. Наш клиентский код оставляем без изменений (либо компилируем ts -> mjs без участия бабеля), пишем современно и используем нативные модули.
Грубо говоря наш исходный код будет таким же, каким его будет исполнять браузер. Бандлер имеет встроенный devserver и hot-reload
нативных модулей (реализовать это было мягко говоря непросто), а также интеграцию с eslint. В продакшин режиме фалы сжимаются, index.html генерируется автоматически.
На данном этапе занят финальным этапом — поддержкой css пре/пост процессоров. Конечно и такое решение не для всех, а лишь для тех кто может себе позволить не поддерживать легаси IE и Safari.
Окей. Давайте нормальную документацию по тому же webpack
А что не так с существующей документацией? Особых проблем с ней у меня не возникало. И кто вас заставляет использовать только webpack?
Дополнительно сразу запрошу пожалуй документацию которая мне даст описание как более менее правильно строить архитектуру того же js приложения.
Ну камон. Серьезно? Дайте мне пожалуйста документацию как правильно строить архитектуру на Rust. Или C++. А и еще на Swift под MacOS пожалуйста заверните.
Потому что vuejs к примеру рассказывает о фичах, но вот упоминаний о рекомендованной структуре проекта там просто нет. Как и собственно нормальных рекомендаций потому как организовывать авторизацию.
Это было бы крайне странно. Реализаций самой авторизации может быть множество. Откуда им знать какая вам нужна? Мало того, было бы странно если бы фреймворк или библиотека диктовала структуру директорий.
А если уже говорить о структуре самого проекта — всегда есть здравый смысл:
Компоненты должны быть в папке компоненты, страницы в папке страницы, константы в папке константы, утилиты в папке утилиты, а модели в моделях. Это очевидно как мне кажется. Тем более для реакта и вью есть cli утилиты которые все настраивают сами.
Простой пример подключаем date-fs, насколько я помню по умолчанию туда затаскиваются все переводы для всех языков. Зачем?
Разработчики библиотеки предоставляют ресурсы необходимые для ее правильной работы. Эта библиотека по умолчанию поддерживает tree shaking. Вы можете не импортировать ее полностью. Идем в документацию date-fns.org/v2.13.0/docs/webpack
Я не очень понимаю в чем проблема использовать тот инструмент который подходит для вашей ситуации и проекта и почитать документацию?
Это с vedorchunk. И не упакованное. Само приложение весит 175 килобайт
Ну по нормам это не ко мне а к Малышевой :). Если честно немного странно почему у вас так много vendor chunk весит. Возможно его стоит раздерибанить.
вам не кажется что вот все вами описанное должен делать не я а упаковщик?
Если пишите не под старые браузеры — современные браузеры это умеют уже даже без сборщика (нативные es6 модули). Грамотно настроенный линтер уже делает почти все за вас. Кроме Webpack есть еще Parcel, Rollup — что еще надо? Куда проще?
Это и есть проблема. Проблема всего JS. А выкинуть никак нельзя.
Нет. Это не проблема JS. Как и любого другого языка. Так же как это не проблема платформы. JS не виноват что вы включили полифил и 1000 библиотек.
Проблема кроется обычно в нежелании открыть документацию, потратить небольшое время на изучение платформы и ее возможностей, выделить время на проектирование приложения и один раз написать нормально.
А и еще. Хочу посмотреть на компиляторы, билдеры из других языков, которые могут сами в архитектуру приложения. Убрать лапшу, копипаст, вынести все автоматом в модули, выносить логику и вьюшек, а вьюшки из логики, патерны использовать, семантически генерировать и именовать расово правильные методы и классы по вызову одной команды?
Были в моей рабочей практике похожие проекты. Проблема на самом деле не в сборке такого проекта, а в нем самом. Начнем с претензий к NPM и сразу посмотрим на другие платформы
1. Почему то никто особо не грустит, когда, чтобы написать на MacOS нормальное приложение размером пару мегабайт, нужно скачать Xcode размером 8 гигабайт, которое при установке занимает 16 гигабайт.
2. Ладно идем в QT. Качаем онлайн установщик — убив куча времени на регистрацию устанавливаем последнюю версию QT — 19 гигабайт. А я всего лишь хотел приложение на пару мегабайт.
Про Visual Studio уже ниже написали.
Вернемся к NPM, вернее к node_modules. Для начала условимся, что эта папка нам нужна только на момент разработки и в любой момент после сборки мы можем ее удалить, а используя yarn — библиотеки очень быстро устанавливаются из кеша. Допустим, по какой-то неведомой причине нам очень критично место на компьютере, а проектов на диске много — можно установить один раз общие devDependencies глобально, а для проектов ставить только dependencies. Это звучит немного бредово, так же как и жалоба на размер node_modules.
Теперь к проекту:
Размер приложения 1.4 мегабайт — это очень много для одного js файла. Скорее всего допущены ошибки в процессе сборки или проектирования.
0. Проанализировать зависимости приложения — действительно мне нужна целая библиотека для реализации или достаточно использовать только ее часть (к примеру lodash, underscore, date-fns и тд.)? Возможно ли вообще обойтись без стороннего кода? Есть ли библиотеки с меньшим размером кода?
1. Нужно убедится что vendor зависимости не входят в файл приложения. Их можно вынести в отдельный файл (chunk) либо подключить по сети через cdn. Зависит от ситуации.
2. Проанализировать насколько монолитен код проекта. Разбит ли код на части или модули? Действительно ли для Login страницы необходима загрузка логики остальной части приложения? Насколько зависимы эти части? Повторяется ли код (copy-paste) из одних компонентов или классов в других? Насколько компоненты переиспользуются? Нужна ли, к примеру, библиотека WYSIWYG редактора на каждой странице? Использован ли tree shaking и работает ли он?
Сделав подобный небольшой рефакторинг — я более чем уверен что размер приложения изменится и вместо одного огромного app.js у вас будет несколько файлов по 100-200 килобайт.
Проблемы у таких проектов начинаются на самой зачаточной стадии еще до написания кода. Из за несерьезного отношения и плохого менеджмента сроки ужимаются, никто не тратит время на проектирование «на бумаге» до того, как писать код. Все сразу бегут начать писать код. «А что там проектировать?» — говорят они. Накидал по быстрому библиотек, написал портянки копипастного кода, подключил всех возможных полифилов чтобы IE6 работал (хотя по факту не будет), сгенерил, не зная того, бабелем легаси код, где вместо async/await и промисов инклюдится transform regenerator и на выходе получаем ЭТО — 2-3 и более мегабайт тормозящего легаси JS кода.
Я не говорю, что у вас так. Но поверьте, такое происходит не из за технологии, а из-за неправильного ее использования.
Частично c вами согласен. Да — JavaScript не идеален, но зная язык и особенности платформы можно писать хорошо даже без TypeScript. Да и в том же C и C++ выстрелить себе в ногу не намного тяжелее, а иногда и легче — зависит от опыта разработчика и его инструментария. Веб меняется как и другие сферы — иногда в правильную сторону, иногда и нет. Но хоронить его потому что браузер очень сложный, сайт сделать сложно и тд. это неправильно.
Приходишь ты потом на такой проект после такого НАСТОЯЩЕГО программиста и смотришь на него со слезами, чешешь свою веб-макаковскую репу, думая, как спасти этот тонущий в говнокоде проект.
В итоге хочу лишь сказать что, веб платформа хоть и имеет недостатки (порой и серьезные), при этом вполне зрелая платформа, которая вполне отвечает современным требованиям и хоронить и переделывать ее в ближайшее время вряд-ли будут без веских причин.
Я бы вас поправил немного — не то чтобы годные, выше вы сами пример привели неточного перевода, сколько целостные и в целом удачные. Да и популярность он приобрел на шуточных переводах Матрицы и Властелина колец в 2000-x, а не на обычных.
Причин может быть много.
Может быть потому что есть множество сил, которые потерпели бы убытки от предпринятых мер, и они оказывали противодействие. Реальное положение дел стало известно лишь к концу декабря. А на западе это новый год и рождество.
А может из — за западной модели в отличие от Китая и его тоталитаризма. Тяжело вводить меры и придерживаться их.
А может так и надо и «все идет по плану».
А может моя теория неверна и я притянул все за уши.
Просто оставьте в покое душевно больных. Это как кричать в пустоту.
Лучше сразу согласиться, что коронавирус придумали жидомассоны в тайных лабораториях ЦРУ, пациент успокоится и ни одна нервная клетка не пострадает.
Ситуация на самом деле очевидная, как 5 копеек. В среднем крупные эпидемии с новой болячкой происходят каждые 15-20 лет. Пандемии 100-150.
Учитывая какую сырую дрянь едят китайцы, а это подразумевает что они охотятся на этих диких животных, не удивительно, что они имеют постоянный контакт с источником болезней. Так же произошло и в этот раз. Мир глобален, особенно Китай с его производственными контактами. Рано или поздно это должно было произойти.
Дальше мои мысли в слух, основываясь на потоке информации, как могло быть гипотетически.
Скорее всего болезнь попала в популяцию людей в середине осени с того самого злосчастного рынка в Ухани. Как сейчас известно, инкубационный период может быть более чем 2 недели, то сначала болезнь не сильно себя проявляла. Затем китайское правительство заметило аномальные смерти от пневмонии и, как нам стало известно позже, начала предпринимать действия чтобы скрыть происшествие. Очевидно, что ведущие разведки мира получили эту информацию, но в силу закрытости Китая не имели прямых доказательств. Поэтому было принято решение попытаться смоделировать ситуацию, чтобы оценить риски и возможные потери. За полтора месяца, до того как Китай больше не смог отрицать и сдерживать болезнь, в Нью Йорке были проведены учения с очень похожим на текущую ситуацию сценарием — в Центре по безопасности здоровья университета Джонса Хопкинса под кодовым названием «Событие 201». Это тот самый университет, который первым сделал сайт мониторинга распространения болезни. По легенде в мире разгорается пандемия из-за нового коронавируса, полученным от свиней, и от которого умирает около 65 миллионов человек. В обсуждение были вовлечены не только представители медицины, но и экономического сектора, корпораций, банковской и политической сферы (как вам?). Оценивался гипотетический ущерб экономике и способы как исправить ситуацию.
Может быть из-за своей чрезмерной уверенности держать ситуацию под контролем мы и имеем то что имеем. Кстати, конечно официально учения ничего общего с пандемией не имеют.
Вот такая небольшая конспирология.
Перед глазами пролетело пол жизни. Могу только добавить что CSS на самом деле очень мощный инструмент стилизации по сравнению с многими другими. Как говорится «не ценим что имеем, потерявши плачем».
Switcher это по сути тумблер. То есть включить / выключить. Дизайн имеет корни из промышленного дизайна рычагов, старинных выключателей света (популярных в США/Великобритании) и так далее.
Checkbox — она же «галочка» пришла к нам уже из бумажных документов, где нужно отметить какие либо пункты/опции/варианты. Семантически галочка и тумблер отличаются по смыслу.
HTTP/2 — вроде как прицел и был на то, чтобы решить проблему множественных соединений. При условии, что мы контролируем server — почему бы и не перейти на него, если проект с нуля?
Плюс необязательно всегда следовать правилу 1 класс/компонент = 1 файл при условии микро компонентов/классов.
К примеру файл buttons.mjs может экспортировать несколько разных кнопок. Но это так — мысли в слух.
А так конечно сборщики никуда не денутся.
А вы микросервис по размеру исходников определяете?
Это размер c devDependencies или без? При деплое приложения размер зависимостей намного меньше. Кстати, я только что скачал Spring и распаковал — 297 мегабайт. Вкладывается Sping в концепцию микросервиса?
А вам надо чтобы в документацию инструмента входило детальное описание процесса упаковки? Если да интересно послушать зачем.
Я даже не знаю как на это отреагировать.
В джанго описан похожий подход как я описал выше.
Если структура папок для вас камень преткновения, и вам нужна одна конкретная, наверное действительно вам входить в web нечего.
В этом и есть смысл — вам достаточно стартовать с папкой компонент.
Используя vue-cli вы устанавили библиотеки для дев окружения, линтер, сборщик, вебсервер… etc. Чем так мозолят эти 100 мегабайт?
Так можно сказать о любой платформе.
Идея отличная но у Rollup и основанных на нем сборщиках нет поддержки Hot Module Replacement из коробки (те два сторонних плагина что есть работают откровенно говоря плохо). Тем более для нативных модулей.
Поэтому в свободное время я занят написанием своего бандлера на основе rollup.
Идея проста как и у snowpack — анализируем наши зависимости из node_modules и собираем их через rollup для импорта в браузере. Наш клиентский код оставляем без изменений (либо компилируем ts -> mjs без участия бабеля), пишем современно и используем нативные модули.
Грубо говоря наш исходный код будет таким же, каким его будет исполнять браузер. Бандлер имеет встроенный devserver и hot-reload
нативных модулей (реализовать это было мягко говоря непросто), а также интеграцию с eslint. В продакшин режиме фалы сжимаются, index.html генерируется автоматически.
На данном этапе занят финальным этапом — поддержкой css пре/пост процессоров. Конечно и такое решение не для всех, а лишь для тех кто может себе позволить не поддерживать легаси IE и Safari.
А разве упаковка nodejs приложения обязательна?
А что не так с существующей документацией? Особых проблем с ней у меня не возникало. И кто вас заставляет использовать только webpack?
Ну камон. Серьезно? Дайте мне пожалуйста документацию как правильно строить архитектуру на Rust. Или C++. А и еще на Swift под MacOS пожалуйста заверните.
Это было бы крайне странно. Реализаций самой авторизации может быть множество. Откуда им знать какая вам нужна? Мало того, было бы странно если бы фреймворк или библиотека диктовала структуру директорий.
А если уже говорить о структуре самого проекта — всегда есть здравый смысл:
Компоненты должны быть в папке компоненты, страницы в папке страницы, константы в папке константы, утилиты в папке утилиты, а модели в моделях. Это очевидно как мне кажется. Тем более для реакта и вью есть cli утилиты которые все настраивают сами.
Разработчики библиотеки предоставляют ресурсы необходимые для ее правильной работы. Эта библиотека по умолчанию поддерживает tree shaking. Вы можете не импортировать ее полностью. Идем в документацию
date-fns.org/v2.13.0/docs/webpack
Я не очень понимаю в чем проблема использовать тот инструмент который подходит для вашей ситуации и проекта и почитать документацию?
Ну по нормам это не ко мне а к Малышевой :). Если честно немного странно почему у вас так много vendor chunk весит. Возможно его стоит раздерибанить.
Если пишите не под старые браузеры — современные браузеры это умеют уже даже без сборщика (нативные es6 модули). Грамотно настроенный линтер уже делает почти все за вас. Кроме Webpack есть еще Parcel, Rollup — что еще надо? Куда проще?
Нет. Это не проблема JS. Как и любого другого языка. Так же как это не проблема платформы. JS не виноват что вы включили полифил и 1000 библиотек.
Ксати, давайте возьмем к примеру Java. Идем на страничку wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
Ой! Прийдется брать старую Java для поддержки старой операционки.
Ой! Есть и такие ограничения? habr.com/ru/post/314416
Почему билдер не решает это за меня?
Проблема кроется обычно в нежелании открыть документацию, потратить небольшое время на изучение платформы и ее возможностей, выделить время на проектирование приложения и один раз написать нормально.
А и еще. Хочу посмотреть на компиляторы, билдеры из других языков, которые могут сами в архитектуру приложения. Убрать лапшу, копипаст, вынести все автоматом в модули, выносить логику и вьюшек, а вьюшки из логики, патерны использовать, семантически генерировать и именовать расово правильные методы и классы по вызову одной команды?
1. Почему то никто особо не грустит, когда, чтобы написать на MacOS нормальное приложение размером пару мегабайт, нужно скачать Xcode размером 8 гигабайт, которое при установке занимает 16 гигабайт.
2. Ладно идем в QT. Качаем онлайн установщик — убив куча времени на регистрацию устанавливаем последнюю версию QT — 19 гигабайт. А я всего лишь хотел приложение на пару мегабайт.
Про Visual Studio уже ниже написали.
Вернемся к NPM, вернее к node_modules. Для начала условимся, что эта папка нам нужна только на момент разработки и в любой момент после сборки мы можем ее удалить, а используя yarn — библиотеки очень быстро устанавливаются из кеша. Допустим, по какой-то неведомой причине нам очень критично место на компьютере, а проектов на диске много — можно установить один раз общие devDependencies глобально, а для проектов ставить только dependencies. Это звучит немного бредово, так же как и жалоба на размер node_modules.
Теперь к проекту:
Размер приложения 1.4 мегабайт — это очень много для одного js файла. Скорее всего допущены ошибки в процессе сборки или проектирования.
0. Проанализировать зависимости приложения — действительно мне нужна целая библиотека для реализации или достаточно использовать только ее часть (к примеру lodash, underscore, date-fns и тд.)? Возможно ли вообще обойтись без стороннего кода? Есть ли библиотеки с меньшим размером кода?
1. Нужно убедится что vendor зависимости не входят в файл приложения. Их можно вынести в отдельный файл (chunk) либо подключить по сети через cdn. Зависит от ситуации.
2. Проанализировать насколько монолитен код проекта. Разбит ли код на части или модули? Действительно ли для Login страницы необходима загрузка логики остальной части приложения? Насколько зависимы эти части? Повторяется ли код (copy-paste) из одних компонентов или классов в других? Насколько компоненты переиспользуются? Нужна ли, к примеру, библиотека WYSIWYG редактора на каждой странице? Использован ли tree shaking и работает ли он?
Сделав подобный небольшой рефакторинг — я более чем уверен что размер приложения изменится и вместо одного огромного app.js у вас будет несколько файлов по 100-200 килобайт.
Проблемы у таких проектов начинаются на самой зачаточной стадии еще до написания кода. Из за несерьезного отношения и плохого менеджмента сроки ужимаются, никто не тратит время на проектирование «на бумаге» до того, как писать код. Все сразу бегут начать писать код. «А что там проектировать?» — говорят они. Накидал по быстрому библиотек, написал портянки копипастного кода, подключил всех возможных полифилов чтобы IE6 работал (хотя по факту не будет), сгенерил, не зная того, бабелем легаси код, где вместо async/await и промисов инклюдится transform regenerator и на выходе получаем ЭТО — 2-3 и более мегабайт тормозящего легаси JS кода.
Я не говорю, что у вас так. Но поверьте, такое происходит не из за технологии, а из-за неправильного ее использования.
Самое смешное — есть определенная категория людей (не все, лишь токсичная часть) из мира Java, C, C++, которая необоснованно называет всех веб-разработчиков веб-макаками, обосновывая это тем, что JavaScript, PHP, Python и остальные интерпретируемые языки программирования гавно по сравнению с серьезными языками и особого ума не надо, чтобы на них писать, и они (настоящие программисты), за вечер лучше напишут. И при упоминании конечно же хоронят веб каждый день.
Когда в силу определенных обстоятельств таким людям все-таки приходиться что-либо сделать серьезное в веб-сфере, НЕОЖИДАННО оказывается — УУУ! СЛОЖНА! СЛОЖНА!© ВЕБ РАЗДУТЫЙ! АПИ ГАВНО! УСТАРЕВШИЕ СПЕЦИФИКАЦИИ! ПРИМУС! МОСКВАШВЕЯ! ПРИЗНАНИЕ РОССИИ! АБЫР… AБЫР… АБЫРВАЛГ!
Фреймворки, библиотеки, спецификации, браузерные API, паттерны, другой синтаксис языка, компиляторы и остальные инструменты — всем этим ОКАЗЫВАЕТСЯ необходимо знать как правильно пользоваться.
Приходишь ты потом на такой проект после такого НАСТОЯЩЕГО программиста и смотришь на него со слезами, чешешь свою веб-макаковскую репу, думая, как спасти этот тонущий в говнокоде проект.
В итоге хочу лишь сказать что, веб платформа хоть и имеет недостатки (порой и серьезные), при этом вполне зрелая платформа, которая вполне отвечает современным требованиям и хоронить и переделывать ее в ближайшее время вряд-ли будут без веских причин.
Может быть потому что есть множество сил, которые потерпели бы убытки от предпринятых мер, и они оказывали противодействие. Реальное положение дел стало известно лишь к концу декабря. А на западе это новый год и рождество.
А может из — за западной модели в отличие от Китая и его тоталитаризма. Тяжело вводить меры и придерживаться их.
А может так и надо и «все идет по плану».
А может моя теория неверна и я притянул все за уши.
Лучше сразу согласиться, что коронавирус придумали жидомассоны в тайных лабораториях ЦРУ, пациент успокоится и ни одна нервная клетка не пострадает.
Ситуация на самом деле очевидная, как 5 копеек. В среднем крупные эпидемии с новой болячкой происходят каждые 15-20 лет. Пандемии 100-150.
Учитывая какую сырую дрянь едят китайцы, а это подразумевает что они охотятся на этих диких животных, не удивительно, что они имеют постоянный контакт с источником болезней. Так же произошло и в этот раз. Мир глобален, особенно Китай с его производственными контактами. Рано или поздно это должно было произойти.
Дальше мои мысли в слух, основываясь на потоке информации, как могло быть гипотетически.
Скорее всего болезнь попала в популяцию людей в середине осени с того самого злосчастного рынка в Ухани. Как сейчас известно, инкубационный период может быть более чем 2 недели, то сначала болезнь не сильно себя проявляла. Затем китайское правительство заметило аномальные смерти от пневмонии и, как нам стало известно позже, начала предпринимать действия чтобы скрыть происшествие. Очевидно, что ведущие разведки мира получили эту информацию, но в силу закрытости Китая не имели прямых доказательств. Поэтому было принято решение попытаться смоделировать ситуацию, чтобы оценить риски и возможные потери. За полтора месяца, до того как Китай больше не смог отрицать и сдерживать болезнь, в Нью Йорке были проведены учения с очень похожим на текущую ситуацию сценарием — в Центре по безопасности здоровья университета Джонса Хопкинса под кодовым названием «Событие 201». Это тот самый университет, который первым сделал сайт мониторинга распространения болезни. По легенде в мире разгорается пандемия из-за нового коронавируса, полученным от свиней, и от которого умирает около 65 миллионов человек. В обсуждение были вовлечены не только представители медицины, но и экономического сектора, корпораций, банковской и политической сферы (как вам?). Оценивался гипотетический ущерб экономике и способы как исправить ситуацию.
Может быть из-за своей чрезмерной уверенности держать ситуацию под контролем мы и имеем то что имеем. Кстати, конечно официально учения ничего общего с пандемией не имеют.
Вот такая небольшая конспирология.
Checkbox — она же «галочка» пришла к нам уже из бумажных документов, где нужно отметить какие либо пункты/опции/варианты. Семантически галочка и тумблер отличаются по смыслу.