Глобальная переменная недоступна через глобальный объект

Столкнулся с такой странной проблемой. Даже в консоли ввожу имя переменной(в моем случае pages) и получаю доступ к ней без проблем, при этом window.pages не существует.
В двух словах опишу, что я делаю, чтобы было понятно, как я дошел до жизни такой, но вообще это не так важно, поскольку вопрос интересен в принципе: как так получается и как с этим бороться.
В данный момент вкуриваю такую вот штуку Bolero: F# in WebAssembly. Если в двух словах, то там создается одностраничное приложение, где основная логика выполняется в WebAssembly, но нужно кое-где подтягивать существующий жс-код и как-то с ним взаимодействовать. Вот я, собственно, так и сделал: подтянул d3.js для визуализации данных, и немного дополнительного кода для инициализаии всего этого дела. В своем скрипте(он в отдельном файле) создал переменную pages, чтобы разделить логику отдельных страниц и уже через этот объект получаю доступ ко всему функционалу. Из кода на F# я могу вызвать жс-функцию через жуткую фиговину, но тем не менее это работает. И вот делаю я вот это вот все и получаю сообщение, что дескать pages не является членом windows, поскольку та самая "жуткая фиговина" ищет указанную функцию именно в объекте window. Ну и как уже написал ранее из консоли сам убедился что переменная доступна при прямом обращении к ней и недоступна при обращении через window.
Проблему я решил, добавив к элементу script атрибут defer, но как бы вопросы все равно остались. Интересно, что и почему происходит, как с этим бороться и все такое ))

0

Сообщение от Peskova_Sveta т.е. код из другого языка сначала компилируется на сервере, страница рендерится и уже готовая отдается в браузер?

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

0

diadiavova, тогда еще вопрос возникает, когда начали применять фреймворки, то при начальной загрузке сложных приложений пользователь видит сначала не полностью отрисованную страницу, либо прелоадер, и отрисовывается долго, особенно на слабых девайсах, или грузится долго(ибо фреймворки тоже весят а интернет слабый), и пользователь просто уходит со страницы. Теперь используют ssr, т.е. страница рендерится на сервере и отдается клиенту статическая, т.е. загружается быстро, и пока пользователь совершит какое либо первое действие, уже успевают подгрузится и фреймворки и либы и прочее. Вопрос: WebAssembly не будет ли аналогично подтормаживать своим компилятором?

0

Сообщение от Peskova_Sveta WebAssembly не будет ли аналогично подтормаживать своим компилятором?

Ну компилятор тут вообще ни при чем, поскольку обычно васм-файл в уже готовом виде лежит на сервере. Если же говорить об описанной проблеме вообще, то тут много зависит от используемого фреймворка. У того, которым пользуюсь сейчас я действительно есть проблема, что нужно ожидать подгрузки. Там в результате трудов создается SPA приложение, то есть первоначально загружается статическая хтмл-страница, за ней тянется статический же скрипт, который всем этим делом рулит и уже этот скрипт начинает подгружать, сначала .Net Runtime, потом основную библиотеку, созданную из пользовательского кода, потом все ее зависимости и прочие ресурсы. Это занимает какое-то время, хотя содержимое статической страницы отображается сразу.
Но тут есть некоторые варианты оптимизации. Если взять .Net Runtime и набор стандартных библиотек .Net Standart, то они хоть и содержат знакомый функицонал, но при этом они сильно порезаны, то есть из них удалено все, что в браузере работать не может, то что осталось оптимизировано, в том числе и по размеру. Также предусмотрены варианты сжатых версий, правда это не будет работать на статических серверах, но если сервер поддерживает сжатие, то он может напрямую брать более компактные версии этих либ. Насколько я понимаю, связано это с тем, что браузер может обрабатывать сжатые файлы, но для этого ему нужно получить соответствующие заголовки, а статический сервер не заставишь их отправлять. Есть еще нюанс: там предусмотрена возможность перенаправлять вызовы на cdn, а поскольку стандартный набор библиотек всегда один и тот же, то браузер может кешировать эти библиотеки и брать их из кеша для разных приложений.
Ну и кроме того, технология сейчас дорабатывается, так что будут еще улучшения. Например, насколько я знаю, собираются в WebAssembly реализовать встроенную поддержку сборщика мусора, это тоже плюс, поскольку дотнет-технологии нуждаются в нем, и его реализация на данный момент находится все в том же файле dotnet.wasm, если будет встроенная поддержка, то этот файл тоже станет легче.
Таким образом, ряд проблем решается, но с другой стороны надо понимать и то, что сложный функционал требует много кода, так что тот факт, что некоторые приложения, построенные на этой технологии будут достаточно тяжеловесными, вряд ли сможет ее убить.

1