Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Раздел полезных советов: Сравнение методов исключения разработки на JavaScript для веб технологий, auto_tips (??), 07-Дек-21, (0) [смотреть все] Решения для создания невообразимо отвратительных проприетарных шпионских сайтов , Аноним (1), 10:21 , 07-Дек-21, (1) +2 // Судя по описанию - сделано ящерами с планеты ниибиру, видимо на js у них аллерги, Аноним (-), 06:51 , 23-Дек-21, (37) А в чем невообразимость Js при данных подходах все равно нужен, который ещё нуж, Аноним (39), 17:31 , 27-Дек-21, (39) Отвратительность и шпионство создают не решения а люди Любой сайт можно сделать, stillswamp (ok), 11:05 , 07-Дек-21, (2) +2 Хорошая статья Если обратиться к исследуемым библиотекам, то нужно быть либо ск, Linuxoid (?), 13:13 , 07-Дек-21, (3) // Суть указанных подходов - сокращение средств разработки Так как избавиться от д, stillswamp (ok), 14:02 , 07-Дек-21, (4) +1 // Нет, теперь бэку, помимо своей основной работы, придется выполнять также и работ, Аноним (12), 10:30 , 11-Дек-21, (12)   // Поясню принцип если работу можно выполнить одному специалисту одним инструменто, stillswamp (ok), 12:39 , 11-Дек-21, (15) –1   При этом предполагается, что у проекта будет только веб-клиент причем один, а н, Аноним (12), 19:01 , 11-Дек-21, (16)   1 Контекст отображения не имеет принципиально никакого значения с точки зрения , stillswamp (ok), 20:16 , 11-Дек-21, (17)   DOMChilds GUID , self ID -- этот код может не сработать Потому что у альтерн, Аноним (12), 21:06 , 11-Дек-21, (18) +2   1 Что такое альтернативный веб клиент Если это один проект, то следует задать , stillswamp (ok), 22:53 , 11-Дек-21, (19)   Все, что угодно Еще одна веб-страница, созданная с нуля, с другой версткой, но , Аноним (12), 14:14 , 12-Дек-21, (22)   Вы выставляете правильное требование и именно оно породило MVC концепцию, когда , stillswamp (ok), 21:11 , 12-Дек-21, (23)   Не увидел ответа, как к существующему сайту на фреймворке прикрутить нативное мо, Аноним (12), 22:10 , 12-Дек-21, (26)   Мы перешли от обсуждения реализации Pusa к архитектурным вопросам Ответ по сущес, stillswamp (ok), 10:00 , 13-Дек-21, (28)   Добавлен пример Copy в буффер- https pusa catlair net section Examples- https, stillswamp (ok), 13:50 , 13-Дек-21, (31)   Если речь не о самом примитивном конструкторе страниц из готовых блоков, то зада, Бывалый смузихлёб (?), 07:01 , 14-Мрт-22, (49) +1   Подход Korolev мне больше нравится Было бы офигенно, если бы кто-то сделал что-, Аноним (5), 10:58 , 08-Дек-21, (5) // Here is a solution to you - JavaScript in browse , DD (??), 23:25 , 04-Фев-22, (47) бредовый подход но история повторяется раньше гоняли ajax-ом сгенеренные куски, Glushko (?), 11:51 , 09-Дек-21, (6) // 1 Прошу конкретику Что применено не по назначению Готовы исправить 2 Прошу о, stillswamp (ok), 23:23 , 09-Дек-21, (7) // 1 не по назначению - это про концепцию совершенно безумная идея перенести ре, Glushko (?), 11:27 , 10-Дек-21, (8) // skip, stillswamp (ok), 19:22 , 10-Дек-21, (9) Благодарю за подробный ответ Перенос событий из браузера на сервер практичен Ут, stillswamp (ok), 19:25 , 10-Дек-21, (10) Да, один раз При самом первом заходе на сайт Дальше браузер все закэширует Пре, Аноним (12), 10:32 , 11-Дек-21, (13) Я давно и много смотрю на логи пользовательских запросов Пользователям нет дела, stillswamp (ok), 12:32 , 11-Дек-21, (14) Ваше мнение принято Выложили helloworld todo на Pusa Ссылка https dev todo , stillswamp (ok), 19:36 , 29-Дек-21, (41) мелочь говорите , Sw00p aka Jerom (?), 12:13 , 12-Дек-21, (21) Оцените по вашему опыту сумму затрат для публичного ресурса с постоянной доработ, stillswamp (ok), 21:20 , 12-Дек-21, (24) зачем мне оценивать сумму затрат, меня интересует вопрос нагрузки, какую нагрузк, Sw00p aka Jerom (?), 00:13 , 13-Дек-21, (27) 1 Потому что я, отвечая на комент мелочь говорите , сопоставлял стоимость раз, stillswamp (ok), 10:08 , 13-Дек-21, (29) И не только php, а также nodejs, go, rust и большая туча других языков RPS и lat, Anonimus (??), 22:48 , 16-Дек-21, (33) а нельзя просто дотнет wasm взять , морошка ягодка такая (?), 11:50 , 12-Дек-21, (20) +1 // С удовольствием обсужу в телеге если у вас есть опыт реализации , stillswamp (ok), 21:23 , 12-Дек-21, (25) Просто взять http www rebol com docs cgi2 html и http www rebol net plugin t, username (??), 13:12 , 13-Дек-21, (30) // Читать умею Поиском пользоваться тоже Интересен реальный опыт использования А , stillswamp (ok), 13:52 , 13-Дек-21, (32) т е он всю клиентскую часть хранит на сервере, а на клиент спускает её в готово, mos87 (ok), 10:14 , 17-Дек-21, (34) // вот, кстати, да , gred (ok), 13:26 , 19-Дек-21, (36) +2 100500, DD (??), 23:26 , 04-Фев-22, (48) Web нужен для связи - это связь Всё Веб - только канал передачи данных Все ег, Аноним (50), 11:49 , 13-Апр-22, (50) // вэб единственное что щас примечательно в нём технологически - это реализация т, mos87 (ok), 18:21 , 13-Май-22, (52) я бы сказал, что для каких-то чисто внутрикорпоративных вещей, почти идеально ос, gred (ok), 13:21 , 19-Дек-21, (35) // Если вы храните состояние DOM на сервере - то действительно это не для выпуска н, stillswamp (ok), 19:39 , 29-Дек-21, (43) шикарная идея, подобные сайты будут быстро работать даже на сименсе м65 меня вол, онанимус (?), 12:59 , 27-Дек-21, (38) –1 // Да Pusa работает даже на тапке Причем как клиент так и сервер , stillswamp (ok), 19:37 , 29-Дек-21, (42) Что люди только не делают, чтобы Blazor не использовать , 18d75a8d3a9b403d82e5f66cdc5d204a (?), 12:50 , 29-Дек-21, (40) Можно же на c писать, через blazor , морошка ягодка такая (?), 10:40 , 01-Янв-22, (44) у нас была возможность не только познакомиТЬся с исходным У меня всё , CHH (?), 15:44 , 28-Янв-22, (45) если цель в выбрасывании js из разработки, то что на счёт PIB https github com, ford153focus (ok), 12:15 , 04-Фев-22, (46) // избавиться от клиентского кода, чтобы абстрагировать писателя бизнес-логики от с, rex (??), 14:21 , 15-Июн-22, (53) Опять пытаются сэкономить на разработчиках за счёт комфорта пользователя Теперь , Аноним (51), 09:08 , 27-Апр-22, (51) 1,2,3,5,6,20,34,35,38,40,44,45,46,51

Сообщения

[Сортировка по времени | RSS]

	12. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от Аноним (12), 11-Дек-21, 10:30
	> сократить девелопинг на фронте Нет, теперь бэку, помимо своей основной работы, придется выполнять также и работу фронтендеров, столь заботливо переложенную на них фреймворком Pusa.     DOMBody()->DOMChilds('GUID', self::ID)->DOMValue(clGUID()); Здесь нет ничего, что бы относилось к "бизнес-логике", здесь исключительно гуйная логика, которая выполняется не там, где должна бы.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Сравнение методов исключения разработки на JavaScript для веб технологий"	–1 +/–
	Сообщение от stillswamp (ok), 11-Дек-21, 12:39
	>> сократить девелопинг на фронте > Нет, теперь бэку, помимо своей основной работы, придется выполнять также и работу > фронтендеров, столь заботливо переложенную на них фреймворком Pusa. >     DOMBody()->DOMChilds('GUID', self::ID)->DOMValue(clGUID()); > Здесь нет ничего, что бы относилось к "бизнес-логике", здесь исключительно гуйная логика, > которая выполняется не там, где должна бы. Поясню принцип: если работу можно выполнить одному специалисту одним инструментом без потери качества и времени, это лучше сделать именно так, так как исключает расходы на координацию. Pusa не про то что "ай бэку нужно делать фронт". Pusa - техническое средство решающее финансовые вопросы унификацией инструментария и специализации.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от Аноним (12), 11-Дек-21, 19:01
	При этом предполагается, что у проекта будет только веб-клиент (причем один, а не несколько альтернативных). Как только понадобится десктоп- или мобильный клиент, всю работу с домом из бэка придется убрать. Потому что фреймворк поощряет идти неверным путем, когда бэк не дает вменяемого интерфейса/схемы и возвращает в ответе черт-те что, прибитое гвоздями к пользовательскому стейту. Далее, как только будет необходим шаг вправо/влево, что-нибудь не предусмотренное фреймворком, ничего не останется, кроме как обратиться к разработчикам фреймворка => отсюда лишняя зависимость от сторонних чуваков, их занятости и заинтересованности. Заинтересованность скорее всего придется банально покупать. Так не проще ли платить своему же фронтендеру, сидящему за соседним столом? Далее, фреймворк предполагает, что бэк-разработчик, помимо своей основной специализации, также владеет как минимум HTML и CSS, а также понимает, в какой аналогичный JS-код выполнятся все эти DOMXxx()-вызовы. Что, очевидно, далеко не всегда так. Если скомпилировать все веб-стандарты (фронт-онли) в единую книгу, получится талмуд, на порядки толще стандартов для целых операционных систем. Поэтому я бы не говорил про отсутствие потери качества. Далее, постоянно приводится пример, когда работает всего "один специалист": "работу можно выполнить одному специалисту одним инструментом" — в связи с этим фреймворк выглядит как временное решение на самом старте бизнеса, от которого постараются избавиться, как только у компании найдутся деньги на найм фронтендера. Далее, для фреймворка такого типа выбран странный транспорт - XHR, когда как веб-сокеты не предполагают переподключения на каждый чих (а чихов будет много -- реакция на гуйные события как-никак). Можно же задействовать XHR в качестве фолбэка в конце концов.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от stillswamp (ok), 11-Дек-21, 20:16
	1. Контекст отображения не имеет принципиально никакого значения с точки зрения фэймворка. Прошу пояснить каким образом конечное устройство влияет на бэк и почему его придется убрать? 2. Повторю ранее заданный в этой же ветке вопрос. Представьте case который не реализуем в Pusa на текущий момент. Он будет либо сделан либо явно включен в ограничения. 3. Разработчк на Pusa НЕ РАБОТАЕТ с DOM. Он оперирует крайне ограниченным набором инструкций которые могут формировать DOM, при этом об его фактическом устройстве знать не обязательно. DOM* функционал Pusa - не более чем набор конечных инструкций. Если вы занимались разработкой под opengl, то подход для вас будет знаком. Разраб работает с инструкциями а не с контекстом. Это принципиально важно. 4. Один разработчик - это крайний пример плоской схемы, когда у вас в наличии вместо нескольких направлений с необходимостью координации линейные бэки. Не погибнет эта схема с расширением бизнеса. Pusa создана масштабированием и под оное. 5. XHR выбран в качестве САМОГО примитивного варианта для демонстрации схемы и доказательства ее работоспособности. Так же была выполнена реализация на iframe, но была отклонена что бы не пугать людей. Мы планируем представить реализации как минимум на ws для golang, java, node.js. При этом мы по прежнему будем настаивать на исключении хранения состояния клиента на бэке.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+2 +/–
	Сообщение от Аноним (12), 11-Дек-21, 21:06
	DOMChilds('GUID', self::ID) -- этот код может не сработать. Потому что у альтернативного веб-клиента такого инпута может не оказаться. DOMParent()->DOMParent() -- требует жесткой иерархии элементов. Если оформлять таким образом весь апи бэка, то в конце придем к ситуации, когда малейшее изменение в HTML повредит половину функционала. В реактах это не так, там явно прописываешь <span>{age}</span>. Ни один из этих примеров не сработает для мобильного клиента. Вот как мне выдрать person name из примера "Read data parameters"? Pusa[3][1].Values.innerHTML? Бред же. > Представьте case который не реализуем в Pusa на текущий момент А очень просто. Берешь вот эту страницу: https://developer.mozilla.org/en-US/docs/Web/API И сверяешься с тем, есть ли аналогичный апи в протоколе: https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la... Мне например интересно, как будет организована кнопка копирования в буфер обмена. Вдуматься только: чтобы скопировать в буфер, нужно будет послать сигнал бэку, чтоб тот прислал ответ: "хорошо, копируй в буфер то, что у тебя в клиент-стейте выделено, я хз, че у тебя выделено, но скопируй". А при медленном соединении полагаю, будет что-то типа, что пользователь жмет Copy, немедленно переключается альт-табом в ворд, вставляет -- а там старое содержимое. Потому что ответ бэка пришел слишком поздно, в момент, когда браузерная вкладка уже не в фокусе, так что браузер запретит записывать в буфер. (А в некоторых браузерах в клипбоард можно записывать только и только из event handler; ставишь setTimeout или ждешь бэка? -- откажут в доступе к клипбоарду.) > Разработчк на Pusa НЕ РАБОТАЕТ с DOM Семантика. Хорошо, JavaScript-разработчик тоже не работает с домом. Он просто посылает в браузер файл с расширением ".js", а браузер его интерпретирует как хочет, в том числе меняет дом. Прямо сейчас в протоколе я вижу императивные команды: DOMSelect, DOMCreate... Это вполне себе работа с домом, просто все команды сериализованы для передачи по сети. DOMParent говорит о том, что бэк в курсе, че там как устроено в доме. Ну и интересно, как выводить текст типа "Подождите, операция выполняется". Допустим, в примере "CRUD Form" я хочу, чтобы нажатие на кнопку выводило где-нибудь throbber. Как это сделать?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от stillswamp (ok), 11-Дек-21, 22:53
	1. Что такое альтернативный веб клиент? Если это один проект, то следует задать вопрос его создателям каким образом в проекте не учитывается отсутствие элемента. Если ваш JS нацелен на наличие этого элемента а его нет, то что тогда? 2. Вы всегда имеете жесткую иерархию элементов. DOM - это жесткая иерархия. Если вы ее создали то вы на нее можете опереться. Тем не менее, методы обращения к элементам без иерархии в Pusa ничем не отличаются от нативного JS только запись короче и не нужен JS :) DOMBody() -> DOMSelect('myelement'); document.getElementsByClassName( 'myelement' ); 3. Я вынужден еще раз уточнить, почему вы делаете различие между мобильными клиентом и каким либо иным. Это всего лишь DOM, управление которым находится в ваших руках. 4. Pusa[3][1].Values.innerHTML - подробнее, это двумерный массив в котором лежит некий элемент Values? Если да, то Pusa не работает в JS. Или ваш пример о чем то другом? Плс... 5. Сравнение спецификаций WebAPI не очень. Предлагаю общностями не оперировать. Только конкретика показывает проблемы и позволяет их решить. 6. Copy() функция копирования будет вычищена из родительского проекта и добавлена в Pusa (код pusa.js возможно уменьшится...). Copy() положит выделенный контент в буфер. Касательно соединения, обратите внимание на это: https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la... это. Pusa умеет делать своеобразные "замыкания", которые не требуют обращения к back: $this -> DOMSelect('CopyButton')->EventFront( $this -> Clone() -> Copy() ); Это красиво :) 7. Повторюсь. Бэк не в курсе как устроен DOM. Бэк обладает набором последовательных инструкций. Как они сложатся в DOM - проблемы браузера а не бэка. Те все то же самое как и в вашем примере, только нет лишнего средства JS. 8. Касательно сообщений и оконного интерфейса. Документацию пишем усиленно НО с тем как это устроено можете ознакомится https://gitlab.com/catlair/pusa/-/blob/main/php/web/win.php. Там и попапы, и диалоговые окна и прочий оконный ифейс с минимизациями максимизациями. Это так же красиво. С благодарностью ожидаю конкретных кейзов закатающих Пусу.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от Аноним (12), 12-Дек-21, 14:14
	> Что такое альтернативный веб клиент? Все, что угодно. Еще одна веб-страница, созданная с нуля, с другой версткой, но тем же бэком. Если бэк грамотно опишет свои интерфейсы, например в виде GraphQL-схемы, то выводить ответ бэка можно хоть в дом, хоть не в дом, хоть на принтер, хоть в консоль, хоть лазером на стену собора парижской богоматери. > различие между мобильными клиентом и каким либо иным Под мобильным клиентом подразумевались нативные андроид- и айос-приложения, где вообще нет никакого дома. Сценарий: допустим уже функционирует сайт на этом фреймворке. Компания решается разработать мобильное приложение и приглашает соответствующего специалиста. Как ему достать person name? Прямо сейчас -- парсить JSON-ответ и доставать person name по страшному пути "Pusa[3][1].Values.innerHTML". Заходи на свой Examples, жми кнопки, мониторь сетевую активность в F12 и подумай, как этот ответ выводить НЕ в дом. Когда это сделает андроид-разработчик, у него зашевелятся волосы сразу во всех местах: const personName = JSON.parse(response).Pusa[3][1].Values.innerHTML. > Сравнение спецификаций WebAPI не очень. Ты требуешь у меня списка того, что твой фреймворк не умеет. Я его тебе дал. Из этого длинного списка (толщиной в книгу) можешь вычеркнуть getElementById, getElementsByClassName, classList.add, classList.remove и еще парочку методов. Всё остальное не поддерживается. > Бэк не в курсе как устроен DOM В курсе, если он делает DOMParent и прочие штуки. Если бэк употребляет слово DOM, если он хоть как-то оперирует дом-терминами (parent, child, attr &cetera), то он знает про то, куда будет выводиться ответ. > Бэк обладает набором последовательных инструкций Причем не просто инструкций, а дом-инструкций. Если бы дом не знал про дом, он бы присылал просто {personName: "Andy"}, а не сериализованные команды инсёрта в дом.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от stillswamp (ok), 12-Дек-21, 21:11
	> Все, что угодно. Еще одна веб-страница, созданная с нуля, с другой версткой... Вы выставляете правильное требование и именно оно породило MVC концепцию, когда приложение имеет слои. Есть слой логики, слой отображения. Ваше приложение должно получить реализацию новой верстки. А Pusa поможет это сделать на единой платформе. >> Сравнение спецификаций WebAPI не очень. > Ты требуешь у меня списка того, что твой фреймворк не умеет. Я > его тебе дал. Из этого длинного списка (толщиной в книгу) можешь > вычеркнуть getElementById, getElementsByClassName, classList.add, classList.remove > и еще парочку методов. Всё остальное не поддерживается. JS на ОЧЕНЬ значительную часть состоит из обслуживания самого JS, который и составляет книгу. А на выходе ограниченный функционал, который Pusa и реализует. Между требованием типового функционала и возможностями Pusa есть некий люфт. Моя задача сделать его минимальным, потому я и веду эту переписку с вами с целью узнать ваши пожелания. > В курсе, если он делает DOMParent и прочие штуки. Если бэк употребляет > слово DOM, если он хоть как-то оперирует дом-терминами (parent, child, attr > &cetera), то он знает про то, куда будет выводиться ответ. Приведу пример - вы получаете инструкцию: - зайдите в комнату. - включите свет. От того кто пишет инструкцию - не требуется ни понимания комнаты, ни понимания как включается свет. При этом вы МОЖЕТЕ выполнить эту инструкцию. От кодера Pusa НЕ требуется понимания реализации DOM. Только понимание последствий инструкций. и да... DOM команды названы исключительно вас, так как вы знаете что такое DOM. Для человека не представляющего что такое DOM это просто набор инструкций.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от Аноним (12), 12-Дек-21, 22:10
	Не увидел ответа, как к существующему сайту на фреймворке прикрутить нативное мобильное приложение. > не требуется ни понимания комнаты, ни понимания как включается свет Зато требуется понимание того, что на клиенте будет и комната, и свет. А в случае с Parent это выглядит так: "переместись на два этажа выше, выдвинь ящик №83, там будет листок бумаги, запиши туда то-то". Все развалится, едва ящик переедет на этаж выше. Или если в определенный момент вместо бумаги туда положат степлер. А в больших проектах, где над ним трудится от 1000 человек, такие правки появляются не ежедневно, а ежеминутно. В итоге, если потребуется просто немного перевестать страницу, нужно потрогать и бэк. Признаком дурно пахнущего кода является то, что какое-то незначительное изменение ведет к правке сразу нескольких файлов в самых неожиданных местах (в данном случае они вообще на разных полюсах - фронт и бэк). Правильная архитектура: - бэк отдает минимум информации, и отдает именно данные, а не "команды", - клиенты эти данные выводят так, как им заблагорассудится, хоть в дом, хоть еще черт-те куда. Имея такую архитектуру, можно распараллеливать разработку: если бы я был мобильным разработчиком, мне бы вообще не пришлось у себя разворачивать LAMP, мне бы просто скинули URL тестового стенда, и я бы спокойно пилил клиент без необходимости правок в бэк. Какой-нибудь фронтендер в это время бы пилил свою часть, имея ровно тот же URL стенда. И никто друг с другом не пересекается (меня например на работе вообще никто в лицо не видел).
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от stillswamp (ok), 13-Дек-21, 10:00
	Мы перешли от обсуждения реализации Pusa к архитектурным вопросам. > Не увидел ответа, как к существующему сайту на фреймворке прикрутить нативное мобильное > приложение. Ответ по существу. Бэк содержит три уровня: - Логика приложения - (источник данных для API) - API - (данные) - View - (строит вывод на основе API) Кому не нужна вьюха берут данные с API. > И никто > друг с другом не пересекается (меня например на работе вообще никто > в лицо не видел). Это нормальная практика. При этом на координацию бэков и фронтов тратятся ресурсы. Чудес не видел.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
	Сообщение от stillswamp (ok), 13-Дек-21, 13:50
	> А при медленном соединении полагаю, будет что-то типа, что пользователь жмет > Copy, немедленно переключается альт-табом в ворд, вставляет -- а там старое > содержимое. Потому что ответ бэка пришел слишком поздно, в момент, когда > браузерная вкладка уже не в фокусе, так что браузер запретит записывать > в буфер. (А в некоторых браузерах в клипбоард можно записывать только > и только из event handler; ставишь setTimeout или ждешь бэка? -- > откажут в доступе к клипбоарду.) Добавлен пример Copy в буффер - https://pusa.catlair.net/?section=Examples - https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/php/pu... Благодарим за идею.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	49. "Сравнение методов исключения разработки на JavaScript для веб технологий"	+1 +/–
	Сообщение от Бывалый смузихлёб (?), 14-Мрт-22, 07:01
	Если речь не о самом примитивном конструкторе страниц из готовых блоков, то задача становится совсем непростой. И тот «один специалист-бэкендер-скалист( такие вообще в природе существуют в ощутимых количествах? )» вмиг превращается в фуллстека, притом не самого плохого с необходимостью понимания очень многих штук. Нюанс в том, что можно хоть треснуть, но стили на клиенте в итоге все равно будут в CSS ( лучше в файлах, инлайн плохо кешируется и обработка его жрет много ресурсов ) Равно как и основная «динамическая» работа будет на JS. И «не работать» с ним удастся только при применении готовых блоков( в которых уже кто-то поработал ), в иных случаях - по многим причинам придётся ещё и жс как-то заталкивать чтобы он не сломал систему. И ещё один, но фундаментальный нюанс в том, что сетевые запросы требуют времени и немалого. В этом смысле нет большой разницы, весит ли скрипт 6кб или 60 - скорее всего, само время сетевых запросов будет больше длительности скачивания. В данном же случае пользователю, чтоб увидеть первую норм страницу, потребуется ожидание нескольких запросов и отработки скриптов, сама реакция на изменения будет с лагом. Особенно это критично в случае разных анимаций и проч, завязанных на действия пользователя( где-то что-то начал вводить, где-то провёл мышкой или пальцем по тачскрину - это ж сколько запросов полетит на сервер, итд ) Хотя сама идея, в общем и целом, весьма интересна. Есть подозрение что для внутренних корпоративных систем будет очень даже годно
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема