Comments 29
Это уже давно не так. Например Errai или VueGWT позволяют нормально использовать Html для UI со статической проверкой во время компиляции. Да и стандартный UiBinder вполне себе декларативный, и ему можно подсунуть любые нестандартные widgets, например Bootstrap или jQueryMobile. И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему. Взял xml из android проекта, чуток поправил, получил рабочую web страницу.
И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему.
У меня не столько фреймворк сделан, сколько компилятор альтернативный. Проблема в том, что ничего GWT-ного в нём не работает, ни UI binder, ни Errai. Теоретически можно попросить создателей Errai портировать его на TeaVM, но вряд ли они на это согласятся. Вот и пришлось городить свой UI-фреймворк.
Да и стандартный UiBinder вполне себе декларативный
Вот есть у меня большущая коллекция, и мне нужно показать её в table или в ul. Что делать в UiBinder? Он такого не поддерживает. Приходится городить код, который итерируется по коллекции и добавляет элементы в нужное место (некоторые для строк таблицы пишут ещё один отдельный шаблон). А если надо ещё и обновлять, причём минимальным количеством действий с DOM, то можно вообще убиться. Так что нет, UiBinder вовсе не декларативен и совершенно не удобен.
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/
Очень интересный проект, желаю ему успешного продолжения!
В Kotlin же есть нативная поддержка компиляции в Javascript. Получается, что я могу скомпилировать Kotlin-фронтенд двумя разными способами. Уже пробовали их сравнивать?
В Kotlin же есть нативная поддержка компиляции в Javascript. Получается, что я могу скомпилировать Kotlin-фронтенд двумя разными способами.
Да, всё так
Уже пробовали их сравнивать?
В каком смысле сравнивать? По производительности? По размеру генерируемого кода? Полагаю, можно написать синтетические бенчмарки, показывающие преимущества того или другого в специфическом сценарии. Что касается концептуального: в Kotlin/JS нет возможности использовать библиотеки, написанные на Java, в TeaVM немного сложнее интеропиться с JS (потому что нет специальной поддержки со стороны языка в Java и Kotlin/JVM, приходится придумывать костыли и обкладываться аннотациями). А так, если интересно, можно потратить некоторое время на исследование и составить подробный список различий, преимуществ и недостатков каждого подхода.
Спасибо. Вообще, я знаю в чём дело. Надо просто немного улучшить реализацию std:foreach
, потому что сейчас она полностью перестраивает DOM, если изменяется начало списка. Улучшение тривиальное, но руки не доходили сделать. Попробую сегодня поправить, собрать TodoMVC на снапшоте и повторить замер.
Кстати, мне пришло в голову, что этот бенчмарк измеряет не просто фреймворк, на котором писали TodoMVC, но ещё и конкретную реализацию. Реализацию, прямо скажем, я даже не пытался оптимизировать, написав максимально простой код, ведь это же пример. Уверен, можно сделать и лучше.
Ну, по хорошему реализация должна быть максимально нативная для фреймворка, без заточенных специально под бенчмарк оптимизаций, типа "сохраняем в localStorage лишь через секунду".
Присылайте пул-реквест сюда: https://github.com/eigenmethod/todomvc
Ну, по хорошему реализация должна быть максимально нативная для фреймворка, без заточенных специально под бенчмарк оптимизаций, типа "сохраняем в localStorage лишь через секунду".
Я не об этом. Например, в моей наивной реализации TodoMVC фильтр (это тот, который All|Active|Completed) применяется при каждом чтении свойства, причём не в ленивый sequence, а в новый ArrayList. Можно сделать sequence, можно немного умнее перестраивать список и т.п. Это никак не относится к фреймворку.
Ну, некоторые фреймворки умеют в реактивное программирование, где пресчёт происходит лишь при изменении данных, от которых зависит результат, а не при каждом обращении.
Flavour — это не про данные, а про их отображение. По идее, для пересчёта данных можно придумать/переиспользовать что-то другое, это никак не отразится на том, как шаблоны выглядят.
Обновление массива от обновления дома ни чем принципиально не отличается. В обоих случаях при изменении одного состояния нужно изменить другое за минимальное число шагов, не делая при этом лишней работы.
В статье я ясно написал:
Фреймворк не создаёт экземпляр класса страницы, и никак не управляет им. Вместо этого вы создаёте его сами и сами же им управляете как хотите
Делается это, чтобы не навязывать пользователю определённую модель данных. А ещё для того, чтобы соблюсти SRP. Но я поиграюсь на выходных, попробую зацепить какую-нибудь RxJava или поищу другие фреймворки для реактивных данных. Суть в том, что пользователь может обновлять данные так, как ему хочется. Хочется руками — пусть обновляет руками, хочется реактива — будет реактив. А если перфоманс не принципиален в конкретном случае, так пусть вообще оставит наивную но простую реализацию.
Скорее всего пользователь сделает как проще и всё буде тормозить. Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.
Скорее всего пользователь сделает как проще и всё буде тормозить
Premature optimization is the root of all evil © Donald Knuth
Обычно, тормозит 10% программного кода, остальные 90% в принципе работают с такими объёмами данных, что тормозить нечему. Зачем в этих 90% кода городить лишние абстракции?
Насколько я понял Flavour никакой не фреймворк, а просто библиотека для рендеринга.
В какой-то степени так. А ещё для роутинга, сериализации, валидации и REST. Не люблю фреймворки, потому что они принуждают пользователей к определённой структуре организации приложения, при этом шаг влево, шаг вправо — расстрел. Но если назвать свой проект "библиотека" или "toolkit", люди не поймут.
https://habrahabr.ru/post/126818/
Не нужно городить лишних абстракций. Фреймворк может брать на себя оптимизации, позволяя программисту писать простой и понятный код.
Фреймворк может брать на себя оптимизации
Заставляя при этом подчиняться ему. И, как я уже писал выше, шаг влево, шаг вправо — расстрел. Вместо этого на себя оптимизации могут брать библиотеки. Одна библиотека (RxJava) оптимизирует пересчёт данных, другая (Flavour) оптимизирует перерисовку DOM.
Заоптимизировал, прислал пулл-реквест. Сам код TodoMVC не менял, просто собрал последний Flavour локально и заменил в pom.xml
версию на 0.1.0-SNAPSHOT. А ещё выставил уровень оптимизации FULL. Стало значительно лучше, причём и при добавлении
Как раз на днях видел описание проекта по запуску Graphhopper в браузере.
Если вы его еще не упомянули — то стоит это сделать.
Это очень древняя история, я давно уже этим не занимаюсь (как и автор Graphhopper). Не стал от греха подальше упоминать о подобных вещах. Но вот в комментах напишу: ещё вполне актуально использование TeaVM в CodenameOne: https://www.codenameone.com/demos.html Почти на каждой демке есть опция JS port. Это они с помощью TeaVM скомпилили.
Ну да, это TeaVM, там насколько я понял, UI кажется вообще нет (да и не нужен). Не знаю, на мой взгляд такая попытка затащить в браузер полноценный роутер заслуживает упоминания. Хотя бы чтобы помнить, почему он оказался неудачен.
Удачные попытки пока редки, про одну совсем недавно пост был, но там была пусть и отлично решенная, но сильно упрощенная в сравнении с GH задача.
Ну да, это TeaVM, там насколько я понял, UI кажется вообще нет
Есть там UI: http://teavm.org/live-examples/graphhopper/
Хотя бы чтобы помнить, почему он оказался неудачен.
Технических проблем не было вообще. Были организационные и коммуникационные проблемы.
TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala