Комментарии 39
Веб — это давно уже не просто документы. Теперь это в основном приложения, исполняющиеся в браузере. И HTML тут является просто контейнером для кода приложения и языком разметки страниц.
И всё-таки автор прав насчёт того, что в JSX или .vue не обязательно использовать только div'ы.
Проблема в том что HTML пытаеться усидеть на двух стульях. К примеру админка сайта — это приложение исполняющееся в браузере и там семантика не нужна. А сам сайт это привычный всем HTML где важно донести структурированный контент. Вот и разрывается бедняга.
Пользователь не смотрит на разметку, контент структурируется для него визуально, используя (сюрприз!) JavaScript и CSS.
И да, тэги и правда нужно бы знать, хотя я и не согласен с мнением автора: например, довольно часто, нажатие на кнопку не просто должно отправлять данные куда-то на сервер, а возможно выполнять анимацию (совершенно другого компонента), отправлять что-либо куда ещё (статистику, например) и т.д.
Проблема в том, что многие программисты/верстальщики не знают, что страница, далеко не всегда, делается только для того чтобы ее увидел посетитель в окне браузера.
Например — страница должна быть верно понята поисковым роботом, что в рамках React, Vue и прочих замечательных реактивных фреймворков (а точнее того как их привыкли использовать) превращается в трудно выполнимую задачу. Даже с использованием SSR.
Например — страница должна быть верно понята поисковым роботом, что в рамках React, Vue и прочих замечательных реактивных фреймворков (а точнее того как их привыкли использовать) превращается в трудно выполнимую задачу. Даже с использованием SSR.
Проблема в том, что когда, например, мне кто-нибудь прислал ссылку на какую-то статью, я хочу прочитать эту статью. Я как пользователь хочу увидеть буквы на экране, и больше не хочу ничего. Страница со статьёй — это как раз таки «просто документ». Делать из сайта со статьями single-page application — это просто верх оверинжиниринга. Такой сайт можно сделать вообще без строчки JS, тем не менее, мне пару раз попадалось нечто, где отдаваемая с сервера страница не содержала даже текста статьи, он подгружался дополнительным ajax-запросом и появлялся секунд через 10 после начала загрузки. Вы считаете, что так и должно быть?
Мой первый сайт был в одном файле index.php… О времена )
О да! Плюсануть не могу (кармой не вышел), но всеми руками «за». В этом как раз и выражается современный веб. Научить на курсах использовать вагон фреймворков могут легко, а вот думать «зачем» — нет. Мы уже тонем во всём этом. Растущие мощности железа явно не успевают за результатами плодящихся методом курсования веб-разработчиков.
Да тут даже не «думать зачем», а понимать их внутреннее устройство и, следовательно, уместность использования в том или ином проекте. В современном программировании, по-моему, в целом не принято о таких мелочах думать. Чем больше низкоуровневого от себя спрячешь за ненужными абстракциями — тем лучше. Определённые инструменты полезны в одних ситуациях и вредны в других, но в программировании почему-то считается, что есть какая-то одна истина для всех, и она в том, чтобы непременно быть в тренде. Это вот всякие вещи уровня «почему ты верстаешь таблицами в 2019». Да, я верстаю таблицами, а не дивами, а на календарь посмотреть забыл, простите. Моя вёрстка подсвечивает нужные пиксели на экране нужными цветами и, прости господи, даже в IE6 не разъезжается, что вам ещё-то нужно?!
Чем больше низкоуровневого от себя спрячешь за ненужными абстракциями — тем лучше.
В целом так оно и есть, да. И этому есть логичное объяснение: так быстрее и дешевле разрабатывать (если не перегибать палку, конечно, с абстракциями). Грубо говоря, сделать "статический" сайт со статьями на голом PHP+MySQL+HTML+CSS+совсем немного JS дольше и дороже, чем сделать примерно ту же функциональность, "обернув" сайт на основном стэке SPA на Laravel+Eloquent+React+Redux
Все так. Увы. Слепое следование за модой. И еще больше фреймворков! Потому, нынче, чтобы положить любой комп на лопатки не нужны никакие специфические программы — просто откройте побольше вкладок браузера.
Автор очень однобоко смотрит на ситуацию ставя лозунги о доступности и мертвую семантику превыше всего.
Автор может и сгущает краски по поводу доступности, однако текущее состояние фронтенда таково, что реакт бездумно засовывают даже туда, где более уместна просто семантичная верстка с минимумом js.
Как раз та семантика, про которую говорит автор – живая (правильный тег дает браузеру минимально необходимую функциональность, скринридеру – правильную роль, и т.д.). Не вся семантика одинаково бесполезна:)
Можно ездить на «Феррари» и ничего не понимать в ДВС.
Но нельзя собирая автомобиль не знать принципа работы четырехтактного двигателя.
Вот что хотел донести автор.
Сегодня многие «разработчики» грешат тем что не знают основы, в данном случае HTML.
И потом появляется такое -
Но нельзя собирая автомобиль не знать принципа работы четырехтактного двигателя.
Вот что хотел донести автор.
Сегодня многие «разработчики» грешат тем что не знают основы, в данном случае HTML.
И потом появляется такое -
Я сделал автомобиль
Забавно наблюдать как меняется мода в вебе, сначала писали нативные onclick и properties (2000-й год), потом решили, что так писать не правильно, начали выносить биндинги в отдельные js-модули и визуальную часть в отдельные css-модули (2010-й год), потом на современных фреймворках стало модно опять писать рядом с тегами биндинги (jsx) и стили (styled-components). Некоторым создателям современных решений полезно было бы почитать историю технологий и понять, почему в своё время сообществом был принят тот или иной подход, вместо того, чтобы промотировать ошибки 20-летней давности.
Автор этой статьи подходит довольно категорично, но нельзя не согласиться, что при современном подходе к разработке большая часть старых нароботок просто выбрасывается на помойку, причём не потому, что устарела, а просто из за невежества и неосведомлённости об их существовании.
Автор этой статьи подходит довольно категорично, но нельзя не согласиться, что при современном подходе к разработке большая часть старых нароботок просто выбрасывается на помойку, причём не потому, что устарела, а просто из за невежества и неосведомлённости об их существовании.
От нативных onclick в свое время отказались потому что типа нельзя навесить несколько разных обработчиков, да и делегирование событий не получится. Современные фреймворки эту проблему решают на своей стороне, ибо все шаблоны парсятся и компилируются в JS и делегирование событий работает само из коробки. Шаблоны уже не HTML, а некий DSL (даже шаблоны vue, которые выглядят валидным HTML).
А вот styled-components действительно выглядит шагом назад. Выглядят они противоестественно, писать их больно, а преимущество только одно — стили находятся рядом с разметкой.
В JSX тоже нельзя навесить несколько обработчников на один элемент. Можно вызывать несколько сторонних функций из функции-обработчика, но это можно было сделать и с нативными биндингами html. Вообще паттерн Observer повсеместно использовался в vanilla-js именно из за возможности делать слабую связанность и отложенный биндинг. В React решили всё это выкинуть и сделать просто передачу функции. Что, приложения в наше время стали проще? Или разработчики менее компетентны? Мне кажется второе.
С одной стороны вы правы, но с другой 20 лет назад условия были несколько другими. И то, что было отвергнуто тогда, сейчас может быть актуальным. И наоборот, то, что было лучшими походами тогда, сейчас, может быть, должно умереть, а не "диды так верстали и я буду".
Просто нужно чётко проводить грань — что есть веб-приложения, а что есть набор объединённых «гипертекстовых» документов (контентный веб-сайт) размещённых в интернете.
Обычно при старте проекта отвечаю себе на такие вопросы:
1) Это что-то публичное и/или сео-чувствительное? Значит пишем по-нормальному — многостраничный сайт, с серверным роутингом и серверным рендерингом, в котором возможные личные кабинеты или сервисы заворачиваем в мини-spa. Немножко нужно с webpack-ом подшаманить. Но, допустим, в symfony он уже нормально интегрирован, очень удобно.
2) Если это внутренний сервис/инструмент… оно же веб-приложение — однозначно SPA (возможно в отдельный микросервис/репозиторий ). Ибо неизвестно куда заведут требования.
Параллельная команда клепает контентные (!) сайты на Ангуляре. При чём решение принимал вроде тим-лид. Без улыбки не взглянешь, столько боли постоянно: то маркетологов морозят от их требований, то героически SSR прикручивают, метр джаваскрипта на каждой странице (на которой только текст), мего спиннер при старте, 10 баллов в google-page-speed, зато роутинг клиентский… круто..)
Обычно при старте проекта отвечаю себе на такие вопросы:
1) Это что-то публичное и/или сео-чувствительное? Значит пишем по-нормальному — многостраничный сайт, с серверным роутингом и серверным рендерингом, в котором возможные личные кабинеты или сервисы заворачиваем в мини-spa. Немножко нужно с webpack-ом подшаманить. Но, допустим, в symfony он уже нормально интегрирован, очень удобно.
2) Если это внутренний сервис/инструмент… оно же веб-приложение — однозначно SPA (возможно в отдельный микросервис/репозиторий ). Ибо неизвестно куда заведут требования.
Параллельная команда клепает контентные (!) сайты на Ангуляре. При чём решение принимал вроде тим-лид. Без улыбки не взглянешь, столько боли постоянно: то маркетологов морозят от их требований, то героически SSR прикручивают, метр джаваскрипта на каждой странице (на которой только текст), мего спиннер при старте, 10 баллов в google-page-speed, зато роутинг клиентский… круто..)
Если кратко о состоянии дел в отрасли:
<div class="site_wrap">
Посыл статьи был ведь не в том, что React — это плохо, или Angular — это плохо, или не нужно делать SPA.
А в том, что если нужен заголовок, то почему не взять для этого тег заголовка (h1-h6), Почему нужно брать div?
Если нужна кнопка, это должна быть именно кнопка, а не кликабельный div, или span, или что-либо ещё.
Почему не взять для чекбокса input с типом checkbox, почему нужно городить что-то своё непонятное?
И в данном вопросе я готов подписаться под каждым словом автора.
И совершенно не важно что мы разрабатываем: сайт, админку, crm… Просто нужно использовать html-элементы по их прямому назначению.
Точно так, как мы стилизируем кликабельный div под требования дизайна, мы можем взять button и тоже придать ему необходимый вид. В чём проблема? Но в последнем случае, мы будем использовать элемент для того, для чего он и предназначен.
И писать правильно можно как на чистом html, так и в том же jsx. Ровно как и наоборот.
А в том, что если нужен заголовок, то почему не взять для этого тег заголовка (h1-h6), Почему нужно брать div?
Если нужна кнопка, это должна быть именно кнопка, а не кликабельный div, или span, или что-либо ещё.
Почему не взять для чекбокса input с типом checkbox, почему нужно городить что-то своё непонятное?
И в данном вопросе я готов подписаться под каждым словом автора.
И совершенно не важно что мы разрабатываем: сайт, админку, crm… Просто нужно использовать html-элементы по их прямому назначению.
Точно так, как мы стилизируем кликабельный div под требования дизайна, мы можем взять button и тоже придать ему необходимый вид. В чём проблема? Но в последнем случае, мы будем использовать элемент для того, для чего он и предназначен.
И писать правильно можно как на чистом html, так и в том же jsx. Ровно как и наоборот.
Иногда очень сложно реализовать задумку дизайнера на семантически подходящих элементах. Вплоть до вроде бы они есть в Dom, но пользователь их не видит, фокус на них не получить ему никак.
Действительно, есть такое, не всякий дизайн можно реализовать «правильно». Сам как-то столкнулся с кастомизацией селекта, и я практически запорол всю работу, пытаясь реализовать задумку именно с помощью селекта, а не стилизовав див под него (возможно, это было моё отсутствие профессионализма, но факт — такая ситуация возможна).
Но суть не в этом. Это все частные случаи. Здесь же речь идет о тотальной «дивизации» и полном игнорировании html как инструмента.
Но суть не в этом. Это все частные случаи. Здесь же речь идет о тотальной «дивизации» и полном игнорировании html как инструмента.
Вот как раз со стилизацией нативных компонентов иногда всё плохо. Попробуйте, например, стилизовать select, округлые края, другая стрелочка, цвет фона… С другой стороны зачем трогать стандартный паттерн UI, который к тому же будет удобно выглядеть на всяких Android/iOS браузерах?
При чтении таких статей с грустью вспоминаю про сайт Gmail.
Я даже не поленился восстановить пароль, чтобы ответить на ваш коммент
Стилизация чекбоксов, радио — это одна из самых простых вещей, label for + before
Касательно select, switch уже менее принципиально, но тоже можно стилизовать
И всегда можно послать дизайнера исправлять свое детище, если он не компетентен и нарисовал откровенную чушь
«Вот мы и вынуждены делать пляски в js.»
Велосипеды :)
Стилизация чекбоксов, радио — это одна из самых простых вещей, label for + before
Касательно select, switch уже менее принципиально, но тоже можно стилизовать
И всегда можно послать дизайнера исправлять свое детище, если он не компетентен и нарисовал откровенную чушь
«Вот мы и вынуждены делать пляски в js.»
Велосипеды :)
Каждый раз, когда в глубинке по GPRS или за рубежом, по тарифам роуминга, пытаюсь найти крайне важную информацию, вспоминаю это «зачем нам оптимизировать какие-то 10-15 килобайт кода и изворачиваться ради этого, если у нас есть 8 гигов памяти на смартфоне и 4g»… А еще, когда на моем макбуке, при загрузке страницы стартует вентилятор, который молчит даже при просмотре 4К видео.
если у нас есть 8 гигов памяти на смартфоне и 4g!
Достаточно отойти от берега на лодке миль на 10, и Фэйсбук уже перестает грузиться. Даже на сравнительно цивилизованной Средиземноморке.
если у нас есть 8 гигов памяти на смартфоне и 4g!
У вас-то оно есть… а у ваших пользователей? ;)
Причина, по которой мы вынуждены отступать от семантики кроется в том, что в 99% случаев дизайнер рисует нам кастомный чекбокс, радио, select, switch(которого на минуточку вообще нет в браузере как такового), выпадающие списки, и вот это всё. И у нас есть несколько (от 2-х до 5-ти) браузеров, где вот это всё должно выглядеть одинаково и одинаково работать. Но разработчики браузеров по какой-то причине до сих пор (2019 год!) не реализовали возможность делать нативные чекбоксы (радио, select и пр.) кастомными без танцев с псевдоэлементами и js. Вот мы и вынуждены делать пляски в js.
Лайфхак. Можно вообще не договариваться с дизайнером.)
Уже давно объявил бойкот кастомным контролам от дизайнеров (особенно чекбоксам, радио кнопкам и выпадающим спискам). Браузер лучше всего отрисует контрол так как положено, как привыкли пользователи этого браузера. Максимум инпуты и cta-кнопки делаю как нарисовали. Более того, если это продукт для внутренних пользователей — даже кастомные попапы не делаю, обхожусь нативными алертом/prompt/confirm — т.к. именно для этого они и были придуманы и автоматом делают все действия (блокировка ui и т.д.), которые пришлось бы делать самому или подключать либу.
Схема работает больше двух лет:
Прилетает макет. Делаешь не обращая внимания на креативные контролы дизайнера, оставляешь их нативными. Более того, если с чем-то не согласен, делаешь по своему… как лучше (вы же знаете, да? фронтендер всегда доделывает за дизайнером..))
Сделал. Закрываешь задачу. Приступаешь к следующей.
Как правило, всех всё устраивает, т.к. главное это функционал. Более того, даже могут и не заметить разницу до 30% с макетом. Потому что опять же, на макет толком никто не смотрел, и внимательно сверять никто не будет. Ваша задача сохранить цветовую палитру, шрифты, контент и отступы.
Если всё-таки замечают, что контролы не такие — заводят баг. Руководству говорим — что можем тратить время на кастомизацию контролов, а можем использовать это время для новой фичи. Как правило, баг остаётся в багтрекере навсегда, и никто по этому поводу не переживает.
А потому что что? Потому что пользователям плевать на дизайн www.slideshare.net/AlexanderKirov/ss-19366795
Главное — грамотный пользовательский сценарий и контент.
Кстати, дизайнеры как правило отдают макет и на этом взаимоотношения заканчиваются. Поэтому и договариваться особо не с кем. Если же в команде есть продуктовый дизайнер в штате — то опять же… ставим вопрос на обсуждение… мы возимся с чекбоксами, или будет делать что-то более приоритетное?
«Хорошая» реклама места, где вы работаете. Если клиент хочет определенный дизайн и на это были отведены определенные сроки — значит они ожидают увидеть тот дизайн, который вы им продали, или есть определенная аналитика, возможно так же проработан рынок и очень странно, если вы «так» поступаете с вашими клиентами.
Не уверен, что в другой компании в нашей сфере вам нашлось бы место с таким подходом.
Не уверен, что в другой компании в нашей сфере вам нашлось бы место с таким подходом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HTML — это и есть веб