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

Потому что говнокодеры.

/thread

имхо такие вопросы возникают какую-то элементарную логику нужно обернуть в красоту неземную

Можно писать просто. Но на этом сложнее заработать.

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

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

Ага, знаем мы таких простаков. Вместо ngFor - велосипед, ломаюшийся в неожиданных местах

Гусь ловко подменил понятия и выставил человека виноватым. Хороший гусь.

Это кто тебе такую глупость сказал?

С голосами в голове везде сложно

Потому что говнокодеры.

Если б только фронтендеры. Я тут столкнулся с тем, что эмбед упорно пишут отталкиваясь от позитивного сценария. Конечно, все это говно отправляется на переписание, но что делать с ТЗ которое пишется исключительно в таком же позитивном сценарии? Люди живут в мире розовых пони и какают радугой, забывая, что вокруг говно, и это печально.

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

не надо верстать таблицами плес((

не надо верстать таблицами плес((

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

Надо. Не надо простыни из css-костылей организовывать.

Я тут столкнулся с тем, что эмбед упорно пишут отталкиваясь от позитивного сценария.

Ебмеддед – это вообще мем. Почитай, что тут на ЛОРе ебмеддщики пишут. Каждый второй даже сишку не знает нормально, но зато считает себя экспертом в этом недоязычки.

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

С другой стороны, это похоже давно общепринятая практика, что доказывается вот этой историей аж из 1995 года или раньше:

From: k...@rational.com (Kent Mitchell)
Subject: Re: Does memory leak?
Date: 1995/03/31

Norman H. Cohen (nco...@watson.ibm.com) wrote:
: The only programs I know of with deliberate memory leaks are those whose
: executions are short enough, and whose target machines have enough
: virtual memory space, that running out of memory is not a concern.
: (This class of programs includes many student programming exercises and
: some simple applets and utilities; it includes few if any embedded or
: safety-critical programs.)

This sparked an interesting memory for me.  I was once working with a
customer who was producing on-board software for a missile.  In my analysis
of the code, I pointed out that they had a number of problems with storage
leaks.  Imagine my surprise when the customers chief software engineer said
"Of course it leaks".  He went on to point out that they had calculated the
amount of memory the application would leak in the total possible flight time
for the missile and then doubled that number.  They added this much
additional memory to the hardware to "support" the leaks.  Since the missile
will explode when it hits its target or at the end of its flight, the
ultimate in garbage collection is performed without programmer intervention.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Тыц: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125

А потом ВНЕЗАПНО это ПО будут использовать в другой ракете - а что, он уже проверенный. Ох… хочу опять работать по КТ-178.

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

В чем измеряется сложность? Как её измерить?

Масса вытошненного адекватно после предложения пописать XYZ.

да никуда он не сложнее

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

А что там с Blazor? Есть ли сложность?

от css ты никуда не спасешься все-равно

был вот сервелат, был неплохой, но его выпилили, потому что гугл везде толкал свой убогий html5

В чем измеряется сложность?

В «абстрактных попугаях» ©.

Как её измерить?

В «конкретных попугаях» ©.

— Фронтенд вообще-то сложнее бэкенда
— А кто его сделал сложнее?
— Кто его сделал сложнее, а? кто?! 😠 😠 😠

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

На canvas же.

Есть Haxe

но зато считает себя экспертом в этом недоязычки

Если бы они ещё себя считали экспертами только в сишке…

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

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

PS. Если что - подобный способ решения проблем ни капли не удивляет - он в эмбеде не просто массовый, он типовой.

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

Мне тут говорили, что у Настоящих Программистов память не течёт. Хочешь сказать, суровый ебмеддед пишут обезьяны?

PS. Если что - подобный способ решения проблем ни капли не удивляет - он в эмбеде не просто массовый, он типовой.

А потом случается вот это: https://en.wikipedia.org/wiki/Ariane_flight_V88

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

Сравнил библиотеку готовых компонентов и подход к использованию стилей (atomic/utility-first CSS).

А потом случается вот это:

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

Хочешь сказать, суровый ебмеддед пишут обезьяны?

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

никуда он не сложнее

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

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

так можно говорить только если никогда не сталкивался с интеграциями со всякими, особенно крупным, говном

И да, гусь с картинки намекает, что фронтэндеры намутили фреймворков, но если серьезно, то это чтобы упрощать решение новых поставленых перед ними задач. Пикрелейтед

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

это ты про луну25?

Я тут столкнулся с тем, что эмбед упорно пишут отталкиваясь от позитивного сценария. Конечно, все это говно отправляется на переписание, но что делать с ТЗ которое пишется исключительно в таком же позитивном сценарии?

Может, в «мирном» эмбеде и пишут в позитиве, но в негражданском всегда все писали исключительно в жестком негативе. Если даже по каким-то причинам негативные сценарии нельзя включить в ТЗ - их отсутствие старались компенсировать избытком в программе испытаний.

Так что, надеюсь, вам попалось исключение

если никогда не сталкивался с интеграциями

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

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

У раздающего листовки нет задачи убедить тебя хотеть электрочайник, его задача — избавиться от листовок. Тоже не всегда тривиальная, да — потому что приходится иметь дело с мясными мешками %)

перфекционизму вы не только становитесь врагом начальства и финансистов, но и все равно никогда не достигнете желанной 100%-ной безошибочности.

А просрав ракету на 300 миллионов ты конечно же врагом финансистов не становишься.

Нет. Там уже за это отвечают другие люди, причем скопом. Над кодером всегда есть множество людей, отвечающих за надежность.

И этот подход нужен только для write only вёрстки. Базировать на нём приложение, планируемое для долговременной разработки и поддержки, — привлекательно, но уродует и усложняет проект в перспективе.

Потому что сделать хороший интерфейс это вам не алгоритм с бумажки по стрелочкам закодить.

этот подход нужен только для write only вёрстки

Если не разбивать представление на переиспользуемые компоненты (React, Vue и тому подобные; или даже просто куски шаблонов; можно даже БЭМ приплести), а херачить всё одной простынёй с utility-first стилями — то да, что-то найти и исправить там будет невозможно. В рамках же одного компонента найти, исправить или написать заново нужные стили будет даже легче, чем обычный CSS.

Потому что

• Не надо мучительно придумывать всратые имена типа .card__wrapper--col (и постоянно писать для них одни и те же стили), просто делаешь <div class="flex flex-col">...</div> и всё.
• Не надо с тоской смотреть на бесконечные классы с одним и тем же повторяющимся атрибутом для цвета текста и переживать за размер файла стилей — просто вешаешь class="text-primary" и всё, этот класс будет упоминаться в итоговом файле стилей ровно один раз.
• Не надо мучительно вспоминать, какой там у нас основной размер текста (и в итоге их всё равно на одной странице будет штуки три разных в разных местах, потому что дизайнер опять играл со шрифтами и проиграл), просто делаешь class="text-base" и всё.
• Не надо на митинге жаловаться, что джуны опять нахерачили 18 размеров отступов в форме логина, в трёх разных единицах измерения, поэтому её едва уловимо, но неприятно для глаза попердолило, и все попытки что-то поправить делают только хуже.
• Не надо вообще писать новый CSS, просто навешиваешь/снимаешь классы для нужных атрибутов и радуешься жызни.

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

Так у приложения в спеках наверно указаны требования по памяти и максимально допустимое время работы. Если не указаны - то да, плохо.

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

Мне тут говорили, что у Настоящих Программистов память не течёт. Хочешь сказать, суровый ебмеддед пишут обезьяны?

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

Все языки со сборщиком мусора по сути основаны как раз на втором подходе - пусть «течёт», а потом мы отсеем нужное от ненужного и почистим. И даже без явного сборщика мусора может существовать второй подход, например на уровне ОС: вызываем текущий процесс, потом он убивается и нам пофиг на его память. Или используем локальный аллокатор с пулом, в конце операции удаляем пул целиком и опять не возимся с конкретными аллокациями из него.