JavaScript в HTML в качестве аналога Include в PHP

и в чём там плюсы, честно не понял

с сервера именно по контенту для всей работы со списком товара один раз грузится JSON на 2.3 Кб + изображения, всё статика.

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

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

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

из 830+ Кб более 650+ Кб занимают картинки где и какую Вы там увидели "библиотеку на 1мегабайт"?

бутстрап 18+ Кб да ангуляр 139+ Кб, остальное на байты счёт идёт + большая пачка изображений от которых никуда не деться при любых концепциях и раскладах.

ангуляр на 139 Кб пугает? так это полный исходник - откомпилированный он весит 70+ для dev, в prod ещё меньше (от хотелок зависит), под гзипом сами догадаетесь сколько это будет.

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

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

ЗЫ: как оказалось даже такие примитивные примеры надо самому собирать, руками, что бы понять все детали. а тут "большое приложение" просили для диагноза :) но народ умный "глядя на каплю догадается о существовании океанов"...

[ATTACH]127537[/ATTACH]

и в чём принципиальное отличие от использования jquery?

всё то же самое делается достаточно элементарно

только вот возникает вопрос, что делать если товаров 10000 то же JSON грузить за один раз, а если их 100000 наименований? :)

для элементарного примера - элементарно, есстествнно.

попробуйте, я сам через это проходил: простыня на десяток другой функций "всего лишь" ерунда ;)

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

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

а потом умножьте все эти траблы на пару порядков для реального проекта и ещё на порядок при командной работе.

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

ангуляр не просто так 70+ Кб весит, есть средствА и хитрого построения приложения и использования всяких разных HTML Storage. а главное модели данных привязаны к HTML, обработка автоматом идёт "в" а не "вне" документа как это происходит при использовании DOM-дрочеров (намёк на огромный плюс того, что вам так не понравилось с первого взгляда) получается эмуляция "динамического HTML" на высоком уровне. это принципиально, но такой подход надо пробовать, объяснять "на пальцах" долго и почти бесполезно.

ЗЫ: кодера, который так организовал структуру данных, что для генерации страницы (в которой без пагинации может быть max 3.000 моделей - больше не осилит даже мозг привыкщего к беспределу своих вебмастеров китайца) каждый раз перелопачивается вся куча из 100.000 надо гнать в шею. любой реальный список моделей легко можно разбить на категории весом не более 3.000 элементов (что бы какой-н экстримал смог отключить пагинацию и высветить всю простыню целиком при желании), ну а уникальные задачи типа полнотекстового поиска по всему списку можно оставить и на стороне сервера - не критично, да и то же решаемо...

для того, чтобы этого кода было по объему сопоставимо с JS сколько страниц надо просмотреть?

Если основной трафик - картинки, не получается экономии на спичках?

Если считать что это витрина среднестатистического интернет-магазина, каков размер экономии?

Даже если все это сжать, то насколько шустро все это будет работать на среднестатистическом мобильнике?

Наконец то вы подошли к вопросу цены.

1. З/п серверного программиста никто не отменял. А вот программиста который работает на фронте в 1.5-2 раза выше зарплаты обычного верстальщика. Поэтому цена проекта будет выше. Точно так же будет выше цена сопровождения.

2. очень здорово шаблонить все на фронте. Но если думать о SEO нужно делать дубликаты страниц поиска для ботов. В результате получаем двойную работу и это тоже увеличивает стоимость разработки и стоимость сопрвождения. Причем заметно.

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

Я об этом уже говорил - сложно придумать проект, на котором все это оправдано. В любом случае это не контент-проект, а какой-то сервис, с большой и постоянной аудиторией. Или что-то уникальное, типа слежения за биржей, тотализатором, онлайн-игрой, CRM, SmartTV, CMS в бэкофисе

что мешает просмотреть исходники примера? ;)

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

а разве кто то сказал, что пример это мобильное приложение? не считаете, что view для мобильного трафика должна быть отличной от десктопного? хотя и так ежу понятно, что в выигрыше по объёму трафика точно можно не сомневаться, хотя бы на "пару спичек" :)

для ангуляра здесь всё не так просто, скрипты капитально сокращаются за счёт работы с HTML dependency injection. получается так на так - сокращается и капитально упрощается код MVC конструкций за счёт внедрения иньекций в HTML шаблоны. зато с системщика снимается вся возня работы с верстальщиком, который кроме HTML знать ничего не хочет. там где работало всегда 2 человека, нечувствительно справиться один, хоть и более дорогой из них.

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

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

вообщем всё как всегда - универсальной магии пока не придумали.

а вот себистоимость сопровождения, сроки тестирования и внедрения дополнений по крайней мере не изменяться, в большинстве случаев сильно уменьшаться: самая зубодробительная и объёмная часть разработки и тестов - отладка интерактива, и она на одной стороне и в одних руках. уже в пакете есть и модульные и e2e тесты, MVC код более чем адекватный и всё на виду в HTML так что выигрыш в упрощении поддержки проекта огромный...

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

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

Ну и неспроста, как только заходит речь об оптимизации, кому-то вспоминается AJAX, хотя зачем тут асинхронность и xml? Достаточно JS или чего-то ещё... из возможностей браузера.

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

нашили к чему цепляться, чес слово: как раз таки ангуляр декларирует в продакшн использовать и гугловский JS компилятор и LESS в обязательном порядке - всё по PageSpeed. не стоит гуглу его же "истины" вещать ;) ...

Просто никакими прилинкованными скриптами/стилями и пр. нельзя сократить время первой загрузки. Его так можно только увеличивать... ну вот HTTP такой.

И ещё могу придираться к тому, что часто ползатель не может начать читать, пока догружаются мегаскрипты.

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