?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

О JS фреймворках вообще

Posted on 2010.12.04 at 23:09

Comments:


Gaperton
gaperton at 2010-12-05 10:17 (UTC) (Link)
> 1 пункт работает только статически?

Насколько я понял - да. Там обычный статический макроинклуд, после чего Closure Compiler делает замес исходников. goog.require динамически выполнить в браузере попросту невозможно - он синхронный.

В require.js реализованы обе опции - можно собрать как статически (за сценой будет задействован тот же Closure Compiler), так и подгружать модули динамически. Код модулей при этом - одинаков.

> про порчу глобального пространства имён тоже сомневаюсь, в моём опыте...

http://requirejs.org/docs/requirements.html
Секция: Allow modules to keep a clean global namespace.

Этот аспект опять же сильно лучше сделан в require.js.

> 2 пункт работает складыванием нужных шаблонов и кода в один файл, вам разве не этого хочется?

2 пункт работает include-ом файлов шаблонов и CSS, а не складыванием чего-то куда-то. Неужели это не понятно из его описания?
скриптун с цифровых плантаций
_arty at 2010-12-05 10:24 (UTC) (Link)
компилятор на этапе разработки можно вообще не использовать, goog.require будет работать при загрузке страницы. Я глянул, что он использует document.write для вставки скриптов, что действительно не подходит для динамики, но это можно хакнуть за минуту, и будет динамично.

насколько я понял пункт про незасорение глобального объекта, единственный аргумент за то, чтобы не добавлять goog в window — одновременное подключение двух разных версий одного кода. Может, это кому-то и нужно «для больших проектов», но гугл вон вроде как справляется, а проекты у него немаленькие.

> 2 пункт работает include-ом файлов шаблонов и CSS, а не складыванием чего-то куда-то. Неужели это не понятно из его описания?

из описания «Не выносящий мозг способ группировать фрагменты HTML шаблонов+JS+CSS способом, пригодным к повторному использованию. То есть - определять свои виджеты, которые лежат в модулях. Чтоб это было почти так же легко, как выделить код в функцию.» — нет, не понятно
Gaperton
gaperton at 2010-12-06 08:18 (UTC) (Link)
> goog.require будет работать при загрузке страницы. Я глянул, что он использует document.write для вставки скриптов, что действительно не подходит для динамики, но это можно хакнуть за минуту, и будет динамично.

Он вставляет в документ тэг script.

Так как вызов goog.require синхронный, определение зависимостей при выполнении самого файла "модуля", как это делает Dojo и require.js, невозможно без блокировки браузера, что в свою очередь, не допустимо.

Как же он тогда может работать? Интересно, правда? А вот так:

"Using goog.require and goog.provide for your own JavaScript packages and modules will not automatically work. You have to use goog.addDependency, and this is best done using a provided python script which will help you create a dependency file."

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

Выглядит этот файлик вот так:
// This file was autogenerated by calcdeps.py
goog.addDependency('../utils.js', [], []);
goog.addDependency('../myapp/deps.js', [], []);
goog.addDependency('../myapp/require.js', [], ['goog.events', 'goog.dom', 'myapp subapp.controller', 'myapp subapp.view']);
goog.addDependency('../myapp/subapp/controller.js', ['myapp.subapp.controller'], []);
goog.addDependency('../myapp/subapp/model.js', ['myapp.subapp.Model'], []);
goog.addDependency('../myapp/subapp/view.js', ['myapp.subapp.view'], []);


Это говно и наколеночный костыль, а не модули. Правильно это сделано не в closure, а в require.js. Который для случая статической сборки использует ваш любимый Closure Compiler.

На этом и закончим. С меня достаточно "открытий чудных".
Previous Entry  Next Entry