Надо отметить что иметь отдельное RenderingTree совсем не обязательно.
В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.
Когда кто-то реально упирается в его производительность то пишут native extension. NumPy как пример.
То же происходит и в JS когда он работает в среде node.js. В обоих случаях есть относительно простой механизм встраивания native code.
Собственно я про это и говорю. Ну не надо писать ray tracers в JS. Гораздо продуктивнее было бы иметь возможность встраивания чего-то что лучше ложится на регистры и архитектуру CPU.
В JS скорость парсинга одинаково важна как и скорость исполнения. Скорость eval() опять же. Т.е. баланс — должной оптимизации и скорости сборки того же C или C++ не добиться — дорого во всех смыслах.
По идее JS в UI это клей связывающий выход одной native функции со входом другой. Т.е. в принципе JS это язык описания event routing / dispatching. Смысла JITить какой-нибудь click event handler немного если он срабатывает ровно один раз за время жизни страницы. А вот парсить их надо быстро.
Понятно что в условиях browser sandbox JS это единственная опция написать какой-нибудь ray tracer. Но вот эта единственность и есть основная проблема.
Представляется что гораздо эффективнее было бы иметь тот же embedded С например или вообще абстрактную bytecode VM типа JavaVM которую можно кормить compiled bytecodes + удобный interop из JS с этим хозяйством.
Т.е. путь того же Python — простой bytecode interpreter + удобная возможность встраивания native (или тех же bytecodes близких к native) для функций которым нужен CPU на 100%.
Как-то такое решение представляется более грамотным с инженерной точки зрения.
А так… создавать чисто интерпретирумый язык по своей изначальной природе, а потом героически преодолевать его интерпретирумость…
А какой смысл в таких глубоких оптимизациях в JS? Ну понятно что какие-нибудь базовые и дешевые jump-to-jump или peephole делать можно и должно, но трансляция JS в native code представляется overkill. Вычиcлительная модель и типы данных как-то совсем далеки от модели и типов native code.
Не знаю как кому, но мне вот представляется что гораздо продуктивнее было бы иметь возможность сделать что-то типа inline C или Dart islands в JS:
"C" int ray_tracer(int a) {
... C code, compiled into native assembly ...
}
// normal JS
var r = ray_tracer(42);
Как-то представляется что это позволит получить более предсказуемые результаты. И уж точно исполняться будет эффективнее.
Да и сократить размер всего этого хозяйства опять же. А то вот получается что весь мой Sciter который есть фактически встраиваемый browser включающий JS superset по размеру меньше чем одна V8.dll ( sciter32.dll — 3.7mb, V8.dll — 4.7mb ).
<ol each="item in items|filter">
<li class="{{done:item.done}}"><input|checkbox(item.done)/> {{item.subject}}</li>
</ol>
Это live data binding в стиле AngularJS.
Но всякий автоматический binding имеет свою цену: далеко не всё укладывается в простой attribute-property binding, хорошо если 90% процентов того что нужно можно забиндить декларативно. Зато имплементауия остальных 10% как раз и занимает 90% отведенного времени. Так на так и приходится.
Как то вот ни разу не пришлось увидеть задачу в которой автоматический биндинг помог хотя бы в два раза увеличить скорость разработки финального продукта.
Написать это вот явным образом
prop1: this.attributes["prop1"],
иногда в разы полезнее чем потом рабираться «где оно тормозит?».
А в Sciter содержимое видно в DOM inspector. Если учесть что перезагрузка UI (если нужно показать изменения) это просто F5
то разницы между design time и run time я не вижу. На поддержку design-time тратится достаточно много ресурсов. В production этот весь код поддержки design-time редактирования не нужен, но он там есть зачем-то.
Как-то мало кто обращает внимание на то что мы тихой сапой (кто такая эта «сапа» я не знаю ) все вместе перебрались в эру AppStores.
AppStore это a) one click installation of native app и b) well known place to get it.
Т.е. если раньше говорилось что мы делаем web app потому как не требует инсталляци, то сейчас дело доходит до совсем странного: на одном из проектов начальство попросило обернуть web app в PhoneGap (т.е. сделать из него как бы native) чтобы его можно было выложить в AppStore.
При этом куча времени убилась на то чтобы обойти ограничения web app и его sandbox модель.
Вопрос про то что есть MVC сугубо религиозный. Model в смысле UI это несколько иное чем data layer data model.
Я считаю что loosely coupled UI и business logic есть хорошо. У каждого layer своя собственная data model.
И общение между ними ограничено фактически get/set запросами.
Во всяком случае код приложения (его core logic) не должен быть приколочен гвоздями к UI.
class MyUserControl : Behavior {
function attached() {
this.html = "<input.name/><button.add-name/>";
}
function onMouse(evt) {...}
function onKey(evt) {...}
}
Я не понимаю смысла фразы «Очень не нативно» в контексте .NET и WPF.
В sciter есть samples/+plus/ модуль. Это duplex data binding в стиле AngularJS и прочих MVC. С templates, repeatable и прочими фишками. Основан на Object.observer(function).
script в иделогии sciter это такой-же способ описания стиля как и CSS. script описывает behavioral style, а CSS rendering style. В это этом случае язык самого приложения выполняет то для чего он предназначен лучше всего — [business] локику приложения.
Да я как бы ни слова про язык code-behind-ui не сказал. Это может быть всё что угодно. В случае Sciter это tiscript, С++, D, Go, Delphi и все языки .NET.
До мощности CSS XAMLу далеко. А markup он должен быть больше semantic. XAML попытался в одном флаконе объединить и то и то, но в результате толком ничего не получилось. ИМХО, ИМХО и еще ра ИМХО.
«Начиная с 2013 года по текущий момент пользователями Linux Mint пожертвовано более $230k.»
$230k это зарплата двух разработчиков на один год. Это без операционных расходов, лоеров, налогов и всего прочего.
Это ничто для проекта уровня Mint. Либо им кто-то подкидывает денег (и что-то за это хочет и получает) либо они живут в долг и ждут что их кто-то купит.
C Rust, и с языками прогрммирования в частности, ситуация совсем иная. Там Open Source это фактически единственная модель в которой что-то еще возможно сделать в наше время.
И кстати Rust как это ни странно есть способ борьбы с OpenSource. Вернее с последствиями OpenSource модели разработки Mozilla «когда любой залетевший дятел с горяшими глазами и патчами рушит цивилизацию» Мерфи. Сложная и не всегда понятная политика владения объектами в таком сложном проекте привела к куче проболем с memory management у них.
Отсюда и растут ноги именно такой архитектуры Rust, который собственно и есть язык на котором он собираются переписывать движок.
Решение спорное в смысле экономической целесообразности. Не ну если конечно Rust делать коммунистически-бесплатным образом — всем миром, всем народом. Да и то… без жесткой модерации нифига не выйдет.
Plug-ins это совершенно иная тема. И ортогональная открытости и закрытости базового продукта. У Visual Studio плагинов всяко больше visualstudiogallery.msdn.microsoft.com
Этот div не содержит блочных элементов поэтому он будет представлен как TextBlockCntr ( или TextBlockRenderer ):
А вот этот markup
будет нормализован в rendering tree как
Где первый TextBlockCntr выше это т.н. anonymous paragraph
В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.
Когда кто-то реально упирается в его производительность то пишут native extension. NumPy как пример.
То же происходит и в JS когда он работает в среде node.js. В обоих случаях есть относительно простой механизм встраивания native code.
Собственно я про это и говорю. Ну не надо писать ray tracers в JS. Гораздо продуктивнее было бы иметь возможность встраивания чего-то что лучше ложится на регистры и архитектуру CPU.
По идее JS в UI это клей связывающий выход одной native функции со входом другой. Т.е. в принципе JS это язык описания event routing / dispatching. Смысла JITить какой-нибудь click event handler немного если он срабатывает ровно один раз за время жизни страницы. А вот парсить их надо быстро.
Понятно что в условиях browser sandbox JS это единственная опция написать какой-нибудь ray tracer. Но вот эта единственность и есть основная проблема.
Представляется что гораздо эффективнее было бы иметь тот же embedded С например или вообще абстрактную bytecode VM типа JavaVM которую можно кормить compiled bytecodes + удобный interop из JS с этим хозяйством.
Т.е. путь того же Python — простой bytecode interpreter + удобная возможность встраивания native (или тех же bytecodes близких к native) для функций которым нужен CPU на 100%.
Как-то такое решение представляется более грамотным с инженерной точки зрения.
А так… создавать чисто интерпретирумый язык по своей изначальной природе, а потом героически преодолевать его интерпретирумость…
Не знаю как кому, но мне вот представляется что гораздо продуктивнее было бы иметь возможность сделать что-то типа inline C или Dart islands в JS:
"C" int ray_tracer(int a) {
... C code, compiled into native assembly ...
}
// normal JS
var r = ray_tracer(42);
Как-то представляется что это позволит получить более предсказуемые результаты. И уж точно исполняться будет эффективнее.
Да и сократить размер всего этого хозяйства опять же. А то вот получается что весь мой Sciter который есть фактически встраиваемый browser включающий JS superset по размеру меньше чем одна V8.dll ( sciter32.dll — 3.7mb, V8.dll — 4.7mb ).
Это live data binding в стиле AngularJS.
Но всякий автоматический binding имеет свою цену: далеко не всё укладывается в простой attribute-property binding, хорошо если 90% процентов того что нужно можно забиндить декларативно. Зато имплементауия остальных 10% как раз и занимает 90% отведенного времени. Так на так и приходится.
Как то вот ни разу не пришлось увидеть задачу в которой автоматический биндинг помог хотя бы в два раза увеличить скорость разработки финального продукта.
Написать это вот явным образом
иногда в разы полезнее чем потом рабираться «где оно тормозит?».
Здесь используются декораторы.
То же можно описать и в классическом JS/jQuery стиле (в Sciter многое из jQuery имплементирвано нативно)
то разницы между design time и run time я не вижу. На поддержку design-time тратится достаточно много ресурсов. В production этот весь код поддержки design-time редактирования не нужен, но он там есть зачем-то.
AppStore это a) one click installation of native app и b) well known place to get it.
Т.е. если раньше говорилось что мы делаем web app потому как не требует инсталляци, то сейчас дело доходит до совсем странного: на одном из проектов начальство попросило обернуть web app в PhoneGap (т.е. сделать из него как бы native) чтобы его можно было выложить в AppStore.
При этом куча времени убилась на то чтобы обойти ограничения web app и его sandbox модель.
Я считаю что loosely coupled UI и business logic есть хорошо. У каждого layer своя собственная data model.
И общение между ними ограничено фактически get/set запросами.
Во всяком случае код приложения (его core logic) не должен быть приколочен гвоздями к UI.
Вот приложение которое уже практически 10 лет живет с htmlayout/sciter UI:
sciter.com/from-skeuomorph-to-flat-ui-evolution-of-one-application
за это время они практически только UI и меняют. CSS и script, ну там animation модно стало по другому делать и пр.
А в Behavior.attached() делаем DOM population:
В sciter есть samples/+plus/ модуль. Это duplex data binding в стиле AngularJS и прочих MVC. С templates, repeatable и прочими фишками. Основан на Object.observer(function).
script в иделогии sciter это такой-же способ описания стиля как и CSS. script описывает behavioral style, а CSS rendering style. В это этом случае язык самого приложения выполняет то для чего он предназначен лучше всего — [business] локику приложения.
А в CSS сказать
И если это С++, то в нем описать
В .NET примерно так же (при наличии толкового binding).
В script то же пишется как
До мощности CSS XAMLу далеко. А markup он должен быть больше semantic. XAML попытался в одном флаконе объединить и то и то, но в результате толком ничего не получилось. ИМХО, ИМХО и еще ра ИМХО.
Кстати если есть желание можем посотрудничать.
Я вот тут недавно сравнивал Sciter и WPF так как они сделаны для одного и того же — declarative desktop UI platforms.
$230k это зарплата двух разработчиков на один год. Это без операционных расходов, лоеров, налогов и всего прочего.
Это ничто для проекта уровня Mint. Либо им кто-то подкидывает денег (и что-то за это хочет и получает) либо они живут в долг и ждут что их кто-то купит.
Пожертвования НЕ работают. от слова вообще.
И кстати Rust как это ни странно есть способ борьбы с OpenSource. Вернее с последствиями OpenSource модели разработки Mozilla «когда любой залетевший дятел с горяшими глазами и патчами рушит цивилизацию» Мерфи. Сложная и не всегда понятная политика владения объектами в таком сложном проекте привела к куче проболем с memory management у них.
Отсюда и растут ноги именно такой архитектуры Rust, который собственно и есть язык на котором он собираются переписывать движок.
Решение спорное в смысле экономической целесообразности. Не ну если конечно Rust делать коммунистически-бесплатным образом — всем миром, всем народом. Да и то… без жесткой модерации нифига не выйдет.