×Закрыть

Технології заради технологій: чому Front-end не розв’язує завдань Back-end

Привіт, мене звати Захар, і я алкоголік веброзробник. Я починав кар’єру програмістом у тролейбусному депо, написав плагін для Grafana, яким користуються в Dropbox, розробив багатопотокову систему кешування для sixt.com, а також безліч нудної нецікавої фігні для безлічі нудних нецікавих компаній. Усе як у всіх.

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

Ілюстрація Уляни Патоки

Проблема

Отже, уявімо собі вебпроєкт. Стандартний такий legacy-сайт на кілька десятків тисяч сторінок. Проєкт, який перевантажений плагінами, контролерами, інтерфейсами, екстеншенами, темплейтами та іншими англіцизмами. 150 таблиць у базі даних, сотні тисяч рядків коду і тисячі файлів застарілого фреймворку. Уявили? Молодці. Я впевнений, що багато читачів працювали з чимось схожим, можливо, навіть неодноразово.

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

Наш проєкт написаний на PHP. Тому це лише питання часу, коли в компанії заведеться візіонер, який запропонує переписати все з нуля. Та так, щоб викинути все погане старе і написати все прекрасне нове — кращого слогану годі й шукати. Нагорі дають зелене світло, візіонер «кусає» інших розробників, решта — справа техніки.

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

Так, стоп. Чому лише фронтендерів? Та тому, що бекенд більше не потрібен.

У нинішні часи розподіл на бекенд і фронтенд, як це було останню сотню років, уже не актуальний. Навіщо множити рівні абстракцій, якщо можна просто взяти React і написати все на JavaScript?

Рішення

Jamstack обрали без тендерів і поза конкурсом як наймодернішу та найперспективнішу схему розробки. Вся бізнес-логіка відтепер житиме лише на клієнт-сайді. Сьогодні всі так роблять.

На жаль, крім логіки рендеру контенту, вебсайту потрібен і сам контент. Контенту на проєкті «вагон і маленький візок», і його потрібно десь зберігати. Це досить нудне завдання, але, на щастя, фронтенд-розробникам не потрібно перейматися такими дрібницями. Для цього існують докеризовані Headless CMS у вигляді напівфабрикатів, які треба раз розгорнути десь на сервері, а далі воно вже якось самостійно працює.

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

Інтеграція

Сказано — зроблено. Стек обрали, фреймворки встановили, бібліотеки під’єднали. Пруф-оф-концепт готовий уже за два тижні, MVP — одразу після того. Вже за два місяці від початку роботи нова версія проєкту опиняється на новенькому git-based хостингу. Анімації анімуються, кнопки кнопкаються, попапи попапаються, а швидкість рендеру тестових сторінок досягає 0.003 секунди за дюжину.

Керівництво щиро усміхається у вуса, ключові розробники отримують премії, legacy-проєкт ось-ось закриють, і більше нікому не доведеться мати справу з цим пекельним монолітом. І ось невдовзі настає фінальний етап — міграція даних і запуск. Тут проєкт успішно та без затримок йде в продакшн, CEO особисто телефонує розробникам і дякує за прекрасну роботу. Акції компанії зростають на 32%.

Гарна історія з гарним закінченням — це завжди приємно, але є одне «але».

Провал

Фінального етапу так і не сталося. Ні за місяць, ні за пів року. Проєкт і досі лежить на окремому інстансі, кнопки досі кнопкаються, а тестові дані рендеряться за 0.003 секунди за дюжину. На нову систему перенесено менше як один відсоток даних. Цукерберг не зателефонував.

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

Чому так сталося і хто в цьому винен? Розберімося.

Front-end is the new Full Stack

Можливо, раніше вам уже доводилося чути цю мантру на різноманітних мітапах і хакатонах. Вона і стала причиною провалу всього проєкту.

Річ у тому, що відмова від повноцінного сервер-сайду накладає на проєкт певні обмеження. На тлі популяризації тренду serverless-технологій ці обмеження здаються багатьом незначними й не вартими уваги. Зрештою сервер-сайд нудний і нецікавий. Що значить фронтенд теж нудний? Всі люблять фронтенд, не вигадуй.

Насправді я не впевнений, хто в цьому винен. Умовний React, бо спонукає людей розширювати функціонал за допомогою бібліотек, чи умовний npm, який нав’язує розробникам ідею підходу до роботи як до конструктора. Але це вже неважливо.

Так склалося історично, що фронтенд-розробка набирала обертів останніх N років катастрофічно швидко, і кількість фреймворків, плагінів, генераторів коду, сніпетів і мікробібліотек збільшувалася в геометричній прогресії. Всі знають жарт про JavaScript-фреймворк, який застарів ще на момент написання документації до нього. Але крім погоні за версіями, ця тенденція має побічний ефект, який нелегко помітити з першого погляду.

Прихована загроза

Розвиток фронтенд-технологій не просто збільшує кількість шляхів виконання завдань, а й розширює зону відповідальності девелопера.

Раніше було достатньо знати HTML i CSS, щоб працювати верстальником. Пізніше, років за 10, до цього списку додався базовий JavaScript. Ще за три роки з’явилося обов’язкове знання jQuery. Згодом виник Angular.js. Тоді Backbone, Knockout, Ember, Polymer, Aurelia, React, Vue, Preact, CoffeeScript, Webpack, npm, yarn, GraphQL, Gatsby, you name it.

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

Зі збільшенням переліку базвордів зміщувався і напрям розвитку фронтенду. Сучасному спеціалісту більше недостатньо вміти працювати з дизайном і браузерами, йому тепер потрібно вміти спілкуватися з API, мутувати дані, стежити за стейт-менеджментом, планувати архітектуру сторінок і переходів. Водночас робити все це за допомогою взаємозамінних компонентів, враховуючи вимоги від SEO-департаменту, оптимізуючи час завантаження та навантаження на CPU... Ну ви зрозуміли.

Бекенд без бекенду

Останній бастіон впав після появи моди на serverless — підхід, який інкапсулює весь бекенд у вигляді чорної коробки з API, який може лежати де завгодно. Хоч на LAMP, хоч у «хмарі». Бекенд можуть наповнювати і люди, і нейромережі. Він може бути один або їх можуть бути тисячі — усе це більше не відіграє ролі. Великі рожеві GraphQL тентаклі відішлють вам будь-які дані в будь-якій формі з єдиного ендпойнту, тільки попросіть.

Тож, трішечки гіперболізуючи, можна заявити, що єдине завдання, яке все ще не підвладне клієнт-сайду, це бази даних і SQL. Але тут діло принципу. Чого тільки не вигадають хитрі фронти, щоб не писати right join. Та бази даних нецікаві, і з цим нічого не вдієш. Все інше — метушня, для якої існує щонайменше три JS-бібліотеки на GitHub.

Але що робити, коли відповідного API-провайдера нема в жодному рейтингу на зразок «топ-64 API-провайдерів сьогодні до обіду?» Доведеться користуватися напівфабрикатами.

Завбачливо запаковані на заводі дбайливими та відлюдькуватими бекендерами, вони запустяться на вашому AWS від найменшого копняка. Рибка в сітці. Так? Чи ні? Чи так? Я заплутався.

Front-end без причини

На жаль, як показує практика — ні. Більшість типових для бекенду рішень все ще не вийшли зі стадії бети на клієнті. GraphQL досі сиріший за курку в шоу Гордона Рамзі, Server Side Rendering збоїть при використанні неправильних плагінів, а зоопарк мікробібліотек змушує 80% часу поєднувати між собою виклики тих чи інших компонентів, які написані невідомо ким і невідомо де. Ви їх підключили тільки тому, що побачили в першому посиланні пошуковика.

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

Отже, за 6 місяців роботи над суперсучасним вбивцею PHP-фреймворку, тільки на JavaScript, ми маємо 43 підключених модулі, кілька тисяч захардкоджених роутів, безліч темплейтів і гору наперед підготовлених GraphQL-запитів, які завжди витягують з бекенду одні й ті самі дані для кожного компоненту на сторінці. А також рафіновану CMS, яка не вміє і 10% з того, що вміє старенький пенсіонер PHP на опенсорсному фреймворку минулого десятиліття.

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

Замість висновків

На жаль, висновків у мене для вас нема. Життя бентежне, тренди заразні, модність технології все ще важливіша за її реальні можливості, а згадка базворду на TechCranch усе ще авторитетніша за відсутність сотні відкритих issues на GitHub.

Але в мене для вас є певні побажання. Про всяк випадок.

Працює? Не чіпай. Очевидна істина, яка не для всіх очевидна. Якщо вам раптом захотілося переписати робочий модуль на сучаснішій технології, згадайте про вояджери, які досі цілком собі крутять дані на Cobol. І ніхто від цього ще не вмер. Ну, крім більшості людей, які знали Cobol.

Уникайте технологій, яким менше як два роки. Жарт про застарілі фреймворки смішний лише перші 24 місяці. Після цього йде рутина і стабільність. Справді більшість бібліотек і форків фреймворків не доживуть до такої дати, але Vue.js на ринку вже 7 років. А React ще довше. Чи використовують їх сьогодні? Питання риторичне. Залиште експерименти з бета-версіями та ультрасучасними технологіями для амбіційних джуніорів, які їх і написали. Продакшн не терпить експериментів зі стабільністю.

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

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

Не оцінюйте технологію за її популярністю. Сьогодні всі ваші колеги говорять про фреймворк X, а завтра перемкнуться на фреймворк Y. Розповіді в курилці, як і публікації на модних платформах, не потребують пруф-оф-концепту, пам’ятайте про це.

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

Цю статтю для вас написав бекендер. Висновки робіть самі.

LinkedIn

58 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Не бывает чистых фронт или бек девов хорошей квалификации, ведь есть черта где они пересекаются.

Статья отличная, спасибо! Сам front-end, пишу на Vue уже 3 года.
P.S. А что не так с пиццой с ананасами?)

Ананасы под пиво не заходят...

Ще цікаво в 2к20 читати про fullstack як про server-client спеціаліста. Це так, якщо треба покрити невеликий функціонал однією людиною, зробити якийсь сайт. Але, з практичної точки зору, для більш комплексніших рішень фронтенд-розробник за способом мислення є ближчим до mobile чи навіть до UX, тож, якщо треба економити на time&material, то ефективніше буде об’єднувати саме клієнтські обов’язки в одну позицію.

Це з власного досвіду чи просто так сказали? Я отримаю насолоду працюючи з обома, це як два різні світи.

That feel when PHP/other backend devs are starting to cope with Javascript Fatigue. Don’t worry brothers, you’ll get over it www.youtube.com/watch?v=-A3n5N8XwpQ

я один сразу перехожу читать комменты?))

ніколи не пишу, але напишу

Мені дуже тяжко дається розуміння наєздів бекенд девів на фронтендщиків. Формошльоплять собі і ладно, госпаді (чи це тому, що JS-ники критикують PHP? це негідники)

Початок статті такий, що очікуєш якусь супер досвідообмінний матеріал, але виявляється, що там вигадана (?) історія фейлу, який міг статись тільки в якійсь ламєрській barbie-size вебстудії. І, типу, через цю історію всім фронтендщикам має стати соромно?) Хоч би причину провалу написав, шо мол тіпа фронтенщик генадій запропонував на мікрофронтендах всьо запіляти, але потім ніхто не зміг це задеплоїти, ну чи шось таке, шоб падушевнєй.

В тексті ціла маса тверджень, правєрять каториє я канєшно же нє буду. Наприклад, «мікросервіси не в моді», «апдейти ліб які все ламають», «graphql сирий», «нема БД на JS», «джуни які пишуть ультрасучасні фреймворки» і ше ціла маса якоїсь такої емоційної штуки, яка, для більш досвідченого читача, викриває псевдокваліфікованість написаного.

В кінці статті «написав бекендер, робіть висновки». Висновок: розповідати, як іншим правильно робити роботу — це справа таксистів, і не варто у них її забирати.

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

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

Как раз потому, что эти языки дешёвые и простые, на них можно делать крутые штуки (заказные проекты/сайд-проекты). It depends, конечно. Более «крутые» языки, а именно Haskell, Clojure, Java, C#, или Rust, Python, Ruby, как пример, их тоже интересно немного знать, хотя бы для общего развития. Однако в определенный момент понимаешь, что язык это тоже инструмент, и если бы прям 10x быстрее/качественнее получалось писать программы, просто выбрав условный язык Elm, тогда трейд офф ещё был бы уместен. А так, it’s just turtles. All the way down. Все одинаково, проблемы, которые ты будешь решать при разработке проекта, возникнут в любом случае. Тулинг поможет, конечно, но только в прямых руках, а иначе получится примерно как в этой статье.

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

Это зависит от манипулятивности игры в статистику :)

А если перевернуть картинку, учитывая ее историю:
PHP стал популярным благодяря CMS, и его долго никто не рассматривал для более серьезных приложений энтерпрайз класса. А после 5ой версии, сохранив область CMS, его стали ЕЩЕ И применять для разработки приложений энтерпрайз класса.

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

и странно тогда звучит тезис:
но никто особо не использует его самые круты фишки
это как, так и пишут на нем как на 4ой и младше версиях?
те самые «приложения энтерпрайз класса».
Уверены?

ибо от PHP в первую очередь нужна дешевизна и простота разработки

От любого языка этого ожидают.
Возьмите историю Java, JavaScript, Go

Java will kill your startup. PHP will save it.

Вот и идет наш холивар вялотекущий, но по моему уже всем давно все равно.

зависит от «возраста» программиста.
молодому программисту очень важно быть в тусовке лучших.
а разве лучшие могут писать на говноязыке?

Та где тут манипулировать то?
63.5% сайтов в мире это CMS, из них почти 90% это CMS на PHP
79.0% сайтов в мире это сайты на PHP

Высчитайте разницу, сколько сайтов на PHP используют не CMS на PHP.
Статистика w3techs, серьезного, известного ресурса.

Та где тут манипулировать то?

из 63.5% и 79.0% сайтов
делается вывод

но никто особо не использует его самые круты фишки
Высчитайте разницу

приведите статистику:
какой процент энтрепрайз решений делался на PHP 10 лет назад, и сейчас
тогда и посчитаю.

вы же как-то посчитали что:
но никто особо не использует его самые круты фишки

как это вы сделали?
у меня про этих «никто» совсем другая информация.
например что на той же Symfony CMS не пишутся (пишутся конечно, но много реже чем на более простых фреймворках).
а что же на ней пишется тогда?

А как вы посчитали «CRMки на Laravel» для внутреннего использования?

То есть, вы манипулируете статистикой, примерно как в случае (скопирую еще раз)
(обманывать это:)
— Сравнивать статистику арестов или столкновений с полицией в данной этнической группе, не показывая статистику собственно преступности в этой группе. Соуэль приводит гипотетический пример — мы обнаруживаем, что огромное, совершенно непропорциональное большинство предупреждений и «красных карточек» в баскетбольных матчах в США получают чернокожие баскетболисты. Но из этого, конечно же, нельзя сделать вывод, что судьи — расисты и предубеждены против негров, потому что абсолютное большинство баскетболистов в США — чернокожие, так что почти все игровое время на поле находятся именно чернокожие спортсмены.
dou.ua/...​rums/topic/30717/#1874642

разницу между
PHP используется для вебсайтиков на CMS
и
PHP используется для вебсайтиков на CMS И энтерпрайз приложений среднего уровня сложности

улавливаете?

по другому
то что
PHP используется для вебсайтиков на CMS
почему у вас исключает
И энтерпрайз приложений среднего уровня сложности

Сергей, вы разводите демагогию. Статистика конечно по веб ресурсам а не внутренним корпоративным системам. Что там твориться — никому достоверно неизвестно. Ведь мы не можем собрать эту статистику. Но то что это написано на пхп? очень вряд ли. Скорее получив эту статистику, от 25% сайтов в мире на PHP, но не на CMS, мы отнимем еще немного, но это как раз таки будет неверная статистика. Нас не интересуют внутренние корпоративные системы, это другой сегмент рынка, с другими правилами, где бывает все, от Cobol до Pascal и уж точно не PHP там доминант, ведь совсем недавно было точно известно что доминантой там была Java. Сейчас Java ушла, однако никаких предпосылок говорить что Java была заменена PHP нету. Чем угодно, от Rust до Node.js, но PHP никогда не был доминантой в этом сегменте разработки.

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

Сергей, вы разводите демагогию.

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

Из статистики:
Язык программирования С применяется для разработки драйверов в «90%» случаев
делаете вывод
а больше он нигде и не применяется!

Сейчас Java ушла, однако никаких предпосылок говорить что Java была заменена PHP нету

куда ушла?
ООП провалилось!, да это из той же оперы

А выводов о ее замене PHP я не делал.

Это вы делайте что PHP там где был — там и остался.
Не представив никакой базы под такой вывод.

Нас не интересуют внутренние корпоративные системы

кого — нас?

Если не интересуют — то и не делайте выводы за пределами «мира CMS»

Чем угодно, от Rust до Node.js, но PHP никогда не был доминантой в этом сегменте разработки.

а где вы у меня прочли о доминировании?

то есть кто тут демагог:
не тот ли кто приписывает тезисы которых не было в изначальном утверждении?

Баскетболисты «чернокожие» потому что генетика афроамереканцев больше приспособлена под этот вид спорта.

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

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

ну вот я вам и предложил подумать что вы вообще не видели графика использования PHP чтобы делать выводы о том — где он еще, помимо указанного среза применяется.

Если вы видите два совпадающих графика, скорее всего у них есть общий фактор.

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

но вопросов к вам больше нет.
как только наивный демагог обвиняет другого в демагогии — дальше нет смысла указывать на ошибки в его рассуждениях.

И какая же по вашему статистика, если я не верно ее прочитал? Я могу подтвердить любой озвученный мной факт статистическими данными. Сделайте доброе дело, если не прав — приведите опровергающие мои слова данные. Только не так как

куда ушла?
ООП провалилось!, да это из той же оперы

"
А цифрами, я например могу подтвердить цифрами падение Java, это есть в ежегодной статистике DOU.

Я могу подтвердить любой озвученный мной факт статистическими данными

с этого я и начал.
подтвердите:

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

подтвердите свой тезис.

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

наивной — то есть незлонамеренной, обычной, нормальной.
большинство совершает такого рода ошибки.

приведите опровергающие мои слова данные

у меня нет статистики чтобы доказать свои наблюдения.

а у вас есть. так давайте ее наконец.

А цифрами, я например могу подтвердить цифрами падение Java

отлично, давайте, интересно посмотреть — сможете не совершить той же ошибки?

Так я же выше писал откуда данные, с w3techs и про статику dou насал( это касательно Java)

Так я же выше писал откуда

я и написал, что эти данные не дают возможности утверждать что

продолжает быть на плаву за счет CMS

и

никто особо не использует его самые круты фишки,

как и то что из «драйвера пишутся в 90% проектов на С» не дают возможности сделать вывод пишется еще что-то значимо, весомо на С помимо драйверов.

Или, как не так давно вживую услышал мнение юноши
— Питон лучший язык для веб!
— Почему?
— Я смотрел статистику посещаемости сайтов джанги и симфони с ларавелем. там много ниже посещаемость — значит меньше программистов на php используют его для веб. а больше программистов для веб используют джангу.

вот вы мне и напомнили этого юношу.
но вы ж не юноша, так наивно трактовать статистику, верно?

w3techs

статистика не отражает многие сферы разработки.

если вот вообще ничего не знать кроме w3techs
вы беретесь по этой статистике сказать какие ЯП популярны в эмбеде и геймдеве?

а что на бекенде у проектов которые попали в w3techs — можно сказать? когда фронтенд SPA?

а учитываете вы что большинство сайтов в интернете — простые, и поэтому круче вордпресса там ничего и не нужно, и поэтому что, можно сделать вывод — что ничего кроме «вордпрессов» и не пишется?

про статику dou насал( это касательно Java)

в бытность мою в джаве, я часто слышал что она мертва, потому что
статистика показывает что ее мало используют для веб.
«а разве бывает что современное без веб? значит — мертва»

вы вторую серию подобного качества рассуждений хотите продемонстрировать?

давайте. как понял уже писали, линк дайте, если не трудно.

Хорошо. Давайте уберем мой вывод, прочитайте мой первый пост, там голые цифры. Вы согласны с ними?

там голые цифры

голые цифры потому так и называются — что они ничего не показывают

вот голые цифры:
124, 61%, 56.777

вы согласны с ними? ;)
или не согласны?

Давайте уберем мой вывод

цифры без вывода — голые.
там нечего обсуждать.

выводы на основе голых цифр — вот это и имеет смысл.

если убрать все ваши выводы, а оставить цифры, так что обсуждать то?
десятичную систему счисления что-ли?

ок, давайте поясню, на любимом примере как статистика превращается в ложь («Есть три вида лжи: ложь, наглая ложь и статистика.»):

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

и собиралась статистика, по паре тысяч студентов которых мучил колледж :)

1. Как вы думаете какое будет распределение выбора цифр?
2. После ознакомления, а почему оно такое, а не другое?

я вам указал на массовую ошибку в выводах по w3techs о php

в ответ вы призвали меня не заниматься демагогией
ну ок, давайте посмотрим когда вы поймете кто ею занимается :)

Вы кажется с демагогии идете куда-то уже в тролинг. Мои цифры подписаны, сгруппированные и с указанием источника.

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

Мои цифры подписаны, сгруппированные и с указанием источника.

а где там выводы которые вы делаете?

покажите пожалуйста.

Что у вас за цифры?

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

так же как на заре ноды — только крайне рисковые ее выбирали.
JS же хейтится не меньше PHP

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

Если в следующем вашем коммент не будет аргументированного ответа,

так я ж от вас жду аргументов к вашим выводам.
или ссылку на авторитет

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

дальше вы продолжите разговор уже без меня.

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

Отрицаете аргументированную точку зрения. Субъективным личным опытом. В научной теории такой метод не используют ввиду того что люди верят своему личному опыту принимая его за глобальную истину.

Мои выводы были основаны на статистике w3techs( w3techs.com )
Я привел цифры в первом своем ответе вам, тут
dou.ua/...​ign=reply-comment#1876864

А именно сказано было следующее:

Та где тут манипулировать то?
63.5% сайтов в мире это CMS, из них почти 90% это CMS на PHP
79.0% сайтов в мире это сайты на PHP

Высчитайте разницу, сколько сайтов на PHP используют не CMS на PHP.

Статистика была взята со следующих отчетов w3techs:
w3techs.com/...​erview/content_management
w3techs.com/...​view/programming_language
Отчеты на 17 Июня 2020

Также мной было упомянуто «падение Java» в этом комментарии
dou.ua/...​ign=reply-comment#1877014
А именно было сказано следующее:

Сейчас Java ушла, однако никаких предпосылок говорить что Java была заменена PHP нету

Эти же строки вы процитировали ниже. Я привел в доказательство ежегодную статистику DOU, ссылка на свежую статистику на момент написания комментария: dou.ua/...​language-rating-jan-2020
А именно, в этой статистике на втором графике отчетливо видно что пик популярности Java пришелся в 2016, после чего она потеряла около трети разработчиков.

Все остальные утверждения были построены на основании этих. Я пишу это не для вас Sergey Lysak, а для того кто будет читать это после. С вами мы диалог закончили. Я вас предупреждал, просил предоставить хоть какие-то аргументы. Есть определенной уровень терпения, сколько я готов потратить на это личного времени.

Отрицаете аргументированную точку зрения.

наличие аргумента не означает истинность точки зрения

В научной теории такой метод

в научной теории метод — по возможности применяеть эксперимент.
и когда «субъективный личный опыт» экспериментатора не совпадает с теорией — то он начинает думать — что не так, с экспериментом или теорией.

так как годами я наблюдаю такую трактовку данных w3techs, и несоответствие наблюдаемой действительности, то вот и думал себе.
и пришел к выводу о неверности трактовки вполне верных данных w3techs

И что это — распространенная ошибка не только в этом случае, а и например в случае с «чернокожими баскетболистами»

Мои выводы были основаны на статистике

вот о неправильности ваших выводов, а не статистике и речь

в этой статистике на втором графике отчетливо видно что пик популярности Java на 2016

если вы исключили такое явление — как расширение статистической базы — то ваш вывод о падении полулярности — неверен.

пример расширения базы
была статистика по мегаполисам о популярности напитка X
расширили на материк.
популярность напитка X — упала?

я тоже пишу не для Alexander Litvinenko. мне до его заблуждений нет дела.

Я вас предупреждал, просил предоставить хоть какие-то аргументы.

я привел их еще в первом посте.

а цифрами — маленьких пугайте.
от неумения трактовать цифры — количество линков на них не спасает.
Голые цифры ничего не значат.

Выводы по ним — это результат работы головного мозга.

Это еще в Delphi было. Джуны дергали данные прямо с базы(бизнес-логика на клиенте) и писали как есть, а сеньоры писали трехзвенку.

Джуны дергали данные прямо с базы(бизнес-логика на клиенте)

столкнулся как-то с приложением на Дельфи, где ребята освоили многопточность на Delphi, и «чтоб быстро работало» делали оптимистичную предзагрузку данных с GUI
все работало отлично, пока не развернули у реального клиента
там не БД, там вся локальная сеть ложилась — каждый клиент, с 5ток запросов, по таймеру(шорт пуллинг, ёпта!), которые получают избыточные данные (чтоб можно было быстро отфильтровать в гриде, без дополнительного запроса), клиентов всего-то пара десятков...

потом уже такие решения массово у тру фронтендеров встречал :)
serverless, ёпта!

Гайд від колишнього бекедщика для тих хто хоче працювати з фронтент\фуллстек
1) Вивчіть основи дизайну, що таке композиція, теорія кольорів.
2) Прочитайте гайдлайни iOS, Android, Material
3) Вивчіть CSS
4) Вивчіть HTML
5) Переведіть основні принципи SOLID на CSS.
6) вивчіть VanillaJS

це база і тільки після цього є сенс розбиратись з веб фреймворками, angular, react, npm.
не витрачайте час на безглузді технології і підходи. Після пункту 1) дуже часто буде зрозуміло чому.

Сам пишу виключно backend, але коли захотів розібратися чим же живе сучасний frontend і почав відразу вивчати фремворк, який використовується на проекті, то в результаті дійшов приблизно до тих же самих висновків.

Розділення людей на бекенд/фронтенд відбулося усього лише років з 10 тому, коли і фронтенд став дуже складним і бекенд теж. До цього всі писали усе і struts(або: php, asp.net, ruby on rails в т.д.) і html/css/js, і ніхто не випендрювався. Тепер (Angular,React,Vue)/Node.js розпіарились — але софт який з цього виходить, часто — в продакшн не виходить. Хоча писати нове однаково треба, просто його треба своїм розумом думати — а не тулити наймодніший фреймверк тому що він такий модний, інколи сенс є — інколи нема. Зовсім недавно мікросервіс який робили 3-ри місяці на node.js + neo4j + redis — полетів собі в козину, бо прийшов нарешті архітектор, проробив архітектуру і зав’язав React фронт напряму на CMS, мікро сервіс став непотрібний як і всі овертайми які пішли на нього. Пів команди, пішло шукати собі кращої долі.
Краще питання чому ми тулимо усі новітні фреймверки до проекту? Як на мене тому що знаємо що робота в нас високо ризикова — завтра можливо доведеться шукати нову, а там треба буде експіренс, бажано продакшн, в якоїсь чергової новітньої технології. Інакше знову будеш джуніором, або взагалі не візьмуть. На роботу в нас беруть на проект позицію закрити клієнту — а не в компанію, бо бізнес такий. От і на намагаємося втулити все наймодніше про що начитали по інтернетах, без прототипів одразу на прод. Спрацює — круто, а втрачати нічого гроші клієнта — а не наші, нам треба строчка в резюме для щоб його знайшла HR за ключовим словом.

Тепер (Angular,React,Vue)/Node.js розпіарились — але софт який з цього виходить, часто — в продакшн не виходить

Да ну?))

Это произошло около 6 лет назад, если говорить о том когда это стало повсеместно.
Бекенд после отделения от него визуализации стал проще, а фронт был сложен из-за отсутствия инструментов. Эру начал ангуляр первый. В 2011-2012 еще был backbone.js, а он был популярен задолго до ангуряла первого, я долго с ним работал. Могу ошибиться в несколько лет, но точно уверен что ангуляр стал на слуху гораздо позже. После популяризации ангуляра, популяризовался Grunt и Gulp, после чего стартовала эра модульности для фронта, как на беке. Она конечно и до того была в виде отдельных решений, но не было столь распостраненных решений, избавляющих от кучи проблем одним скриптом. И решения сегодня — вебпак и реакт, как квинтэссенция решений предыдущих лет. Последние несколько лет это решение всех проблем. Это стабильные библиотеки.

Сложность архитектуры приложения повысилась, но не сложность разработки. Мы тратим меньше времени на сложную штуку, чем например лет 13 назад на простую. Тогда предел мечтаний было сделать хоть что-то читабельное, а для кроссбраузерности нужны были библиотеки вроде jQuery или конкурирующего тогда с ним еще Mootools, о котором сегодня помнят только старожилы в веб разработке или те кто случайно где-то услышал, например только что, тут, от меня. Сложность разработки снизилась, просто раньше даже простую вещь было сделать очень сложно. Мы тратим гораздо меньше времени, чтобы делать очень крутые штуки.

Фух... Приятно слышать, что Back-end в безопасности и нас не оставят без куска хлеба.

Front end evolution timeline:

— Let’s add xml to JS
— Let’s render HTML with JS
— Let’s use 15 styles to center divs
— Let’s add more tooling
— Let’s release webpack 2.0
— Let’s write tooling to reduce impact of tools
— Let’s write CSS in JS
— Let’s rewrite React in Suspense
— Let’s add hooks
— Let’s engineer web components
— Let’s add Shadow DOM
— Let’s add Virtual DOM
— Let’s rewrite React Router
— Let’s add types to JS
— Let’s make our builds to last 5 minutes
— Let’s create tools to improve build time
— Let’s make a Chinese React
— Let’s render as we parse
— Let’s add parse as we render
— Let’s load as we render
— Let’s use AMP
— Let’s stop using AMP
— Let’s use Rust for web
— Let’s use FRP for web apps
— Let’s make a framework that disposes at build time.
— Let’s render on server
— Let’s send HTML through websockets

— Let’s send HTML through websockets

Ух ты, отстал, классная штука!
а то мы только до отсылки новостных блоков в SPA додумались. в HTML.
а пуш сообщения идут в json
и правда, зачем, если можно сразу в HTML слать. и на фронтенде js код упростится.

на беке и так php, он умеет HTML

Век живи — век учись. а за трендами фронтенда все равно не уследишь!

мы вообще отказались от http api, какой смысл поддерживать два интерфейса, когда можно только один?

Bingo! Дякую за цю статтю — дуже точно підсумовує мої власні почуття стосовно сучасного зоопарку Client-side технологій.

мабуть преподу не занесли гешефт :-)

А есть линк на полную версию? =)

Тільки цей скріншот гуляє

Стилістика просто чудова, приємно читати!

Цю статтю для вас написав бекендер

А що там з Java? Вмерла?)))

Частина мене померла разом з нею

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

не сталкивался пока с serverless. чаще это react фронт + asp core бек.

В нашому ажурному світі це Azure Functions, можете глянути.

Я б ще додав — фронтенд тупий, він має лише відображати дані.

Скажіть це про Google Docs, Trello, Figma і іншим популярним веб-застосункам

Дякую, корисні нагадування )

Интересная статья, очень толково. Спасибо большое !

Підписуюся під кожним словом статті. Дякую!

legasy-проєкт

ачипятка очевидно

ну то ще

legasy-сайт

виправте

Вобщем элои и морлоки из Машины времени Уэллса :)

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