SEOD, не то чтоб я топил за Мак... но важнее не сколько пользователей вообще у платформы, а сколько пользователей платежеспособных и стало быть бабла. Не вспомню сейчас источник, но как-то читал, что в среднем в пересчете на 1 юзера приложения для iOS приносят разработчикам в 6 (шесть!) раз больше денег, чем для Андроида. Покупателей Маков относительно немного в сравнении с Виндой (да и то, смотря по какой стране), но денег тратить они готовы больше.
asd111, это видел. Это некачественная верстка. Я знаю, что Артюх опытный спец и уверен, что он умеет хорошо. Но с такой спешкой даже у него результат фиговатый. Рассматривайте этот видос как спортивный челендж, а не руководство по практической работе.
Stalker_RED, первый вариант конечно правильнее, потому что делает единый обработчик, а второй размножает копии по количеству инпутов.
Только нужно учитывать, что уже на таком простом примере из трёх строк нам потребуются полифилы (если нас интересуют пользователи из реального мира). В 1 случае для matches, во 2 для forEach. Насчет сравнения читаемости кода каждый пусть судит сам.
Нельзя так сравнивать. Гуглите по словам addy osmani cost of javascript. Если в двух словах, то скрипты обходятся намного дороже, чем картинка такого же веса.
Причем тут cdn? Количество строк - это в первую очередь нагрузка на мозг, а уж потом на канал. Больше строк - больше нужно читать, сложнее разбираться, больше возможностей ошибиться, наговнокодить, наделать багов.
profesor08, можете, но... Во-первых, гораздо более многословно - там где jQuery нужна одна строка кода, ванила потребует несколько. Во-вторых, нужно помнить гораздо больше нюансов - ну-ка, какой процент нынешних разрабов навскидку скажет мне разницу между Node и Element? Или между NodeList и HTMLCollection?
Есть несколько известных сайтов, типа youmightnotneedjquery.com которые приводят ванильные "эквиваленты" джеквериевского кода. Так вот они там часто лукавят и приводят не точные аналоги, а лишь приблизительные, которые отличаются важными "мелочами" в поведении.
Чтоб не было недопониманий, я подчеркну, что я не против ванильного JS и не агитирую за jQuery, как "лучший" вариант. Я против мифа и нигилизма, которые сопровождают jQuery последние пару-тройку лет - мол, ванила уже полностью всё заменяет, а кто не согласен, тот лошара. Не заменяет, там куча нюансов. Если мы решили писать на ваниле и сознательно готовы принять все её плюсы и минусы - отлично, я поддерживают стремление к оптимизации. Но не нужно мне рассказывать, что jQuery это бесполезный легаси-мусор. На нём пол-интернета работает и ещё долго будет работать.
Ну вообще говоря да.
Я вижу в этом коде просто наложенный поверх лишний уровень абстракции, который не несёт никакого полезного действия, кроме другого нестандартного синтаксиса. Конкретно в данном случае - что мы выиграли? Неужели писать @apply font-bold намного быстрее, чем font-weight: bold? Вряд ли, а с учетом помощи ide возможно даже медленнее. А читать многочисленные сокращения сложнее. А если писать в одну строчку, то ещё менее читабельно.
При этом вопросы организации кода эта система не решает вообще никак. Никакой структуры, семантики, переиспользования и вот это всё. Знаете, это похоже на детские игры, когда дети придумывают свой "иностранный язык" - в реальности, конечно, никакого языка нет, есть только собственный алфавит из необычных значков. А для пущей загадочности можно писать справа налево. Зачем? Да ни зачем, прикольно же.
То что ванильный JS может полностью и безболезненно заменить jQuery - это миф. Если вам нужна поддержка браузеров из реального мира, то проблемы кроссбраузерности и многословности ванили существуют до сих пор. Конечно, в сильно уменьшенном виде в сравнении с 10 годами ранее, но отнюдь не до полного нуля. Можно, конечно, обвеситься полифилами с ног до головы, но это просто заход с другой стороны, а проблема есть.
Кстати, часто случается смешная ситуация, когда люди используют jQuery сами того не зная :) Например, подрубают какой-нибудь vue-slick и думают, что они такие модные и всех обманули. А оно само через зависимости притянулось. Чесслово, это реальные случаи, не придумываю.
Atomic-CSS на стероидах? Концепия известная, все плюсы (порог вхождения) и минусы (говнокод) давно перетёрты. Подходит в случае если проект небольшой, несложный и с кратким жизненным циклом. То есть примерно: нужно быстро нафигачить небольшой лендосик, а потом через некоторое время мы его просто выбросим, а вопросы поддержки нас не парят от слова совсем. Во всех остальных случаях отказать.
Я понимаю, что кем-то эти понятия могут смешиваться. Но я так же понимаю, что существуют ситуации, когда термины не эквивалентны и разница между ними важна. Да, в наши дни.
Пример из разговора разработчиков: "Этот блок сделай просто резиновым, адаптировать не надо". И все всё понимают за секунду.
Получается, вместо этого я должен сказать "Этот блок адаптируй, только не в общем смысле с перестройкой лейаута, а в частном смысле без перестройки"? Я должен ломать мозг себе и другим только потому, что кому-то не понравилось слово, правильно?
Vaultboy84, это не моё личное мнение, а факт. Такое понятие есть во всём в мире, только называется иначе - на Западе это называют fluid layout в противовес fixed/static layout. Ну а у нас устоялось слово "резиновый". Просто вот так терминология исторически сложилась - совершенно обычная история.
Это было в начале нулевых, когда никакими адаптивами и респонсивами в вебе ещё и не пахло, потому что тогдашний CSS этого не умел в принципе. Тогда шло противостояние между фиксированными и просто тянущимися страницами. И был дискусс на эту тему, были свои сторонники со своими доводами за и против. Да, сегодня это кажется нелепым, но тогда действительно были и сторонники фиксированных страниц. Не помните? Судя по числу 84 теоретически могли застать, хотя сомневаюсь.
Если совсем уж вдаваться в историю, были еще термины liquid или elastic. И даже выходили статьи, которые объясняли, что это не совсем синонимы, и что есть какие-то мелкие нюансы-отличия. Но даже тогда эти различия почти никто не понимал и слова употреблялись как синонимы, а уж сегодня тех нюансов тем более уже никто не помнит.
Кстати, Лебедев вопреки его утверждениям не был первооткрывателем данного принципа. Но действительно много сделал для его развития и популяризации, тут не поспоришь.
Тут можно возразить - к чему ты всё это рассказываешь в 2019 году, кому это теперь нужно?
К тому, что термин "резиновая верстка" всё равно жив и применяется. Целые страницы без отзывчивости действительно уже почти немыслимы (хотя и там бывают исключения), а вот на уровне блоков нередко используется именно резиновая верстка, то есть просто механически растягиваемая.
В общем, термин жив, и не нужно пытаться его отменить или замылить.
Нет.
Резина и адаптив не одно и то же, и разница между ними совершенно понятна. Резина - тупо растягиваем, адаптив - тянем и перестраиваем лейаут.
Вот понятия адаптива и респонсива действительно смешались и де-факто стали синонимами, хотя изначально там тоже были отличия.
1. Дело даже не в том, понимают ли браузеры колор-менеджмент, то есть умеют ли взаимодействовать с профилями устройств и картинок (современные в большинстве умеют, хоть и с некоторыми оговорками). Главное то, что если мы говорим о вебе, то по спецификациям W3C/WHATWG пространство sRGB - единственное стандартное пространство для веба. Все цвета, указанные в коде, подразумеваются только в нём.
Apple сейчас продвигает свои предложения по расширению стандартов:
Но это ещё не стандартизировано и поддержка пока не очень.
И кроме того там всё равно нельзя писать цвета в произвольном профиле, только ограниченный список стандартных: MDN
2. Профиль sRGB лучше наоборот НЕ внедрять, а просто конвертировать в него. Потому что для веба sRGB это стандартное пространство и по умолчанию в вебе всегда подразумевается именно оно. Даже если условный Safari на iMac умеет в P3, но получая картинку без внедренного профиля, он обязан интерпретировать её как sRGB. Но без профиля меньше вероятность словить проблемы на какой-нибудь старой системе, не понимающей или некорректно понимающей профили.
Araya, дело в том, что знать фреймворки и быть хорошим верстальщиком - это мягко говоря не синонимы. Абсолютное большинство людей, которые называют себя верстальщиками и фронтэндерами - верстают очень плохо.
Люди думают, что едва узнав список html-тэгов и css-свойств, они автоматически получают ачивку "верстальщик" и сразу же спешат "развиваться дальше". Но на самом деле верстать они не умеют.
Например пришел я в автосалон и попросил менеджера подобрать мне авто.
Какой же ты упертый. Забудь про готовые продукты, это совершенно другое ценообразование. Нужно сравнивать с ситуацией, когда нужно разработать автомобиль.
Вы спорите ни о чем. И приводимые примеры - левые. Потому что вы путаете продажу стандартного товара/услуги с кастомной разработкой нечта в условиях неопределенности.
Если электрик пришел на объект, то сколько бы там розеток и кабеля ни было - их можно сосчитать, потому что у задачи есть понятные рамки в виде здания (готового или нарисованного в проекте). Поэтому тут цена выставляется без проблем. Баня тоже имеет некие рамки, как минимум по числу квадратных метров выделенного пятака на участке.
А кастомная разработка сайта очень часто поначалу не имеет вообще никаких четких рамок - есть только кучка расплывчатых хотелок и отсылок типа "а вот я видел в интернете такое..." Такая разработка, если её не ограничить, зайдет в никуда. Бюджет - одно из важных ограничений.
Я сейчас перечитал вопрос автора и понял, что он сформулирован расплывчато, и каждый может понять его по своему. Объясню подробнее, в каких случах спрашивать бюджет можно и нужно.
Неважно, фриланс у нас или не фриланс. Важно, насколько задача конкретна или, напротив, расплывчата.
Поменять розетку - это очень конкретная задача, её цена в зависимости от подробностей меняется в довольно ограниченных пределах. Исполнитель задаст несколько уточняющих вопросов и без проблем выставит конкретную оценку.
Теперь представим, что заказчик приходит с задачей "построить дом". Это очень нечёткая задача. Какой дом? Их может быть миллион вариантов с разбегом по цене в несколько порядков. В этом случае вопрос о бюджете - это не обязательно признак деньгоотсоса. Это попытка исполнителя сориентироваться, в какой сегмент рынка смотреть, что предлагать клиенту и какие обозначить клиенту ограничения.
Теперь ситуация из IT и личной практики. Клиент говорит, что он торгует такими-то товарами и ему нужен сайт. Какой сайт?! Лендос-визитка или полноценный магазин с полной обработкой заказа и интеграцией с 1С?! Сложность, стоимость и сроки этих вариантов различаются многократно. А клиент поначалу и сам не знает. Точнее, он хочет всё и сразу, но совершенно не понимает, во что ему это обойдется. В этой ситуации спросить ориентировочный бюджет, на который рассчитывают - это нормально.
Разумеется, если клиент четко понимает, чего хочет, данный подход не работает. Но таких мало.
