Вхід і реєстрація
Різне · 29 березня, 17:50 5831
Андрій Гуцалюк

Що швидше помре: фронтенд, бекенд чи ми?

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Мав два цікавих окремих діалоги з фронтендщиком та бекендщиком:

Фронтендщик:

Бек має померти. Наразі умовний Angular може виконати всю логіку, не витрачаючи ресурси сервера, а бекенд потрібен тільки для приховування запитів до БД.

Коротше, бек буде дуже специфічною темою і рідко де знадобиться.

Бекендщик:

Фронт має померти. Сьогодні ці «комбайни» по 150 МБ не потрібні, бо наразі можна генерувати сторінку на сервері та передавати вже готову сторінку на пару мегабайт без ваших кривих JSON-ів.

До того ж не кожен клієнтський комп’ютер витримає.

Коротше, фронт буде дуже специфічною темою і рідко де знадобиться.

Пишіть, хто що думає: що помре швидше — фронт, бек чи ми?

Теми: back-end, Front-end, обговорення
👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Eugene Krashtan 31.03.2025 12:40

Маю надію, що путін...

Перейти до дискусії
Beaver Green 30.03.2025 11:54

Коли я про це думаю — у мене виникає деяке розчарування. Ніби ІТ замість розвиватися — роками ходить по-колу.
Перші гроші я заробив зробивши типовий CRUD аплікейшин для обліку товарів на Delphi. На той час Delphi підтримувала усе потрібне для бізнеса: і локалізацію, і таймзони і локальні налаштування користувача і навіть RTF (дзеркальні форми). Компонентів було багато і на будь-який смак. Прив’язку до бази можна було робити взагалі без коду. До 1С уся автоматизація бізнесу писалася на Delphi — а у деяких супермаркетах я бачив на касах типові іконки на кнопках ще років 5 тому.
Потім була Java і Swing. Багато хто намагався жерти цей кактус, пробував перейти з піратських Вінди та Офіса на безкоштовний Open Office. Але на той момент Java працювала щонайменше 2 рази повільніше. Не кажучи вже про особистий зовнішній вигляд UI.
З розвитком Web поступово попит на сайти значно перевищив попит на desktop UI (GUI апки). Але на той момент веб браузер був справжнім «тонким клієнтом», як і було задумано. Тобто користувач отримував вже готову сторінку підготовлену сервером.
Здавалося б: що змінилося у цей момент з архітектурної точки зору? Змінився тільки UI. Робота з базами — не змінилася, бізнес логіка — так само.
Але чомусь для веба зробили повністю нові фреймворки: які міняли усю архітектуру і потребували розробки як бекенда так і «фронтенда» (на той момент збирався на сервері).
ASP, JSP, PHP, ASP.Net, Razor і ще купа фреймвоків які на різних мовах робили переважно ті самі форми та CRUD, які 5-10 років тому чудово робив Delphi.
Потім з’явилися планшети, мобільні телефони і бажання робити SPA (single-page аби сторінка виглядала як мобільна апка (лол)). Мода знову змінилася: замість «тонкого клієнта» тепер максимум функціонала стали пхати на фронтенд. І знову замість якогось повторного використання з’являються свіженькі нові фреймвоки для фронтенду. У великій кількості на усі смаки (кажуть додай JS до будь-якого слова і знайдеш NPM пакет). Але усі знову хворі на ті самі проблеми з локалізацією, датами, таймзонами, RTF.
Чомусь, на відміну від інших технічних галузей, в ІТ не люблять використовувати вже напрацьовані рішення. Усе викинути і написати з нуля свій модний фреймвок — саме такий підхід. При цьому фреймвоки для десктопа — свої, для веба — свої, для фронтенда — свої, для мобільних аплікейшинів — знову свої. Усюди різні контроли, різні моделі даних, різний біндінг.
Хоча усе це переважно виконує ті самі бізнес задачі, які були ще на Delphi.
Одні і ті самі базові задачі за 20 років не змінилися — але змінилася купа рішень, при цому рішення не ставали принципово новими! Ось, наприклад:
— Реляційні бази даних. Вони мабуть змінилися найменше. SQL стандарт працює як і 20 років тому.
— З якогось моменту додалися No SQL бази, але фактично вони не дуже відрізняються від «файлових» баз, які були 20 років тому. Тоді переважав CSV, потім пішла мода на XML, з часом його змінив JSON. Окрема історія з Big Data — тут свої формати і свої процесори, але різниця здебільшого тільки у паралельній обробці.
— DAL тобто рівень доступу до даних. DAO, ADO, JDBC, Hibernate, Entity Framework — і це тільки які швидко згадав. Бази не змінилися, SQL не змінився — але за 20 років так і не змогли зробити одного технічного рішення. А ще й досі хтось пише свої «велосипеди».
— Сервіси. COM+, CORBA, Java Beans, WCF, REST, RPC ... Купа рішень однієї простої проблеми віддаленого виклику і передачі даних. За стільки років вже мабуть мав існувати єдиний протокол з апаратно підтримкою, як TCP. Але знову: купа різних форматів, різних стандартів і переписування WCF сервісів на REST а завтра ще на щось нове.
— UI. А конкретно — форми. «Форми не міняються» — це основа будь-яких бізнес систем. І навіть користувачі зацікавлені у простому, звичному інтерфейсі. Це не ігри де потрібна нова красива графіка. І що ми бачимо? Я знаю ентерпрайз систему, яка працює вже 25 років. За цей час її переписували з VB6 + COM + ASP на ASP.Net Web Forms, потім на WCF + ASP.Net MVC, потім на зоопарк з JQuery + Backbone + Knockout, потім на React + Open API + Microservices і от зараз поступово на Angular. Сотні людино — років роботи!
При цьому функціонал для користувачів на 80% залишився тим самим що і 25 років тому. Якщо б усі витрачені на цей проєкт гроші вклали у будівництво — то можна було б один раз побудувати офісну будівлю яка б простояла щонайменше 50 років!
Мені здається що саме зараз настав час, коли ІТ доведеться «подорослішати». У бізнеса більше нема зайвих грошей на ІТ експерименти — буде попит на стабільні рішення, побудовані на роки уперед.
Модні фреймвоки залишаться тільки у стартапах, де їх будуть розробляти ентузіасти за їжу. Комерційні проєкти більше не дозволятимуть себе збирати «зоопарк» з опенсорсних пакетів. Скоріше усе більше будуть використовуватися готові «конструктори» тику Dynamics 365 та інших хмарних SAS.
Колись для заробляння грошей девелоперу не потрібно було добре знати Pascal, але треба було знати Delphi. Так само скоро більшості девелоперів не потрібно буде глибоко знати будь-яку мову програмування чи фреймвок. Але треба буде добре розуміти які хмарні сервіси узяти, як їх поєднати, як налаштувати під потреби бізнесу і де доведеться кастомізувати. Девелопер пише код, а Software Engineer має вирішити бізнес-проблему. А чи буде потрібен код і який — це вже замовника не цікавить. Тим більше що знайти чи згенерувати потрібний код може допомогти ШІ — тільки треба правильно його попросити!
P.S. Ентерпрайз — звалища легасі коду нікуди швидко не зникнуть. Бізнес буде «кататися на мертвій кобилі» ще багато років. Так само ШІ навряд-чи добре розбереться в усьому місеві, яке люди наворотили за 20 років. А отже на наш вік роботи з кодом ще вистачить! Це нове покоління вже буде збирати ІТ проєкти у якийсь 3D віртуальній реальності (а ШІ усе це переведе в код).

Перейти до дискусії
Igor Tsvyak 31.03.2025 20:12

Головне, що статті про те що «<щось> скоро помре» не вимруть ніколи

Перейти до дискусії
Valentyn Hlyvich 29.03.2025 21:51

Кожна жаба своє болото вихваляє.

Треба ще додати Дизайнера, який каже, що фронтенд помре бо одразу з фігми виходитимуть готові веб-сторінки.

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Inna Chapkevych 14.04.2025 11:06

Замість того, щоб розганяти паніку, краще б написали статтю про те, які є можливості для розвитку з поточним станом речей. Розвиток це нормально, еволюція неминуча, і потрібно вміти адаптуватися до нових умов, а не нити, як все погано. Стаття тупо ні про що

Відповісти
Підтримати
Дмитрий Мирошник Lead QA Automation Engineer 01.04.2025 11:48

Я сначала подумал, что тема за 01.04, глянул — но нет :D

Відповісти
Підтримати
Igor Tsvyak Systems Engineer 31.03.2025 20:12

Головне, що статті про те що «<щось> скоро помре» не вимруть ніколи

Відповісти
Підтримати
Andreus 31.03.2025 19:30

швидше помре те що легше нагенерити за допомого ШІ
тобто веб (під вебом я маю на увазі і веб фронтенд і веб бекенд)
трошки довше протримається бекенд — дістрібьютед сістемс, драйвера, ембедед, дата інжиніринг etc.

Відповісти
Підтримати
Бартоломео Россі 31.03.2025 15:42

Одразу після смерті С++ або Віндоуз, ага

Відповісти
Підтримати
Andrey 31.03.2025 14:13

Всiм вiдомо по першим помре мануальне тестування, а потiм Java, або вони разом помруть!

Відповісти
Підтримати
Олександр Мощенко 31.03.2025 14:15

нє ну раз пхп помер, то і ці двоє незабаряться

Відповісти
Підтримати
Andrey
Вова Москаленко 31.03.2025 16:41

Чув думку, що тільки мануальне тестування й залишиться, бо треба буде тестити всю ту шляпу, що АІ нагенерує

Відповісти
Підтримати
Andrey
Bohdan Kryvyi 01.04.2025 11:27

Погоджуюсь, що обов’язки мануального тестування в найближчі роки не можуть пропасти. Єдине, що це може бути не окремий напрям, а частиною обов’язків інших напрямів. Зокрема тестувальник — це і мануальні обов’язки та автоматизація необхідного. Розробникам теж треба все перевіряти, що їм нагенерує АІ і т.д.

Відповісти
Підтримати
Вова Москаленко
Олександр Мощенко 31.03.2025 12:45

доречі про фронтенд — ви вже бачили новий сайт мілітарного? як вам оця фіскована шапка на третину сторінки? От вам і «виживе фронтенд» — як взагалі такому можна дозволити вижити? ні-ні-ні, тільки бекенд і сторінки на голому хтмл.

Відповісти
Підтримати
Eugene Krashtan Пінгвінів перевертаю в Зоопарк 31.03.2025 12:40

Маю надію, що путін...

Відповісти
Підтримати
Beaver Green 01.04.2025 09:38

І що це змінить? Кажуть що вже 2 чи 3 путіних померли — але усе одно знаходять нових.

Відповісти
Підтримати
Eugene Krashtan
Viktor Levytskyi SDE 01.04.2025 10:56

єрмак із командою міг би підтримати тенденцію

Відповісти
Підтримати
Eugene Krashtan
Dmytro A Senior Java Developer в Zooplus 03.04.2025 12:53

Нажаль, навіть й якщо, вони ж все одно виберуть нового путіна. Він буде інакше спілкуватися і виглядати, матиме інші ім’я та прізвище, може навіть буде жінкою, але все одно це буде хло, бо він, це їхня національна ідея.

Відповісти
Підтримати
Eugene Krashtan
Віталій Мартиник Senior Software Engineer в United Software 31.03.2025 12:15

Тільки мене напрягає, що цей автор генерить купу беззмістовних тем?
Може не варто на повному серйозі коментувати ті висери?

Відповісти
Підтримати
Андрій Гуцалюк 31.03.2025 12:53

Краще бузька на хаті ніж токсичного сенйора в команді

Відповісти
Підтримати
Віталій Мартиник
Віталій Мартиник Senior Software Engineer в United Software 31.03.2025 15:29

Придумай щось новіше

Відповісти
Підтримати
Андрій Гуцалюк
Азаза Заазааз 31.03.2025 11:44

Фронт частіше міняється банально.

Відповісти
Підтримати
Nikita Podgorbunskyi Software Engineer в безмежних просторах цифрових технологій 31.03.2025 11:03

Мені частіше траплялася ситуація коли в архітектурі клієнт-сервер бекендери хочуть частину роботи спихнути на фронт, а фронт хоче щоб данні які вони отримують були структуровані таким чином щоб їм меньше працювати довелося.

Відповісти
Підтримати
Karina Kosenko PHP developer в IT Craft 31.03.2025 11:29

Я як бекендер, навпаки намагаюсь віддавати як можна менше логіки на фронт. І дані намагаюсь структурувати зручно для фронту, мені не шкода :))

Відповісти
Підтримати
Nikita Podgorbunskyi
Nikita Podgorbunskyi Software Engineer в безмежних просторах цифрових технологій 31.03.2025 12:54

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

Відповісти
Підтримати
Karina Kosenko
Vitalii D Frontend Engineer в Tide.co 31.03.2025 12:00

обидва підходи мають сенс

Відповісти
Підтримати
Nikita Podgorbunskyi
Nikita Podgorbunskyi Software Engineer в безмежних просторах цифрових технологій 31.03.2025 12:46

Та сенс все може мати, але воно буває що за замовчуванням стрктура яку відає бекернд фреймворк не дуже відповідає тому що хотілося б мати фронтенду, змінювати це може будти геморно. Простий приклад коли в формі 1 помилка то повертається об’єкт, а коли декілька то список таких об’єктів. Інший приклад це коли фронтенд фреймворк з лібами зібрали собі данні форми і відправляють це у форматі який не можна впихнути у функцію валідації просто так і треба писати якийсь парсер додатково. Це все не те щоб капець яка проблема, але скоріше виникає спір в команді хто ж це має робити і в кожного свої аргументи і всі розуміють що якщо зараз оце почати на своїй стороні це робити то це гарантія що потім це завжди буде на його стороні додаткова робота.

Відповісти
Підтримати
Vitalii D
yvs2014 31.03.2025 11:11

А браузер то електрон, який в снап, який в лінукс, який потім ще в докері на хост ос.
І обов’язково використають щей повний цикл вебізації для реалізації команди `ls` у вигляді електрон app фіналізуючи створення bloatware.

Відповісти
Підтримати
Eugene Samonenko
Long John Silver 31.03.2025 10:53

Ці фронтендщик та бекендщик були з якоїсь школи в який дітей навчають програмуванню з 6-ти років?

Відповісти
Підтримати
yvs2014 31.03.2025 11:02

ендщики то вебпрограмування, діти і програмування тут перпендикулярно)

Відповісти
Підтримати
Long John Silver
Dmytro Brahinets Engineering Manager в Uinno 31.03.2025 10:31

Якісь у вас дивні діалоги вийшли. Дві абсолютно некомпетентні думки у підсумку 😆

Відповісти
Підтримати
Олександр Мощенко 31.03.2025 09:26

тю. навіщо тут слово «помре»? Як на мене то був би чудовий заголовок «що швидше — бекенд чи фронтенд». І публікувати треба було в четвер увечері, або в п’ятницю.

А так то маю два зауваження:

Бек має померти. ... Коротше, бек буде дуже специфічною темою..

схоже фронтендщик і досі не вміє в логіку, бо у нього якийсь бекенд шредингера виходить.

...бо наразі можна генерувати сторінку на сервері...

схоже бекендщик — малолєтній зумірок, який і не здогадується, що «генерувати сторінку на сервері» можна не «наразі», а завжди.

Відповісти
Підтримати
Andrey Lapshov 31.03.2025 00:38

Ще раз.
НЕ —
Бекенд та не фроненд.
А —
Вєб фроненд та вєб бекенд.

Відповісти
Підтримати
yvs2014 31.03.2025 00:53

В принципі так воно і є. Хоча і так по дефолту якщо говорять frontend/backend, то вже зразу спрацьовує асоціація з вебпрограмуванням.

Якщо більш до того як раніше розуміли програмування — то починають оперувати термінами server-side client-side UI і т.д. А так як форум орієнтований практично на вебпрограмінг з відносно рідкими виключеннями (принаймні так виглядає зі сторони), то цілком очікувано що будуть оперувати термінологією фронт-бек-фул.

Відповісти
Підтримати
Andrey Lapshov
Andrey Lapshov 31.03.2025 18:18

Я це розумію, що 90% программінгу то про ВЄБ.
Але ще є ті 10% які там про ємбеддед, гєймдєв, графіку, БД кор, чи інші 100500 сегментів.

І нам трохи як ніяково коли кажуть вас (все що не вєб) не існує...

Відповісти
Підтримати
yvs2014
yvs2014 31.03.2025 18:43

софта веб не так вже й багато, а якщо поза браузерами і електрон той ще значно менше, а бабл вебпрограмування по сайтам — то так, трохи зашкалює

Відповісти
Підтримати
Andrey Lapshov
Vic Programmer 31.03.2025 12:53

Слухайте юзвери, то все було в ті часи коли юзвери самі писали собі драйвери
Звісно ми в сучасному ІТ аутсорсу, тому йдеться про Web застосунки.
Бо Frontend та Beckend чи User Space, System Space по іншому — є в більшості програмно апаратних архітектур, у компіляторів, операційних систем, десктопних та мобільних застосунках, чи принаймні бібліотеках за допомогою вони написані тощо.
А так класична травнева архітектура Web застосунку, Business Logic, Persistence та Presentation, де останнє це якраз про що йдеться про при SPA коли сервер просто віддає JSON і ідеалі RESTful API (а реальності State full де завгодно), а товстий клієнт на JavaScript чи діалектах або мобільний, а інколи декстопний застосунок — робить запити до сервера, коли йому треба бізнес логіка. В більшості випадків на сервері теж дуже прості CRUD операції, та якась бізнес логіка на викиди них, наприклад валідація вхідних данних. Відповідно 3 мінімально необхідні компоненти — web сервер який віддає статичний контент та frontend HTML/JavaScript, beck end сервер із бізнес логікою та API і сервер керування базою данних.
Те що інтерфейси стали писати окремі люди, а серверну частину теж окремі — просто потреба бізнесу, можна більше людей застафити замовнику. Року до 14, усі робили усе, окрім може дизайн присилав дизайнер в Photoshop файлі, який ще самому треба було різати, робити спрайти і т.п.

Відповісти
Підтримати
Andrey Lapshov
yvs2014 31.03.2025 13:49
то все було в ті часи коли юзвери самі писали... а ми в ... тому йдеться про Web застосунки

Грр.. хтожті загадкові «ми»)
сучасні неюзвери вебюзери в кількості 15ти фронтбек одиниць і однієї вебтім напишуть мін.тулзу з двома кнопками у вигляді електрон app розміром в пару гіг та запустять то в контейнері, називаючи цей тип bloatware — веб застосунок.

можна більше людей застафити замовнику ... Photoshop... різати спрайти

решта АІ-іш тексту перпендикулярна до когерентності

Відповісти
Підтримати
Vic
Vic Programmer 31.03.2025 13:54

Бо так дешевше розробка. Так береться фреймверк який може з гармати по гробцям по усім питанням, та для комерційного програмування тобто бізнесу це може бути і нормально.
А так то я в коли починав в 2006, були дядьки які не визнавали навіть ЯВУ, усе що не ассемблер сприймалося як парад збочень. Та я давно нікого з них не бачів і нічого про них не чув. А гроші там де фреймверки, не обов’язково хороші — але обов’язково з маркетинговою підтримкою Big Tech.
Якщо Fecebook — пише фронт на React, а якась частина Google на Angular чи Vue, так робитиме решта індустрії. Так само Microsoft на TypeScript і скоро чверть індустрії на TypeScript.

Відповісти
Підтримати
yvs2014
yvs2014 31.03.2025 14:06
так дешевше розробка ... обов’язково з маркетинговою підтримкою

точно нормаль вийшла, особливо з 15ма дешевими фронтенд одиницями)
або щось десь поломалось.. хоча.. з джава асоціація в тему

Відповісти
Підтримати
Vic
Dmytro 30.03.2025 23:43

— Та нахєр ті бекенди потрібни, просто два запита к БД виконати
— Та нахєр ті фронтенди потрібні, що там дві кнопочки в HTML віддати
Я пропоную цім двом панам створити разом свій фулстек фреймворк, щоб й бекенд не потрібен був й фронтенд. Є припущення правда, що вийде PHP зразка 2000х років. Так що навіщо робити велосипед, беріть та й пишть на голому PHP, він вже існує.

Відповісти
Підтримати
Beaver Green 30.03.2025 11:54

Коли я про це думаю — у мене виникає деяке розчарування. Ніби ІТ замість розвиватися — роками ходить по-колу.
Перші гроші я заробив зробивши типовий CRUD аплікейшин для обліку товарів на Delphi. На той час Delphi підтримувала усе потрібне для бізнеса: і локалізацію, і таймзони і локальні налаштування користувача і навіть RTF (дзеркальні форми). Компонентів було багато і на будь-який смак. Прив’язку до бази можна було робити взагалі без коду. До 1С уся автоматизація бізнесу писалася на Delphi — а у деяких супермаркетах я бачив на касах типові іконки на кнопках ще років 5 тому.
Потім була Java і Swing. Багато хто намагався жерти цей кактус, пробував перейти з піратських Вінди та Офіса на безкоштовний Open Office. Але на той момент Java працювала щонайменше 2 рази повільніше. Не кажучи вже про особистий зовнішній вигляд UI.
З розвитком Web поступово попит на сайти значно перевищив попит на desktop UI (GUI апки). Але на той момент веб браузер був справжнім «тонким клієнтом», як і було задумано. Тобто користувач отримував вже готову сторінку підготовлену сервером.
Здавалося б: що змінилося у цей момент з архітектурної точки зору? Змінився тільки UI. Робота з базами — не змінилася, бізнес логіка — так само.
Але чомусь для веба зробили повністю нові фреймворки: які міняли усю архітектуру і потребували розробки як бекенда так і «фронтенда» (на той момент збирався на сервері).
ASP, JSP, PHP, ASP.Net, Razor і ще купа фреймвоків які на різних мовах робили переважно ті самі форми та CRUD, які 5-10 років тому чудово робив Delphi.
Потім з’явилися планшети, мобільні телефони і бажання робити SPA (single-page аби сторінка виглядала як мобільна апка (лол)). Мода знову змінилася: замість «тонкого клієнта» тепер максимум функціонала стали пхати на фронтенд. І знову замість якогось повторного використання з’являються свіженькі нові фреймвоки для фронтенду. У великій кількості на усі смаки (кажуть додай JS до будь-якого слова і знайдеш NPM пакет). Але усі знову хворі на ті самі проблеми з локалізацією, датами, таймзонами, RTF.
Чомусь, на відміну від інших технічних галузей, в ІТ не люблять використовувати вже напрацьовані рішення. Усе викинути і написати з нуля свій модний фреймвок — саме такий підхід. При цьому фреймвоки для десктопа — свої, для веба — свої, для фронтенда — свої, для мобільних аплікейшинів — знову свої. Усюди різні контроли, різні моделі даних, різний біндінг.
Хоча усе це переважно виконує ті самі бізнес задачі, які були ще на Delphi.
Одні і ті самі базові задачі за 20 років не змінилися — але змінилася купа рішень, при цому рішення не ставали принципово новими! Ось, наприклад:
— Реляційні бази даних. Вони мабуть змінилися найменше. SQL стандарт працює як і 20 років тому.
— З якогось моменту додалися No SQL бази, але фактично вони не дуже відрізняються від «файлових» баз, які були 20 років тому. Тоді переважав CSV, потім пішла мода на XML, з часом його змінив JSON. Окрема історія з Big Data — тут свої формати і свої процесори, але різниця здебільшого тільки у паралельній обробці.
— DAL тобто рівень доступу до даних. DAO, ADO, JDBC, Hibernate, Entity Framework — і це тільки які швидко згадав. Бази не змінилися, SQL не змінився — але за 20 років так і не змогли зробити одного технічного рішення. А ще й досі хтось пише свої «велосипеди».
— Сервіси. COM+, CORBA, Java Beans, WCF, REST, RPC ... Купа рішень однієї простої проблеми віддаленого виклику і передачі даних. За стільки років вже мабуть мав існувати єдиний протокол з апаратно підтримкою, як TCP. Але знову: купа різних форматів, різних стандартів і переписування WCF сервісів на REST а завтра ще на щось нове.
— UI. А конкретно — форми. «Форми не міняються» — це основа будь-яких бізнес систем. І навіть користувачі зацікавлені у простому, звичному інтерфейсі. Це не ігри де потрібна нова красива графіка. І що ми бачимо? Я знаю ентерпрайз систему, яка працює вже 25 років. За цей час її переписували з VB6 + COM + ASP на ASP.Net Web Forms, потім на WCF + ASP.Net MVC, потім на зоопарк з JQuery + Backbone + Knockout, потім на React + Open API + Microservices і от зараз поступово на Angular. Сотні людино — років роботи!
При цьому функціонал для користувачів на 80% залишився тим самим що і 25 років тому. Якщо б усі витрачені на цей проєкт гроші вклали у будівництво — то можна було б один раз побудувати офісну будівлю яка б простояла щонайменше 50 років!
Мені здається що саме зараз настав час, коли ІТ доведеться «подорослішати». У бізнеса більше нема зайвих грошей на ІТ експерименти — буде попит на стабільні рішення, побудовані на роки уперед.
Модні фреймвоки залишаться тільки у стартапах, де їх будуть розробляти ентузіасти за їжу. Комерційні проєкти більше не дозволятимуть себе збирати «зоопарк» з опенсорсних пакетів. Скоріше усе більше будуть використовуватися готові «конструктори» тику Dynamics 365 та інших хмарних SAS.
Колись для заробляння грошей девелоперу не потрібно було добре знати Pascal, але треба було знати Delphi. Так само скоро більшості девелоперів не потрібно буде глибоко знати будь-яку мову програмування чи фреймвок. Але треба буде добре розуміти які хмарні сервіси узяти, як їх поєднати, як налаштувати під потреби бізнесу і де доведеться кастомізувати. Девелопер пише код, а Software Engineer має вирішити бізнес-проблему. А чи буде потрібен код і який — це вже замовника не цікавить. Тим більше що знайти чи згенерувати потрібний код може допомогти ШІ — тільки треба правильно його попросити!
P.S. Ентерпрайз — звалища легасі коду нікуди швидко не зникнуть. Бізнес буде «кататися на мертвій кобилі» ще багато років. Так само ШІ навряд-чи добре розбереться в усьому місеві, яке люди наворотили за 20 років. А отже на наш вік роботи з кодом ще вистачить! Це нове покоління вже буде збирати ІТ проєкти у якийсь 3D віртуальній реальності (а ШІ усе це переведе в код).

Відповісти
Підтримати
Prairie Marksman 30.03.2025 12:16
Ніби ІТ замість розвиватися — роками ходить по-колу.

імхо, воно розвивається з «фрактальним ускладненням», просто перевикористовуючи речі, які довели свою ефективність і які можна перетворити на building block чогось іншого

і в цьому айті не відрізняється від будь-якого іншого інжинірінгу (включно з протоінжинірингом доместикації, артом, стратегіями війн і тп), хоч сапієнсів, хоч «blind watchmaker’а» (в якій би «іпостасі» чи сенсі про це говорити)

Відповісти
Підтримати
Beaver Green
yvs2014 30.03.2025 13:41
Емдаломожливість вирішення...
розвивається з фрактальним ускладненням,.. протоінжинірингом доместикації,.. хоч сапієнсів, хоч blind watchmakerа

Кул, а це про шо та «протофрактальна доместінжінірія емдалосапієнсів»?))

Відповісти
Підтримати
Prairie Marksman
Prairie Marksman 30.03.2025 19:21

перепрошую, в мене з віком розвинулася «гуморова ангедонія», механіку розумію, але ступінь дотепності вже ні %)

але стосовно топіку мені раптом «резонанс інфосфери» приніс ще більш радикальне твердження, від еволюційних біологів (в офігєнній книзі A Hunter-Gatherer’s Guide to the 21st Century: Evolution and the Challenges of Modern Life by Heather Heying, Bret Weinstein):

This is where we must break our sense of obligation to measure things. Adaptive evolution—the process that increases the «fit» of creatures to environment—is about all levels of descent at once. Adaptive evolution is therefore fractal, and the term that encapsulates it is lineage.

тобто не вужче твердження яке я висловив, щодо фрактальності розвитку в інжинірингу, а взагалі будь-чого, що відчуває на собі еволюційний тиск і при цьому забезпечується persistence цього чогось..

Відповісти
Підтримати
yvs2014
yvs2014 30.03.2025 19:45

напевно ще не всі homo sapiens увійшли в резонанс інфосфери в своїй адаптивній еволюції, мені навіть трохи соромно за себе що недостатньо для того еволюціонував

Відповісти
Підтримати
Prairie Marksman
Long John Silver 31.03.2025 11:11

Завжди дивуюся людям які називають себе еволюційними біологами і не знають базованих речей про еволюцію.
Еволюція ніколи не

the process that increases the «fit» of creatures to environment—is about all levels of descent at once.

Еволюція це про постійні, вимушені під впливом помилок від радіації зміни, і потім безжальне вбивство тих хто не змінився до умов життя які в свою чергу змінюють планета, космос, та сама еволюція коли залишає лише тих хто змінився.
«fit» — саме через цей термін більшість пересічних громадян вважають еволюцію маячнею.
І фрактали тут теж доволі груба метафора.

Відповісти
Підтримати
Prairie Marksman
Prairie Marksman 31.03.2025 11:24

хм, ви мабуть розумієте еволюцію глибше тих, про кого зі зневагою висловлюєтесь, то мабуть готові вказати на свої публікації в цій області?

я користуюсь чужими, бо я точно не відчуваю себе глибше розуміючим ці речі ніж люди які собі обрали це як один з головних напрямків інтелектуальної діяльності, якщо ваші будуть цікаві і глибші, думаю не один я подякую за це

Відповісти
Підтримати
Long John Silver
Long John Silver 31.03.2025 12:09

А до чого тут «хм» і «мабуть»? Невже не є очевидним, що я розумію еволюцію, а ці два представника лівацького схибленого способу мислення, ні.
Щодо їх публікації. Це тупо два викладача, які втратили роботу через своє ***натство. Після втрати роботи вони написали книгу.
Отой Вайнштейн ще і прихильник теорій змов. Постійно поширював шкідливу інформацію про ВІЛ, Ковід та інше.
Це як би ваш вчитель з уроків труда, якого звільнили за пияцтво, написав би монографію про вплив світового розподілу труда на зростання біржових індексів в період 1970-1990 років.
Ось не моя думка про цю книжку. Це реценція Гардіан «Weinstein and Heying „lazily repeat false information from other pop-science books“, and that overall the book was characterized by an annoying, know-it-all attitude»

Відповісти
Підтримати
Prairie Marksman
Prairie Marksman 31.03.2025 12:20

ну, я більше не про людей і їх погляди в чомусь, що не частина топіку, але дякую за відповідь

Відповісти
Підтримати
Long John Silver
Long John Silver 31.03.2025 14:10

Незалежно від тупості авторів книжка може вийти гарною? Плоскоземельник може написати цікаву монографію про космологію?
Я впевнений що ні. Зараз критично важливо дізнаватися про погляди автора. Бо сучасний маркетинг робить дива і легко ставить пройдисвітів поруч з геніями.
Оком не встигнете блимнути як купите щось типу Екхарта Толле і будете його читати. Не варто цього робити!

Відповісти
Підтримати
Prairie Marksman
Roman Pliasovytsia the last cowboy in the town 29.04.2025 23:28

А порадьте, будь ласка, якусь хорошу книжку. Таку щоб і читати цікаво, і в житті ті знання використати можна було. Як от «Thinking, Fast and Slow», наприклад.

Відповісти
Підтримати
Long John Silver
Long John Silver 31.03.2025 12:14

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

Відповісти
Підтримати
Prairie Marksman
Prairie Marksman 31.03.2025 12:57

хм, почитав трохи, послухав трохи подкаст, на який критики ссилаються

я колись в дитинстві бачив кроля, який пережив «досвід майже-смерті», от схоже травля, яку Вайнштейну влаштували за опінію («лівацьку» в термінології тих, хто не розділяє і цілком собі класично ліву) призвела до зсувів у нього в голові, (споводованих шоком травлі та/або необхідністю якось жити далі — та сварка поставила хрест на будь-якій можливості в штатах знайти йому роботу), сумно але не перший і не другий такий випадок, так працює психіка

так чи інакше, аргумент ad hominum і непрошена порада це трохи не те, що про що я казав, коли питав про публікації (нехай не власні, але цікаві)

Відповісти
Підтримати
Long John Silver
Long John Silver 31.03.2025 14:02

Ну ви ж не могли казати серйозно про пораду почати писати статті з біології на форумі для програмістів? Чи то був не жарт?
Щодо ad hominum. Всі ці поради вони з минулого або може з позаминулого століття. Зараз неймовірно важливо дізнатися хто автор. Це може не тільки зекономити час але і вберегти від більших негараздів.

Відповісти
Підтримати
Prairie Marksman
Prairie Marksman 31.03.2025 14:18

ось це

готові вказати на свої публікації в цій області?

дійсно можна трактувати як

пораду почати писати статті з біології на форумі для програмістів

?

я намагався уникнути давати непрошені поради незйнайомим людям, але при цьому дати змогу підкріпити свої твердження про свій рівень розуміння теми переконливими аргументами
оскільки тема надзвичайно складна (це моя опінія така) то для мене є очевидним, що у форматі форуму вона не може бути розкрита, залишається формат публікацій і його можна обрати цілком вільно, я схожу і ознайомлюся

Зараз неймовірно важливо дізнатися хто автор.

колись я теж так думав, зараз я просто розділяю message/messenger/a guess about messenger’s motivation і аналізую ці теми окремо, іноді між ними є звязок, який я вважаю достатнім, щоб бути обережним, іноді ні

до речі моє питання про публікації, хм, воно ж теж — щоб краще зрозуміти — хто пише, про своє глибоке розуміння, так?

Відповісти
Підтримати
Long John Silver
Long John Silver 31.03.2025 14:32
дійсно можна трактувати як

absolutely!

хто пише

Ну ви ж бачите ім’я, аватарку і посаду.
Чи не здається вам, що теза про непрошені поради на форумі (sic) це нонсенс. Ту тобто я не чув жодного разу, ще з часів fido, що на форумах існує якась стала заборона на поради. Мені навіть здається, що порада це головний паттерн спілкування на форумах. Особливо, непрошена порада від незнайомої людини. Це кров всіх форумів.

Відповісти
Підтримати
Prairie Marksman
yvs2014 31.03.2025 14:41

окрема цікава тема для інтернет3.0 :

не чув жодного разу що на форумах існує якась стала заборона на поради

навіть поради від AI /з AI контентом/? (деінде тегується-чи-баниться)

це кров всіх форумів

і там АІ додасть ще більш ̶в̶о̶д̶и̶ жару...

Відповісти
Підтримати
Long John Silver
Beaver Green 01.04.2025 09:41
Я, в своем познании настолько преисполнился, что я как будто бы уже сто триллионов миллиардов лет, проживаю на триллионах и триллионах таких же планет, понимаешь? Как эта Земля. Мне уже этот мир абсолютно понятен, и я здесь ищу только одного: покоя, умиротворения и вот этой гармонии от слияния с бесконечно вечным, от созерцания этого великого фрактального подобия и от вот этого вот замечательного всеединства существа бесконечно вечного — куда ни посмотри: хоть в глубь — бесконечно малое, хоть ввысь — бесконечно большое, понимаешь?
Відповісти
Підтримати
yvs2014
yvs2014 01.04.2025 10:37

стисліше треба той фрактал-ish текст подавати)

Відповісти
Підтримати
Beaver Green
yvs2014 30.03.2025 13:31
Ніби ІТ замість розвиватися — роками ходить по-колу

Скоріш бабл вебпрограмування здується (точніше зміниться з аі-агентами та промптерами). Програмування те що під ним раніше розуміли — залишиться. Хоча ймовірно теж зміниться, але не так кардинально як з вебпрог та різними safe мовами (з якими для ші напевно легше буде генерувати код).

Відповісти
Підтримати
Beaver Green
Mohican 30.03.2025 16:18
Сотні людино — років роботи

білці потрібне колесо

Відповісти
Підтримати
Beaver Green
Просто Анон 30.03.2025 20:15
У бізнеса більше нема зайвих грошей на ІТ експерименти

І тут новина на виділення 500ккк$ на опен аі)
Гроші будуть завжди бо для бізнесу ті гроші нічого не коштують, все на позичені гроші

Відповісти
Підтримати
Beaver Green
Beaver Green 01.04.2025 09:43

Так, але гроші постійно вкладають у нові бульбашки. IT бульбашка вже «луснула» — тепер будуть вкладати у ШI, а девелоперів — звільняти.

Відповісти
Підтримати
Просто Анон
Long John Silver 31.03.2025 11:00

А до того були перфокарти, платівки для грамофонів, кресало, руки...
Нащо оте все понавигадували потім!?

Відповісти
Підтримати
Beaver Green
Beaver Green 01.04.2025 10:13

Усе, що вигадували у фізичному світі — це був розвиток попередніх ідей, а не їх заміна. Перфокарти перетворилися на штрих-коди, платівки — на компакт-диски.
Уявіть інженера, який вирішив створити повністю нові технології — «з нуля» аби зібрати революційний велосипед. І йому це вдалося: трикутна рама замість «труб», 3 — кутні гайки замість 6-кутних, людина лежить на спині і дивиться на дорогу через камеру. Можливо така конструкція буде легше, міцніше, мати меншу вітрову поверхню ... Але виробляти таке у реальності ніхто не буде! Бо це у рази дорожче, ніж використовувати стандартні гайки, труби, зубчасті колеса. Тим більше що для стандартних компонентів вже прораховані усі параметри міцності, витривалості, витрат матеріалу.
І тільки в ІТ через 10 років після того, як навчилися робити досконалий GUI інтерфейс з урахуванням усіх потреб користувачів — усе це викидають аби з нуля розробляти такий самий інтерфейс усередині браузера за допомогою мови, яка не має 60% можливостей, розроблених до цього! Банальна робота з датами, яку вирішили ще на мейнфреймах, викликає купу проблем у Java Script і на більшості сайтів працює неправильно. Спеціальні типа даних для грошей, які мінімізують втрату точності — їх також не існує у фронтенді.
І тільки ще через 10 років браузери навчили робити усе те, що робили GUI аплікейшини і почали використати для розробки повноцінні мови. І що у підсумку? Браузер тепер це майже своя «операційна система усередині операційної системи». Тепер залишилося створити усередині браузера новий «тонкий клієнт» аби не грузити кілометрові веб-аплікейшини. Чекаємо новий IE написаний на Java Script.

Відповісти
Підтримати
Long John Silver
yvs2014 01.04.2025 10:30

Мейнстрім браузери то бізнес, відповідно з точки зору тих браузеровиробників вигідно утилізувати свій софт по максимуму та заганяти все в «браузеро-електрони», і навколо умовного «все є браузер» цілу індустрію вебпрограмування створили. Ресурсоємкість то так там по ходу вже як вийде. Але вибір ще поки є, щоб робити то значно більш ефективно ніж вебзастосунки.

Відповісти
Підтримати
Beaver Green
Long John Silver 01.04.2025 14:28

Це геть не так. Вам зараз нічого не заважає верстати на чистому html. Але ви не будете цього робити бо це неймовірно дорого розробляти і не можливо підтримувати.
Всі ускладнення і ходіння по колу на які ви скаржитеся, це від нерозуміння вами причини. А причина проста — вимоги ПОСТІЙНО зростають, щоб ви там не думали себе за КРУД операції які наче опанували тридцять років тому. До речі де опанували?
І раджу вам почитати про комерційні катастрофи з форматом дати на мейнфреймах за останні п’ятдесят років. Остання була коли Ілон Маск та його малолітні ідіоти почали зчитувати дату яку створювали на COBOL за останні сімдесят років. І вони не змогли розібратися. Сказали що там є люди яким по 250 років. І те що вони тупі, включно з Ілоном, це половина проблеми. Там в ваших мейнфреймах таке ПЕКЛО з датами що я взагалі не розумію про який порядок та красоту ви розказуєте.

Відповісти
Підтримати
Beaver Green
Serhii 31.03.2025 11:16
Ніби ІТ замість розвиватися — роками ходить по-колу.

Так, бо такий шлях. Будь яка еволюція будь чого працює схожим чином, за тими самими законами. Ідея — реалізація — перевірка часом — невеликі покращення — смерть та забуття через те, що зʼявилося щось краще.

Від бурхливого розвитку на початку формування екосистеми (JQuery, Knockout.Js, Angular.Js, Backbone, та десятки невідомих або забутих) до конкуренції декількох високоспеціалізованих видів (React, Angular, Vue) з часом. Зі зміною умов життєдіяльності (WebAssembly) цикл повторюється.

Відповісти
Підтримати
Beaver Green
юнит тест 01.04.2025 09:54
— Реляційні бази даних. Вони мабуть змінилися найменше. SQL стандарт працює як і 20 років тому.
— З якогось моменту додалися No SQL бази, але фактично вони не дуже відрізняються від «файлових» баз, які були 20 років тому.

та конечно, если писать говнокруды, то хватит и sql 30-летней давности, его вышла куча ревизий en.wikipedia.org/...​L#Standardization_history , добавились оконные функции, CTE.
Есть куча колоночных, timeseries, графовых баз, которые в аналитических запросах просто на ноги укладывают реляционки, понятное дело в гнилом ентерпрайзе поставили МС Скуль или Оракул, там просто баблом закрывают потребности в ресурсах. 20 лет назад был только скуль, оракул, майсикл и глючный firebird, который обожали в дельфи сувать и труп interbase где-то еще дедушки юзали

Відповісти
Підтримати
Beaver Green
Юрій Ярош developer в bitsnap 13.04.2025 13:53

1. VCL компоненти — це Qt3 ... хтось просто продовжував писати на хрестах під Qt, й ATL/WTL коли треба було щось мале й швидке
2. Жаба була різна — там був Jooq... й якщо не лізти в J2EE, то можна було нормально жити. Якщо й J2EE — для простоти там придумали Grails.
3. Великий відсоток UI’я українських банків працював на Zkoss / Vaadin, якщо прям «в тонкі клієнти лізти», щось працює й до сьогодні.
3. ORM’и в будь якому випадку увесь функціонал бд не покривають, за дуже рідкими виключеннями... схеми та живі міграції через CDC всеодно доводиться дописувати під конкретні платформи — там AWS DMS чи усякий CNPG/Stackgres під debezium чи щось інше
4. SQL2003 SQL2006 SQL2008 SQL2011 SQL2016 SQL2019 SQL2023 ... люди не знають SQL. В SQL стандарт запихнули обробку JSON’a, наприклад, й зараз немає жодної SQL бд яка б не могла замінити монгу.
5. COM+/Corba лишились там де й були. REST ніхто як не вмів так й не вміє — OpenAPI кодогенератори доволі посередні, а OData спека занадто роздута. Для людей лишилось пропагування RPC на рівні типів та IDL’ки, там tRPC / GRPC тощо. GraphQL не має стабільної специфікації та для авторизації треба в розмальовку графу дерективами.
6.З формами там насправді трохи складніше...
7.Модні фреймворки отримують по 30-100M$ інвестицій, й подекуди купуються по 5B$ за штуку. Просто ви не там живете, й трохи не тими речами цікавитесь
8. Як людина яка почала з TP в 9 років, я загалом погоджуюсь майже з усім вищесказаним, якщо не брати до уваги суто теоретичний аспект комп’ютерних наук.

В нас не було розроблено теорії синхронізації розподілених систем в рамках Bidirectional Transformations (Bx), не було сформульовано теорію безконфліктної синхронізації (CRDT), не були розписані правила для денормалізації нормалізованих реляційних схем у форми (UI Forms) або представлення (SQL Views), з урахуванням когнітивної складності, контексту взаємодії, та контексту привласнення (entity ownership models). Навіть з точки зору логіки — відповідна Bunched/Separation логіка для залежних систем типізації з’явилась в 2019ому році. Тобто ми спершу написали Rust, а потім формально вивели його логіку роботи з наукової точки зору... щоб зрозуміти на скільки воно погане й що його потім ще доведеться обмазувати костилями по типу RustBelt/RustHornBelt.

Зараз по схемі БД люди генерують й форми, й добрий шматок фронту... й всі CRUD API, разом з правилами авторизації, але частіш то похідні від ReBAC по Zanzibar’у, з RBAC трохи складніше бо то потребує стабільного наслідування в правах ролей.

Теорія сильно практику не наздогнала, й ринок переповнений дилетантами останніх 20 років вирішував усі задачі екстенсивно — інженерна культура розглядалась менеджментом як Товар, який можна придбати чи продати. Відповіно не існувало організаційної зрілості, й більшість компаній (90%) могли там бути лише на першому-другому рівні, без робочого менеджменту. Народжувались спотворені ідеї «сімейних компаній» й відповідні системи цінностей, що не мали ніякого відношення до успіху (workplace deviance in family-type companies).

Відповісти
Підтримати
Beaver Green
Prairie Marksman 30.03.2025 11:47

імхо, все залежить від розвитку технологій, які власне виконують heavy lifting, тобто хард та інтерконекти, економічна доцільність побудови кнкретної хардової архітектури ну і «Емдаломожливість» вирішення завдання (те, що не дуже то й паралелиться має свою окрему архітектурну нішу(-і))
а далі — калькуляція моделі черг типу www.perfdynamics.com/Tools/PDQ.html і «поїхали»
іншими словами — поки що, окрім самобутних нішевих речей типу функціональщини всі інші типи софтової архітектури з пересуванням логіки/обчислень далі-ближче є просто похідними і самостійного сенсу існування не мають
тому — може бути будь-як, імовірніше все буде уживане, бо типи задач будуть достатньо різні, щоб один підхід не був можливий %)

Відповісти
Підтримати
Володимир Обрізан Директор в Design and Test Lab 30.03.2025 11:36
наразі можна генерувати сторінку на сервері та передавати вже готову сторінку

Always has been.jpeg

Відповісти
Підтримати
Vic Programmer 29.03.2025 23:12

Ну як створено вже таке www.youtube.com/watch?v=I44_zbEwz_w Тепер не знаю, це ж реально термінатор, такі рухи далеко не усім людям доступні. Єдине що, сучасні доступні техпроцеси мікросхем які це дозволили 12-5 нм (вже є 2 в цьому році TSMS починає массовий випуск) швидко деградують, в період десь 5 років. Старі мікросхеми на попередніх тех процесах застарівали морально десь за цей самий період.
Щодо генерації коду ШІ, то тут — таке поки що, це електричний гайковерт яким можна зробити якусь рутину але усе одно потім руками догвинчувати. І дуже багато залежить у кого в руках той гайковерт.
Щодо — чистого беку і чистого фронту, так вигідно бізнесу, а доволі довго усі були фулстек , тепер як бізнесу треба.

Відповісти
Підтримати
Valentyn Hlyvich 29.03.2025 21:51

Кожна жаба своє болото вихваляє.

Треба ще додати Дизайнера, який каже, що фронтенд помре бо одразу з фігми виходитимуть готові веб-сторінки.

Відповісти
Підтримати
Andrii Simakov BSE 31.03.2025 11:59

Дизайнери скоро теж будуть непотрібні, бо користувач буде відразу йти у Фігму.

Відповісти
Підтримати
Valentyn Hlyvich
Yurii Vlasenko Full-stack dev | Backend-focused | Building on web3 18.04.2025 12:52

і чому це досі не зробили🤔

Відповісти
Підтримати
Valentyn Hlyvich
Valentyn Hlyvich 29.03.2025 21:32
наразі можна генерувати сторінку на сервері та передавати вже готову сторінку

Server-Side Rendering це все ще фронтенд з вибором кольору кнопочок та відступів...

Відповісти
Підтримати
Symonenko Volodymyr software engineer 30.03.2025 23:50

Погоджуюсь, саме юзер інтерфейси виділяють як фронтенд

Відповісти
Підтримати
Valentyn Hlyvich
Просто Анон 29.03.2025 20:00
Наразі умовний Angular може виконати всю логіку, не витрачаючи ресурси сервера, а бекенд потрібен тільки для приховування запитів до БД.

Лол

Бізнес логіку тримати на фронті щоб її всі могли подивитись?

Чи щоб табка в хромі жерла 1 гіг оперативки?

І фронт, і бек будуть розвиватись, просте формошльопство буде виконуватись АІ тулзами. Тобто буде таке ж просте як і тікет змінити назву кнопки.
Так як бекенд складніший (транзакції, бізнес логіка, інтеграції з іншими сервісами), то бекендщиків буде ваще замінити.

Відповісти
Підтримати
Вова Москаленко 30.03.2025 11:38

Безпека вийшла з чату. Бувало, коли мене дратував якийсь сайт, я заходив в інспектор, вимикав required поля, відновлював приховані поля, прибирав набридливі банери. А відредаговані мною форми успішно сабмітилися десь в 30% випадків (бо все ж часто якась валідація на беку була). Якби все було на фронті, рівень скаму досяг би геть непристойних розмірів, і всі швиденько перейшли б назад на бек.

Відповісти
Підтримати
Просто Анон
Азаза Заазааз 31.03.2025 11:46
Чи щоб табка в хромі жерла 1 гіг оперативки?

Це взагалі не проблема, сервери дорогі, а комп юзера безкоштовний, значить його ресурси всі належать моїй апці.

Відповісти
Підтримати
Просто Анон
yvs2014 29.03.2025 19:17

схоже що то АІ розрулить які промптери кращі

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.