konsoletyper 13 окт 2017 в 00:21

TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala

9 мин

7.6K

Я пиарюсь

+23

Комментарии 29

slavap 13 окт 2017 в 06:02

> В GWT просто ужасный фреймворк для создания UI.
Это уже давно не так. Например Errai или VueGWT позволяют нормально использовать Html для UI со статической проверкой во время компиляции. Да и стандартный UiBinder вполне себе декларативный, и ему можно подсунуть любые нестандартные widgets, например Bootstrap или jQueryMobile. И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему. Взял xml из android проекта, чуток поправил, получил рабочую web страницу.

asm0dey 19 окт 2017 в 00:00

Errai вроде бы закрыли с концами?

slavap 19 окт 2017 в 22:45

кто закрыл? посмотри коммиты на github, релизы регулярные, свежему двух недель нет :-)

asm0dey 20 окт 2017 в 07:21

Ничего себе! Я прям уверен что видел на сайте jboss информацию о закрытии… Прошу прощения

konsoletyper 20 окт 2017 в 12:03

И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему.

У меня не столько фреймворк сделан, сколько компилятор альтернативный. Проблема в том, что ничего GWT-ного в нём не работает, ни UI binder, ни Errai. Теоретически можно попросить создателей Errai портировать его на TeaVM, но вряд ли они на это согласятся. Вот и пришлось городить свой UI-фреймворк.

Да и стандартный UiBinder вполне себе декларативный

Вот есть у меня большущая коллекция, и мне нужно показать её в table или в ul. Что делать в UiBinder? Он такого не поддерживает. Приходится городить код, который итерируется по коллекции и добавляет элементы в нужное место (некоторые для строк таблицы пишут ещё один отдельный шаблон). А если надо ещё и обновлять, причём минимальным количеством действий с DOM, то можно вообще убиться. Так что нет, UiBinder вовсе не декларативен и совершенно не удобен.

slavap 21 окт 2017 в 02:50

UiBinder декларативен в том смысле, что можно написать:

<da:JQMDataTable ui:field="grid" 
    searching="true" scrollX="true" scrollY="100px"
    useParentHeight="true" pagingType="FULL_NUMBERS" 
    lengthMenu="10, 20, -1={i18n.textAll}" 
    rowSelectMode="SINGLE"
    colSorts="7,9" 
    addStyleNames="{r.style.subNormalFontTableBody} 
      {r.style.subNormalFontTableHead} {r.theme.gridEmptyTextHighlighted}">
    <da:column>
      <da:ColumnDefEx name="CHECKBOX_ROWSELECT" 
          defaultContentType="CHECKBOX_ROWSELECT" />
    </da:column>
    <da:column>
      <da:ColumnDefEx name="SHIP" title="{i18n.textShip}" />
    </da:column>
...
</da:JQMDataTable>

Соответственно класс DataTable — это визуальный компонент, умеющий работать с данными, самописный или обёрнутый js через interop/jsni. Выбор гридов достаточный, я например обернул https://datatables.net/

justboris 13 окт 2017 в 11:28

Очень интересный проект, желаю ему успешного продолжения!

В Kotlin же есть нативная поддержка компиляции в Javascript. Получается, что я могу скомпилировать Kotlin-фронтенд двумя разными способами. Уже пробовали их сравнивать?

konsoletyper 13 окт 2017 в 11:46

В Kotlin же есть нативная поддержка компиляции в Javascript. Получается, что я могу скомпилировать Kotlin-фронтенд двумя разными способами.

Да, всё так

Уже пробовали их сравнивать?

В каком смысле сравнивать? По производительности? По размеру генерируемого кода? Полагаю, можно написать синтетические бенчмарки, показывающие преимущества того или другого в специфическом сценарии. Что касается концептуального: в Kotlin/JS нет возможности использовать библиотеки, написанные на Java, в TeaVM немного сложнее интеропиться с JS (потому что нет специальной поддержки со стороны языка в Java и Kotlin/JVM, приходится придумывать костыли и обкладываться аннотациями). А так, если интересно, можно потратить некоторое время на исследование и составить подробный список различий, преимуществ и недостатков каждого подхода.

justboris 13 окт 2017 в 11:47

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

Из вашего ответа это становится понятно, спасибо!

vintage 13 окт 2017 в 16:07

Не плохо, но на удалении задач из начала списка — просадка.

konsoletyper 13 окт 2017 в 16:15

Спасибо. Вообще, я знаю в чём дело. Надо просто немного улучшить реализацию std:foreach, потому что сейчас она полностью перестраивает DOM, если изменяется начало списка. Улучшение тривиальное, но руки не доходили сделать. Попробую сегодня поправить, собрать TodoMVC на снапшоте и повторить замер.

konsoletyper 13 окт 2017 в 16:31

Кстати, мне пришло в голову, что этот бенчмарк измеряет не просто фреймворк, на котором писали TodoMVC, но ещё и конкретную реализацию. Реализацию, прямо скажем, я даже не пытался оптимизировать, написав максимально простой код, ведь это же пример. Уверен, можно сделать и лучше.

vintage 13 окт 2017 в 18:01

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

Присылайте пул-реквест сюда: https://github.com/eigenmethod/todomvc

-1

konsoletyper 13 окт 2017 в 18:25

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

Я не об этом. Например, в моей наивной реализации TodoMVC фильтр (это тот, который All|Active|Completed) применяется при каждом чтении свойства, причём не в ленивый sequence, а в новый ArrayList. Можно сделать sequence, можно немного умнее перестраивать список и т.п. Это никак не относится к фреймворку.

vintage 13 окт 2017 в 18:52

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

konsoletyper 13 окт 2017 в 18:55

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

vintage 13 окт 2017 в 19:17

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

konsoletyper 13 окт 2017 в 19:25

В статье я ясно написал:

Фреймворк не создаёт экземпляр класса страницы, и никак не управляет им. Вместо этого вы создаёте его сами и сами же им управляете как хотите

Делается это, чтобы не навязывать пользователю определённую модель данных. А ещё для того, чтобы соблюсти SRP. Но я поиграюсь на выходных, попробую зацепить какую-нибудь RxJava или поищу другие фреймворки для реактивных данных. Суть в том, что пользователь может обновлять данные так, как ему хочется. Хочется руками — пусть обновляет руками, хочется реактива — будет реактив. А если перфоманс не принципиален в конкретном случае, так пусть вообще оставит наивную но простую реализацию.

vintage 13 окт 2017 в 19:35

Скорее всего пользователь сделает как проще и всё буде тормозить. Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.

konsoletyper 13 окт 2017 в 19:48

Скорее всего пользователь сделает как проще и всё буде тормозить

Premature optimization is the root of all evil © Donald Knuth

Обычно, тормозит 10% программного кода, остальные 90% в принципе работают с такими объёмами данных, что тормозить нечему. Зачем в этих 90% кода городить лишние абстракции?

Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.

В какой-то степени так. А ещё для роутинга, сериализации, валидации и REST. Не люблю фреймворки, потому что они принуждают пользователей к определённой структуре организации приложения, при этом шаг влево, шаг вправо — расстрел. Но если назвать свой проект "библиотека" или "toolkit", люди не поймут.

vintage 13 окт 2017 в 21:03

https://habrahabr.ru/post/126818/

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

konsoletyper 13 окт 2017 в 21:34

Фреймворк может брать на себя оптимизации

Заставляя при этом подчиняться ему. И, как я уже писал выше, шаг влево, шаг вправо — расстрел. Вместо этого на себя оптимизации могут брать библиотеки. Одна библиотека (RxJava) оптимизирует пересчёт данных, другая (Flavour) оптимизирует перерисовку DOM.

vintage 14 окт 2017 в 03:40

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

НЛО прилетело и опубликовало эту надпись здесь

konsoletyper 15 окт 2017 в 01:45

Заоптимизировал, прислал пулл-реквест. Сам код TodoMVC не менял, просто собрал последний Flavour локально и заменил в pom.xml версию на 0.1.0-SNAPSHOT. А ещё выставил уровень оптимизации FULL. Стало значительно лучше, причём и при добавлении

sshikov 14 окт 2017 в 11:00

Как раз на днях видел описание проекта по запуску Graphhopper в браузере.

Если вы его еще не упомянули — то стоит это сделать.

konsoletyper 15 окт 2017 в 13:22

Это очень древняя история, я давно уже этим не занимаюсь (как и автор Graphhopper). Не стал от греха подальше упоминать о подобных вещах. Но вот в комментах напишу: ещё вполне актуально использование TeaVM в CodenameOne: https://www.codenameone.com/demos.html Почти на каждой демке есть опция JS port. Это они с помощью TeaVM скомпилили.

sshikov 15 окт 2017 в 15:55

Ну да, это TeaVM, там насколько я понял, UI кажется вообще нет (да и не нужен). Не знаю, на мой взгляд такая попытка затащить в браузер полноценный роутер заслуживает упоминания. Хотя бы чтобы помнить, почему он оказался неудачен.

Удачные попытки пока редки, про одну совсем недавно пост был, но там была пусть и отлично решенная, но сильно упрощенная в сравнении с GH задача.