это несколько разнится с вашим ответом. Опять же. Кому верить?) я склонен считать что пора использовать this. Даже в курсе от CodeSchool, который проспонсировали Google, испольуется this вместо $scope.
Я работу работаю, как и большинство хабражителей, как я думаю. Выпускаю в год около 20 проектов как фрилансер или через ИП + множество доработок готовых сайтов, но у меня есть время почитать про новый фреймворк, увидеть его плюсы и применить в следующем проекте, предложить заказчику новые возможности для его проекта, объяснить почему ООП верстка лучше макаронной, изучить и проверить в работе паттерны проектирования, попробовать разработать сайт на другом языке (Python, Ruby) зная требования по безопасности / скорости / особенности проекта.
Только я обычный человек, который любит свою работу, ничем не выделяющийся среди тысяч разработчиков, и мне не понятно, почему большая часть рынка считает что заказчику достаточно продать битрикс и левой пяткой «натянуть шаблон» без юнит тестов, без вникания в бизнес / наполнение и прочие моменты,
Когда интеграция дизайна в систему выглядит так, будто ее делала шимпанзе два дня изучающая язык программирования, а заказчика все устраивает и он обвиняет тебя а криворукости, мировоззрение подкашивается.
Или когда разработчик с 10ти летнем стажем не может разобрать код на ангуляр.
Сам я фулл-стак разработчик. Не претендую на идеальные знания в каждой конкретной области, но то что мне попадает на доработку, никак кроме как хламом назвать нельзя.
Читаю подобные статьи часто, все нравится, пытаюсь забрать себе как можно больше рекомендаций, но когда сталкиваюсь с реалиями рынка веб разработки в России, мне становится грустно. Никому не нужны тесты, спецификации и проектирование.
Менеджеры хотят сдать проект, получить денег и как можно меньше заплатить разработчику.
Заказчики отличаются от первых только желанием заработать в сети за чужой счет.
Разработчики (процентов 90) вообще не знают предметной области, и работать с ними или дорабатывать после них невозможно.
Мне иногда начинает казаться, что это со мной что-то не так, но после каждой такой статьи понимаю, что нет.
Я лишь сравнил «оригинальный CSS» и CSS из фреймворка. Если выбирать из этих двух вещей, то лучше уж систематизированный но не доработанный фреймворк, чем pure css. В случае с фреймворком, любым (а так же любым его форком или собственной наработкой), править и модифицировать проект будет проще, нежели простыню из чистого CSS.
Я тут сделал несколько проектов подряд на бутстрапе, а потом мне заказали сверстать лендинг для уже готового сайта с готовой шапкой и половиной готовых стилей, это был ад… я увидел что люди до сих пор используют контекст идентификаторов в составных селекторах в качестве стилизации, ну и в 2014 году больше половины населения не слышали про box-sizing: border-box, который приятнее и проще, из-за этого бутстрап подключить было нельзя, пришлось пилить свою систему внутри этого хаоса, я уже разучился верстать не объектно, или без применения инкапсуляции внутри css.
В итоге получилось не идеально, но это лучше чем то что было на проекте.
В написании своего bootstrap, кстати, нет ничего плохого, лишь бы кроссбраузерный. Это будет на много лучше чем безсистемные велосипеды в css. А то потом править чужие стили без какой либо системы — ужасно, а поддержка такого проекта может превратиться в ад.
С учетом выше сказанного, а так же использование исключительно jQuery. Могу догадываться только что тег script лежит сразу после каждой секции.
jQuery может выполняться синхронно только в том случае, если dom уже загружен (или по крайней мере необходимый элемент). В противном случае вызывается callback после ready или load.
Я понял в чем дело. Мы с вами на разных языках говорим. Для меня использование стилей повторно — это их использование в разметке, а хранение стилей на клиенте это браузерный кэш, для Вас, видимо, все по другому. Ну да ладно.
Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса. С другой стороны всегда есть минификация «на лету».
Вы говорили о настоящем времени, а теперь про тенденцию развития. Это разные вещи.
Да, когда тысячи разработчиков переучатся с Flash на что-то другое и старые браузеры канут в лету (меньше 1%) — ваша фраза про неактуальность Flash станет актуальной.
Не вижу никакого смысла применять сейчас Flash (Вы обратное доказать не можете), никогда не видел задачи, с которой не может справиться HTML5, а Flash может (я говорю про реальные задачи, которые продаются на рынке веб-разработки). К тому же, я не видел в профессиональной разработке «тысячи разработчиков», которые создают сайты на Flash и тем более в портфолио у таких людей Flash не значится.
На мой взгляд, Flash это такая же заноза, как и верстка через ID. Сотни компаний по всей России (причем из топ-10 в РР) продают каждый год по два десятка сайтов сверстанных по ID и без компонентной структуры, код, который невозможно поддерживать (не говоря уже про серверную часть). То же самое и с Flash сайтами и плагинами. И что теперь? Будем считать что не компонентная верстка через контекст идентификаторов это хорошо, потому что 90% специалистов так делают, или будем считать что Flash все еще актуален потому что люди учились на нем работать? Я знаю специалистов которые до сих пор таблицами верстают и на div переходить не собираются. Их тоже припишем к актуальным или нет?
Я другой вопрос задавала. И Flash пока еще как актуален, несмотря на вышеперечисленные технологии.
Приведите пример пожалуйста.
На мой взгляд тенденция развития веба сильно разнится с Flash-технологиями, из-за чего он и теряет актуальность.
Прощай повторное использование стилей?
Почему же? Что мешает использовать стили повторно, изменив метод их загрузки на страницу? Проанализировав код главной страницы google, я сделал вывод, что именно так они и делают.
Очень не красиво строить веб-приложение, интерфейс которого зависит от JS. Хорошей практикой и хорошим тоном считается разрабатывать рабочее приложение и для устройств с выключенным JS. Если же с выключенным JS Ваше приложение разъезжается в разные стороны — это плохо, в конце концов клиент может что то не отработать в 1 случае из 100.
CSS пока не умеет загружаться асинхронно с DOM. Когда браузер встречает тег link, он начинает загрузку CSS с отдельным HTTP запросом к серверу, прерывая загрузку оставшейся страницы. Получается что, чем больше файлов подключено в head, тем больше запросов на сервер, тем больше скорость приложения зависит от сервера. Это, конечно, в нынешнем мир, измеряется милисекундами, но все же полезно, особенно когда файлов много.
Едва ли загруженная картинка важнее работающей вкладки?
JavaScript можно всегда опустить в самый низ, особенно если он работает по событию ready(). А вот CSS опускать в самый низ по моему бредово. На секунду (или больше, если пропускная способность канала у пользователя не высокая), пользователь видит «голый» html, без стилизации. Возможно имело бы смысл дать рекомендацию вынести весь CSS, кроме основной разметки макета, в нижнюю часть страницы, да только никто так не будет делать.
Как Google поймет, что есть замена? Какой нужно код конкретно написать?
Flash уже не актуален. Есть CSS3 / WebGL / Canvas. Они меньше весят и легче внедряются.
Абсолютно не согласен с автором. В сети достаточно много трудов от опытных фронт-енд разработчиков которые описывают Модульный / Компонентный / Объектно-ориентированный CSS, да тот же БЭМ, разрабатываемый для многократного повторения.
Совершенно никуда не годится. Если так верстать, то конечно может показаться что фреймворки это плохо.
Я часто полагаюсь на theme классы и наследование, а ваш пример трещит от helper-классов и модификаторов. Такой винегрет даже писать не хочется, не то что поддерживать. Но да ладно. Я не об этом.
В современной веб разработке такие понятия как минификация уже стали нормой, по этому говорить о количестве строк кода в фреймворках бессмысленно. Всегда в порядочном проекте есть dev и build (min) версии, по одной идет разработка, а другая компилируется в продакшн и их размеры ничтожно малы.
Ту концепцию, что предлагаете Вы будет сложнее поддерживать чем БЭМ, просто потому что декларирование в HTML-шаблонах задача куда более простая, нежели «алхимия в css» (С) Николас Галлахер.
Завязывая оформление сайта на составных селекторах Вы будете зависимы от четкой HTML структуры, которая никогда не изменяется. Это приведет к большей шаблонности, которую Вы, как говорите, пытаетесь избежать, не говоря уже про селекцию по тегам и скорость рендеринга браузером такого сайта. Компонентная структура бутстрапа или другого CSS фреймворка как раз завязана на том чтобы использовать компонент или элемент в любом месте в разметке. Компонент / элемент в бутстрапе это виджет в готовом проекте. Вы сможете создать файл с виджетом и архитектуру подключения виджетов, в параметрах которой передавать темы и модификаторы для конкретного виджета. Весь код можно будет разбить на отдельные сущности и шаблоны, чего нельзя будет сделать при фреймворке завязанном на CSS.
Чтобы избавится от кучи модификаторов и хэлперов для элемента следует рассмотреть изменение этого самого элемента в контексте других компонентов. Например тот же btn будет выглядеть всегда так и так, а если он находится в контексте thumbnail или navbar, то его вид немного изменяется. Так же можно оперировать и темами. Если кнопка располагается внутри navbar-default она имеет одни свойства а внутри navbar-inverse уже другие.
Вы рассуждаете в статье о CSS3 и о том какие возможности он предоставляет. Сестринские селекторы, :nth-child. Да все верно. Эти возможности прекрасны, но их потенциал раскрывается не тогда когда вы верстаете постранично, а когда верстка идет покомпонентно. Приведу пример:
Мне недавно попались два, на первый взгляд, не плохих сайта на переоформление и поддержку. Во время переоформления я столкнулся с тем что разрабочтики завязали весь сайт на контекстных селектоорах. То есть просто btn я бы никогда не создал, а свойства обтекания каждый раз применяются заново и заново к новым элементам, без использования хэлперов. Таким образом любое изменение в структуре рушило весь сайт. А для изменение стилей для одной и той же кнопки в списке товаров / в карточке товара / в списке акций приходилось искать три различных селектора в CSS. Для того чтобы повторить какую то часть верстки, мне приходилось копировать имеющиеся стили в новый контекст, что раздувало CSS до ужасных размеров. Если бы разработчики создали компоненты, вместо постраничной верстки, такие компоненты которые можно было воспроизвести на абсолютно пустой странице, то даже изменения в CSS были бы менее болезненными. При этом не обязательно пользоваться бутстрапом, но не закладывать изначально возможности развития и кастомизации в проект это зло, которое потихоньку исторгается.
Да раньше была табличная верстка, я помню свои первый табличные сайты и первый скрипты еще до появления jQ и им подобных и это было ужасно скажу я Вам. Блочная верстка долгая время была под конекстом идентификаторов, и казалось что контентс ID создает как бы компонент на странице. Дальше пошли классы но проблема осталась та же. И то что Вы описываете в статье как раз такие прошлые подходы с новыми инструментами, а не наоборот.
Правило работает только на картинки из директории /upload/iblock/.
Битрикс?
Если так, то почему не воспользовались стандартным методом CFile::ResizeImageGet()? Он вам и картинку создаст нужных размеров и сам ее найдет при втором обращении, а при обновлении оригинала обновит и измененные изображения при новых обращениях.
это несколько разнится с вашим ответом. Опять же. Кому верить?) я склонен считать что пора использовать this. Даже в курсе от CodeSchool, который проспонсировали Google, испольуется this вместо $scope.
Кому верить.
Извиняюсь за два сообщения, писал с мобильного.
Только я обычный человек, который любит свою работу, ничем не выделяющийся среди тысяч разработчиков, и мне не понятно, почему большая часть рынка считает что заказчику достаточно продать битрикс и левой пяткой «натянуть шаблон» без юнит тестов, без вникания в бизнес / наполнение и прочие моменты,
Или когда разработчик с 10ти летнем стажем не может разобрать код на ангуляр.
Сам я фулл-стак разработчик. Не претендую на идеальные знания в каждой конкретной области, но то что мне попадает на доработку, никак кроме как хламом назвать нельзя.
Менеджеры хотят сдать проект, получить денег и как можно меньше заплатить разработчику.
Заказчики отличаются от первых только желанием заработать в сети за чужой счет.
Разработчики (процентов 90) вообще не знают предметной области, и работать с ними или дорабатывать после них невозможно.
Мне иногда начинает казаться, что это со мной что-то не так, но после каждой такой статьи понимаю, что нет.
Я тут сделал несколько проектов подряд на бутстрапе, а потом мне заказали сверстать лендинг для уже готового сайта с готовой шапкой и половиной готовых стилей, это был ад… я увидел что люди до сих пор используют контекст идентификаторов в составных селекторах в качестве стилизации, ну и в 2014 году больше половины населения не слышали про box-sizing: border-box, который приятнее и проще, из-за этого бутстрап подключить было нельзя, пришлось пилить свою систему внутри этого хаоса, я уже разучился верстать не объектно, или без применения инкапсуляции внутри css.
В итоге получилось не идеально, но это лучше чем то что было на проекте.
С учетом выше сказанного, а так же использование исключительно jQuery. Могу догадываться только что тег script лежит сразу после каждой секции.
jQuery может выполняться синхронно только в том случае, если dom уже загружен (или по крайней мере необходимый элемент). В противном случае вызывается callback после ready или load.
Действительно при импорте стилей в тег style последующие хиты будут работать помедленнее, чем при подходе с файлами и это не даст общей оптимизации ресурса. С другой стороны всегда есть минификация «на лету».
Не вижу никакого смысла применять сейчас Flash (Вы обратное доказать не можете), никогда не видел задачи, с которой не может справиться HTML5, а Flash может (я говорю про реальные задачи, которые продаются на рынке веб-разработки). К тому же, я не видел в профессиональной разработке «тысячи разработчиков», которые создают сайты на Flash и тем более в портфолио у таких людей Flash не значится.
На мой взгляд, Flash это такая же заноза, как и верстка через ID. Сотни компаний по всей России (причем из топ-10 в РР) продают каждый год по два десятка сайтов сверстанных по ID и без компонентной структуры, код, который невозможно поддерживать (не говоря уже про серверную часть). То же самое и с Flash сайтами и плагинами. И что теперь? Будем считать что не компонентная верстка через контекст идентификаторов это хорошо, потому что 90% специалистов так делают, или будем считать что Flash все еще актуален потому что люди учились на нем работать? Я знаю специалистов которые до сих пор таблицами верстают и на div переходить не собираются. Их тоже припишем к актуальным или нет?
Приведите пример пожалуйста.
На мой взгляд тенденция развития веба сильно разнится с Flash-технологиями, из-за чего он и теряет актуальность.
Почему же? Что мешает использовать стили повторно, изменив метод их загрузки на страницу? Проанализировав код главной страницы google, я сделал вывод, что именно так они и делают.
Очень не красиво строить веб-приложение, интерфейс которого зависит от JS. Хорошей практикой и хорошим тоном считается разрабатывать рабочее приложение и для устройств с выключенным JS. Если же с выключенным JS Ваше приложение разъезжается в разные стороны — это плохо, в конце концов клиент может что то не отработать в 1 случае из 100.
JavaScript можно всегда опустить в самый низ, особенно если он работает по событию ready(). А вот CSS опускать в самый низ по моему бредово. На секунду (или больше, если пропускная способность канала у пользователя не высокая), пользователь видит «голый» html, без стилизации. Возможно имело бы смысл дать рекомендацию вынести весь CSS, кроме основной разметки макета, в нижнюю часть страницы, да только никто так не будет делать.
Flash уже не актуален. Есть CSS3 / WebGL / Canvas. Они меньше весят и легче внедряются.
p.s. developers.google.com/speed/pagespeed/insights/?hl=ru&utm_source=blogspot&utm_campaign=mobile_ux&url=google.ru&tab=mobile
p.s. появилась мысль на счет CSS. Во время исполнения серверного кода, можно импортировать CSS в тег style напрямую в head. Тогда не будет ругаться
Ваш пример
Совершенно никуда не годится. Если так верстать, то конечно может показаться что фреймворки это плохо.
Я часто полагаюсь на theme классы и наследование, а ваш пример трещит от helper-классов и модификаторов. Такой винегрет даже писать не хочется, не то что поддерживать. Но да ладно. Я не об этом.
В современной веб разработке такие понятия как минификация уже стали нормой, по этому говорить о количестве строк кода в фреймворках бессмысленно. Всегда в порядочном проекте есть dev и build (min) версии, по одной идет разработка, а другая компилируется в продакшн и их размеры ничтожно малы.
Ту концепцию, что предлагаете Вы будет сложнее поддерживать чем БЭМ, просто потому что декларирование в HTML-шаблонах задача куда более простая, нежели «алхимия в css» (С) Николас Галлахер.
Завязывая оформление сайта на составных селекторах Вы будете зависимы от четкой HTML структуры, которая никогда не изменяется. Это приведет к большей шаблонности, которую Вы, как говорите, пытаетесь избежать, не говоря уже про селекцию по тегам и скорость рендеринга браузером такого сайта. Компонентная структура бутстрапа или другого CSS фреймворка как раз завязана на том чтобы использовать компонент или элемент в любом месте в разметке. Компонент / элемент в бутстрапе это виджет в готовом проекте. Вы сможете создать файл с виджетом и архитектуру подключения виджетов, в параметрах которой передавать темы и модификаторы для конкретного виджета. Весь код можно будет разбить на отдельные сущности и шаблоны, чего нельзя будет сделать при фреймворке завязанном на CSS.
Чтобы избавится от кучи модификаторов и хэлперов для элемента следует рассмотреть изменение этого самого элемента в контексте других компонентов. Например тот же btn будет выглядеть всегда так и так, а если он находится в контексте thumbnail или navbar, то его вид немного изменяется. Так же можно оперировать и темами. Если кнопка располагается внутри navbar-default она имеет одни свойства а внутри navbar-inverse уже другие.
Вы рассуждаете в статье о CSS3 и о том какие возможности он предоставляет. Сестринские селекторы, :nth-child. Да все верно. Эти возможности прекрасны, но их потенциал раскрывается не тогда когда вы верстаете постранично, а когда верстка идет покомпонентно. Приведу пример:
Мне недавно попались два, на первый взгляд, не плохих сайта на переоформление и поддержку. Во время переоформления я столкнулся с тем что разрабочтики завязали весь сайт на контекстных селектоорах. То есть просто btn я бы никогда не создал, а свойства обтекания каждый раз применяются заново и заново к новым элементам, без использования хэлперов. Таким образом любое изменение в структуре рушило весь сайт. А для изменение стилей для одной и той же кнопки в списке товаров / в карточке товара / в списке акций приходилось искать три различных селектора в CSS. Для того чтобы повторить какую то часть верстки, мне приходилось копировать имеющиеся стили в новый контекст, что раздувало CSS до ужасных размеров. Если бы разработчики создали компоненты, вместо постраничной верстки, такие компоненты которые можно было воспроизвести на абсолютно пустой странице, то даже изменения в CSS были бы менее болезненными. При этом не обязательно пользоваться бутстрапом, но не закладывать изначально возможности развития и кастомизации в проект это зло, которое потихоньку исторгается.
Да раньше была табличная верстка, я помню свои первый табличные сайты и первый скрипты еще до появления jQ и им подобных и это было ужасно скажу я Вам. Блочная верстка долгая время была под конекстом идентификаторов, и казалось что контентс ID создает как бы компонент на странице. Дальше пошли классы но проблема осталась та же. И то что Вы описываете в статье как раз такие прошлые подходы с новыми инструментами, а не наоборот.
Битрикс?
Если так, то почему не воспользовались стандартным методом CFile::ResizeImageGet()? Он вам и картинку создаст нужных размеров и сам ее найдет при втором обращении, а при обновлении оригинала обновит и измененные изображения при новых обращениях.