• Как делать livereload проекта на php?

    @Froggyweb
    Сделать сборку на gulp
    Использовать browsersync для релоада https://webdesign-master.ru/blog/tools/601.html
    Ответ написан
    Комментировать
  • Как делать livereload проекта на php?

    DevMan
    @DevMan
    VSCode не релоадит, prepross не релоадит.
    про vsc не в курсе, а препрос и древнючий лайврелоад у меня спокойно релоадят.

    может есть что-тотипа хтмл-инклюда?
    любой вменяемый шаблонизатор под пых поддерживает инклюды.
    Ответ написан
    9 комментариев
  • Стоит ли использовать препроцессор отличный от SCSS?

    sim3x
    @sim3x
    1 Итого, реально есть 3 препроцессора. Везде в интернетах, где обсуждают препроцессоры, говорят только о трех. В последнее время добавляется еще обработчик postCSS
    Знаете ли вы еще какие-то варианты цсс препроцессоров кроме перечисленных, на которые стоило бы обратить внимание и потратить время? Используете ли что-то кроме...sass?
    Пока у других препроцессоров нет с/с++ либы, альтернативы сасс/сцсс нет.

    2 Почему, раз всё началось с DRY, все равно вернулись к обычному цсс "избыточному" синтаксису? Ведь ни sass ни stylus, при прочих равных плюшках, но с простым чистым синтаксисом, не стали столь же популярными, как scss и less, которым нужны скобки, кавычки и точки с запятой.
    вкусовщина

    3 почему сасс выиграл гонку у лесс(даже бутстрап пересел на сасс в 4й версии), тогда как препроцессинг немного более муторный, чем просто возможность подключить жаваскрипт, и отдавать как есть на клиента?
    libsass

    4 Почему такой крутой стайлус, где больше плюшек от "настоящего языка программирования", и даже свои фреймворки есть, вообще где-то на задворках по проценту его использования? Даже Koala не может его компилировать. И в VS Studio live reload с ним не работает(впрочем, с Sass тоже, хотя с scss работает)
    PR + совместимость

    5 Есть ли вообще смысл использовать Stylus? Или забить, и пользовать сцсс, как все?
    для души - я б посоветовал попробовать css-in-js. Где-то в том направлении находится веб будущего и будущий делфи

    6 интересная статья 2018года, задающаяся вопросом нужны ли сейчас препроцессоры, или можно обойтись нативными средствами цсс, которые пытаются реализовать преимущества препроцессоров(математические выражения, переменные, вложенность, миксины). Приходит ко мнению что препроцессоры скорее еще нужны. А в комментах даю ссылки на статьи, где знатные верстуны рассказывают почему не пользуют препроцессоры.
    верстуны, которые в состоянии за вечер накидать костяк юи кита и превратить его в фреймворк могут писать на чем угодно

    7 Но есть мнение, что достаточно просто писать ванильный цсс, и отдавать постпроцессору. Я не улавливаю чем постпроцессор может заменить препроцессор. Вот почему некто может отказаться от sass и перейти только на postcss?
    постцсс просто название. Оно ничего не означает и не обязует автора
    Если у вас есть куча времени на сборку вашего кода, то данный препроцессор - ваш выбор
    Ответ написан
    4 комментария
  • Стоит ли использовать препроцессор отличный от SCSS?

    Sanes
    @Sanes
    Думаю LESS вам будет достаточно, если задаётесь таким вопросом. Тот же Uikit3 написан на LESS и SASS. Фреймворк там покруче бутстрапа будет.
    Ответ написан
    31 комментарий
  • Стоит ли использовать препроцессор отличный от SCSS?

    delphinpro
    @delphinpro Куратор тега CSS
    frontend developer
    О, мой любимый холиварчик! =))

    Начнем с indent vs brackets. Код с отступами лаконичен, по-своему красив, но обладает фатальным недостатком — его нельзя просто так взять и скопипастить из одного места в другое. Отступы обязательно нарушатся, IDE не поймёт и всё развалится. Нужно вручную поправлять, чтобы все встало на свои места. Также в процессе рефакторинга нарушаются отступы и появляется геморр. Второй серьёзный недостаток — это несовместимость с native css. Нельзя взять кусок css кода из интернетов и вставить в свой файл, его нужно вручную (или онлайн конвертером) переформатировать под нужный синтаксис. Всё это лишние телодвижения, лишние сложности, трата времени. Поэтому только скобки. Благо скобочный синтаксис поддерживается во всех трех препроцессорах.

    В пункте 3 вы ерунду написали. Никто в серьезном проекте не будет подключать браузерный компилятор стилей. Даже при использовании less стили все равно обрабатываются заранее и на продакшн выкладывается готовый css файл.
    Так что это преимущество less не стоит брать во внимание от слова "вообще".

    [Написанное в следующем абзаце, исключительно моё мнение, а не общепризнанные факты]
    Почему же sass выигрывает? Во-первых, это достаточно мощный препроцессор, с огромным количеством возможностей. Во-вторых, и я думаю, это главное, он единственный, компилятор которого написан на "С" -> скорость работы. Другие два написаны на javascript. И в-третьих, исторически так сложилось. Стайлус крутой препроцессор, но он появился много позже остальных и возможно, еще не успел набрать популярность.

    В свою очередь у scss есть свои серьёзные недостатки.
    Первый — невозможно в scss/sass файл импортировать обычный css, он не будет включен файл, а будет заменен css-импортом. В других препроцессорах имеются специальные синтаксические конструкции для этого.
    Второй — отсутствие резолвинга путей, что другими так же предоставляется "из коробки". Приходится извращаться с прописыванием путей к картинкам. Проблема нивелируется при использовании вэбпака, но ведь не всегда он используется.

    Что касается меня, то я готов мирится с этими двумя недостатками sass. Остальные возможности их с лихвой перекрывают.
    На чем вам остановиться,я советовать не буду. Я свободно работаю со всеми тремя инструментами, но новые проекты всегда начинаю с использованием scss.
    Ответ написан
    4 комментария
  • Стоит ли использовать препроцессор отличный от SCSS?

    Faustlogger
    @Faustlogger
    Front-end developer
    В разное время пользовался SASS - > SCSS - > Less - > PostCSS - >SCSS. Мой личный опыт подсказывает что лучше PostCSS на данный момент ничего нет.

    В чем его преимущество - ты пишешь CSS с JS примесями, которые приносят нужный тебе функционал. Ты можешь сконфигурировать процессор (я не оговорился, постпроцессором он уже не является) под себя. Работает в разы быстрее, поддерживает css-модули. Если чего-то не хватает, берёшь и сам дописываешь. Оч сильный механизм плагинов и функций.

    Недостатков вижу два - игнор инструмента разработчиками CLI (привет команде ангуляр-кли ума которых хватило только на использование автопрефиксера) и игнор со стороны JetBrains, которые не смогли разводиться на адекватную поддержку данной тулзы. Теперь я благополучно пересел с IDEA на vsc.

    Вывод : SCSS - хорош и достаточен, SASS - ruby on rails only, Less - пожалуй уже не актуален, PostCSS - все же немного лучше SCSS и предлагает иной и более удобный механизм работы с CSS (рекомендую его попробовать после изучения scss).

    P. S. Сугубо моё мнение исходя из опыта, не навязываю. Холиварить глупо
    Ответ написан
    Комментировать
  • Стоит ли использовать препроцессор отличный от SCSS?

    gobananas
    @gobananas
    finishhim.ru
    Думаю не стоит. Посмотреть можно. Серьёзно применять в работе вы всё равно будете только один из них, а значит зачем тратить много времени.
    Ответ написан
    1 комментарий
  • Стоит ли использовать препроцессор отличный от SCSS?

    webinar
    @webinar
    Учим yii: https://youtu.be/-WRMlGHLgRg
    1. scss, less
    2. ниже порог входа = больше популярность = больше востребованность
    3. тема отдельной статьи и их уже миллион
    4. порог входа
    5. дело вкуса. Если он Вам удобнее - используйте его
    6. Есть проекты где нет смысла, есть где есть смысл. Есть староверы, которые принципиально пишут на css. Есть амиши, может от них взять больше, тогда вообще вопрос отпадет. Вы пытаетесь найти идеальное решение - его нет. Было бы - не было бы других.
    7. Нельзя решать такие вещи оторвано от проекта. В конкретном проекте может быть оправданным тот или иной метод. В абстрактом они равнозначны. Дело вкуса.
    Ответ написан
    Комментировать
  • Стоит ли использовать препроцессор отличный от SCSS?

    dom1n1k
    @dom1n1k
    Использую Less и Scss.
    Scss мощнее, но некоторые аспекты языка реализованы на удивление коряво.
    Less более ограничен по возможностям, но имхо на типовом коде удобнее и для небольших проектов его почти всегда достаточно.

    Почему, раз всё началось с DRY, все равно вернулись к обычному цсс "избыточному" синтаксису?
    Про синтаксис на отступах я всегда говорил и говорю - он смотрится круто и чистенько на маленьких стерильных примерах, но в реальном большом проекте читается хуже, чем код с нормальными скобками.

    тогда как препроцессинг немного более муторный, чем просто возможность подключить жаваскрипт, и отдавать как есть на клиента?
    Компиляция less-стилей на клиенте - это фича сугубо для разработки! На продакшене про неё нужно забыть, совсем и напрочь.

    Есть ли вообще смысл использовать Stylus?
    При соблюдении нескольких условий: продуктовая разработка, сильная команда, увидели для себя конкретную пользу в каких-то фичах - можно. Иначе (заказная разработка, джуны, выбор не-мейнстримного инструмента без конкретных причин, а просто оригинальности ради или потому что кто-то где-то написал, что он крут) - однозначно нет.
    Ответ написан
    Комментировать
  • Стоит ли использовать препроцессор отличный от SCSS?

    DevMan
    @DevMan
    1. не знаю. пользую sass и less.
    2. потому же почему люди не пришли к эсперанто/аналогам (можно привести еще множество аналогий): они, в большинстве своем - ленивые жопы.
    3. потому что даже с лесс мало кто пользует жабаскрипт для его трансляции, компилируют в нативный css.
    4. смотреть п. 2. плюс в наше время достаточно сложно/невозможно взлететь без активного маркетинга.
    5. конечно есть, если он устраивает больше других. меня вообще убивают подобные вопросы, типа учить css-препроцессор нужно годами.
    6. нужны. по крайней мере пока ванильный цсс не покрывает хотя бы большую часть функционала препроцов.
    7. можно конечно. если вам не лень учить жабаскрипт/учить ему верстальщиков и писать правила под него.

    учить или не учить что-то, использовать или не использовать что-то - это выбор каждого конкретного человека и окружения, в котором он работает. даже, если большинство вокруг считает иначе.
    Ответ написан
    2 комментария
  • Как выглядит современный процесс верстки?

    IT_Highlander
    @IT_Highlander
    Пробовал множество разных вариантов верстки, от самого "ручного" до webpack или gulp. В итоге понял, что если сайт не SPA, а просто лендинг или корпоративный многостраничник, то идеальным по скорости подготовки и удобству лично для меня является алгоритм:
    1. Папка обычной структуры index.html + /img + /css + /js + /fonts + /sass .
    2. Сразу инициализирую репозиторий (использую битбакет, а не гитхаб).
    3. Открываю папку в VSCode, копирую настройки из любого другого проекта для плагинов.
    3.1. Если только начинаем использовать VSCode, то нужно сразу поставить плагин для автокомпиляции Sass в CSS в онлайн режиме (Live Sass Compiler), этот плагин на лету конвертит код + сразу автопрефиксера функционал имеет + css map + минификация. Один раз настраиваем его для всех проектов.
    3.2. Ставим Live Server, один раз настраиваем его для всех проектов.
    3.3. Подключаем репозиторий во вкладке для репозиториев в VSCode
    4. Всё, начинаем работать.
    Я пропускаю шаг по настройке VSCode всякими мелочами типа линтеров, подсвечивалок кода, и прочего, тут кому что удобнее.

    Такая связка позволяет использовать один инструмент (VSCode) для комфортной и быстрой верстки, если все в норме настроено, то я пишу\правлю код и тут же сразу всё вижу в браузере, не нужно ни обновлять ничего не подтягивать, ни ставить плагины в браузеры. Sass использую давно, ИМХО, ускоряет написание стилей в разы, и это при том, что не использую обычно даже миксины, максимум иногда готовые куски кода, а так обычно только дерево делаю через &, чтобы не писать по BEMу длиннющие цепочки руками и переменные через $.

    Если идем дальше и уже верстку натягиваем куда-то, то добавляется еще и OpenServer, и все файлы переносятся в локальную папку виртуального сайта, перебиваются пути и все происходит точно также.
    Изображения оптимизирую руками, не знаю почему, привычнее и быстрее, обычным tinypng или встроенными PageSpeedIns инструментами.

    WebPack и Gulp много раз пробовал, и через OptimizeHTML, о котором выше писали, но не зашли на простых и средних проектах, слишком много всего нужно настраивать и подключать постоянно, что-то отваливается или криво работает, постоянно отвлекаешься на то, чтобы разобраться почему и что происходит. Ну и огромные папки получается, с нодовскими либами, бейбелами и прочими вещами, которые реально усложняют жизнь.

    Для SPA, когда нужен React или Vue тут да, webpack, а на простой верстке - лишнее.
    Как-то так, спрашивайте, критикуйте)
    Ответ написан
    Комментировать
  • Когда использовать jpg а когда png?

    Margari
    @Margari
    Если мы говорим про сайты, то тут еще приходится следить за размером. SVG, как правило, намного качественнее (т.к. векторная графика) и весит меньше png. К тому же его не надо ужимать, что приходится делать с png и jpg через плагины, проги или сервисы. SVG применяют в основном для иконок, логотипов компаний. На всех устройствах будет качественно выглядеть, особенно на Retina. PNG в таких случаях иногда бывает пиксельным при ближнем рассмотрении, поэтому я бы рекомендовала использовать svg там, где это возможно. На маках разница очевидна!
    Ответ написан
    1 комментарий
  • Как правильно настроить показ всего текста до загрузки шрифтов?

    @sozonovalexey
    Методом проб и ошибок выяснил, что нужно указывать путь до шрифта без ../
    Ответ написан
    4 комментария
  • В каком сервисе для управления проектами удобно писать эстимейты?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    в том, где есть диаграммы Ганта

    все хитровые обычно Ганта толкают за бабки, так что поищи сам

    например
    https://www.openproject.org/release-notes/openproj...
    https://www.teamgantt.com/ (что-то нормальное тоже за бабки, но можно по одному на проект )))) )

    ну и, разумеется, MS Project классика
    Ответ написан
    8 комментариев
  • Может ли эта уязвимость навредить сайту?

    SagePtr
    @SagePtr
    Еда - это святое
    А ещё в пост вставить картинку с котиком, а через некоторое время (когда пост затеряется и шанс модератора наткнуться на него будет минимальным) - заменить картинку с котиком на изображение листа конопли и натравить на него Роскомнадзор.
    В итоге сайт улетает в блокировку, а владельцы некоторое время не понимают, почему кол-во посетителей из России вдруг упало, а найти картинку, к которой РКН придрался, будет весьма сложно, так как факт замены в логах нигде отражён не будет, ибо заменена она будет на стороне стороннего сервера.
    Ответ написан
    1 комментарий
  • Кто знает про 3Д очки(шлем виртуальной реальности)?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Lenovo Explorer
    Купить (20к)
    ИМХО: не особо дорогой и лучший вариант на сегодня.
    Ответ написан
    Комментировать
  • Кто знает про 3Д очки(шлем виртуальной реальности)?

    Stalker_RED
    @Stalker_RED
    Те что с телефоном - используют экран телефона. На него выводится две картинки, которые потом линзами направляются в глаза. Качество зависит от экрана телефона и немножко от его мозгов.

    Те что "фабричные", типа oculus, htc vive, sony - отличаются немножко качеством экрана, отличаются временем отклика (это важно!), отличаются по весу и удобству, по количеству дополнительных аксессуаров, и по количеству совместимого софта.
    Если вы хотите покупать - сходите сперва в какой-нибудь VR-клуб, потестируйте разные модели, причем желательно не по 10 минут, а подольше. Может оказаться что в одних углы обзора не те, а в других тупо жарко сидеть и через 20 минут пот заливает глаза.
    Ответ написан
    4 комментария