Helios Javascript framework

простое движение над кнопками дает CPU 100%.

>простое движение над кнопками дает CPU 100%.

движение курсора мыши я имел ввиду

>> простое движение над кнопками дает CPU 100%. > движение курсора мыши я имел ввиду

Попробуйте запустить под гуглохромом, там супербыстрая обработка JS.

Интересно, на сколько изменится результат? (мне лениво, да и тут интереснее со 100% на сколько именно на Вашем компьютере что изменится)

Надо было еще добавить тег "трафик". :(

Есть ХОТЬ ОДИН проект, использующий этот фреймворк не как демо, а как основное средство автоматизации?

Пример сосёт. Калькулятор не понимает ввод с клавиатуры. В приличных фреймворках даже просмотр фоток понимает клавиатуру, а уж в калькулятор точно никто мышкой тыкать не будет. Это намекает нам на то, что авторы немного оторваны от реальности. Пример с «изменением всего лишь одного параметра» загружался столько же, сколько загруженный в соседней вкладке первый пример. Хотя, казалось бы, библиотеки-то все те же.

Авторам читать хотя бы Чикуёнка.

>А ваше уёб приложение так умеет? Боюсь калькулятор - потолок :]

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

переполнение не обрабатывается, фигня

Хмы, так солидно грузилось. Я думал будет что-то более эпическое чем калькулятор )))

> простое движение над кнопками дает CPU 100%.

в каком браузере? в firefox 3.0.13 не наблюдается

> Фреймворк и код приложения один раз скачиваются и потом всегда берутся из кеша браузера.

Странно, у меня заново все скачивалось, перед этим по ссылке http://absens.org/helios/helioscalc/ смотрел.

>Свободной, открытой X11 под Windows пока нет. Вы же не думаете, что бизнес выбросит 95% пользовательской базы.

а это тогда что? http://sourceforge.net/projects/xming/

/me посмотрел и решил писать свой велосипед дальше

Аналогично.

В линаксовой опере 10 beta 1 тоже 100% тормоза при движении мышкой над кнопками.

Постараюсь кратко ответить на некоторые посты:

> Классический пример проекта, который должен использовать AGPL

afaik GPL3 позволяет перелецензировать в AGPL, хотя я особо с лицензиями не разбирался

> Почему svn пустой?

Профиксил, хотя пока я один девелоплю, это мне было не особо нужно. Для экспериментов использовал бэкап в качестве бранча :)

> Ну так а чем он лучше/перспективнее существующих всяких YUI например?

Это активно обсуждалось по ссылке.

> простое движение над кнопками дает CPU 100%.

> В линаксовой опере 10 beta 1 тоже 100% тормоза при движении мышкой над кнопками.

Плавное изменение прозрачности слоя, содержащего подсвеченный вариант кнопки. С одной стороны, хотелось сделать красиво, с другой - из за этого появляются тормоза. В качестве критерия я тестирую (и, собсно, девелоплю) на третьем пне 660мгц 128мб озу. По этому критерию я уже отказался, например, от плавного изменения состояния кнопок (enabled-disabled) при изменении основания системы исчисления. Хотя, я так думаю, что в дальнейшем уберу избыточную гламурщину, юзабельность важнее. Сейчас основные тормоза наблюдаются при взаимодействии с canvas, в опере оно вообще дико медленно работает. Надеюсь, что допилят разработчики броузеров производительность. Ну и я со своей стороны постараюсь сделать код порезвее.

> Калькулятор не понимает ввод с клавиатуры

Отслеживание событий клавы пока не реализовано, как и взаимодействие с сервером, всё это в планах. Меня на всё не хватает, потому я и повесил объявление сюда.

> Пример с «изменением всего лишь одного параметра» загружался столько же, сколько загруженный в соседней вкладке первый пример. Хотя, казалось бы, библиотеки-то все те же.

> Странно, у меня заново все скачивалось, перед этим по ссылке http://absens.org/helios/helioscalc/ смотрел.

Это в идеале всё берётся из кэша. В примерах я просто раскопировал фреймворк и библиотеки сначала на absens.org, потом на gna.org (когда разобрался :) ). Соответственно, тёмная и светлая версии калькулятора содержат каждая свою копию фреймворка и либов. Броузер думает, что это разные скрипты и не берёт их из кэша. Если хотите сравнить разницу в скорости - попробуйте просто обновить приложение. Модули будут взяты из кэша и только проинициализированы. На моём коннекте этот этап занимает чуть больше времени, чем загрузка, так что выигрыша здесь особо нет.

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

>а это тогда что? http://sourceforge.net/projects/xming/

Переползать из-за этого с w2k на wxp? =)

>>Свободной, открытой X11 под Windows пока нет. Вы же не думаете, что бизнес выбросит 95% пользовательской базы.

>а это тогда что? http://sourceforge.net/projects/xming/

Спасибо maloi и vasily_pupkin.

Обязательно посмотрю, как оно работает.

обсудили уже в девелопменте, плюсов перед GWT не нашли))

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

>>поддерживать один сервер проще, чем 100000 десктопов
>Ваше утверждение мне не понятно
Что в моём утверждении вам непонятно?

javascript не нужен

> > > поддерживать один сервер проще, чем 100000 десктопов

> > Ваше утверждение мне не понятно

> Что в моём утверждении вам непонятно?

Это, мягко говоря, неверное утверждение. Броузеров - не один десяток, а считая кучу наставленных плагинов и включенных/отключенных опций - даже не одна сотня. Разработка по-настоящему кроссброузерного решения - очень затратное мероприятие и для создания "тяжелых" клиентских веб-приложений больше подходит не броузер + javascript + HTML + CSS, а Java / C# / или QT с биндингами.

Не оправдывайся.

У тебя какой жаббер?

>Разработка по-настоящему кроссброузерного решения - очень затратное мероприятие и для создания "тяжелых" клиентских веб-приложений больше подходит не броузер + javascript + HTML + CSS, а Java / C# / или QT с биндингами.
Это, мягко говоря, неверное утверждение.
Поддержка приложения в разнных городах и странах, обойдётся в десятки раз дороже, чем поддержка сервера.
Кроме того. Ограничения накладываетмые на UI браузаром, позволяют не обращать внимания на свистелки а заняться бизнаслогикоий, что сноваю удешевляет сапорт.

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

> У тебя какой жаббер?

xpostman at jabber dot ru

Я пишу WebUI на ExtJS. Сейчас у меня стоит задача визуализации деревьев, притом, со всяким драг-н-дрпопом узлов. Возможно ли решить эту задачу с помощью данного фреймворка?

> Я пишу WebUI на ExtJS. Сейчас у меня стоит задача визуализации деревьев, притом, со всяким драг-н-дрпопом узлов. Возможно ли решить эту задачу с помощью данного фреймворка?

Я думаю, что нет. То, что я сечас выложил - ещё даже не альфа, а скорее некоторый набор идей.

>Странно, у меня заново все скачивалось, перед этим по ссылке http://absens.org/helios/helioscalc/ смотрел.

Это типа инициализация наверное.

Аффтару - вывод на экран реальных данных про инициализацию может и выглядит кому-то нужным - но по факту ее сильно тормозит.

> Аффтару - вывод на экран реальных данных про инициализацию может и выглядит кому-то нужным - но по факту ее сильно тормозит.

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

> А на google-docs и gmail нечего смотреть.. у них на java script/html только морда.. остальное, афаик на python.

На Java. На Python Гугл ничего серьёзного не пишет.

Прикольный баг: нажать на кнопку калькулятора, после чего отвести курсор в сторону, не отпуская нажатую кнопку. Результат - кнопка залипает. Ладно бы одна, так все залепить можно...

>> И на ноль делить не может.

очень важное замечание

>Броузер думает, что это разные скрипты и не берёт их из кэша.

И какое же решение? Загружать файлы с GNA? А если модифицировал?

>> Броузер думает, что это разные скрипты и не берёт их из кэша.

> И какое же решение? Загружать файлы с GNA? А если модифицировал?

Решений уйма, начиная с того, чтобы хранить все файлы одного приложения (с одного веб-сервера) в одном месте. В примере с калькулятором таким местом мог быть родительский по отношению helioscalc и helioscalc_dark каталог. И заканчивая хранением файлов определённой версии фреймворка на каком-нибудь публичном сервере.

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

во-первых, экономится трафик (поскольку приложение и библиотеки загружаются единожды по крайней мере за сессию);

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

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

В общем, это обычные давно разрекламированные ajax-фичи, которые не получили пока широкого хода, на мой взгляд, как раз потому, что DOM суть объектная модель _документа_, а HTML суть язык разметки _гипертекста_. Здесь же упор делается на приложения, а не на документ и текст.

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