Пока сумтно представляю зачем это нужно. Не могли бы Вы дать несколько конкретных юзкезов (примеров использования) для такой системы?

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

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

Ну и кроме того, хтмл уже изжил себя, он был хорош для гипертекста, а программы нужно всё-таки делать на языках программирования, а не разметки.

В чём преимущество по сравнению с Флексом? Только отсутствие зависимостей от флеша?

>интерфейсы к почте, соц сети, вообще чему угодно

Программировать отдельно на JavaScript? Подход GWT мне кажется куда как разумнее. Если посмотреть контакт, гмейл - без "хтмл"я там всё равно не обойтись (если пишете именно под хтмл). А "калькулятор" в вёбе не нужен. Кстати. Ещё про построение RichClient - во-первых стоит посмотреть Eclipse RAP, во-вторых видел фреймворк, который умеет одновременно генерить DHTML И Flash. Я пока не вижу что конкретно ваша библиотека даёт.

На мой взгляд, это очень существенное преимущество :) Хотя, с другой стороны флекс убирает проблему совместимости между броузерами. Я начал этот проект до того, как узнал о флексе (это было пару лет назад). И ещё в числе преимуществ в сравнении с флексом я бы выделил то, что мой подход "более непосредственный", откуда следует, например, меньшее потребление памяти и, возможно, большая скорость работы. Хотя, сейчас canvas очень медленный, надеюсь ситуация улучшится постепенно.

>что мой подход "более непосредственный"

эээ?

>большая скорость работы.

Оочень сомневаюсь, учитывая заточенность флекса

> Программировать отдельно на JavaScript?

да, именно так

> Если посмотреть контакт, гмейл - без "хтмл"я там всё равно не обойтись (если пишете именно под хтмл).

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

Я, к сожалению, весьма поверхностно знаком с упомянутыми технологиями, но я хочу попробовать отойти от идеи писать код на каком-то языке, а потом неким транслятором всё это превращать в неудобоваримый DHTML + JS + flash + что угодно. Javascript очень гибкий и удобный язык, но пока ему негде было проявить свою мощь.

> >что мой подход "более непосредственный"

> эээ?

имеется в виду непосредственное написание js кода и отсутсвие дополнительных прослоек в виде флэша

>Javascript очень гибкий и удобный язык

Тогда почему с него валят при разработке проектов больше "галереи фотографий"? GWT и все его последователи, Eclipse RAP, Charisma?

>в приложении для helios хтмл вообще к использованию не предполагается.

Ну я пока видел только калькулятор. Я мне бы что-то вроде GoogleReader.

>дополнительных прослоек в виде флэша

Флэш не прослойка а другая платформа.

> Тогда почему с него валят при разработке проектов больше "галереи фотографий"?

Потому что из-за отсутствия нормального апи (DOM это ненормальный апи :) ) для проектов больше галереи с фотографиями код превращается в crap (по-русски не знаю такого меткого слова). Либы гелиоса как раз и предполагается что предоставят такой апи.

> Ну я пока видел только калькулятор.

Ну я пока написал только калькулятор, уж извините :) За тем я сюда этот тред и запостил.

> >дополнительных прослоек в виде флэша

> Флэш не прослойка а другая платформа.

Тогда, может быть, в связке "приложение - флэш - броузер" лишним является броузер?

>Потому что из-за отсутствия нормального апи

А чего в jQuery не хватает?

>Тогда, может быть, в связке "приложение - флэш - броузер" лишним является броузер?

Ну почему же, он рисует привычные пользователю рамочки с кнопками "закрыть" и "свернуть" =)

> А чего в jQuery не хватает?

jQuery облегчает работу с DOM, DOM предоставляет интерфейс по манипуляции HTML, HTML определяет разметку веб-страницы. Здесь опять всё завязано на HTML и на том факте, что есть страница. Это далековато от программирования приложения.

>jQuery облегчает работу с DOM,

Ну вот не надо, jQuery действительно поднимает уровень абстракции и привносит понятия виджетов и действий с ними связанных. Можно было бы добавить к этому расстановку их тоже на jscript но даже не вижу в этом особого смысла. Вы не спрячете глубоко HT<ML - всё слишком уникально, а общее имеют только калькуляторы. ПОсмотртие на google reader, gmail. Да и не понимаю зачем его вообще прятать. Такие прятки не могут быть самоцелью.

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

В heliwidgets для разметки предоставляется апи, который, на мой взгляд гораздо удобнее для приложений. Он описан в комментах к include/heliwidgets/Geometry.js, хотя, Вы, скорее всего не будете туда заглядывать (мне бы было лень на Вашем месте :) ), ну да это и не так важно.

Почитал код калькулятора. Китайский метод программирования ужасает. Особенно при том, что вроде всё добросовестно закомментировано - то есть времени уделено не мало. Скажите действительно циклы не возможны?

Если бы не это, то смотрится ничего. Но задание таким способом лэйаута хотя в таком варианте и смотрится неплохо - не уверен что это подойдёт для действительно сложных конструкций (Протмер из Eclipse RAP : http://ondemand.yoxos.com/geteclipse/start ), тем более что лэйаут при помощи html хорошо изучен и для него уже много готовых тулзов.

> Китайский метод программирования ужасает.

что именно?

> Скажите действительно циклы не возможны?

где именно? =)

> Но задание таким способом лэйаута хотя в таком варианте и смотрится неплохо - не уверен что это подойдёт для действительно сложных конструкций

Для действительно сложных конструкций я ещё создал виджет Table, он должен дополнить объект Geometry в тех случаях, где его штатных возможностей не хватает.

> Протмер из Eclipse RAP : http://ondemand.yoxos.com/geteclipse/start

Что есть протмер? Страница подвесила бровзер на полминуты, наверное у меня машина слабовата :( Я не увидел там ничего такого, что нельзя сделать с помощью Geometry & Table, и даже ничего такого, что на хтмл делалось бы более быстро/удобно чем с помощью объектов из heliwidgets.

> лэйаут при помощи html хорошо изучен и для него уже много готовых тулзов.

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

> Скажите действительно циклы не возможны?

а, это речь о вешаньи евентов на кнопки в конструкторе калькулятора? циклом это описать не сложно:

for ( var i = 0; i <= 9; i++ ) { this["button" + i].sigPushed.listen( function(){ this.handleDigit( i ) }, this ); }

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

Вообще, весь этот калькулятор не имеет свой целью продемонстрировать, как нужно писать код. Я лишь хочу продемонстрировать апи библиотек.

tl;dr

>Ну и кроме того, хтмл уже изжил себя

Дальше можно и не читать :}

> >Ну и кроме того, хтмл уже изжил себя

> Дальше можно и не читать :}

Сразу видно, мы на лоре :(

> > Скажите действительно циклы не возможны?

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

в общем, калькулятор - это просто демка, я буду очень признателен, если мне кто-нибудь выскажет подобные комментарии по поводу кода в каталоге include/

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

А ты не Ext JS изобрёл?

А так круто мне нравится

> А ты не Ext JS изобрёл?

Ext JS тоже ведь DOM-ориентирована, насколько я знаю. мб есть аналогия в плане виджетов, я же думаю, что может получиться что-то интересное, если не заморачиваться на DOM и писать на чистом JS. Посмотрим, во что это выльется..

>сейчас я вижу что два ассоциативных массива решили бы эту проблему

Дадада, именно их я и имел ввиду =).

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

Как кстати у вас с динамическим изменением лэйаута - насколько всё просто?

> Во-вторых - тот-же файрбаг покажет мне именно ДОМ, а не ваш джаваскриптовый код, и это тоже, на мой взгляд, существенный минус.

В фаербаге вкладочка скрипт покажет js код, позволит выбрать в списке нужный модуль, расставить где нужно брейпоинты, в-общем, всё как положено. Дом он конечно тоже покажет, но он уже будет не так существенен.

> Как кстати у вас с динамическим изменением лэйаута - насколько всё просто?

Примерно как-то так:

myWidget.geometry.set({
    left : 10, top : 20, right: 30, bottom: 50
});

перерисует myWidget в новом месте и также перерисует все его дочерние виджеты, если их геометрия указана, например, в процентах. Кстати у geometry тоже есть сигнал-нотификатор, на который можно подписаться если нужно.

У виджета Table есть некоторые свои методы, упрощающие манипуляцию с ячейками таблицы. Этого нет в codecast с калькулятором, поэтому я приведу краткое описание его апи здесь. Сейчас Table представляет с собой пустой (в плане графики) виджет с некоторым дочерними виджетами, упорядоченными одномерно (то есть либо по-вертикали, либо по-горизонтали). Это определяется его свойством layout. Кстати говоря, основные свойства виджетов --- это наследники объекта js.Property, о котором я писал в первом мессадже, и поэтому если программист пишет, например, myTable.layout.set( "vertical" ), тогда по сигналу вызовется некоторый метод объекта, который обновит геометрии его ячеек, согласно новому лейауту, и так же вызовется метод, описанный уже в движке, который всё что нужно перерисует. Эти методы подписываются на сигнал в конструкторе. И, конечно, программист может повесить на этот сигнал какие-то свои действия.

Table предоставляет необходимые методы для манипуляций с ячейками (addCell, resizeCell, removeCell, switchCells, moveCell). Размер каждой ячейки м.б. задан либо абсолютно (в пикселах), либо относительно (в процентах), в этом случае такие "резиновые" ячейки таблицы растягиваются пропорционально указанному их значению в процентах так, чтобы заполнить всю ширину (высоту) таблицы.

Виджет Table задумывался как раз для того, чтобы можно было создавать лейауты, подобные тому, на который Вы сослались (из Eclipse RAP). Пользуясь только лишь свойством geometry было бы действительно сложновато создавать сложные лейауты.

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

> Вот если бы вы такое на Jetbrains MPS замутили - да, было бы очень даже не плохо. 

К сожалению, не знаком с Jetbrains MPS и не владею джавой. Про динамику и выразительность языка --- это вопрос скорее философский, и наверное можно бесконечно его обсуждать. Я снова приведу в качестве примера объект js.Property, поскольку, как мне кажется, он очень хорошо демонстрирует динамику и выразительность языка: реализация подобной функциональности на том же C++ требует в разы больше кода. И, поэтому, да: если говорить о JS, то, на мой взгляд, выразительность этого языка как раз и заключается в его динамике.

> Я снова приведу в качестве примера объект js.Property

прошу прощения, имеется в виду js.Signal, конечно же. Речь идёт о возможности посылать сигнал так, чтоб подписавшееся на него функции получали произвольное число аргументов

>Сразу видно, мы на лоре :(

Просто это слишком категоричное утверждение. А альтернатива HTML'у только поделки вроде флеша и явы. Нет уж, уж лучше пусть HTML, а ява может и десктопным приложением быть сама по себе, если очень хочет.

Пригляделя к лэйауту калькулятор. Да он у вас ручной о_О Скажите, а нельзя что бы было просто - сказал GridLayout 8х5 а потом навставлял в цикле кнопок - и они бы правильно расставились?

>прошу прощения, имеется в виду js.Signal, конечно же. Речь идёт о возможности посылать сигнал так

Так вы и не выражаете такую конструкцию. Всё на что способен язык "сделать так, чтоб работало". Рефакторинг, валидация, комплишн идут найух. А всё это очень нужно, особенно для тех, кто не автор этого фреймворка. Вот в MPS это всё делается тривиально, с поддержкой всего того что я описал. Очень советую приглядеться - к реализации этого на MPS я бы присоединился.

> А альтернатива HTML'у только поделки вроде флеша и явы.

Нунуну. Зря не порчитали - автор не предлагает откзаться от HTML. Он предлагает построить более удобное АПИ надо DOMом и минимизировать код разметки на HTML за счёт генерации его в рантайме джаваскриптом.

Так от этого HTML никуда не исчезает. А автор пишет «хтмл уже изжил себя». Что есть ложь выходит, ибо он полагается на него.

К тому же, интерфейс, который не работает без JS это фейл.

>А автор пишет «хтмл уже изжил себя». Что есть ложь выходит, ибо он полагается на него.

Ну это конечно не очень корректно, но схоже фразе "ассемблер изжил себя" - вобщем то без него никуда - любой компилятор транслирует программу в асм, но на асме писать хреново. Скорее всего имеется ввиду использование HTML непосредственно для вёрстки интерфейса вёб-приложения.

> тому же, интерфейс, который не работает без JS это фейл.

И у скольки реально отключен JScript? (кроме красноглазых с лора). Да, у те кто ставят NoScript могут его включать на этом сайте. И да, можно проовать генрировать JScript на "сервере" и отдавать статику (урезанную).

>Ну это конечно не очень корректно, но схоже фразе "ассемблер изжил себя" - вобщем то без него никуда - любой компилятор транслирует программу в асм, но на асме писать хреново.

Но ты то на асме не пишешь при этом (если только очень не надо), а автор прямо использует HTML.

>И у скольки реально отключен JScript? (кроме красноглазых с лора). Да, у те кто ставят NoScript могут его включать на этом сайте. И да, можно проовать генрировать JScript на "сервере" и отдавать статику (урезанную).

Юзабилити это такая штука, я тебе скажу…

А потом говорят, мол, это у тебя во вкладках сайт с тяжёлым js, а не Firefox тормозит…

> Пригляделя к лэйауту калькулятор. Да он у вас ручной о_О Скажите, а нельзя что бы было просто - сказал GridLayout 8х5 а потом навставлял в цикле кнопок - и они бы правильно расставились?

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

> Так вы и не выражаете такую конструкцию.

Более конкретно, я имел в виду возможность послать сигнал так:

mySignal.send( arg1, arg2, arg3, whatever );

и получить все эти аргументы на входе подписавшихся функций.

> Рефакторинг, валидация, комплишн идут найух. А всё это очень нужно, особенно для тех, кто не автор этого фреймворка.

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

Про валидацию --- в ядре гелиоса я сделал небольшой лог, куда отправляются сообщения об отсутствующих модулях, о циклических зависимостях и прочем. Этот лог можно потом прочитать, кажется, через heliosKernel.errorLog, хотя могу ошибаться. Это описано в туториале на сайте проекта. У меня была мысль приспособить этот лог каким-то образом и к поимке исключений в коде. Например, сейчас если подписать на сигнал несуществующую функцию, тогда, при попытке послать сигнал, в лог JS ошибок броузера вывалится какое-то сообщение из серии signal.listeners[ 0 ][ i ] is undefined, это действительно очень усложняет отладку. Пока такая валидация (если я правильно понял, что Вы подразумеваете под валидацией) не реализована, и основная здесь причина даже не в том, что я не успел ещё это сделать, а в том, что при разработке мне пришлось столкнуться с некоторыми вещами, в которых я, увы, слабо разбираюсь. Иногда для обеспечения некоторой функциональности мне приходится полагаться на интуицию, а через некоторое время я обнаруживаю, что этот вопрос уже давно решён, а моя реализация примитивна и вообще некорректна. Это относится к валидации, и, вероятно, к рефакторингу.

Комплишн --- это тот вопрос, который должен решаться редактором кода?

Про MPS почитал на сайте, с их концепцией Language-oriented programming я и вовсе не знаком, поэтому пока ничем подобным заниматься не планирую. Но Вы можете портировать туда код, исходники ведь открыты ;)

Ещё хотел бы в очередной раз пару слов сказать о тёрке вокруг ХТМЛ. Мне довольно часто приходится идти на компромиссы между функциональностью/скоростью, функциональностью/портируемостью и функциональностью/ясностью апи. Сейчас helios представляет собой то, что показано на демке с калькулятором. Вопрос о поддержке того же самого, но с отключенным JS как минимум не корректен. Роль HTML & DOM в helios (точнее, в реализации движка для heliwidgets) была зафиксирована довольно давно. Ничто не мешает сделать движок для heliwidgets, который будет рендерить виджеты, скажем, в какой-нибудь апплет с флешом, сообщаясь по LocalConnection. Я выбрал один способ, который наиболее удобен или интересен лично мне, и сейчас развиваю его. Гелиос просто предоставляет возможность логически связать модули друг с другом, разделить код на части. Тулкит heliwidgets определяет только лишь логику виджетов и их апи. Остальное --- задача движка, который отслеживает, что происходит с виджетом как объектом в JS и применяет соответствующие изменения на экране.

> а автор прямо использует HTML.

неправда :) я использую домовский апи, он из JS юзабельнее:

var newLayer = document.createElement( "div" );
newLayer.style.bla = "bla";
newLayer.style.bla2 = "bla2";
...
someExistingLayer.appendChild( newLayer );

хотя сути это, конечно, не меняет =)

>я использую домовский апи

А он, по вашему, что ли через астрал работает? Это и есть прямое использование HTML'а — создание его элементов :) Вот если бы создавалось что-то другое…

Я не document.write() имею в виду, естественно.

> Вот если бы создавалось что-то другое…

Что другое? у Вас есть идеи? Я уже упоминал в постах выше, что у меня была мысль сделать один огромный канвас и рисовать на нём без хтмл. Я даже написал небольшую либу, которая добавляет в канвас поддержку слоёв и ловет мышиные евенты, определяя слой. В принципе, думаю, за пару вечеров можно переписать движок под него. Но, видимо, сейчас хтмл гораздо лучше в броузерах оптимизирован, чем canvas. Только по этой причине дефолтный и единственный движок для heliwidgets использует хтмл. а вообще он здесь не принципиален, никаких хтмльных фич (типа табличного лейаута) не используется. Я даже может быть кого-нибудь удивлю, но вся произвольно задаваемая геометрия для виджетов считается и конвертится в абсолютные координаты "top-left-width-height" внутри JS кода, такая нотация гарантированно однозначно воспринимается самыми копризными эксплорерами.

>Не могли бы вы пояснить, каким именно образом фреймворк препятствует всему этому?

Этому припятсвует язык и способ его использования. Логи - это хорошо. Но с учётом того, что нормально простро AST невозможно, то всё то что я написал - то же невозможно, за исключением нескольких тривиальных случаев. Подскажите хоть один редактор, который позволяет всё это с вашей библиотекой.

>Но Вы можете портировать туда код, исходники ведь открыты ;)

Это бессмысленно. Работа в LOP очень сильно меняет сам процесс разработки и то что получается.

>mySignal.send( arg1, arg2, arg3, whatever );

Ещё раз, вы делаете "так чтоб работало", а не так, что бы компилятор понял что вы написали. Он этого не понимает.

>Калькулятор --- это редкий пример, когда виджеты можно расставить в цикле.

Дело не "в цикле" а вообще в нормальных лэйаутах. Именно человеческих лэйаутов и хочется - вы же планирует писать "вёб-_приложения_".

> Вот если бы создавалось что-то другое…

Лично я бы был очень доволен прикрученным плагином к бразеру Qt с Declarative UI. Мне кажется это было бы очень круто.

Внезапно

>Что другое? у Вас есть идеи?

Я быть может кого-то удивлю, но фразу «хтмл уже изжил себя» сказали здесь вы.

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

Выделение текста не будет работать? Такое в вебе не нужно́.

>а вообще он здесь не принципиален, никаких хтмльных фич

DIV и style это тоже не из астрала.

> Лично я бы был очень доволен прикрученным плагином к бразеру Qt с Declarative UI. Мне кажется это было бы очень круто.

Если я правильно понимаю, Вы имеете в виду делегировать рисование виджетов броузеру? У меня была такая мысль, это кстати легко делается. Броузер просто должен предоставть свой движок (как джаваскриптовый объект с необходимым интерфейсом), а программист --- разрешить его использовать, в случае если таковой есть. Тогда можно рендерить виджеты на чём угодно, хоть на gtk/qt.

theos, я вижу что Вы знакомы с некоторыми интересными концепциями, с которыми не знаком я, и поэтому я иногда не понимаю, что Вы имеете в виду. Моя позиция заключается в том, что есть фреймворк с либами на js для броузера, Вы имели возможность с ним ознакомится. Понятно, что и броузер, и язык накладывают всевозможные ограничения, но давайте всё-таки будем исходить из того, что имеем. Конструкции языка добавлять на лету, увы, не получится. Это наверное минус и всё же. Я попытался сделать максимально удобный/функциональный апи, при этом я исходил из своих субъективных соображений. Наверняка я что-то упустил. Если у Вас есть идеи, относительно того, как можно улучшить или сделать более удобным этот фреймворк, я буду очень благодарен, если Вы эти идеи выскажете. Я имею в виду, конечное, идеи помимо смены платформы =)

Ну вот собственно тогда z бы хотел что бы вы посмотрели QML - http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/

Было бы здорово натыреть оттуда разных фич, потому как у вас есть с ним схожесть - только он работает на базе Qt, а вы - на базе браузера. ПО крайней мере мне там вкусно следующие:

1)Лэйауты 2)MVC, где модель может быть как кастомная, так и (вот это меня очень пропёрло) создаваемая из XPath запросов на XMLном источнике. 3)State Machine + custom transform - автоматы очень удобны для программирвания UI

Ну вот собственно тогда z бы хотел что бы вы посмотрели QML - http://labs.trolltech.com/blogs/2009/05/13/qt-declarative-ui/

Было бы здорово натыреть оттуда разных фич, потому как у вас есть с ним схожесть - только он работает на базе Qt, а вы - на базе браузера. ПО крайней мере мне там вкусно следующие:

1)Лэйауты
2)MVC, где модель может быть как кастомная, так и (вот это меня очень пропёрло) создаваемая из XPath запросов на XMLном источнике.
3)State Machine + custom transform - автоматы очень удобны для программирвания UI

> include( "combintation.js" );

Для подключения модулей в js есть своя спецификация: https://wiki.mozilla.org/ServerJS/Modules/SecurableModules . Во всяком случае, ряд js-фреймворков (http://code.google.com/p/v8cgi/ , например) ее придерживаются.

> Ну вот собственно тогда z бы хотел что бы вы посмотрели QML

спс, посмотрел видео, в ближайшее время постараюсь почитать про эти технологии. предварительно, я думаю, что если эта функциональность может быть реализована поверх Geometry (точно так же как Table поверх него реализована), тогда я покамест на это забью и м.б. займусь позже. сейчас для меня главное определить актуальность проекта и если она достаточная, тогда привлечь ещё народ. с актуальностью самое сложное: я девелопил гелиос практически один, и среди моих знакомых прогеров толково разбирающихся в вопросе нет. я ещё иногда получал комментарии из серии "О! офигительно! мега круто!", от такого фидбэка, понятное дело, тоже никакого толку нет :) а моё личное мнение слишком уж субъективно.

думаю сегодня-завтра запостю новость о проекте.

>> include( "combintation.js" );

> Для подключения модулей в js есть своя спецификация

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

> var inc = require('increment').increment;

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

А на хабре запостить не хочешь? Там аудитория немаленькая, вёб-девелоперов много.

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