Comments 95
HTML был прост. Когда-то очень давно. Когда его использовали по первоначальному назначению как язык гипертекстовой разметки.
HTML и сейчас прост. Даже проще чем было, т.к. убрали теги форматирования и оставили чисто разметку. И JS с CSS достаточно просты в чистом виде. Я не являюсь веб-разработчиком вообще, но вполне знаю и HTML, и JS, и CSS - не наизусть конечно, но знаю как это устроено и что гуглить чтобы получить желаемый результат. При этом не знаю ни одного фреймворка и до сих не могу для себя сформулировать, что они делают такого что нельзя сделать без них:)
В общем, мне кажется что в современном фронтэнде накручено весьма много лишней сложности за счет фреймворков и инструментов разработки.
и до сих не могу для себя сформулировать, что они делают такого что нельзя сделать без них:)
поддерживать сделанное на фреймворках проще чем разбираться в 1001 велосипеде
не могу для себя сформулировать, что они делают такого что нельзя сделать без них
А они ничего такого и не делают. Как и любой язык программирования не делает ничего такого, чего нельзя на машинном коде выразить. Вопрос удобства и времени.
Если говорить о проекте, в котором не требуется поисковая выдача(от слова совсем), то вёрстку можно сделать одними дивами и всем будет все равно. Но когда речь идёт об прямо противоположном варианте, то не просто так в стандарте html на данный момент более 140 тегов и созданы они не просто так. Также в семантической вёрстке нужно не просто знать какие теги за что отвечают, но и учитывать сам проект, так как каждая страница будет состоять из определенных сущностей и важно понимать как правильно передать значение этих сущностей машине Гугла. И НЕ ДЕЛАТЬ типичных ошибок, что header это только шапка сайта, footer это обязательно подвал, а main это основной контент и т.д Почитав стандарт все станет не так однозначно
Фреймворк - это типовое решение типовой задачи. Вообще говоря, фреймворк - это всегда следствие, а не причина. Сначала возникает, задача, потом её решение, а потом, когда это решение требуется поддерживать и модернизировать - решением становится какой-никакой фреймворк. Если задача типовая, если фреймворк не надуманный - он становится популярным и востребованным.
По себе, разраб с 20+ стажем в состоянии сеньор/архитектор, могу сказать что больше всего напрягает именно CSS. С его помощью можно сделать нынче почти все, но надо хорошо разбираться. Когда обычный контрол магией CSS превращается в нечто совершенно другое это впечатляет.
т.к. убрали теги форматирования и оставили чисто разметку.
Там новых тегов много добавили ещё. Для всяких агентов браузеров там, для доступности людям с ограничениями, для поисковых систем и т. д.
Увы, статья “Forgiving” Browsers Considered Harmful была права - именно вот это всепрощение с низким порогом входа и привело к тому раздутому кошмару со сложностями на ровном месте, которое мы имеем сейчас.
Теперь проще всё выкинуть, уничтожить Web и начать что-то новое, чем исправить горбатого.
“Forgiving” Browsers Considered Harmful
Не читал, но сама идея прощабельности чрезвычайно характерна для технологий, не предназначенных для промышленного использования. Главное, вовремя осознать, когда начинается промышленное использование. Её ужасные корни до сих пор можно встретить там и сям. Например, браузер спокойно кушает '1' + 1, и никаким каком его не заставишь взрываться и отрывать шаловливые руки (вообще, моя розовая мечта!).
Теперь проще всё выкинуть, уничтожить Web
Ну нет. Достаточно ввести "use strict2";. Или "use superstrict";. Или хотя бы "use strict. Im Fukken Serious!";.
А ещё есть браузеры, использующие свои диалекты Экмы, которые умеют в такое из коробки. (В строгую типизацию, а не в use, предложенный выше).
"Результат: имеем 15 16 конкурирующих стандартов" (c)
Я как бэкендер считаю, что фронтенд сильно сложнее бэка, так как требует огромного количества постоянно обновляемых знаний и навыков, зоопарки фреймворков и пакетов, постоянные новые версии, лютейшая функциональщина в современном JS, особенности разных браузеров и "how to center div". И поверх всего этого отношение "ну ты же только кнопочки рисуешь". Мдэ.
Как будто на бекенде нет проблем, когда зоопарк сервисов на .Net Framework, .Net Core, python 2/3, Go, зависимости на фортране, деплой только в устаревший облачный оркестратор обвешанный костылями для поддержки всего этого. Ах да, особенности разных SQL БД и боттлнек в шине данных, как же без этого)
Есть сложные фронтенды, есть сложные бекенды. Также как есть простые фронтенды и простые бекенды.
В целом согласен, что у всего есть сложность. Но как фуллстек имею возражения. В бэке несложного монолита я МОГУ обойтись одним голангом и постресом, которые в общем-то обновляются раз в пару месяцев. И мои сложности начинаются, когда я хочу 10000 пользователей вместо сотни. В маленьком монолите сложностей особых нет.
Во фронте я стартую сразу с 10ка технологий. По несколько обновлений в неделю только основных зависимостей. TS помогает, но всё плохо. Язык интерпретируемый, в переменной может оказаться всё что угодно - ts-компилятор помогает, но не гарантирует! Два DOM: react + настоящий. Навигация управляет логикой - в SPA хотя бы можно обойтись одной точкой входа. Состояния только в компонентах, хуки это не компоненты, глобальные и локальные переменные тоже не состояния - и управлять с учетом рендера. Форматы MIME и кодировки text/json/XML. Куки и куча хранилищ браузера. Кросс-запросы и origin's стоили мне нескольких дней жизни. CSS можно прикрутить несколькими способами - и еще смотреть в браузере откуда подтянулось! А ТАКЖЕ куча устройств с различными размерами экрана - писать что-то скрытое, но что открывается при определенной ширине экрана...
Хаос начинается с 5 страничек с разными урлами - у меня основная боль именно в UI/UX. И это с учетом того, что это мелкий проект, и я могу не тащить легаси.
По бекенду: не только от количества пользователей сложность, может быть B2B проект под 100 пользователей но с большими нагрузками, сложной доменной моделью, многопоточными алгоритмами, ML, permissions, распределенными транзакциями, кафкой и всем остальным фаршем. Про аутентификацию не надо забывать, она обычно идет из коробки но есть нюансы. CORS это проблема бекенда, он запрещен по умолчанию в целях безопасности, поэтому клиент ругается. Не знаю, как там в Go, но в .Net все конечно идет из коробки, однако допиливать всегда что-то нужно. Конечно зависит от проекта, CRUD не проблема - но и на реакте todo-app за пару часов запилить можно, только кто за такие проекты платить будет?
Во фронте проблема с зависимостями решается фикс версиями в package.json, я перешел на это пару лет назад и всем советую. Обновления большинства библиотек смело можно игнорировать.
В переменной все что угодно - смотрите в сторону zod/yup. Валидируем данные с бекенда и от пользователя и больше не боимся атомной бомбы. С другими проблемами тоже есть решения: какой-нибудь jotai/mobx для управления состоянием.
Да, технологий дофига нужно, сейчас к сайтам высокие требования в B2C. Вот в B2B полегче, там иногда можно ограничиться chrome/safari, 1440+, без поддержки мобилок, стандартный css из UI-framework.
Я ж не всё перечислил :) В моем исполнении клиент почти зеркально отражает апи бэкэнда, нечасто удается повторно заюзать эндпоинт сервера. Авторизацию также надо продумывать на клиенте - например не передавать пароль в чистом виде, сначала запрашивать openkey, а на сервер передавать уже хэш. С ролями тоже очень весело - хочется натянуть одну страничку на все роли, но говно получается.
В итоге подстраиваю апи сервака, чтобы js-клиент был более аккуратным. Усложнить бэкенд проще, чтобы упростить фронт - такое пока имхо.
Решабельно всё, но вход в голанг сильно проще для меня был, чем фронт. Я js-проект запускал несколько дней - до видео в ютубе опустился. Хотя первый сайт на HTML+CSS сделал 25 лет назад.
А расскажите про openkey подробнее, это что-то похожее на SRP-6? Мне он нравится, но слишком уж повально все передают пароль в https, и не парятся. Так что я тоже забил. А если между терминирующим nginx и бекендом окажется дырявый логгер - то это проблема devops)
Меня эта тема пару лет назад интересовала. По памяти напишу. Смысл не в том, что кто-то посередине окажется. А в том, чтобы сервер вообще пароля не знал, который может использоваться где-то еще. И какой-то "полезный" сервер может собирать образцы с логином. В общем, серваку сам пароль и головняк вообще не нужны.
Потому при регистрации пользователь генерирует openkey, добавляет salt, хеширует. И на сервер уходит логин, openkey и hash. Какой-то алгоритм гарантирует, что пароль из этого восстановить нельзя. При логине клиент запрашивает openkey к логину, добавляет salt, и отправляет вторым запросом логин с хешем. Сервер сравнивает сразу хэш в бд - сам пароль ему пофиг.
В контексте коммента выше в клиенте нужно было согласовать длину полей, соль и обработчики.
- до видео в ютубе опустился.
Я не знаю почему видео в ютубе считается чем-то плохим, возможно это из-за того что 8-10+ лет назад большинство материалов было низкого качества, но сейчас хорошего контента в разы больше, при чём часто он встречается на каналах с 0-20к подписчиков(особенно если что не особо популярное делают), поэтому нужно задавать более подробные вопросы или поглубже порыться. Как по мне видео с настройкой различных инструментов иногда удобнее посмотреть в формате видео, т.к. из статьи не всегда можно понять правильно ли ты всё настроил и должно ли так быть, т.к. в статье просто не пишут об этом т.к. думают что ты это знаешь либо информации слишком много и её просто убирают из статьи.
Видосики в ютубе иногда помогают. Выше в контексте того, что голанг я запустил по тексту, а с реактом мне документации оказалось недостаточно. Сейчас-то пофиг, а вот прихненел несколько лет назад - оказалось неочевидным, что после установки node.js + `npm i create-react-app` нужно отдельно добавить `npm i` и подгрузить еще 400Mb в папку проекта. А чтобы результат увидеть, то еще браузер запустить. Когда в голанге котлеты отделены от мух заранее, а сам код в байтах измеряется, и результат в консоли.
Нормальный фреймворк взять не пробовали, а не хипстерскую поделку? Вам не нужны десятки левых зависимостей, прикрученных изолентой, не нужно дублировать дом, нет никаких хуков, состояние храните где хотите и тд.
Кросс-запросы и origin's стоили мне нескольких дней жизни.
Братка, дай обниму...
А мы вам ещё WebAssembly сейчас будем задвигать. У вас будет три DOM: два пишем, один в уме!
Далеко не каждому фронту нужен react, ts, webpack и т.п., большинству jquery хватает. Вы просто описали вариант с тонким беком и толстым фронтом, можно кучу диаметрально противоположных вариантов привести: википедия, либрусек, руторрент и легион других.
Денис, не было задачи объять необъятное. Могут быть и полярные варианты: сервер без фронта, сайт без бэка. Здесь ИМХО, что вход во фронт был для меня тяжелее даже с опытом ворда и HTML+CSS-сайтов. За пределами "входа" особого смысла сравнивать нет - проекты и опыт у всех разные.
Так html, css, jquery - это уже фронт )) Ему как раз соответствует ваш пример бека простенький монолит на голанге. Вот их и надо сравнивать. А если со стороны фронта начинаем обсуждать ts, react, spa, локалстораджи, styled css, responsive, то и со стороны бека надо сравнивать с сопоставимым примером, вроде того, что вам привели - многопоточность, rbac, ddd, распределенные хранилища, валидации кешей, highload. И тогда сложность входа будет у них сопоставима.
В первую очередь мы говорим о субъективном. Потому норм, что у нас разное видение. В ваших словах вижу, что я пока поверхностно юзаю голанг. Соглашусь, вероятно, что когда доведу до ума фронт, то буду иметь сложности в бэке. И возражу - мы сравниваем широкое и глубокое. В бэке сложность растет по мере углубления и, подозреваю, нелинейно. Во фронте сложность входа не связана с html+css - тут сложность на уровне ворда. JQuery пролистнул, но сравню с VBA. Но SPA уже далеко не ворд - есть router, который диктует логику, есть fetch+promises+race'сы. Bootstrap помогает - скрывает кучу интересного. Но как я писал выше, на старте сложность фронта сильно выше голанга.
Со временем фронт тоже не упрощается. Почему-то народу проще с нуля переписать на новом фреймворке, чем старое поддерживать. Но тут имхо. И замечу, в голанге лопатить старый код сильно приятнее. Хотя бы из-за запрета цикличных импортов.
Но ведь это все привычные проблемы и на некоторые из них ответы на SO висят уже более десяти лет. Конечно, вы правы относительно того, что сложность может быть и там и там, просто из личного опыта я часто могу довольно быстро понять архитектуру дотнет проекта, просто на него взглянув, чего часто не скажешь о цепочках джаваскриптовых промисов, мешанине из пакетов для всего на свете, компонентов и визуальных хаков в реакте. Возможно, конечно, это дело привычки.
Простите...)
Я как бэкендер считаю, что фронтенд сильно сложнее бэка
А мне кажется вы начинающий верстальщик, и топите за свою специализацию использую странную аргументацию в пользу сложности фронтенда: лютейшая функциональщина или how to center div, что не является вызовом в современном фротне.
vue/react знает каждый, вкатиться в него можно за неделю, а вот выстраивать огромные spa, подбирать архитектуру под возможность переиспользования кодовой базы в связи с постоянным обновлением дизайна, оптимизация размеров бандлов, оптимизация рендеринга и тп это уже под силу профи в сфере фронтенда (с зп под 3k).
Я разрабатывал небольшие spa на react и vue, но все равно считаю себя бэкэндером. Не скажу что фронтенд это просто, но главное отличие его от бэка - цена ошибки.
Вам кажется. Ловите минус в карму) может быть это научит чуть более вежливому общению. За неделю вкатиться в реакт, как же) за день понять, что такое функция и прототип, за второй, что такое монада, за третий, что такое промисы и асинхронность, а за четвертый - что такое virtual dom и как он работает. Ну и ещё три дня настроить вскод и подебажиться. Каждый может ага.
Справедливости ради вот эти "функция, прототип, промисы и асинхронность" - это самые основы Javascript. Виртуальный DOM - это способ перевалить на библиотеку свои обязанности по аккуратному и производительному обновлению частей страницы. Это способ меньше думать в привычных повседневных задачах. Единственное в вашем списке, что может вызвать вопросы - это монады. Мир современного JS сильно повернут в сторону ООП, и люди часто не знают, как какие штуки называются в терминах ФП, хотя что-то очень похожее используют постоянно. Если начать смотреть уже реализованные примеры, то сразу начнутся озарения в духе "ааа, так вы вон ту штуку этим словом обозвали". Так что для человека, занимающегося фронтендом, неделя на "вкатиться" в конкретную библиотеку и начать делать хоть что-нибудь полезное - реальность. Там гораздо сложнее может быть разобраться в том, что люди на местности уже наворотили, чем в самой библиотеке. Хотя если вкатываться с нуля - то да, естественным образом упрешься в незнание основ, и за неделю вообще ничего не получится.
Так мы всё-таки говорим про фронтендера, например, с N летним бэкграундом JS + jquery, или про того, кто всю жизнь занимается бэкендом, и с вебом до этого был никак не связан кроме как "вот тебе api route, возьмёшь там Json"? Я утверждал, что во фронтенд вкатываться сложно именно для второго типа, а не для того, кто знает основы и с ними несколько лет работает, и просто хочет освоить новую библиотеку...
кто всю жизнь занимается бэкендом
Вы правда считаете, что тот кто всю жизнь занимается бэкендом хотя бы раз ради спортивного интереса не открыл консоль браузера и не попытался разобраться о чем там говоря фронтендщики, что это за промисы такие? Я еще могу понять что фронтендер не захочет поднимать докер с постгрей, джавой и т.п ради поиграться в хеловерд, хотя опытный разработчик из любой сферы всегда стремится изучать что-то новое.
А монады, да, это только во фротне и только на js )))
Ну вот я занимаюсь бекендом
Из фронта я знаю jquery и vue.js и вообще образно как оно там работает
в остальном у меня прям очень стойкое ощущение что "пи...ц какойто несусветный, как они там чото понимают в этой мешанине".. на всех проектах сколько в фронт не заглядывал..меня прям ужас одолевает, я конечно понимаю что js имеет своеобразный синтаксис и многие еще любят вложенные процедурки писать...помноженный на npm-мный кошмар, но почемуто у меня всегда то что я вижу ассоциируется с php нулевых годов с гвоздями прибитыми костылями в виде if id==="radioknopka1" && action==="sobitie" { something } ... бл..ладно я в одном бы месте так видел...но оно какоето массовое причем даже если какието адекватные фреймворки там есть но всёравно такое сплошь и рядом и почемуто все считают что это норм, может мне так на проекты везет и на квалификацию фронтов... но хз...пока я идеала не видел
и каждый раз если приходится чтото править в фронте...чёнить простое, типа поменялся какойто флаг в json..был например isAvailable стал isActive ... ну логично же поменяй маппинг какойто в одном месте где пакет разбирает но нет блин всегда это выливается в исправление полумиллиона строк кода
Ещебы фронт уровень входа низкий имел...этож кошмар какойто
А когда показываешь фронтам адекватный фреймворк с ооп, разделением декларативной композиции и императивной логики, минимумом бойлерплейта, неглупыми моделями - они его люто минусуют.
Судя по статистике одобрения этого адекватного фреймворка можно задаться вопросом, а адекватный ли он?
Не нужно выдавать желаемое за действительное.
Вы считаете адекватным определять "адекватность" по "статистике одобрения"?
Статистика, на то и статистика, чтобы давать оценку тому, что происходит. И картинку вы подобрали прям идеально, когда большинство считает что нечто является калом, а один считает это нечто есть нектар, не значит что большинство ошибается, а значит стоит задуматься о том, а нектар ли это.
В постковидные времена многим вкус и нюх отбило... /i
Вы, как мне кажется, сравнивает написание кода на бэкенде с написанием кода на фронтенде. Тогда вы правы.
Но часто под "бэкенд" понимается и вся инфраструктура, облако, асинхронное взаимодействие в гетерогенных сетях, внешние интеграции и т.д. Пусть сферическому бэкендеру в вакууме это все знать не надо, но по мелочи отовсюду.
CSS - женский удел. Занятное утверждение...
Ну а если серьёзно, то CSS и HTML - изначально прекрасные инструменты, особенно если сам не пытаешься там что-то усложнять.
CSS - женский удел.
Киндер, кюхе, кирхе унд каскаден таблицен стилен? /s
Да и вообще программирование исторически женское занятие ;)
/hj
…когда HTML-код плохо структурирован, становится труднее писать для него CSS.
Я бы добавил в этот список ещё один важный пункт (либо как продолжение данного пункта). Про крайне актуальную нынче адаптивность вёрстки. Формально, конечно, это тоже задача CSS — однако, прежде всего, это зависит от того, насколько грамотно HTML-макет спроектирован (а это понятие более обширное, чем структурирование).
То есть, верстальщик должен знать и заранее учитывать все моменты и тонкости, необходимые для реальной адаптивности макета, заранее предвидеть как "развести" элементы при адаптации, да ещё и не нарушив дизайн. В ряде случаев это та ещё головоломка, решение которой требует недюжинной логики, знаний и интеллекта — простым "знанием тегов" тут никак не обойтись.
Однажды я совершил страшную ошибку. Десять лет назад я поверил залихватским утверждениям одного… гм… графического алгоритмиста: «Да с этим вашим UI на HTML справится любая макака!» Ошибка стоила мне больше тысячи долларов и я все выходные днём и ночью переделывал то, на что было выделено несколько недель.
Флекс? Грид? Таблицы? Абсолютное позиционирование с перерасчётами на скриптах!
Стили? Эффекты? Инвоук в бизнес-логику для обработки изображений!
Запросы? Кастомные псевдоклассы? for, да ещё на стороне браузера (C++)!
Но эти деньги были потрачены не зря. Недавно общаясь с разработчиком, который неуважительно отозвался об объёме работ при создании VS Code, я сразу понял, с кем имею дело.
Если попытаться достаточно углубиться в CSS, то он окажется не таким уж и простым инструментом...
Почему люди считают, что фронтенд-разработка – это легко?
Потому что они никогда с ней не сталкивались.
Бэкенд – это чёрный ящик, который проделывает свою магию и просто выдаёт данные во фронтенд. Фронтенд-разработчику в итоге «просто» нужно отобразить эти данные, добавить цвета и выстроить макет
Времена, когда фронт просто отображал данные безвозвратно прошли. Фронт всегда был посредником между пользователем и приложением. А сейчас, в эпоху SPA фреймворков, это еще более актуально. По сути значительная часть логики из бэка переходит во фронт. Фронт-разработка – это вам уже не слайдер прикрутить.
Фронт только кажется простым. Да он и прост, пока не требуется выполнять указания дизайнера... особенно, если стандартный функционал браузера его не устраивает.
Все таки разница во фронтенде и бекенде в цене ошибки или в отвественности. Если где-то поехала кнопка, то это неприятно, конечно, но не так критично, как например, если вдруг данные в БД пишутся не туда или еще каие-то ошибки в бизнес логике. Конечно, для заказчика фронтенд возможно важнее бекенда, это это только потому, что его видно
Конечно, для заказчика фронтенд возможно важнее бекенда, это это только потому, что его видно
Заметил интересную тенденцию. Корейцам действительно фронт важнее, они заставляют пилить сначала фронт, чтобы клиенту было что показать, а бек, по их мнению, "подтянется". Тогда как остальным бек важнее, ибо там цена ошибки может стоить не только репутации, но и денег, иногда приличных.
Согласен, но заказчик иногда недооценивает бэк и явно переоценивает фронт
Так это логично. Он же бэк не видит, только фронт видит. Он не знает, что там в бэке вообще нужно и понамешано
забавно бывает, ты пилишь три спринта какуюнить пятиэтажную интеграцию с 50 сервисами, чтобы человек кнопачки потыкал и увидел данные из 50 сервисов в списке...и мог ими рулить...кто главный? фронт!! вон кнопочки тыкаешь чото меняется! фронты все сделали, молодцы! им премию и почёт
Это вот блин как банковскую карточку оценивать по тому что на ней картинка красивая нарисована, а то что чёто там ктото программирует..ну и уволить их всех, самые главные там дизайнеры же, они картинки рисуют для клиентбанка....транзахции какието, холды, платежные файлики, реджекты, бред какойто, все знают что кнопочки на фронте всю магию делают
фронт важнее, они заставляют пилить сначала фронт, чтобы клиенту было что показать, а бек, по их мнению, "подтянется"
Один из текущих проектов у нас сейчас как раз такой, ооооо...
В стиле
"Ну вот вы вот так вот напилите код, а фронтендер вот новый у нас на аутсорсе ест, он молодец, он там уже почти всё сделал до вас (нет. Процентов 10 в лучшем случае), там уже всё показано "наверх к начальству и заказчику", все довольны, всё красиво, кнопочки красивые, анимации, всё так живо и стильно, и данные в выпадающих списках все есть, так красиво оформлено, да он почти всё уже сделал, осталось то на деле - захардкожены данные которые должны с бэка браться, голый фронт (на vue, если не ошибаюсь), вам осталось фигню, всего - то базу данных накидать да код наваять, ну и архитектуру проекта давайте на ходу придумаем (в т. ч. и структуру БД), ага, ну и по базе данных - нормализация это вообще вред, т. к. джойнить надо много в запросах, замедляет.
ТЗ - да потом напишем постфактум, пока все же всё знают да разбираются, посоны, ну там ещё поменять конечно надо вот это и вот это, ну и СУБД поменять на Постгрес (в базе 500+ таблиц), ага, ну и одновременно на микросервисы монолит распилить, там ж фигня совсем"
(озвучивал это человек, который код в последний раз писал на Паскале (причем в годы его (Паскаля) актуальности)))))
И я не шучу
Проект на 200-400к онлайна, лол (взамен текущего, что на старом стеке)
ШТОШ, зоонаблюдаем ))
там уже всё показано "наверх к начальству и заказчику", все довольны, всё красиво, кнопочки красивые, анимации, всё так живо и стильно, и данные в выпадающих списках все есть, так красиво оформлено, да он почти всё уже сделал, осталось то на деле - захардкожены данные которые должны с бэка браться, голый фронт (на vue, если не ошибаюсь), вам осталось фигню, всего - то базу данных накидать да код наваять, ну и архитектуру проекта давайте на ходу придумаем (в т. ч. и структуру БД), ага, ну и по базе данных - нормализация это вообще вред, т. к. джойнить надо много в запросах, замедляет.
Откуда вы знаете нашего заказчика??!! /s
У нас 99% заказчиков такие. Работаю на галеру, мы аутсорсеры - субподрядчики, все заказы из Кореи. То есть это даже не конечные заказчики, далёкие от ИТ, а "профессионалы", много лет работающие в этой сфере.
Заблокируйте эту кнопку, и неважно куда там на бэке что-то пишется )
Зато если фронт отошлет на бэк операцию "удалить мой аккаунт" вместо "просмотри мою почту" то цена ошибки фронта оказывается не менее велика.
Можно поподробнее как это модет произойти?
Ошибка из-за недоисправленного копипаста в конце списка?
Ну странно, если бэк позволит так просто удалить какие-то данные из БД, то вопросы опять же к бэку. А вообще сейчас для таких значимвх операций как "удвление аккаунта" есть защита от дураков в виде всевозможных кодов подтверждения и.т.д
Ещё вариант когда-то был, когда Опера была платная, с бесплатным вариантом с баннером.
Она отсылала просматриваемые адреса поисковому роботу, который проходил по всем ссылкам, в том числе и для удаления.
Разработчики не ожидали, что адрес типа сайт.ру/(много-случайных-символов-которые-id_сессии)/delete может быть случайно доступен не пользователю сайта ¯\_(ツ)_/¯
(Там дальше и подтверждение могло быть, тоже ссылка.)
delete обычно работает только в паре с куками и токенами, поисковый робот на 403 наткнется (а если разработчики такую дыру упустили, их увольнять в волчьим билетом надо)
а вот из реальных проблем которые я видел - ссылки подтверждения почты для активации аккаунтов, когда оутлук для предпросмотра ссылок ходит по ним и их активирует до того как пользователь по ним кликает
Фронт труднее для меня. Как минимум из-за того, что другой. И чёрт с ними, со скриптами. Вот вся эта разметка, все эти стили... Бррр.
Как бэкэндер я готов настаивать, что серверная сторона тяжелее, требует больших точных познаний, навешивает на разработчика большую ответственность и т.п... Но для меня-то это привычно. А вот фронт вселяет почти что ужас. Ладно, не ужас, а просто выбешивает. Сижу и плююсь, пытаясь что-то там изобразить...
Вообще я знаю, что код фронта МОЖЕТ быть красивым, аккуратным, читабельным. Но чаще попадается откровенная ересь, особенно на старых проектах. Или когда веб-морда прикручена к бэку чем-то вроде Thymeleaf, однажды написана фронтами и далее годами дополняется бэкэндерами на скорую руку... Читать аж больно.
"и меня может легко заменить любой разработчик…"
Шо ты мелешь тут вообще? HTML - это действительно просто, для детей. С точки зрения любого человека, который хоть как-то связан с разработкой чего-либо. Тебя может заменить не то что любой разработчик, тебя может заменить даже ChatGPT, бездушный робот...
Сложно - это когда ты полгода что-то делаешь каждый день. Но все равно ничего не можешь понять. А html это реально просто.
В промышленном фронтенде весь HTML уже остался под капотом, это уже наталкивает на мысли, что в нем даже недооценивать особо нечего.
Другое дело сопутствующие CSS и JS - это, даже если и несложно, то как минимум, весело. Причем, тем веселее, чем меньше там ангулара, реакта и прочего vue.
HTML сам по себе то прост. А вот фронтэнд разработка нет. Не надо смешивать всё в кучу
HTML никуда не денется, как никак в нем много метаданных и SEO.
А вот на счёт отрисовки, то по хардкору:WebGL,WebGPU.
А что вообще значит «просто»?
В данном контексте просто следует заменить на "Быстро, понятно и доступно". А вообще конечно, кто говорит так, тот пытается вас обесценить, современный HTML достаточно объемен и функционален. HTML+JS+CSS это уже профессиональное высшие образование.
производительность на машине разработчика обычно оказывается высокой
По моему скромному мнению, это одна из основных причин, почему сайты (и вообще приложения) "жиреют", дольше загружаются и требуют всё больше процессорных ресурсов.
Не стоит недооценивать HTML