LINUX.ORG.RU

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

flant ★★★★
()

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

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

vvn_black ★★★★★
()
Ответ на: комментарий от tiinn

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

DumLemming ★★★
()

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

MoldAndLimeHoney
()

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

urxvt ★★★★★
()

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

Lordwind ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

aiqu6Ait ★★★★
()

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

Xintrea ★★★★★
()
Ответ на: комментарий от HE_KOT

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

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

Xintrea ★★★★★
()
Ответ на: комментарий от HE_KOT

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от aiqu6Ait

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

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

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

С другой стороны, это похоже давно общепринятая практика, что доказывается вот этой историей аж из 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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

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

aiqu6Ait ★★★★
()
Ответ на: комментарий от buddhist

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

t184256 ★★★★★
()

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

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

lovesan ★★
()
Ответ на: комментарий от buddhist

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

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

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

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

quickquest ★★★★★
()

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

Pr0f1t
()

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

ddidwyll ★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

theNamelessOne ★★★★★
()

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

anonymous_sama ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

vaddd ★☆
()
Ответ на: комментарий от vaddd

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

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от lovesan

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

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

Nervous ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

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

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

vaddd ★☆
()
Последнее исправление: vaddd (всего исправлений: 1)
Ответ на: комментарий от lovesan

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

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

Nervous ★★★★★
()

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

goingUp ★★★★★
()
Ответ на: комментарий от Nervous

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

lovesan ★★
()

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

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от Nervous

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

HE_KOT
() автор топика
Ответ на: комментарий от aiqu6Ait

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

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

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

vaddd ★☆
()
Ответ на: комментарий от lovesan

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

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

Nervous ★★★★★
()
Ответ на: комментарий от HE_KOT

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

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

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от vaddd

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

vaddd ★☆
()
Ответ на: комментарий от Nervous

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

static_lab ★★★★★
()

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

thesis ★★★★★
()
Ответ на: комментарий от static_lab

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

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

Потому что

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

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

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 8)
Ответ на: комментарий от aiqu6Ait

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

firkax ★★★★★
()
Ответ на: комментарий от Nervous

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

firkax ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

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

firkax ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)