Задать вопрос
  • Идеальный алгоритм вёрстки сайта?

    delphinpro
    @delphinpro Куратор тега Вёрстка
    frontend developer
    В целом согласен. До пункта №7.

    Я обычно придерживаюсь принципа верстки независимыми блоками.
    Поэтому после анализа макетов, я делаю одну-две-три (смотря по объему макетов) вспомогательных страниц, на которых верстаю:

    1. Базовые элементы. Общая типографика, кнопки, ссылки и т.п.
    2. Общие блоки. То что повторяется на нескольких страницах и/или может быть переиспользовано, какие-то виджеты, менюшки, и т.п.

    Все это занимает основную часть времени работы. И к окончанию этих этапов я имею своего рода набор, или конструктор, из готовых блоков. Остается только написать лейауты для разных страниц и раскидать по ним имеющиеся блоки.

    Для этого всё закидываю на гитхаб-пейдж, чтобы по ссылке я мог открыть с телефона или попросить знакомого проверить на другой ОС c телефона


    Это лишняя трата времени. Пусть небольшая, но все же. Плюс, отслеживать качество верстки все-таки удобнее в процессе, а не по окончании подкручивать.
    Поэтому используем browser-sync. Поднимается сайт, доступный по IP в домашней локалке с любого устройства. Совет: использовать всегда один порт в browser-sync, а на устройствах сделать закладки на этот адрес. Любой сайт, который в данное время разрабатывается, открывается одним тапом по закладке.
    Кроме того BS дает бонус в виде синхронизации действий сразу на всех устройствах: клики, прокрутка, ввод. Это мега-удобно — кликаешь на компе, краем глаза смотришь в планшет и телефоны, сразу видишь там все изменения и поведение.

    Всё готово, сжимаю CSS, JS. через веб-сервисы.


    Опять тратите время. Настроенный Gulp в одну команду проделает все оптимизации (на больших проектах даже кофе можно успеть сделать, пока собирается билд=).

    Еще обратите внимание на инструмент lighthouse в инструментах разработчика.

    скриншот
    608fcaa260f31153020142.png


    Не нужно никуда сайт заливать, чтобы проверить на доступность, производительность и т.п.

    Про CMS ничего не скажу. Клиенту удобнее кнопочки тыкать в условном вордпрессе.

    Я не упомянул SASS-фигас и т. д, так как не увидел практической пользы для проектов на 1-15 страниц.


    Возможно вы плохо знакомы с возможностями препроцессоров, или вам никогда не требовались они, кроме переменных.
    Но даже в этом случае, препроцессор помогает упорядочить и структурировать код, а не писать одну простыню на 10 тыс строк в одном файле.

    Ну вот зачем PUG? Как конкретно он помогает на небольших проектах 1-15 шаблонов страниц.


    Помогает. Нет, конкретно Pug я очень не люблю. Но другой, более "хэтээмэльный" шаблонизатор бывает полезен. Я уже упомянул выше о верстке независимыми блоками. Шаблонизатор позволит не копипастить эти блоки, а использовать их как компоненты.

    Префиксы? В кодовом редакторе они и так есть.


    Я считаю, что исходный код должен быть чистым, без префиксов. Это лишний визуальный мусор. Пусть лучше автопрефиксер этим занимается. К тому же этот плагин использует актуальную базу caniuse на основе вашего .browserlist. Пусть профит и не большой, но все же поменьше на выходе неактуальных свойств.
    Ответ написан
    2 комментария
  • Как лучше всего написать сайт?

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

    SeaInside
    @SeaInside
    15 лет пилю все эти штуки
    Лучшее, что вы можете сделать - не тащить на сайт кучу всякой херни, которая обычно много весит, ухудшает перфоманс, затрудняет восприятие контента и не нужна никому, кроме вас. Серьёзно.
    Любая анимация должна быть уместна, и если вам, глядя на дизайн, никаких конкретных идей в голову не приходит - то и не нужно. Нет способа удешевить сайт сильнее, чем добавить элементам разного толка выпрыгивания со всех сторон, глитч-эффекты и всё такое.
    Хочется динамики - найдите какое-нибудь не сильно быстрое видео и поставьте его как фон, или по запросу "canvas background animation" найдите ненапрягающую анимацию.

    P.S. Речь идёт не о сайтах, которые должны побеждать на Awwwards, а об обычных сайтах, которые делаются для людей, а не для конкурсов.
    P.P.S. Если всё-таки очень хочется, то нужно гуглить по запросам "hover effects" и "canvas animation", остальное без конкретной дизайнерской задумки вреда несёт куда больше, чем пользы.
    Юзабилити - это про то, чтобы "работает быстро и понятно (как у всех)".
    Ответ написан
    2 комментария
  • Какой язык программирования изучать в свободное время?

    dollar
    @dollar
    Делай добро и бросай его в воду.
    Какой-то конкретной цели, объясняющей для чего мне это надо, пока что нет.

    - Скажите пожалуйста, куда мне отсюда идти?
    - А куда ты хочешь попасть? - ответил Кот.
    - Мне все равно... - сказала Алиса.
    - Тогда все равно куда и идти, - заметил Кот.
    - ...только бы попасть куда-нибудь, - пояснила Алиса.
    - Куда-нибудь ты обязательно попадешь, - сказал Кот. - Нужно только достаточно долго идти.

    Льюис Кэрролл
    Ответ написан
    1 комментарий
  • Почему некоторые люди утврерждают что плохо использовать jQuery?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Во-первых, jQuery родилась во времена, когда каждый браузер реализовывал JS и DOM API по-своему, её основным назначением было сглаживать эти различия. В наше время это преимущество библиотеки уже утеряно. Во-вторых, jQuery не соответствует основному вызову современности - сложной кодовой базе. В развитом фронте код, использующий jQuery, быстро превращается в трудно сопровождаемую лапшу. Поэтому для простого фронта чаще стали использовать ванильный JS, а для сложного фреймворки типа React, Angular и Vue.
    Ответ написан
    23 комментария
  • Почему вход в web сейчас такой сложный?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Сложный? Сейчас?!
    5dbf9c5664851438289708.jpeg
    Вам бы в 70-е или хотя бы 90-е попробовать.

    но когда уборщица и охранник получают как минимум в 2 раза больше , это очень странно!

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

    никто учить не хочет и не собирается

    Бизнес - это не школа. Бизнесу нужно деньги зарабатывать, а не учить вас.

    В итоге , надо 2-3 года вкалывать , что бы перестать работать за еду. Что не так с IT?

    Например в медицине этот срок 6-9 лет.
    Ответ написан
    17 комментариев
  • Стоит ли читать спецификацию w3c?

    delphinpro
    @delphinpro Куратор тега CSS
    frontend developer
    Недавно наткнулся на фразу, что тем кто пишет спецификации легко, т.к. они только описывают как технология должна себя вести, а внедряют её разработчики браузеров.

    Вовсе нет. Спецификации писать нелегко. Вы не можете взять и тупо дописать в спеку новый тег. Это длительный процесс обсуждений и черновых реализаций.

    В w3c разрабатывается Amaya
    Работа над Amaya началась на W3C в 1996 году для демонстрации веб-технологий в полнофункциональном веб-клиенте. Основной мотивацией для разработки Amaya было создание фреймворка, способного интегрировать как можно больше технологий W3C. Он предназначен для демонстрации этих технологий в действии, используя преимущества их комбинации в единой, согласованной среде.


    Почему тогда, какие-то технологии где-то работают только с префиксами?

    От префиксов давно уже отказались. Остались только для совместимости или типа того. Новые фичи теперь пилятся под экспериментальными флагами до готовности.
    Почему они были нужны? Потому что браузеры либо частично реализовывали функционал, либо по-своему (когда, например, спецификация еще не была в статусе рекомендации).

    И насколько стоит доверять спеками w3c

    На 100%. Это стандарт, к которому рано или поздно приводятся все фичи браузеров.

    если они не занимаются технической реализацией этих технологий?

    Будьте спокойны. В написании спецификаций участвуют не какие-то отдельные личности. Список участников достаточно большой, и в нем присутствуют все ведущие разработчики браузеров: и гугл, и мозилла, и опера, и хрен знает кто еще. Изучите список сами: https://www.w3.org/Consortium/Member/List

    В общем, поменьше читайте сеошные статейки, и побольше признанных разработчиков в интересующей сфере. И официальной документации.
    Ответ написан
    Комментировать
  • Что плохого в количестве коммитов чуть больше, чем за которое могла решиться задача на самом деле?

    Xuxicheta
    @Xuxicheta
    инженер
    В личных тараканах ревьюера. Если уж его так парят коммиты при слиянии PR можно слепить коммиты в один.

    Наоборот, чем меньше изменений в коммите. тем лучше. Я вот страдаю обратным, в конце дня делаешь коммит, потом не разберешься во всем этом.
    Ответ написан
    1 комментарий
  • Зачем frontend девелоперу такой большой опыт?

    @managrib
    К тому же если он например закончил университет и проработал 6 лет , ему уже под 30. Мозг работает хуже, нет уже целеустремленности и желания развиваться.


    Если он балду не пинал, а получал ценный опыт на практике - то с головой у него все нормально.
    Напротив: он уже лучше/быстрее ориентируется в технологиях.

    Вы написали примерно следующее:


    Я классный программист, но никому не нужен
    Все кругом дураки, кроме меня
    Но меня на работу не берут
    Но виноваты в этом другие, не я.


    Это у вас просто гимн осознания собственной неполноценности.

    Что до цены - цена определяется только спросом и предложением.
    Подавляющее большинство программистов (да и в других профессиях это тоже так) - низкоуровневый шлак. Что бы они там о себе не думали.
    Профессионалы настоящие - редкость.

    Сейчас рынку нужно больше программистов на веб-фронтенд, чем на С.
    А предложений - маловато.
    Только этим прежде всего, а не мнимой или реальной сложностью технологий определяется сегодняшняя цена.

    Все, что связано с пользовательским интерфейсом - трудоёмко.
    И так не только JS.

    Ну а по конкретно JS и веб-фронтенду - быстро меняющиеся стандарты дополнительная сложность.

    Но там почти все вакансии 3-6 лет опыт работы. То есть именно опыт работы в офисе/удаленно подтвержденный документами


    Это не так.
    Никакого документального подтверждения не требуется, если только это не госконтора или корпорация формализованная.

    Так вот вопрос зачем работодатель ограничивает себя от реально талантливых молодых разработчиков и ищет 30 летних бездарей


    Вы программист, что ли?
    Слишком уж формально подходите к делу.
    Они никак не ограничивают, простой пойди и побеседуй покажи свои знания - и получишь сразу большую зарплату.

    "Бездарей"?
    Чувствуется обиженного.

    Нет, бездари фильтруются также на собеседовании.

    50 лет назад был язык программиство - Си. и язык пользователей - бейсик.

    Как же мало вы знаете о программировании.
    А понтов-то понтов.

    50 лет назад С еще не было. А когда он появился - далеко не мгновенно стал мейнстримом.

    Я понимаю ваши обиды - "учил настоящий язык С, а оказалось, что такой программист как ты и не нужен, платить не желают.".
    Но это не повод передергивать факты.

    Получается можно работать 3-6 лет и не знать что такое замыкания

    Я и за 20 лет работы не выяснил что такое замыкания.
    Погуглил, а, знаю уже лет 20 как. Только не знаю, что это так называется.

    Мне достаточно 3 дней чтобы разобраться как работает React вся его экосистема Redux и тд.


    Зачем же тогда вы пишете такой огромный опус, весь пронизанный завистью.
    Ведь в 3-х днях от вас зарплата в 3-5 раз большая чем ваша.
    Или все же не в трех днях?

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


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

    Технологии - это не чтение доки.

    Технологии - это умение пользоваться.
    А тут человечество ничего не придумало - умение приходит только с опытом реального использования.

    Они просто берегут силы интервьюеров не давая шанс абсолютно каждому и теряют очень много. Можно было бы с первого же неправильного ответа на вопрос отправлять домой и все, но давать шанс всем.

    Все дураки, кроме вас и поступают неправильно. Мы поняли.
    Шанс дается всем.

    Но как показывает практика - на вакансию приходит 90% шлака вроде вас, которые только еще думают, что они уже программисты.

    Есть конечно исключения например в jetbrains можно сразу синьор разработчиком устроиться из универа. Такие компании уважаю.


    Ну мы все мним себя особенными. Совершенно без оснований

    Устраивайтесь.
    Но, боюсь, это ваши фантазии.
    Один-два человека-исключения - это не общепринятый порядок.
    Ответ написан
  • Как быть хорошим junior?

    saboteur_kiev
    @saboteur_kiev Куратор тега IT-образование
    software engineer
    1. Адекватность и самостоятельность.
    Детальнее: Умение понять суть задачи, чтобы выполнить ее. Самостоятельно решать проблемы - в это слово входит не только то, что возникла проблема - порешал. А умение решить проблемы, которые ты решить не можешь. То есть организовать решение проблемы. Заблочили аккаунт? Выяснить, вызвонить, попинать, чтобы разлочили побыстрее. Не знаешь как решить какую-то техническую проблему - достучаться до куратора. Не сидеть и ждать три дня, пока он вспомнит про твою проблему, а регулярно уточнять. Занят куратор - подойти к другому. Не успеваешь решить в срок - прийти к куратору заранее, а не за час до конца срока.
    В общем, чтобы за тобой не бегали.

    2. Умение ставить правильные вопросы.
    Сперва загуглить, потом задать вопрос для уточнения. В идеале ставить вопросы, на которые ответ будет "да" или "нет", но это я утрирую. Не бояться спрашивать вещи, которые совсем не понимаешь, но тут не нужно ожидать что все будут разжевывать - следует задать вопрос, чтобы понять куда копать. Иногда достаточно знать пару ключевых слов, по которым можно загуглить.

    3. Желание учиться.
    Не бояться изучить лишнее, потому что "мне же это не пригодится". Умение гуглить по ключевым словам. Не лениться изучать как что-то работает, чтобы понимать почему это происходит. Понимание принципов работы очень сильно увеличивает интуицию.
    Ответ написан
    1 комментарий
  • Правда ли что рынок веб разработки "перегрет"?

    OTCloud
    @OTCloud
    Программирование и Архитектура ПО
    100% перегрет, но не программистами или веб-мастерами, а индивидами, которые решили что веб это просто и легко и не стоит сильно париться над своими скиллами и знаниями.
    Ответ написан
    8 комментариев
  • Почему падает приложение Vue?

    Не углубляясь в реализацию, обычно из asyncData возвращают Promise<Object|void>, а у вас Promise<Array>. Да, массив тоже объект, но пути джаваскриптовы неисповедимы. Этот массив потом передаётся в функцию роутера next в entry-client.js:16, которая тоже не должна уметь его обрабатывать, и т.д. и т.п.

    Так или иначе, если asyncData используется только для наполнения store, смысла передавать что-либо в resolve промиса нет:

    async asyncData ({ store }) {
      await Promise.all([
        store.dispatch('func1'),
        store.dispatch('func2'),
        store.dispatch('func3'),
        store.dispatch('func4')
      ])
    }
    Ответ написан
    1 комментарий
  • Как добыть информацию этого тега?

    kshnkvn
    @kshnkvn
    yay ✌️ t.me/kshnkvn
    Кому-то двойной цикл не помогает, а кому-то и одной строки может хватить:
    print(soup.find('span', {'class': 'searchBar__mediaTabTextValue searchBar__mediaTabTotal'}).get_text())

    >>> 75

    А вообще, с таким вот:
    Нужно рабочее решение !!!!

    На соседний ресурс иди.

    А с такими вот предъявами:
    не принимаю и даю жалобу.

    Иди к маме, а не сюда. Тут ты в первую очередь просишь.
    Ответ написан
    Комментировать
  • Насколько забивает память "const self = this" в методах классов?

    yarkov
    @yarkov
    Помог ответ? Отметь решением.
    const self = this;
    request(params, (err, req, body) => {
          self.result(body, ext);
    });

    А зачем тут self, если у вас стрелочная функция?
    Ответ написан
    6 комментариев
  • Как сделать кастомный checkbox на JS?

    Ankhena
    @Ankhena Куратор тега JavaScript
    Нежно люблю верстку
    потому-что с CSS-ом геморно кастомный чекбокс замутить

    Ну прям

    (усовершенствованный вариант со специально видимым фокусом, который потом можно кастомизировать как хочется)
    Ответ написан
    Комментировать
  • Опять сомнительный заказчик на Upwork, обман ли?

    ZERGE
    @ZERGE
    Сейчас не знаю что и делать, странно как то это все.

    Действительно, странно, сначала делать, потом думать.
    Зачем вы вообще пришли на Апворк? Чтобы заниматься подобным схематозом?
    Ответ написан
    1 комментарий
  • Какие используете единицы измерения при верстке?

    Ankhena
    @Ankhena Куратор тега CSS
    Нежно люблю верстку
    Какие используете единицы измерения при верстке?

    Подходящие!
    Для решения разных задач используются разные единицы измерения

    примеры

    1. Размер шрифта удобно писать в px, em и rem.
    Если он фиксированный, то это px.
    Если зависит от настроек пользователя, то rem. Для html задают font-size: 62.5%, для body font-size: 1.6rem в итоге для стандартных настроек получают изначальные 16px, но для удобства расчетов в этом случае 1rem=10px.
    Если размер шрифта зависит от размера шрифта родителя, то используют em, например, заголовок должен быть в 1.2 раза крупнее текста. h1{font-size: 1.2em}
    А может быть мне нужен адаптивный шрифт, чтобы на всех экранах слово занимало всю ширину, тогда vw vh

    2. Границы. Обычно толщина границ не зависит от шрифта или размеров блоков, значит, px
    border: 1px

    3. Блоки.
    У блоков могут быть разные зависимости.
    Например, четверть родителя -> проценты %
    Или фиксированная -> px
    Или зависит от ширины/высоты вьюпорта -> vw vh
    Или зависит от шрифта -> ch (Ширина символа 0 в шрифте текущего элемента.)

    4. Отступы.
    Могут зависеть от шрифта, могут быть % от ширины блока или фиксированными в px.

    Это не все варианты, все мне, наверное, так сразу и не перечислить
    Ответ написан
    2 комментария
  • Что посоветуете изучать?

    IonDen
    @IonDen Куратор тега IT-образование
    JavaScript developer. IonDen.com
    1. Английский язык - очень плотно возьмитесь.
    2. Математику и алгоритмы
    3. Какой-нибудь простой язык программирования для начальных экспериментов (вроде Python)
    Ответ написан
    Комментировать
  • А какая архитектура reactjs/redux приложения у вас?

    Отказался от деления компонентов на умные и глупые. Любому компоненту может потребоваться прямой доступ к данным, и перекидывать лапшу в props - неблагодарное занятие. У меня в целом все просто: компоненты в папке Components, редьюсеры в папке Reducers, экшены в Actions, константы в Constants, и все остальное по назначению.
    Ответ написан
    6 комментариев
  • Стоит ли начинать изучение Vue.js с посредственными знаниями javascript?

    @McBernar
    Не стоит. Потому что при таком уровне знаний ваш максимум — это повторить пример из туториала. Шаг влево-вправо — и вот вы уже в тупике.
    Ответ написан
    Комментировать