ViT93

Низкий порог вхождения для C++ и Vulkan означает продвинутый уровень владения инструментом C++, экспертные навыки обработки графики, работы с шейдерами и управления памятью GPU (да, там все иначе). Для входа в работу с Vulkan нужно быть, как минимум, Middle Graphics Engineer и уже уметь уверенно работать с DirectX11 или OpenGL4.5. Без этих знаний вулкан будет очень сложно понять, а правильно работать с ним получится только через десятки и сотни полностью неудачных итераций написать одно и то же.

Vulkan является очень низкоуровневым GAPI и требует от пользователя изначально серьезной подготовки. У этого GAPI много точек привязки к системной памяти, содержимое которой трактуется как на GPU, так и на CPU. Поэтому работать с памятью в C++ правильно нужно уметь с самого начала. Поэтому, еще до начала работы с вулканом от пользователя требуются экспертные знания языка. В противном случае вместо обучения работе с довольно сложным GAPI получится блуждание по полю граблей, где ничего не понятно.

При этом, курсов, статей и книг для обучения вулкану очень много и их очень легко найти.
Есть очень хороший цикл статей для самостоятельного обучения, есть даже перевод на наш язык.
Есть множество книг, по которым люди учатся работать с вулканом. Learning Vulkan считается самой лучшей.
Поисковиком легко ищутся разные мелкие примеры работа с вулканом.
Есть даже онлайн курсы для обучения под наблюдением инструктора.

И тем не менее, вулкан легко не дастся. Для его понимания нужна база, нужно знать устройство GPU, принципы коммуникации с ним, принципы его работы и всю теорию обработки графики. Нужно уже уметь быстро писать много стабильного и сложного кода на C++, нужно уметь безошибочно писать на GLSL или SPIR-V. Нужно уметь пользоваться графическими отладчиками, профилировщиками, разбираться в диагностике проблем при работе с графикой.
Все это приобрести можно в процессе практики с DirectX11 и OpenGL4.5.

Например. Если взять современные и популярные html/css фреймворки:

1. Bootstrap 5 (уже есть альфа версия) - flex
2. ZURB Foundation 6 - flex
3. UI Kit - flex
4. Materialize CSS - float?!
5. Semantic UI -flex

Откройте themeforest HTML - popular items в топе темы с bootstrap или кастомной версткой, но на flex.

НО

Если Вы делаете современный сайт (необязательно практичный, не рассчитанный на большое количество пользователей) , вроде тех что на awwwards , то вполне можно рисковать с grid

Поддержка: caniuse

+ Гриды не могут заменить флекс, их стоит использовать вместе. Подробнее тут.

P.S: Ничего не стоит на месте, grid на замену не придут, но в помощь точно вольются, поэтому их тоже стоит разбирать на будущее!

Grid чувствует себя прекрасно.

Можно уже спокойно их использовать и забыть про flexbox?

Grid не является заменой Flex. Вот тут очень важно это понимать. Плохой идеей будет взять весь Flex на странице и заменить его на Grid

Добрый день!

Когда Вы задаётесь вопросом поддержки и совместимости, той или иной технологии, смело идите на х ороший такой ресурс "CanIUse", в поисковой строке которого, пишите интересующее Вас. В результате вам отрендерится таблица поддержки запрашиваемого по всем браузерам.

caniuse.com

Если Вас устраивает поддержка , то можно

Добавлю к первому комментатору несколько замечаний
1. Чтобы качественно верстать, надо знать, что происходит по капотом. Каскады в css - не просто так называются каскадами. Браузер парсит цепочку каскада начиная с самого правого класса. Отсюда и следствие, что выгоднее для производительности: если мы пишем .mybox div div a, то парсер берет все теги a на странице, проверяет первое условие вложенности в div, потом следующее... Если же писать .mybox .inbox .link - то выборка будет только элементов с указанными стилями.
2. Хороший стиль в верстке - когда следующий за тобой разработчик не проклинает тебя и всю твою родню из-за загадок и кривого кода. Писать надо лаконично и максимально понятно. Современные мощности позволяют не заморачиваться с длиной имен классов.
3. Верстать лучше всего исходя из предварительного анализа структуры страницы. Можно создать страницу с типографикой, вынести туда все универсальные переиспользуемые компоненты и блоки, оформить их так, чтобы ничего не ломалось при изменении вложенности. Все изменения базового компонента делать через класс-модификатор. Каскады стоит делать в случае, когда в рамках одного компонента прослеживается постоянная структурная и смысловая связь. Т.е. блок вывода анонса новости всегда имеет заголовок, дату, анонс и ссылку. Можно делать каскадом, можно делать по БЭМ прописывая все зависимости в именах классов.
Но если уж взялся использовать какой-то подход - важно пользоваться именно такой устоявшейся конструкцией.
Всех благ :)

Если есть возможность, используй модификатор для дочернего элемента блока юзер.
Если ты собираешься существенно изменить свойства блока — создавай новый блок. Чтобы в будущем не оказаться в ловушке у кода.
Можешь сделать обращение напрямую к блоку изображения (да, надо, чтобы изображение в таком случае тоже было блоком. Атомарность етить ее)., либо просто к изображению.

В целом первый вариант предпочтителен. Так как остальные могу спокойно привести не туда. Хотя первый и приведет к добавлению кода везде.

А твой вопрос в документации тут, в рубрике «как хотите, так и еб...» (На сайте не пашут анкоры, так что просто глянь, что в адресной строке и докрути).

Впрочем, в целом, такое обычно делать и не приходится. Жестко так миксовать в смысле. В этом и заключается принцип БЭМ, «взболтать, не смешивать».

Ну вот смотри на примере той же button - каждый класс как-то модифицирует отображение кнопки. Каждый из этих классов может использоваться по отдельности и в любых сочетаниях. Ты просто один раз прописал эти классы, а дальше по необходимости накидываешь какие надо: одна кнопка так, другая эдак, ничего не дублируется ничего не надо заново выверять.
Как ты это собрался делать каскадом? Железно прописывать стили для каждой вложенности? Так завтра те бизнес скажет: "Передвинь кнопку на блок вниз и влево", и у тебя всё посыпется, придётся переписывать куски css. А после завтра попросят передвинуть весь блок и выровнять кнопку по правому краю. Опять всё переписывать.
Тащем абсолютно непродуктивно это.

Я не мастер, но нужно верстать как удобно и при этом не нарушать читабельность кода, так что любая верстка, которая нормально отображается, и не делает каши в голове - хорошая