Почему фронтенд сложнее бэка?

Не надо мучительно придумывать всратые имена

Имена переменных и классов в коде тоже мучительно придумывать? А необходимо. Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules — пишешь только .col.

просто делаешь … и всё

Потом в разметке лесенка из flex flex-col и долго ищешь, какой из компонентов использовался.

Не надо с тоской смотреть на бесконечные классы с одним и тем же повторяющимся атрибутом для цвета текста

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

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

Опять-таки, стили шрифтов тоже ортогональны тейлвинду. Более того, часто нужно указать не только размер, но и межстрочный интервал, и жирность. Этим самым мы приходим к нескольким полноценным стилям шрифта.

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

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

Не надо на митинге жаловаться, что джуны опять нахерачили 18 размеров отступов в форме логина, в трёх разных единицах измерения

Для этого есть код-ревью. Наговнокодить можно с любым инструментарием.

Не надо вообще писать новый CSS, просто навешиваешь/снимаешь классы для нужных атрибутов и радуешься жызни.

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

Проблема тут не со стилями, а с модульностью представлений

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

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

Это потрясающая отмаза! Я теперь всегда так буду говорить, когда мой говнокод будет течь!

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

Все языки со сборщиком мусора по сути основаны как раз на втором подходе - пусть «течёт», а потом мы отсеем нужное от ненужного и почистим.

Мне кажется, ты не очень понимаешь, как работает GC.

Это потрясающая отмаза! Я теперь всегда так буду говорить, когда мой говнокод будет течь!

Собственно, если всё это никак не сказывается на потребительских свойствах программы, то никто тебе претензий и не предъявит. Но в большинстве случаев утечки, когда их называют утечками, это именно утечки и никакие подмены понятий этого не изменят.

Мне кажется, ты не очень понимаешь, как работает GC.

Зря тебе кажется.

потому что у тебя chrome/safari/ie, и они тебя, фронта, сотнями своими версиями сношают.
*mozilla вроде на chrome-based движок перешла, либо добавь в список.

Случайные имена тоже никому не нужны. Чтобы не писать всрато, есть css modules

Поделил на нуль. CSS Modules ведь как раз и генерирует случайные имена для классов %)

Потом в разметке лесенка из flex flex-col

Никто не мешает добавить маркерные классы или напесать комменты, если у вас там 38 уровней вложенности флексбоксов в одном компоненте.

возможность динамической темизации, в отличие от захардкоженных в конфиг цветов.

Не обязательно хардкодить — есть CSS vars.

В тейлвинде точно так же вертальщик зафигачит условный text-[14pt] вместо text-base.

И получит по рогам на ревью. Заметить косяк очень просто — любая квадратная скобка в классе есть потенциальный косяк. Регулярку можно напесать.

часто нужно указать не только размер, но и межстрочный интервал, и жирность

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

18 размеров отступов

Для этого есть код-ревью

Только вот заметить такой косяк будет гораздо труднее — ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

дизайнер приходит с редизайном какой-нибудь панельки, которую разработчики поленились оборачивать в компонент, а просто написали инлайном, и теперь надо искать её по всему проекту и менять классы

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

тейлвинд не даёт модульность

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

Необходимость в отдельной модульности для стилей вообще сильно зависит от задачи — если у вас сайт/приложение, которое полностью под вашим контролем, можно обойтись глобальными. Если надо, к примеру, встраивать компоненты на чужие страницы — придётся озаботиться изоляцией, с тейлвиндом или без. Например, те же CSS Modules или тейлвинд с префиксом.

Нет единого стандартва, классика в стиле «лебедъ, рак и щука». К тому же, фронтенд ближе завязан к хотелкам маркетинга и своеобразный дроч на «интерфейс», который был кривой, а ставиться еще хуже, но с визуальным фактором, а-ля 'пользователям' на основе исследования X, лучще воспринимает психологически голубые цвета или что-то в этом роде. Программисты, вернее кодеры больше идут в сторону фронтенд, соприкосновение с этим «отродием» платят на много больше $$$, к тому же условной «макаки», после курсов туда легче вкатить. Для «бека» - нужно кое-какое образование, желательно математическое, к тому же «база» на много реже меняется, а менеджеры и маркетологи вообще не знают, что это такое...

Для «бека» - нужно кое-какое образование, желательно математическое

Большинство бека – перекладывание JSON в PostgreSQL и обратно. Образования там не нужно вообще.

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

у нормальных людей, фронт это картинка которую видит пользователь.
traefik,nginx,cdn,pgpool/pg,kuber это всё миддлваре - девпёсовское, хотя тут пг под вопросом - таки dba-момент.
бизнес логика, апи, sql, интерконнекты по необходимым сервисам и работа с ними - это бэк, кмк.

Нет, просто разновидность ошибки выжившего.

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

Для таких людей уже в принципе не существует понятие «сложности», на них отражается только лимитированное время 24 часов в сутках.

Если тебя заставить вручную написать одно и то же слово миллион раз - для тебя это не будет сложной задачей. Просто долгой и трудоемкой.

Поэтому такой человек на вопрос «сложно ли тебе» - ответит что нет, не сложно, а зачастую даже интересно.

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

Естественно такой макаке ВСЁ кажется сложным, даже ее работа.

«сложно ли тебе» - ответит что нет, не сложно, а зачастую даже интересно

Потому что он не смотрел проповеди Рича и не знает, что «сложно» и «трудно» — это не одно и то же. Трудности субъективны, но сложность (aka essential complexity) — это объективная характеристика системы, и современные фронтенды — далеко не самые простые из систем.

CSS Modules ведь как раз и генерирует случайные имена для классов

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

Никто не мешает добавить маркерные классы

Если у нас есть маркерные классы, то почему бы в них и не записать стили, а?

если у вас там 38 уровней вложенности флексбоксов в одном компоненте

Дядя, ты дурак? 38 уровней не в одной компоненте, а в 38 разных.

Тейлвинд позволяет это делать. Если очень надо, можно и скомбинировать несколько классов в один.

Через @apply? Это и без Тейлвинда можно.

любая квадратная скобка в классе есть потенциальный косяк

ревьюерам надо помнить, какие отступы разрешены: em? rem? px? кратное двум? четырём? или список разрешённых есть?

Практика показывает, что рано или поздно потребуется что-то нестандартное типа паддинга 3px или вообще calc().

Если панелька переиспользуемая и не выделена в компонент — это не дизайнера косяк, а разработчиков. Так что сначала выделить в компонент, а уже потом менять классы. В компоненте.

Тейлвинд поощряет не задумываться над существованием готовых классов или компонентов, а наговнокодить аккорд прям на месте.

удобные, переиспользуемые, консистентные стили

И чем .flex лучше, чем display: flex? В коде тоже стоит писать? Переиспользуемо же!

const ONE = 1;
const TWO = 2;
const add1 = x => x + 1;

Например, те же CSS Modules или тейлвинд с префиксом.

Чтобы написать CSS Modules нужно добавить семантические названия классов, а вы считаете, что это не нужно.

Если у нас есть маркерные классы, то почему бы в них и не записать стили, а?

Разрешаю, записывайте %)

38 уровней не в одной компоненте, а в 38 разных

Так как ты их увидишь лесенкой, если они в разных компонентах. В готовом DOM разве что.

рано или поздно потребуется что-то нестандартное типа паддинга 3px или вообще calc().

Обязательно. Обоснуешь на ревью необходимость — одобрят.

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

Альо, тейлвинд это набор готовых классов (плюс тулинг). Совокупность эффектов этих готовых классов в пределах компонента и даёт нам стили для этого компонента. Вместо кастомной кулебяки у нас получается стилевое решение, собранное из стандартных запчастей.

или компонентов

Компоненты — не проблема тейлвинда. Ему безразлично, как ты их будешь определять. И если ты забьёшь на модульность, горя хапнешь независимо от наличия/отсутствия тейлвинда.

чем .flex лучше, чем display: flex?

Тем, что не надо повторять в CSS атрибут display: flex для каждого элемента (селектора), к которому его нужно применить, только применить класс (логическое имя) этого атрибута (набора атрибутов) к нужным элементам. А — абстракция, П — переиспользование. Вкупе с разбивкой на компоненты, конечно.

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

Чтобы написать CSS Modules нужно добавить семантические названия классов, а вы считаете, что это не нужно

А если тебе завтра какой-то хрен с форума авторитетно заявит, что надо писать только на бейсике, ты побежишь учить бейсик? %)

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

Собственно, если всё это никак не сказывается на потребительских свойствах программы, то никто тебе претензий и не предъявит.

Если машина, в которой контроллер запрограммирован такими обезьянами, убивает водителя об стену, претензии тоже никто не предъявит. PROFIT!!!

https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/

The ECM software formed the core of the technical investigation. What follows is a list of the key findings.

Mirroring (where key data is written to redundant variables) was not always done. This gains extra significance in light of …

Stack overflow. Toyota claimed only 41% of the allocated stack space was being used. Barr’s investigation showed that 94% was closer to the truth. On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn’t incorporate memory protection to guard against stack overflow.

Two key items were not mirrored: The RTOS’ critical internal data structures; and—the most important bytes of all, the final result of all this firmware—the TargetThrottleAngle global variable.

Although Toyota had performed a stack analysis, Barr concluded the automaker had completely botched it. Toyota missed some of the calls made via pointer, missed stack usage by library and assembly functions (about 350 in total), and missed RTOS use during task switching. They also failed to perform run-time stack monitoring.

Прикинь, сишник просрал-обосрал стэк и кого-то об стену убило. Вот же хохма!

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

Ты опять переводишь тему на некомпетентных программистов. И я опять тебе сообщу что речь была не про них.

Автомобиль с электроникой не надо, да. И не только поэтому.

Ты опять переводишь тему на некомпетентных программистов. И я опять тебе сообщу что речь была не про них.

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

что делать с ТЗ которое пишется исключительно в таком же позитивном сценарии?

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

Я не знаю что было в той ракете, я только заметил что подход «не освобождаем память вовремя» не во всех случаях является дефектом. Например если они математически доказали, что установленной памяти хватит, то всё в порядке. (в тойоте очевидно это не делали)

У бытовых компов такая логика ограничена. Во-первых тут железо и софт могут выбираться пользователем раздельно и из-за текущей памяти он будет сильнее ограничен в выборе. Во-вторых, в бытовых компах стоимость памяти существенна (обычно составляет от 10 до 50% стоимости всей системы). В ракете же это всё единый продукт, который без дополнительных исследований модифицировать после изготовления не положено, а стоимость компа в ней вряд ли даже 0.1% составляет.

Больше работы? Больше технологий?

Больше геморроя.

Так как ты их увидишь лесенкой, если они в разных компонентах. В готовом DOM разве что.

Я и говорю про готовый DOM и трудности с отладкой всего этого дерьма

Альо, тейлвинд это набор готовых классов

Я говорю про цельные стилевые классы для каждого из элементов, а тейлвинд даёт в основном только единичные правила.

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

Стандартные запчасти — это правила CSS, а не тупые обёртки над ними

Тем, что не надо повторять в CSS атрибут display: flex для каждого элемента (селектора), к которому его нужно применить, только применить класс (логическое имя) этого атрибута (набора атрибутов) к нужным элементам. А — абстракция, П — переиспользование.

Эта абстракция убога тем, что она протекает, ибо требует набора соответствующих правил как на контейнере (flex, flex-col), так и на дочерних элементах (flex-grow, flex-shrink и т.д.).

А если тебе завтра какой-то хрен с форума авторитетно заявит, что надо писать только на бейсике, ты побежишь учить бейсик? %)

Вот мне какой-то хрен с форума авторитетно заявляет, что тайлвинд — труЪ. Мне бежать его внедрять?

Дефолтные реализации CSS Modules для React и Vue используют конкатенацию имени модуля, имени класса и хеша.

Потому что из страниц делают приложения, ироды.

+100500 :)) Это пожалуй самое компактное объяснение :)

Ну просто runtime-среда - веб-движки - была изначально заточена на небольшие правки статического контента, который, в свою очередь, формировался на языке (HTML+CSS), абсолютно ортогональном классическому программированию UI. Все это развивалось путем добавления каких-то нашлёпок-прибамбасов. Плюс, наличие специфики конкретных движков и версий Javascript, с чем тоже раньше очень сильно приходилось считаться. В результате и получилась какая-то неудобоваримая хрень ))

«Фронт» это же не только браузер. Отдельно под Android, отдельно под iPhone, под всякие телевизоры с приставками - и всё это «фронты». И вот разработчики под Tizen, допустим, объявили забастовку и не хотят переходить на API v8. И бэку, и БД теперь надо поддерживать все 8 вариантов запросов, с которыми могут обратиться разные фронты.

Тоже, в целом, те же страдания.

… И вот разработчики под Tizen, допустим, объявили забастовку и не хотят переходить на API v8. И бэку, и БД теперь надо поддерживать все 8 вариантов запросов, с которыми могут обратиться разные фронты.

Не совсем понятно, какое отношение бэк и БД имеют к API v8. Другое дело, что все фронтовое барахло благополучно переползло и на программирование мобильных приложений)

… Отдельно под Android, отдельно под iPhone … те же страдания.

В принципе - да. Если обобщить, то «Backend» существенно более стабилен чем «Frontend», где нужно клепать отдельный софт для разных клиентских устройств учитывая специфику различных движков, OS и их версий.

Не совсем понятно, какое отношение бэк и БД имеют к API v8

Менеджеры уже напридумывали новых, полезных полей в БД, а где-то в мире всё ещё гуляет какой-то древний Андроид который про них ничего не знает и шлёт запросы так, словно нет никаких новых полей (по API v1).

Так понятнее?

готовый DOM и трудности с отладкой всего этого дерьма

С трудом верится, что ты не найдёшь способ идентифицировать элементы, если понадобится. Идентификаторы, классы, дата-атрибуты (которые можно даже отключить для прода), комментарии. Но нет, мы будем ломать глаза о сгенерированные CSS Modules всратые имена классов %)

тейлвинд даёт в основном только единичные правила.

Потому что это его задача, его single responsibility. Разбивкой на компоненты занимается условный реакт. Он определяет границы компонента как минимальной единицы для переиспользования, а не CSS-утилиты.

Представление — это разметка, стили и логика вместе, не надо их кроить по отдельности.

Стандартные запчасти — это правила CSS, а не тупые обёртки над ними

Свойства CSS, особенно с непрерывным диапазоном значений (padding: 13,68px, padding: 3.5em) — это не стандартные запчасти, это сырой материал, из которого тейлвинд делает стандартные запчасти (p-1, p-2, p-3).

Эта абстракция убога тем, что она протекает

Разделение на контейнеры и элементы не тейлвинд привнёс, оно всегда тут было. Главное — чтобы абстракция не вытекала за пределы компонента.

какой-то хрен с форума авторитетно заявляет, что тайлвинд — труЪ. Мне бежать его внедрять?

Желательно бегом %)

… а где-то в мире всё ещё гуляет какой-то древний Андроид который про них ничего не знает и шлёт запросы так, словно нет никаких новых полей (по API v1). Так понятнее?

Я уж подумал, что это про Javascript API v8 ))

С древними Анроидами можно проще поступить - за «годик до» вежливо предупредить, что поддержка заканчивается. Ну и потом обламывать. Решать проблемы забастовок - это конечно сложнее) Но это уже относится к организационным сложностям, а не к техническим.

Так и в реальности на передовой труднее, чем в тылу.

на передовой труднее, чем в тылу

Бэка служба и опасна, и трудна, но на первый взгляд как будто не видна.