это примитивные минификаторы не изменяют. Angular использует Google Closure Compiler, у которого есть режим aggressive, и в нём «private» свойства объектов очень даже изменяются, если только явно не отметить их неизменными. Посмотрите на код gmail, например.

Fesor 5 янв 2014 в 18:01

эти проперти специально делают доступными из вне с пометкой что это внутренние состояние. closure compiller смотрит только на аннотацию private, которой там нет.

arty 5 янв 2014 в 18:21

вот это уже более достойный ответ. Первый-то был откровенной неправдой. А если бы вы ещё сразу мне сказали, использует ли angular ADVANCED_OPTIMIZATIONS вообще, и отмечает ли хоть какие-то свойства как private, было бы совсем хорошо

Fesor 5 янв 2014 в 18:59

приватных я в исходниках не встречал если честно. но билдится он с SIMPLE_OPTIMIZATIONS.

Fesor 5 янв 2014 в 17:56

Перевод на троечку. Особенно умиляет «одним из лучших шаблонов для front end разработки». Вообще ваш перевод довольно тяжело читать.

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

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

Пока видел только ленивую подрузку модулей с целью сложить в модули переводы текстов/шаблоны

AndyGrom 5 янв 2014 в 17:56

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

Tulov_Alex 5 янв 2014 в 20:06

Круговорот кода в природе. Теперь ваша очередь вновь улучшить улучшенную реализацию в вновь запостить на хабре. :)

demiazz 5 янв 2014 в 20:31

Меня всегда волновал вопрос, зачем люди используют ленивую загрузку по сети. Ну, вот например, многие обосновывали мне использование require.js или AMD.js — мол модули, мы без них жить не можем, а тут они есть и это круто. Ок.

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

В каких особенных ситуациях нужны вот такие костыли (вероятно они есть, но лично я их никогда не встречал, ну разве что чистейший SPA, и то это довольно редко обоснованный случай)?

Fesor 5 янв 2014 в 20:51

если у вас приложение сильно модульное и один из модулей может спокойно работать без учета остальных — то это полезно. Но в случае с приложениями на angular.js я слабо представляю себе такой кейс.

demiazz 5 янв 2014 в 20:55

А что мешает разбивать приложение на модули (даже если они не связаны), загружать клиенту один раз большим (или несколькими поменьше — там в зависимости от) файлом, и кешировать это у него же (я имею ввиду инструменты подобные assets pipeline из Rails)? Тем более, так будет даже быстрее, чем за каждым мелким файлом обращаться к серверу, тратить время на коннект, ждать загрузки, и только потом получать полезный профит от непосредственно кода?

Есть еще какие-то причины такой вот ленивой загрузки?

Fesor 5 янв 2014 в 21:16

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