Drive your career as React Developer with Symphony Solutions!
×Закрыть

Чи підходить Angular та взагалі концепція SPA для нормальних проектів?

Осатаннім часм це дуже популярна тема, сам я переважно користуюсь JSF, колись робив це за допомогою Asp.Net та JSP/Servlets. Але останнім часом довелось зтикнутись з такими завданнями в яких такі технології, як JSF явно не кращій вибір, або взагалі безсилі. Тому довелось «доганятись» простим JS та jQuery. Тому такі теми, як SAP, Angular, ReactJS та JAMstack дуже цікавлять мене останнім часом.
Тут з’явилась цікава саття про Angular (dou.ua/...​three-years-with-angular), але там коментувати в мене немає прав. Тому спробую задати питання тут. Тим більше, що вони виходять за межі одного фреймворка.

Отже питання:
1) Оскільки ідея SPA працювати на одній сторінці, значить все, що в принціпі вміє ваша програма має поступово підвантажуватись до пам’яті браузера? Якщо це не пару хелло ворлд екранів, це все здатно суттєво роздути пам’ять на клієнті. А можливостей звільняти(вивантажувати зайві скрипти), начебто в сучасних браузерах немає?
Тобто вони дуже не ефективні для серйозних програм з велигою кількістю різних екранів, функцій?

2) Який сенс взагалі у всіх цих складностях, з купою різних файлів, які генеруються ще в купу інших файлів, а ті іноді перекомпілюються ще в щось? Реальна програма в будь-якому випадку не може обійтись без back-end, так чи інакше там ви все рівно муситемете проводити реальну валідацію, виконувати реальну бізнес-логіку, перейматись аутентифікацією і т.п. Тобто жодного сенсу серйозно перевантажувати фронт-енд. Там має сенс робити лише різні UI-світульки, та первинну валідацію данних. А це в свою чергу можна все спокійно робити і простим JS(лише тільки охайно все писати і оформлювати). То навіщо всі ці ускладнення з Node.js, транспілерами і т.і. Заради чого?

3) ...тим більше, що самі по собі Angular чи ReactJS не пропонують готові компоненти, як такі. А от для того ж jQuery є багатий вибір готових компонентів. Або є той же порт відомої JSF ліби Primefaces, і для Angular, ReactJS і для jQuery. То який сенс тоді ускладнювати собі життя всіма цими ангулярами, якщо головне саме готові(або такі, що вимагають мінімум додаткової роботи) компоненти, а основна робота буде все рівно робитись на сервері?

4) Що ви думаєте про таку архітектуру, де все що може бути статичним робиться статичними сторінками з JS+jQuery+jQueryUI/PrimeUI/etc. Ну там шаблони всілякі є, але генеруються в кінцевому підсумку в статичні сторінки перед релізом.
Все що потребує бізнес-логіки на сервері робиться як прості веб сервіси(microservices, JSON), +bonus ті самі сервіси можна використовувати в Android, iOS клієнті.

Яке в такій архітектурі може буте місце Angular чи ReactJS? Що вони можуть спростити чи покращити?

LinkedIn

Лучшие комментарии пропустить

4) Що ви думаєте про таку архітектуру, де все що може бути статичним робиться статичними сторінками з JS+jQuery+jQueryUI/PrimeUI/etc.

До появления фреймворков оно так и было. И это был лютый писец и адище из коллбеков. Оно того не стоит, забудьте вообще.

С подключением. Всех уже тошнит от angular/react/vuejs, а вы только начали задумываться...

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
1) Оскільки ідея SPA працювати на одній сторінці, значить все, що в принціпі вміє ваша програма має поступово підвантажуватись до пам’яті браузера? Якщо це не пару хелло ворлд екранів, це все здатно суттєво роздути пам’ять на клієнті. А можливостей звільняти(вивантажувати зайві скрипти), начебто в сучасних браузерах немає?
Тобто вони дуже не ефективні для серйозних програм з велигою кількістю різних екранів, функцій?

В Angular v2+, слід враховувати мабуть чотири базові поняття в цьому плані:

1. Сервіси, чиї дані можуть зберігатись у пам’яті браузера, поки користувач не покинув поточний application. Хоча ці дані можна, звичайно ж, видаляти коли заманеться.

Angular має дуже гнучкий інструмент — Dependency Injection — він дозволяє створювати довільну ієрархію і відповідну тривалість життя інстанса сервіса. Наприклад, якщо вам потрібно щоб дані завантажувались, існували й видалялись при кожному зверненні до певного компонента — немає проблем — передавайте провайдерів для dependency injection на рівні компонента.

2. JavaScript DOM-дерево, де кожна частина живе у пам’яті браузера, до поки її не видалили. Якщо користувач переходить від одного компонента до іншого, в’юха попереднього компонента видаляється з DOM-дерева й пам’ять браузера звільняється.

3. Функції, що виконуються асинхронно, наприклад, setTimeout, setInterval, код, написаний на RxJS. Тут дійсно можна написати код, що призведе до витоку пам’яті, але цього не знають хіба що джуни...

Angular автоматично відписується від RxJS Observable, якщо його код зустрічається у в’юхах або у HttpClient. В усіх інших випадках потрібно обов’язково відписуватись від підписок на нього.

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

С подключением. Всех уже тошнит от angular/react/vuejs, а вы только начали задумываться...

и что вы со своей стороны предлагаете?

так я и думал
именно это я и полагал

Питання що винесене в назву треду, на мій погляд, не вірно сформовано. Треба запитання, щось на кшалт: Насколько применима концепция SPA для WEB проектов. Бо якщо SPA, то звісно фреймворк. А питання наскільки і коли потрібно саме SPA, на мій погляд слушне.

концепція SPA для нормальних проектів?

Для нормальный проектов написано тонны готовых CMS/CRM/ERP и так далее, бери и внедряй.

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

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

Який сенс взагалі у всіх цих складностях, з купою різних файлів, які генеруються ще в купу інших файлів, а ті іноді перекомпілюються ще в щось?

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

...тим більше, що самі по собі Angular чи ReactJS не пропонують готові компоненти, як такі.

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

Що ви думаєте про таку архітектуру...

Чем сложенее будет становися приложение тем сложнее будет поддерживать его. 2008 — 2012 использовал подобный подход, очень сложно потом поддерживать проект, в итоге перешел на ExtJS (cейчас использую React).

Яке в такій архітектурі може буте місце Angular чи ReactJS?

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

SPA для ввода данных пользователем JS для украшения бизнес-логику в 1С

Чувак, ты куда попал, где проект с таким стеком в 2018 и ты не видишь смысла в джс фреемверках?

JS+jQuery+jQueryUI

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

Сайт на котором вы это написали использует как раз технологию начала тысячелетия. И вполне нормально работает
screenshots.gennady.pp.ua/20180319_22e847f2a.png

Можу побажати вам удачі, якщо вирішите розробляти додаток на подобі Google Drive/Gmail без фреймворку.

тим більше, що самі по собі Angular чи ReactJS не пропонують готові компоненти, як такі.

material.angular.io
react-toolbox.io

Тем не менее, ни Gmail ни Drive вроде как и не на ангуляре :) более того, если уже у самого гугла аппы на ангуляре глючные (тормозящие, лагающие, жрущие) — это analytics и adwords например — то возникает вопрос... )))

Віталій, перший реліз Angular v2+ був у вересні 2016 року. Тобто йому всього 1.5 рочки. Ви думаєте цього достатньо для побудови десятків ентерпрайз-рішень на рівні Google?

Первый вышел 7 лет назад, этого мало? А если почему-то первый гуляр не подходил для юзания внутри самого гугла, зачем вообще было его выпускать наружу — чтобы ежики кололись?

Вам показати кількість вакансій на сайтах пошуку роботи для першої версії Angular? Ви зможете протиставити якийсь інший фронтенд-фреймворк, що згадується більше разів в описі вакансій?

По-моєму, це значно вагоміший аргумент, ніж кількість сервісів Google, написаних на Angular.

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

Очень удивлюсь, если ангуляр все еще будет в мейнстриме через 5 лет. На моих глазах умер флеш\флекс — кто помоложе, даже не представляют, насколько это звучало нереально даже в 2010. При этом технология была — по всем параметрам js SPA до нее было далеко. Silverlight также ярко слил разработчиков которые в него поверили, но там фейл не настолько эпичен — он быстро взлетел и помер.

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

Есть что-то другое на замену? Я работал\работаю с интырпрайзами с SPA и без оного — все же с SPA попороще, как минимум — выносится вся фронт-энд логика нах к юзеру и не парит мне мозг на бэк-энде. Конечно все сводится к частным случаям, но если выбирать из двух зол — то SPA лучше.

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

SPA заставляет работать в условиях физического барьера между сервером и клиентом, соприкасаясь только данными. Иначе, как обычно, все превращается в монстровидную кашу из различных вставок, неявных обработок, нагромождения абстракций и т.д. Закон разработчика гласит, что если легче сделать плохо, то плохо будет сделано обязательно. В библиотеке сколько_можно_ваш_... именно это учитывалось при проектировании. Именно за ней будущее, а не за ангуларом. Это я точно знаю, потому что не учил и не собирался: перл, флеш, пхп даже тогда, когда все вокруг было перл-флеш-пхп. Зато я хорошо освоил ColdFusion и его идеи потом всплывали во многих продуктах.
SPA будет жить, а по мере развития библиотек, подобных react-symbiote, ангулар станет маргинальным совсем

Про SPA речь не шла, тем более что в текущем виде — это часто тот же монолит но на фронте. Правда, уже начали говорить про micro frontends и гибридные вебаппы — что намного правильнее подхода «будем пихать SPA везде потому что хайп».

Также появляются первые прототипы новых SPA вроде github.com/aspnet/blazor который, возможно, также отправит ангуляры и реакты на свалку, как когда-то туда отправился скажем Backbone — причем, на мой взгляд, незаслуженно. Просто стал «немодным», а у фронендеров это самый главный критерий походу :-)

жаваскрип не подходит для нормальных проектов

Спасибо за отчет.
Продолжайте вести наблюдения.

тяпница же, время вбросов

GWT? Dart? Что подходит?

С++, ессно
веть если разобраться, СПА это ж не просто так. это от бедности языка. приложения сложнее тормозные и вермишелеподобные

jQuery. 2018.

Щось явно не те.

Тобто, jQuery ніхто не використовує і проект потрібно закрити і код видалити?

Для SPA ні, не використовують.

Та ні, таки використовують, на жаль. Підсісти на jQuery так само легко, як перейти по лінку й підхопити вірус в інтернеті. Дев, інфікований вірусом jQuery, буде його тулити куди тільки можна = ), від нього не так легко вилікуватись.

если вы пишете новое приложение, толстый клиент.
в 2018.
и не используете никакие структурные фреймворки, только jquery.
то да, лучше удалить.

Google Closure — це структурний фреймворк?

не работал с ним.
судя по туториалу — не структурный, скорее как jquery + jqueryUI.
ни реактивности(Vue, React), ни change detection(Angular), ни модели как источника событий(Backbone).
при наличии сложной структуры данных(пачка связанных моделей) либо сложного представления(куча связанных виджетов) задолбаетесь выгребать что-то типа «пользователь прочёл все сообщения, но всё еще показывается счетчик непрочитанных!»
если вам нужно что-то, что можно прикрутить на существующий проект с jQuery или Google Closure, но чтоб постепенно — посмотрите VueJS

www.smashingmagazine.com/...​02/jquery-vue-javascript
medium.com/...​-than-jquery-abbbb9c12cf8

Та ні, я до того, що саме це сам Гугл використовує для своїх сервісів(gmail, drive, gmap etc), а не той же Angular.
Якщо все так складно, як Ви пишете, то чому Google обрав саме Closure, а не Angular?

як Ви пишете, то чому Google обрав саме Closure, а не Angular?

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

Базовый поиск дает:
www.madewithangular.com/categories/google
Я бы не был так категоричен про гугл и использование Ангулара)

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

У нас есть несколько внутренних проектов, сделанных на одном конструкторе. В этом конструкторе на фронт-енде именно jQuery с плагинами — так было сделано преднамеренно, чтобы снизить порог входа для новичков, которые специализируются на back-end разработке, и для которых освоение Angular / React / Vue будет сродни обучению пилотирования космического корабля.

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

з приводу готових компонентів подивіться наприклад ant.design

Готових компонентів безліч. Це не проблема.
Є питання, навіщо самі ці фреймворкі типу Ангуляра? Чудові компоненти є і для старого доброго jQuery

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

А в який спосіб Angular/React/Backbone спрощують це завдання? Я так розумію там так само на JavaScript або TypeScript треба програмувати цю взамодію?

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

Вам варто свою оцінку перевести з площини упередження у площину аргументації. Якщо ви з повагою ставитимесь до SPA, якщо ви поекспериментуєте і напишете свій тестовий проект, складніший за «hello world», ви зрозумієте для чого вам потрібні SPA-фреймворки.

Я людина далека від веб фронтенду(хоча іноді доводиться щось рендерити в браузері) але спробую відповісти. На мою думку не треба порівнювати SPA і статичні сторінки в такому форматі як ти намагаєшся порівняти(переваги і недоліки). Суть SPA, я вважаю, інкапсулювати якусь певну бізнес логіку, як має тісний рілейшеншип з юай компонентами, наприклад, гуглові доки, таблиці(там вся бізнес логіка в тому що юзеру зручно оперувати даними без миготіння і перезавантажень), стрічка новин, фейсбук фід стрічка, і т.п. Ні SPA ні статика не забороняє писати 1 бекенд, просто уже як і написали нижче і спа і статика є клієнтами твого бекенду. Інша справа що в тебе може бути рівень(левел) абстракції на бекенді головним ретурн тайпом якого буде не голий json а готовий html. Уяви таку структуру рівнів на твоєму сервері:
-бізнес логіка()
-> return JSON
-> SPA(JSON path through)
-> SPA (rendered Angular module html)
-> Static Page (render from header to footer html)
-> Static Page ( JSON for AJAX == SPA(JSON path through))

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

дуже не ефективні для серйозних програм

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

навіщо всі ці ускладнення

Уяви що ти навчився їздити на трьохколісному велосипеді, а завтра тобі скажуть їздити на моноциклі. До чого метафора, трьохколісний == jquery, двухколісний == Angular, React, моноколісний == Angular, React + 100500 компонентів які вже на проекті. А мораль така, якщо ти шариш правила їзди на двухколісному(тримати рівновагу, не зупинятись бо впадеш і т.д) то ці правила працюють і для моноцикла(але плюс ще навики треба), тобто вся фішка в правилах і умовних «договорняках» які позбавляють замовника(платника) грошей кожного разу витрачати час на перенавчання нових робітників, які прийдуть зі своїм «велосипедом» і скажуть, пацани го їхать на моєму, і пофіг шо у вашого вєліка може шось там і краще(goo.gl/HFqC4k).

Angular чи ReactJS не пропонують готові компоненти

про які компоненти йде мова? якщо про UI то статтю, то погано прочитана була, так як автор ссилався на той же Angular Material

де все що може бути статичним робиться статичними сторінками з JS+jQuery+jQueryUI/PrimeUI/etc.

глянь уважніше на фейсбук(сайт)...

вже й жалію що почав писати цей комент, та й видалять впадло)

Я можливо невдало виклав свої питання. Я жодним чином не хотів протиставляти SPA vs Static pages. Чесно кажучі я взаглі вважаю, що SPA і є статичною сторінкою, яку просто потім динамічно змінюють в браузері.
Переше питання було, до якої межі може мати сенс триати все саме на ОДНІЙ сторінці.
А друге питання було про те що дають всілякі популярні нині фреймворки, що не можна зробити простіше за допомогою більш «преземлених» технологій.
Ну а третє — це приклад такої технології, альтернативного підходу. Html, JS+jQuery + (увага, це здається тут не дуже зрозуміли) готові компоненти для jQuery. Їх дуже багато і є навіть готві бібліотеки компонентів такі, як PrimeUI.

Я нічого не стверджую, намагаюсь дізнатись. Що саме дають Angular, ReactJS, чого не може дати підхід описаний в моєму третьому пункті.

P.S. Фейсбук — це жах! Гадаю, що єдина причина чому цим сайтом досі користуються люди — те що ви просто не можете перейти на інший, бо там не буде всіх ваших друзів.
Може це і є гарний приклад того, чому дуже важко написати нормальну програму в одному вікні браузера?

P.S. Фейсбук — це жах! Гадаю, що єдина причина чому цим сайтом досі користуються люди — те що ви просто не можете перейти на інший, бо там не буде всіх ваших друзів.

— приведи пример любой другой соцсети, написаной на jQuery.

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

Не удобно, потому что сталкиваетесь с реальными техническими багами или просто UX смущает?) Потому что если вам неудобно пользоваться, но оно хорошо работает (мой опыт с фейсбуком), то не в фреймворке дело. Но, смею уверить, что на jQuery едином UX был бы нереально хуже, а технических багов в разы больше.

и баги, и UX там очень сильно страдает. По крайней мере в Safari

З багами там наче все непогано. Там проблема саме з реалізацією. І, справді, найбільші проблеми там все ж не в UX, а в серверних технологіях, що вони обрали. Пошук, система комментів і т.і.
Але і з UX там все не дуже. Є прості проблеми, як от коли ви тиснете Лайк на якомусь сайті і потім, щоб набрати текст більше 3 літер іноді треба дуже постаратись. Або є проблеми, що витікають з обмежень архітектури SPA, коли досить проблематично букмаркати цікаві матеріали, особливо коментарі. Система коментів взагалі неюзабельна. Навігація дуже заплутана, ну звісно, якщо треба щось більше ніж скролати стрічку. Простір використовується вкрай нераціонально, все дуже перевантажено зайвим.

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

Это не проблема того что фейсбук SPA. Это проблема UX. Тут не нужно путать UX c его программной реализацией, т.к. в первую очередь UX — это принятые решения о том как пользователи будут пользоваться ресурсом (бизнес аналитика, дизайн и т.д.), а не технология реализации. SPA архитектура как раз дает больше простора для UX и позволяет создавать более удобные решения, но в конечном итоге пользователь страдает не столько от криворукости программистов, сколько от неудачных решений UX

Або є проблеми, що витікають з обмежень архітектури SPA, коли досить проблематично букмаркати цікаві матеріали, особливо коментарі.

Не совсем понимаю связь проблемы с архитектурой SPA :)

Що ви думаєте про таку архітектуру, де все що може бути статичним робиться статичними сторінками з JS+jQuery+jQueryUI/PrimeUI/etc. Ну там шаблони всілякі є, але генеруються в кінцевому підсумку в статичні сторінки перед релізом.

Как при таком подходе написать условный гугл.мапс?

Тобто жодного сенсу серйозно перевантажувати фронт-енд.

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

1)Гугл Мапс, насправді в цьому контексті дуже проста програма. Там один (ну може 2 з гугл стріт) вікон. Наскільки мені відомо там вони використовують свою JavaScript бібліотеку Closure, як і у більшісті гугловских сервісів, самі вони свій хвалений Ангуляр не дуже то і використовують для реальних проектів.

2)Це не факт. Зараз Інтернет все більше зміщується на мобільні пристрої. А у них зазвичай з ресурсами не дуже. Особливо в плані батареї.
Наприклад той же фейсбук на телефоні, що програма, що сайт постійні учасники усіляких антирейтингів bloatware. Дуже багато користувачів їх не люблять саме за цю жирність не ресурсоємність. Але від фейсбуку поки люди відмовитись не можуть. А від вашої програми?

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

самі вони свій хвалений Ангуляр не дуже то і використовують для реальних проектів.

Google Adwords, який приносить гуглу 60+ % revenue, написаний на Angular2 + Dart.

Цікаво!
Знайшов статтю з цього приводу:
news.dartlang.org/...​i-uses-dart-we-asked.html

Як взагалі Dart підтримується для Angular? В Angular все ж на TypeScript заточено з коробки...

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

Ви називаєте «більшістю бізнес логіки» аутентифікацію та авторизацію? Це називається «за вуха притягнуті аргументи».

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

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

Зараз Інтернет все більше зміщується на мобільні пристрої. А у них зазвичай з ресурсами не дуже. Особливо в плані батареї.

Ви думаєте, що цей ваш аргумент служить на користь сторінок, сформованих на бекенді? — Ні, SPA якраз тут можуть показати значно кращий результат, оскільки архітектура SPA дозволяє один раз завантажити, наприклад, header, footer, widget... і не підзавантажувати їх за кожним переходом, з відповідною перемальовкою. Це перше. Друге — об’єм даних може суттєво скоротитись через цю особливість.

Не треба приписувати мені того, що я не казав. Аутентифікацію та авторизацію я привів лише, як приклад. Сама бізнес-логіка, звичайно, включає набагто більше різних задач.
Окрім того не варто плутати авторизацію з аутентифікацією. Це різні речі. І авторизація на клієнті... серйозно? Можете розкрити детальніше, що Ви маєте на увазі?

щодо SPA то все не так однозначно. Завантажити header&footer та відрендерити простий html може бути не такою вже і великою проблемою в порівнянні з перевантаженою логікою, яка буде «перегрівати» процесор. Підвантажувати та частково перемальовувати контент можна і в не SPA сайтах. Просто можна це робити там де це має сенс і не робити там де це перевантажує складність системи.
Але я не ствреджую. Це як раз я намагаюсь з’ясувати.
Для чого скажімо деякі фреймворки мають сервер-рендерінг режим?

Аутентифікацію та авторизацію я привів лише, як приклад.

Ви навели цей приклад в контексті аргументації своїх слів про «більшість логіки на бекенді»...

І авторизація на клієнті... серйозно? Можете розкрити детальніше, що Ви маєте на увазі?

Так, серйозно. Ви сумніваєтесь, що можна на клієнті прописати роль користувача і його право заходити на певні закрити сторінки?

Завантажити header&footer та відрендерити простий html може бути не такою вже і великою проблемою в порівнянні з перевантаженою логікою, яка буде «перегрівати» процесор.

А для чого порівнювати «перевантажену логіку» із «неперевантаженою»? Якщо вас цікавить SPA і не SPA архітектура, то для початку беріть однакові умови, порівнюйте їх... А тоді ще зважте додаткові можливості SPA-архітектури, що абсолютно недосяжні для «статичної» архітектури...

Для чого скажімо деякі фреймворки мають сервер-рендерінг режим?

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

Якщо це не пару хелло ворлд екранів, це все здатно суттєво роздути пам’ять на клієнті. А можливостей звільняти(вивантажувати зайві скрипти), начебто в сучасних браузерах немає?

В браузерах? В браузерах есть- DOM узел скрипта удалить, ссылки на импортируемый код за null’ить, сборщик мусор уберет, если его никакие колбеки не держат. Хотя все это на практике грузится внутри модульной системой через ajax+new Function() и то, что они не предоставляют такой функционал это другой вопрос, но при нужде там в некоторых это можно сделать через костыли.

Суть питання не в тому чи можна це якось в принципі десь зробити з милицями. Якщо я використовую Angular, ReactJS, Vie.JS etc вони здатні мені гарантувати, що в разі дуже складної архітектури вони будуть підчищати в пам’яті браузера той контент, що зараз не використовується? Або воно буде так потихеньку пухнути поки не завантажить все що можливо?Уявіть сайт з великою кількістю різних розділів, форм для заповнення і т.п. така типова бізнес програма.
Браузерів багато, на всіх милиць не наробишся.

вопрос утечек памяти в системе с автоматизированным сборщиком мусора и без прямого управления памятью.
дайте-ка подумать.
а как с такой задачей справляется код на Java, .NET, Python, Ruby etc?

Там це не є такою проблемою. Java програму ніхто в 100500 табах браузера не відкриває.
І є багато різних можливостей для оптимізації в залежності від специфіки задачі.
.Net з власного досвіду скажу дуже гарно віддає пам’ять, можна сказати все що бере миттєво і повертає. З Java було дещо гірше, коли в мене були такі задачі, але зараз там, здається, теж все непогано(принаймі є ключі для JVM). Хоча, зазвичай, кого це хвилює на сервері?
Про Python, Ruby нічого не знаю, але ж і їх ніхто в табах браузера в неймовірних кількостях не запускають. І на мобільних пристроях теж не запускають де обмежена пам’ять, батарея і можливості процесора.

Java програму ніхто в 100500 табах браузера не відкриває.

сервіс під Андроїдом може крутитися місяцями до наступного перезавантаження.
на сервері також існують програми-демони на Джава, що дофіга часу проводять у пам’яті без перезапуску.

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

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

ага, пам’ятаю, як мені треба було на своєму Fly IQ440 час від часу дропати усі контакти з телефоної книги і завантажувати їх заново через синхронізацію. Бо contacts storage починав пожирати 300Мб+ замість 12Мб без жодних дій з мого боку.

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

бо це не програма користувача, це сервіс-контейнер.

Хоча, зазвичай, кого це хвилює на сервері?

Вы вот это сейчас серьезно, да? Т.е. вы серьезно думаете, что утечки памяти на серваке никого не парят? Вы, по-моему, вообще не от мира сего.

Тут виникла деяка каша з понять.
Я питав про розрастання пам’яті за рахунок підвантаження навих модулів. Це не

утечки памяти

(memory leak). І якщо ви пишете на Java там про memory footprint зазвичай думють, але лише коли в цьому є реальна потреба. Подивіться просто на Java проекти яких безліч в мережі. Там просто зазвичай інші пріорітети. Ті для кого дуже важливий розмір програми і скільки вона використовує пам’ять роблять проекти на C++, а де це критично і взагалі на C.
Коли в програмі є memory leak звичайно це серйозний баг і його завжди нормальні люди виправляють.

Теперь понял.
Да, действительно, вопрос memory footprint в ентерпрайз джаве даже не ставится как таковой.

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

Кажется, он не об утечках памяти в коде, а в разрастании памяти

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

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

как по мне — это и есть утечки памяти. если обработчик уже не актулен, но все еще висит на элементе.

то сам модуль — занимает фигню.

Ну да, в принципе оно так, память относительно дешевая (хотя уже и не очень), она клиента и за это платить не надо :) Вон в 12 году никто не верил, что веб приложения будет гиг отжирать. Но с каждым годом аппетиты приложений таки растут, куда быстрее чем озу, так что рано или поздно проблема может стать весьма актуальной, особенно на мобильных девайсах. Да на них собственно уже чувствуется, если у тебя не 4 гб. К тому же, движку перворманса это не добавляет, оперирование кучей памяти, гонять по ней мусорщика в поисках.

Набор функций и всё.

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

как по мне — это и есть утечки памяти. если обработчик уже не актулен, но все еще висит на элементе.

Ну так она же и есть, из за этого модуль просто за nullить и удалить с кеша загрузчика не получится, ссылки не разорваны, а текущие модульные системы не имеют функционала деиницализации. Тоесть чтобы при выгрузке дать разработчику возможность подписаться на это и подчистить за собой. И даже если сейчас оно для 95% не актуально, но лучше бы заложить этот функционал на будущее.
Если допустим, заделали мы какой то компонент, который подгружается по клику, например выбор аватарки юзеру. Ну компонент модули подгрузил, все отрисовалось, выбрали, пора закрывать. Что делать с подгруженными модулями? Например для редактирования аватарки погружался фреймворк роботы с canvas. Сейчас это «пусть висит, авось пригодится когда». Как по мне нужно таки дать возможность чтобы сборщик мусора смог это убрать из памяти. Написать web приложение уровня FL Studio, которое не будет отжирать 5гб сейчас было бы проблематично.

4) Що ви думаєте про таку архітектуру, де все що може бути статичним робиться статичними сторінками з JS+jQuery+jQueryUI/PrimeUI/etc.

До появления фреймворков оно так и было. И это был лютый писец и адище из коллбеков. Оно того не стоит, забудьте вообще.

А после появления фреймворков конечно же все проблемы решились: hackernoon.com/...​ript-in-2016-d3a717dd577f

Для примитивного бложика сойдет.

А если Ваше приложение расчитано на несколько клиентов? Будете под каждого свой бекенд писать? Это так, одна из проблем. А вообще это вполне естественно, стараться изолировать апликейшн от клиента и не смешивать их.

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

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

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

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

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

Конечно нет, только jQuery!
Видно автор не знаком с предметом.

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