А почему у Gtk еще нету официальной React-подобной библиотеки поверх?

Всё равно выросла бы. Вместо исследования хитростей React люди бы писали утилиты к конкретному проекту поверх jQuery.

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

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

Если брать конкретно React и Vue, то там проблема в том, что требуется, фактически, интерпретатор на базе строк или XML, в который надо передавать переменные окружения. Для компилируемых языков такой подход практически неприемлем.

Вот еще, так можно на Glade XML? (нет, я знаю)

Glade нужен, если интерфейс надо нарисовать в редакторе интерфейса. Если его нужно генерировать программно, то зачем XML, если есть нормальный язык программирования?

где можно будет описывать интерфейс декларативно, с использованием javascript, с удобным получением данных из C++ или Python части

Используй QML.

Всё равно выросла бы. Вместо исследования хитростей React люди бы писали утилиты к конкретному проекту поверх jQuery.

Но у jQuery/Vanilla.js сейчас и так больше утилит.

Если брать конкретно React и Vue, то там проблема в том, что требуется, фактически, интерпретатор на базе строк или XML, в который надо передавать переменные окружения. Для компилируемых языков такой подход практически неприемлем.

https://github.com/mbasso/gccx

Если его нужно генерировать программно, то зачем XML, если есть нормальный язык программирования?

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

Но у jQuery/Vanilla.js сейчас и так больше утилит.

Так значит скорость разработки на них выросла?

https://github.com/mbasso/gccx

Это новый язык, компилируемый в Си++. Так можно и https://github.com/jscl-project/jscl считать библиотекой для JS.

Это новый язык, компилируемый в Си++.

React и Vue тоже компилируются.

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

return (<section>
  <ul>{ Items().map(item => (
    <li key={item}>{item}</li>
  ))  }</ul>}

в синтаксисе Rust

return view!{
  section { ul: Items().map(|item| li { key: item, item }) }
}

гораздо лаконичнее и не надо в конце писать россыпь скобок «)) }}».

React и Vue тоже компилируются.

Вот и второй ответ, почему нет такой библиотеки для Rust.

Я не спрашивал про библиотеки для Rust, спросил почему у Gtk нету библиотеки где можно в стиле .vue файлов описывать интерфейс с использованием js и обмениваться данными с rust, c, c++, python.

Это не синтаксис Rust, если имя в «вызове функции» кончается восклицательным знаком, то это макрос, макросы не связаны с rust, это такой препроцессор, следовательно внутри может быть что угодно, например json https://github.com/serde-rs/json

К синтаксису придираться это такое, он может быть любым. Мне нравится синтаксис Vue.

Это не синтаксис Rust, если имя в «вызове функции» кончается восклицательным знаком, то это макрос, макросы не связаны с rust, это такой препроцессор, следовательно внутри может быть что угодно

Я имею в виду, что если внутри должна быть логика, то лучше внутри оставлять синтаксис Rust, чтобы можно было реализовать вставить любую конструкцию. Любая трансляция в чуждый синтаксис ограничивает возможности.

Также как в Common Lisp хорошие макросы всегда оставляют лисповый синтаксис внутри.

спросил почему у Gtk нету библиотеки где можно в стиле .vue файлов описывать интерфейс с использованием js

Потому что компилятор js не входит в состав Gtk.

Я имею в виду, что если внутри должна быть логика, то лучше внутри оставлять синтаксис Rust, чтобы можно было реализовать вставить любую конструкцию. Любая трансляция в чуждый синтаксис ограничивает возможности.

В JSX как раз внутри JS. Отличия вижу лишь в том что у JSX теги, так как они реально и будут потом использоваться, а у Rust некие section ну это имена компонентов.

А зачем компилятор для JS? Есть GJS, можно использовать его. Он уже хорошо используется.

В JSX как раз внутри JS.

Там лапша из тегов XHTML и JS. Но в целом JSX хороший макрос поверх JS. При этом периодически абстракция протекает: тег for переименован, CDATA непонятно как вставлять.

Есть GJS, можно использовать его. Он уже хорошо используется.

Может когда-то и будет. Всё-таки написать аналог QML поверх Gtk — это достаточно много работы.

Отличия вижу лишь в том что у JSX теги, так как они реально и будут потом использоваться, а у Rust некие section ну это имена компонентов.

section взято из твоего примера. Можно легко сделать view!, внутри которого имя-тэга { … } является тэгом. И нет проблемы с тремя наборами скобок и необходимостью переименовывать атрибуты HTML. И легко втыкается CDATA в виде такой же структуры.

Ну так и в React можно тоже самое, и в Vue. Но мне нравится Vue и так, не понимаю зачем там CDATA может понадобится, и читается намного чище, но это субъективно конечно же.

не понимаю зачем там CDATA может понадобится

В шаблоне у тебя

<script type="text/javascript">
  $script.ready('lorjs', function() {
    fixTimezone("Asia/Yekaterinburg");
  });
</script>

Как будешь писать в JSX?

const t = <script type="text/javascript">
  $script.ready('lorjs', function() {
    fixTimezone("Asia/Yekaterinburg");
  });
</script>

думаю, попытается заменить фигурные скобки на строку и выругается на отсутствие fixTimezone.

Это пишется в public/index.html.

Если это динамический скрипт, то добавляется script динамически с src и запускается действие после добавления из кода, а не инлайна

Но к примеру это код для учебника, тогда:

Как будешь писать в JSX?

return (<section class=«blog-post__code»>{codeText}</section>)

{codeText}

Вот и я про то же. Приходится часть представления вытаскивать в переменные, несмотря на то, что логика от него не зависит.

И это же может быть не только скрипт. Это может быть любой текст с фигурными скобками, угловыми скобками. Поэтому в XML есть CDATA. А в JSX решили, что и так сойдёт (через переменную же обход есть).

А в HTML вообще CDATA есть?

В обычном (который не XHTML) нет. Но там и парсер позволяет ошибки структуры и по-разному разбирает разные тэги (script работает как CDATA, p может не закрываться и т.д.)

Из приколов разбора HTML. Приходится писать так:

<script type='text/javascript'>
  if (typeof window['jQuery'] == 'undefined') document.write('<scr'+'ipt type="text/javascript" src="http://z-ecx.images-amazon.com/images/G/01/javascripts/lib/jquery/jquery-1.2.6.pack._V265113567_.js"></sc'+'ript>');
</script>

чем и каким образом это ускорит разработку ?

Ты qml видел? Вот этим и ускорит.

Кто формошлёпку мержил, тот в цирке не смеётся.

Через 10 лет додумаются до аналога WPF из винды. Насколько же всё таки выше уровень разработчиков в микрософте. Активисты опенсорса не скоро догонят.

Вбей в гугл термин «MVVM» для начала, окажется что Gtk к такому отношения не имеет и иметь не может - он другой, про другое.

Vue работает поверх Gtk браузера, значит и библиотека поверх Gtk вполне возможна, не понимаю к чему ты это.

Ну а ты вбей, возможно поймешь.

Я не смогу случайному человеку объяснить очень сложный концепт современной веб-разработки, извини.

Мне незачем вбивать, я и так знаю что это.