• Смена основного стека с .NET на Java
    0
    Да, я знаю про jOOQ, но ни разу не видел его использование хоть в чем-то, напоминающем продакшен.

    Есть Querydsl, использовал в продакшене и не могу нарадоваться. Ещё есть Jinq, но с ним я только игрался и идея использовать его в продакшене мне кажется сомнительной. Причина — использует сериализуемые лябмды, что накладывает множество ограничений (лучше анализировал байт-код лябмд с помощью какого-нибудь инструментатора/класслоадера).


    Возможно потому что это полу-платный новодел без JSR, возможно по другой причине.

    JSR не панацея. На спринг есть JSR? А, скажем, для логгирования используют log4j/logback/slf4j вместо стандартного (JSR) java.util.logging.

  • List.of() и все, все, все…
    0

    А что я тут ещё заметил: для списков разной длины возвращается свой класс. Это плохо, потом будет какой-то код, написанный для List<T> получать всё это многообразие разных реализаций и нарвёмся мы на мегаморфные вызовы, что сразу убьёт все полезные оптимизации.

  • Блеск и нищета джавовых веб-фреймворков
    +1

    А чем это отличается от jSweet?

  • Блеск и нищета джавовых веб-фреймворков
    +3
    С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.

    Самописный, идеологически напоминающий Angular. Посмотрите сайт проекта, там про всё это написано


    А в чем преимущества в вашем проекте, если «GWT такой же»?

    А в том, что в отличие от GWT можно писать на Java, Kotlin и Scala. А ещё есть несколько приятных фишек, отсутствующих в GWT (например, эмуляция тредов на корутинах). Ну и собственно, упомянутый фреймворк, которого для GWT нет.

  • Блеск и нищета джавовых веб-фреймворков
    +2

    Сама TeaVM никуда не входит. Это всего лишь AOT-компилятор, который порождает самодостаточный JS-файл, где всё есть и которому ничего больше не нужно загружать.

  • Блеск и нищета джавовых веб-фреймворков
    +2
    1. Интернет не всегда высокоскоростной
    2. Из-за размера увеличивается нагрузка на устройство (больше парсить, кэш браузера отжирает больше хранилища).
  • Блеск и нищета джавовых веб-фреймворков
    +2
    Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.

    Спасибо


    А есть у тебя какие-нибудь дополнительные документы, кроме короткой документации на глагне? Про внутреннюю архитектуру и решения.

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


    Про внутреннюю архитектуру есть совсем немного на wiki в github. Там проще не статьи писать, а сразу послать читать Мучника + дать ссылок на несколько имеющихся статей по оптимизациям на SSA.


    Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)

    Можно, но я не буду этого делать. Раздел "Я пиарюсь" мало кто читает, а правила Хабра запрещают где-либо ещё публиковать статьи. Я хотел написать статью про то, как я делал online TeaVM (который на самом деле является просто javac, скомпиленным в JS), но буду публиковать на англоязычных платформах, скорее всего.

  • Блеск и нищета джавовых веб-фреймворков
    +1
    Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK

    TeaVM как раз и ставит задачу: сделать Java на клиенте достаточно лёгкой, чтобы не тащить за собой мегабайты JDK (как это делает, скажем, какой-нибудь CheerpJ). Hello World на чистом DOM сейчас занимает порядка 30 кб (на System.out чуть побольше, ибо надо тащить кусок java.io). Это, конечно, не сотня байт, как в случае ES или TS, но уже и не пара мегабайт. Скажем, какой-нибудь TodoMVC занимает всего 125 кб, сравните с TS + Angular 4. Кстати, справедливости ради, GWT такой же: если отказаться от его (весьма ущербной) библиотеки виджетов и писать на чистом JSInterop, то результирующий JavaScript очень радует своими размерами.

  • Блеск и нищета джавовых веб-фреймворков
    +1

    Опять же, мой проект уже поддерживает WebAssembly (частично). Есть демка. И полноценное openjdk очень долго качать, даже очень сильно порезанное — всё равно несколько мегабайт. В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK. Правда, достигается это путём отказа от reflection (и запиливания своей альтернативы, которая хорошо дружит с DCE).


    Затащить JDK таким обhазом можно и в JS, причём WebAssembly пока непонятно какие преимущества даёт в этом плане. Там ни GC нет (пришлось свой написать), ни человеческого интеропа с DOM, а в плане размера бинарника и скорости WebAssembly совсем пока не радует.

  • Блеск и нищета джавовых веб-фреймворков
    +1

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

  • Блеск и нищета джавовых веб-фреймворков
    0
    Вот зачем тащить чуть ли не весь JDK на клиента?

    Это заблуждение. GWT умеет этот JDK очень хорошо вырезать. И небольшое приложение на GWT скорее всего приведёт к генерации небольшого количества JS. И вовсе GWT не тяжёлый

  • Kotlin 1.2: общий код для JVM и JavaScript
    0

    Нашёл конкретную ссылку


    Правда, условие path.startsWith("META-INF/resources/") || !path.startsWith("META-INF/") надо убрать.

  • Kotlin 1.2: общий код для JVM и JavaScript
    0

    Проще всего, пожалуй, включить DCE — он сам распакует и порежет kotlin.js. А так, можно всегда написать copy task в gradle, который вытащит kotlin.js из нужного артефакта. Где-то в документации была (устаревшее) руководство по этому поводу.

  • Kotlin 1.2: общий код для JVM и JavaScript
    –1

    Да. На всякий случай, чтобы предупредить возможные возмущения, что kotlin.js — огромная библиотека, дам эту ссылку. И третий элемент script не нужен — meta.js используется только компилятором. Кстати, это уже является во многом вашим выбором, но насколько мне известно, люди предпочитают проект на Kotlin/JS паковать с помощью webpack, с котором Kotlin совместим.

  • Kotlin 1.2: общий код для JVM и JavaScript
    +2
    Вы вырвали фразу из контекста и прилепили к ней кажущееся очевидным, но по сути некорректный контраргумент.

    Контраргументов я не приводил. Ответил на вопрос "зачем Kotlin/JS", который является подмножеством заданного вопроса (по остальной части вопроса позиции не имею, поэтому оставил ответ другим комментаторам). Ответ таков: если кто-то считает Kotlin уместным на бэкэнде, то ему приятнее будет писать на Kotlin на фронтэнде (как раз аргументы в пользу этого я привёл).


    Но язык этот должен подходить и для front-end и для backend. Если вы будете использовать C++ или Go для фронта, то ничего кроме раздутых сроков и бюджета не получите, для подавляющего числа проектов, надесь понятно почему

    Нет, мне вовсе не понятно, почему. Особенно, если мы говорим об абстрактной задаче в вакууме. Для каких-то задач C++ или Go не подходят, очевидно, для каких-то подходят. На фронте задач разных хватает. Держу пари, что у ребят из какого-нибудь ONLYOFFICE задачи такие, для которой 90% существующей JS-экосистемы, с вебпаками и ангулярами не подходит. А ещё ведь есть игровые движки (ради которых, как я понял, и затевалась вся движуха с WebAssembly).


    и для фронта не очень, т.к. придется писать кучу ООП шного кода, вместо простого JS или аналогов.

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


    Для начала вы ответьте на вопрос зачем использовать колтин для разработки back-end'a, если есть другие альтернативы и они полуше

    Я не могу ответить на этот вопрос. Кто использует Kotlin для бэка, тот на него уже, видимо, имеет какой-то ответ.


    Возможно вы просто кроме Java ни на чем и не программировали

    Программировал. На ABAP, 1С, C#, немного C — в прод, и на Nemerle, Scala, Haskell, Scheme — в стол.


    во всяком случае я не вижу другого объяснения, почему вы считаете небольшое кол-во синтаксического сахара, чем то прорывным и вообще достойным внимания

    Я так не считаю, где я про это сказал? Я вообще лично не против продолжать писать на Java, если надо. Не во всех задачах Kotlin, Scala или какой-нибудь Haskell добавляют существенной продуктивности разработчикам (а иногда, наоборот, лишь убивают её), так что надо прежде всего смотреть на задачу, которую вы решаете, на ваши реалии.

  • Kotlin 1.2: общий код для JVM и JavaScript
    +1
    А так же что Kotlin дает для разработки front-end'a

    То же, что node.js даёт для разработки бэкэнда, а именно — возможность писать всё на одном языке. Дальше обсуждать бессмысленно, потому что есть 1000 мнений на этот счёт. Но уже одно то, что node.js есть и собирает большое коммьюнити, говорит о том, что идея иметь один язык для всего, не так уж маргинальна.


    Кроме возни и гемора с классами и как следствие тонн всяких конверторов JSON->Object и обратно

    kotlinx.serialization всю возню берёт на себя, это должно упростить жизнь.

  • Kotlin 1.2: общий код для JVM и JavaScript
    +2
    есть немного специального кода для поддержки пакетов

    Уже давно нет. Пакет — просто пустой объект JS, куда накидываются свойства.


    Что символы, что строки часто используют обёртки от Kotlin

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


    Нет switch на уровне языка, when же всегда преобразуется в набор if. Не знаю, плохо ли это.

    Как раз недавно пофиксили, см. KT-21160.

  • Kotlin 1.2: общий код для JVM и JavaScript
    +1

    Ещё вы можете компилировать Kotlin в JS не через Kotlin/JS, а через вот это, и использовать хоть BigInteger, хоть всякие локали, форматы, даты и т.п.

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    +1
    И городить свой UI фреймворк имеет смысл только с прицелом на android разработчиков по-моему.

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


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

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Ну да, это TeaVM, там насколько я понял, UI кажется вообще нет

    Есть там UI: http://teavm.org/live-examples/graphhopper/


    Хотя бы чтобы помнить, почему он оказался неудачен.

    Технических проблем не было вообще. Были организационные и коммуникационные проблемы.

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

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

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

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    +1
    Фреймворк может брать на себя оптимизации

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Скорее всего пользователь сделает как проще и всё буде тормозить

    Premature optimization is the root of all evil © Donald Knuth


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


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

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

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

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


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

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

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

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

  • TeaVM — инструмент для создания веб-фронтэнда на Java, Kotlin и Scala
    0
    Ну, по хорошему реализация должна быть максимально нативная для фреймворка, без заточенных специально под бенчмарк оптимизаций, типа "сохраняем в localStorage лишь через секунду".

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

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

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

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

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

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

    Да, всё так


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

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

  • Spark — Потрясающий веб-микрофреймворк для Java
    +1
    1. В TeaVM не надо писать на JavaScript, для того он и создан
    2. Есть возможность делать гуй на шаблонах (с биндингом, перерисовкой только изменившегося DOM). Пишите шаблоны под bootstrap — будут и компоненты. Можно создавать свои компоненты для шаблонизатора, можно биндиться к JavaScript-компонентам (как и в GWT). Но, разумеется, т.к. мой проект пока не нашёл широкого применения, под него есть только небольшой набор стандартных компонентов.
  • Spark — Потрясающий веб-микрофреймворк для Java
    +1
    Например Element.querySelector() уже более 5 лет доступен в браузерах, а в GWT его так и не поддержали

    А зачем его вызывать вручную? Я всегда думал, что выбор элементов за меня сделает библиотека виджетов. А сделает она это через JSNI или через overlay-тип — мне какая разница? Конечно, иногда надо напрямую сделать что-то с DOM, но это настолько редко требуется, что кусочек JSNI не проблема написать. Зато остальные 99% кода пишутся на Java без проблем.


    но зачем тогда вообще тащить GWT

    Причина одна, но для кого-то может быть крайне весомой — возможность писать клиентский код на Java.

  • Spark — Потрясающий веб-микрофреймворк для Java
    0
    начинать на нем что-то новое на мой взгляд не надо

    А можно услышать какие-нибудь аргументы? Просто интересно

  • Spark — Потрясающий веб-микрофреймворк для Java
    +2

    Пользуясь случаем, попиарю свой проект: http://teavm.org/
    Поддерживаются Java, Scala, Kotlin, есть Angular-образный фреймворк в комплекте

  • Kotlin для Android: Теперь официально
    +1

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

  • Kotlin для Android: Теперь официально
    +1
    например благодаря тому, что котлин дает полный контроль над тем, как API библиотеки выглядит со стороны джавы

    Ну даже "из коробки" тот API, который Kotlin отдаёт Java, выглядит достаточно удобным и естественным, за исключением классов, оканчивающихся на Kt, и необходимости явного обращения к companion object. Обе претензии больше эстетические, чем концептуальные, да и возникают подобные ситуации не очень часто.

  • Kotlin для Android: Теперь официально
    +6

    Ну это интересный вопрос. Я, как один из разработчиков языка, должен бы по идее защищать язык. Однако, скажу честно: я не знаю. Я так понимаю, просто есть разные люди с разным мировосприятием, кто-то хочет стабильности и надёжности (и поддерживаемости кода конченными индусами), кто-то хочет чего-то с приятными синтаксисом. Так что пусть на вопрос "зачем" отвечают разработчики для самих себя. Как мы видим, достаточно большая часть разработчиков нашла ответ на этот вопрос, и Google даже пришлось пойти им навстречу.


    Для себя я придумал такое объяснение, зачем мы делаем Kotlin — чтобы дать людям выбор. Ну и ещё одно — чтобы у людей была возможность писать fullstack-приложения. В мире JS есть node.js, почему в мире Java нет fullstack-решения? Есть GWT, но он в последнее время тихо загибается, плюс это сторонний инструмент от стороннего разработчика, а не официальная технология от разработчиков Java. Мы же в Kotlin координируем усилия между командами, разрабатывающими JVM, JS и Native бэкэнды. А некоторые внутренние продукты JetBrains уже пишутся на fullstack Kotlin.


    когда есть обкатанная Java c миллионом библиотек и готовых решений под неё

    Ваша ошибка в том, что эти библиотеки "для Java". Это не так, Kotlin прекрасно работает с библиотеками, созданными специально "для Java"

  • Пробуем делать web-frontend на Rust (WebAssembly)
    0

    Сборщик мусора можно и свой написать. Я уже частично портировал свой Java-JavaScript компилятор в WebAssembly: https://github.com/konsoletyper/teavm

  • «Скорее всего, будет расти как снежный ком» — Андрей Бреслав и Антон Кекс о Kotlin
    –1

    Внутри у любого современного компилятора есть IR, да не один. У Java это — байт-код, у LLVM — биткод или текстовый IR, у gcc — какой-нибудь gimple и т.п. Над IR, в виду его простоты, достаточно тривиально делать подобные трансформации. В Kotlin есть свои IR, но они ещё не устаканились, так что мы пока не публикуем их. В данный момент трансформация в state-машины в реализации корутин для JS и JVM делается по-разному, возможно, когда-нибудь мы сделаем универсальную трансформацию. Основная проблема в том, что на уровне байт-кода (или любого подобного представления) трансформация делается тривиально, а на уровне AST (который удобен для генерации JS) та же трансформация выглядит значительно менее тривиальной, и оставляет в коде значительно больше мусора.


    Вообще, наличие простого как пробка байт-кода у Java — это то, за что я так люблю эту платформу. Стоит лишь не полениться его выучить, овладеть такими инструментами как asm, и можно творить такую магию, что никаким lisp не снились (к сожалению, очень мало разработчиков знают о такой киллер-фиче и умеют её правильно готовить). По опыту работы с JS, как с целевой платформой, для него как раз такой фичи очень не хватает. Надеюсь, мы когда-нибудь дойдём до того, что сделаем этакий платформо-независимый kotlin bytecode.

  • «Скорее всего, будет расти как снежный ком» — Андрей Бреслав и Антон Кекс о Kotlin
    0

    Вообще-то, JVM хорош тем, что синтаксис новый не нужен — достаточно просто поинструментировать байт-код. Собственно, мы в Kotlin так и делаем (аналогично делает какой-нибудь quasar).