Ещё никому не удалось опоздать на свои похороны.
Валентин Домиль
На прошлой неделе команда из Google наконец-то выложила исходники фреймворка J2CL, о котором говорили с 2015 года. Идея трансляции Java в JavaScript далеко не нова, и все уже давно набили шишек с Google Web Toolkit, однако этот продукт сообщество ждало как ни один другой — о нем говорили и делали выступления, но никто его не видел.
????????
Прошло больше 3-х лет с первого анонса и, кажется, что продукт потерял рынок даже не родившись. Сегодня у нас есть Scala.js, Kotlin.js и JSweet, не говоря уже о том, что веб-разработка захвачена TypeScript и для Java не осталось места. За такое время многие, даже самые преданные джависты, утратили веру в “Java для Front-end” и обуздали тот или иной JavaScript фреймворк.
Поскольку релиз всё-таки случился, давайте посмотрим, что получилось, и кому это может пригодиться.
Идея
Фундаментально, эмулировать JVM в браузере — задача сложная. Её долгое время решали разработчики Google Web Toolkit и достигли определенных успехов: построили транслятор, разработали механизмы эмуляции стандартной библиотеки Java, предоставили тулинг для разработки приложений.
Плюсов у такого подхода много: статическая типизация, возможность переиспользовать серверный код в браузере, готовые инструменты в виде Java IDE. Многие подходы, изначально заложенные в GWT мы сейчас видим в TypeScript, Web Pack и других инструментах фронтенд-разработки.
Старичка Google Web Toolkit не любили за его громоздкость и свою абстракцию для построения UI. Идея J2CL проще — позволить транслировать Java в JavaScript с наименьшими возможными расходами, так чтобы можно было легко вызывать Java из JavaScript и наоборот.
И если бы в далеком 2015 году действительно существовал качественный транслятор Java в JS без лишнего мусора, то неизвестно, как развивалась бы веб-разработка дальше.
Предыстория J2CL
В начале 2015 года команда Google GWT приняла трудное, но необходимое решение — разработать новый продукт, позволяющий задействовать Java во фронтенд-разработке.
В основном это было связано с изменением тенденций в веб-разработке и их новыми внутренними клиентами, которые рассматривали Java для веб не как изолированную экосистему, а как неотъемлемую часть большого стека. Это потребовало совершенно нового видения и создания инструментов с нуля, которые должны быть тесно интегрированы с остальной экосистемой.
При помощи GWT практически невозможно было достичь этих целей. И хотя в GWT присутствовали средства для двустороннего взаимодействия с JavaScipt, фреймворк не мог избавиться от большого багажа в виде UI, RPC библиотеки и других прикладных API.
Что это за зверь
Как утверждают разработчики, J2CL дает бесшовную интеграцию Java кода в JavaScript приложениях. Он представляет из себя простой и легковесный транслятор Java в JavaScript с упором на оптимизацию кода при помощи Closure Compiler.
- Можно легко смешивать Java и JavaScript в одном проекте, получая лучшее от каждого из языков.
- Позволяет переиспользовать код между серверным решением, веб-приложением и платформой Android. Доступно большое количество Java библиотек, таких как: Guava, Dagger и AutoValue.
- Современный и удобный. Сборка проектов построена на базе Bazel, поддерживается Live-reload.
- Проверенный. Утверждается, что J2CL используется в продакшене в проектах GSuite: GMail, Docs, Slides и Calendar.
По существу, J2CL транслирует исходный Java код в JavaScript код, не используя при этом байткод Java классов. Это означает, что как и в случае с Google Web Toolkit, для компиляции проекта нужны исходники для всех используемых библиотек. Кроме того, это вызывает вопросы о поддержке языковых возможностей Java в новых релизах. На данный момент, разработчики обещают поддержку всех синтаксических возможностей Java 11.
J2CL не будет поддерживать GWT Widgets, GWT RPC и другие GWT библиотеки — только базовую Java и механизм интеграции с JavaScript — JSInterop.
Т.е. это очень ограниченная версия GWT с полностью новым транспайлером. И, поскольку новый продукт больше не совместим с GWT он называется не GWT, а J2CL. В итоге, планируемый релиз GWT 3 будет представлять собой фреймворк поверх J2CL, где все прикладные библиотеки будут отделены от системного уровня самого транслятора.
Существующие ограничения совместимости с Java описаны на GitHub. В основном, они остались такими же как в GWT — отсутствует поддержка рефлексии, нет сетевого API Java. Но кое-что отличается — семантика массивов и списков не эмулируется, например не выполняется проверка вхождения индекса в границы массивов. Разработчики делают упор не на эмуляции поведения JVM, а на синтаксических средствах языка, чтобы обеспечить минимальные накладные расходы и не генерировать тонны JavaScript для обеспечения полной совместимости.
Хотя J2CL и готов к продакшену, его OSS версия все еще далека от этого. Например, есть проблемы со стартом проектов на Windows и разработчики не обещают стабильного API.
Выбор Bazel в качестве системы сборки для внутреннего продукта Google легко объяснить, но для сообщества в нём нет никаких плюсов, и для использования J2CL сейчас нет другого пути, кроме как изучить эту систему сборки. Пока остаётся только ждать, когда сообщество напишет плагины для Maven / Gradle.
Пробуем
Во-первых, чтобы сейчас попробовать J2CL вам понадобится Mac OS или Linux.
Во-вторых, вам нужно установить Bazel — несколько экзотическую систему сборки от Google.
Теперь можно хоть что-то собрать, например, HelloWorld из официального репозитория.
> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld Если мы заглянем в вывод, то будем приятно удивлены:
> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js
document.write('Hello from Java! and JS!');Это конечно же ничего не доказывает, но очень радует своей минималистичностью после модулей GWT. Больших примеров приложений пока нет, будем ждать их появления.
Зачем это нужно если есть xxx.js
Ответ на вопрос зачем это нужно найти пока сложно. На первый взгляд, в J2CL заключена очень сильная идея — переиспользовать Java для фронтенда так же, как люди используют TypeScript. С другой стороны, кажется что проект опоздал.
Новые проекты транспайлеров в JS, такие как Kotlin.js и Scala.js реализованы в виде плагинов для компиляторов и им не требуется повторный разбор исходного кода. И в этом плане, J2CL — это шаг назад, поскольку ему нужны исходники, которые он будет разбирать.
Отдельный момент, это сам язык Java. Зачем писать на многословной Java, если можно и сервер, и клиентскую часть написать на лаконичном Kotlin?
Хотя, если сравнивать с другим похожим проектом — JSweet, то J2CL я доверяю больше. Тулинг у JSweet намного более дружелюбный и готовый к использованию, но у JSweet небольшое сообщество и он почти весь написан одним человеком.
Код говорите открытый?
Безусловно радует, что у проекта открытая лицензия Apache 2.0.
К сожалению, открытый код совсем не означает открытый процесс разработки. Самое большое разочарование наступило в сообществе от сложившейся ситуации, проект J2CL анонсирован 3 года назад, но никто не показывает его исходный код, нельзя повлиять на его итоговый API и никак не ускорить процесс разработки, потому что некуда слать патчи.
Будем надеяться, что ситуация наладится и продукт станет жизнеспособным.
Комментарии (44)
qasta
19.11.2018 14:30Всё то, что хорошее было в GWT успешно взяли на себя TypeScript, ES6 и другие многочисленные языки программирования. Они легко и просто встраиваются в веб-проекты, взаимодействуют друг с другом, их легко интегрировать в webpack. А ГМейл как пример неудачного веб-приложения с точки зрения производительности и т.п. уже здесь разбирали не раз.
Даже модули в npm не положили. Хотя может быть энтузиасты и запилят плагины к популярным фреймворкам… Посмотрим.
konsoletyper
19.11.2018 23:42Ну как же это? JSweet упомянули, а TeaVM нет, хотя у него и на гитхабе звёздочек больше, и делает его ваш соотечественник.
konsoletyper
19.11.2018 23:45Хочу сказать о достаточно узкой нише, где без GWT (или аналога) — никак. Это приложения в несколько миллионов строк Java-кода, которые нужно запускать ещё и на Web (при этом требований к нативности интерфейса нет). Это всякие мультимедиа-приложения, игры и т.п. Переписывать всю эту тонну кода на TS и держать две параллельные ветки кода — это слишком затратно.
v_m_smith
20.11.2018 02:16программисты на Clojure/ClojureScript тоже чешут бороду от недоумения — Зачем? Когда уже 10 лет как есть прекрасный язык, который и в JVM, и в JavaScript.
SergejKiller
21.11.2018 16:43Разрабатывать только Web приложение, используя J2CL — немного странновато. Ещё глупее делать это используя Kotlin и подобные ему языки.
J2CL действительно нужен только для больших проектов, которые было бы не целесобразно поддерживать на N разных платформах. Взгляните не продукты гугл: Gmail, Calendar, Drive, Docs. Все эти приложения имеют клиентов на 3-х платформах (Web, Android, iOS).
J2CL это всего лишь один из инструментов в крос-платформенной разработке. Вторым инструментом является J2ObjC. Нету смысла имлементоировать один и тот же функционал 3 раза на разных языках. Гораздо выгоднее написать это всё один раз, чтобы оно работало везде. От сюда и тесная связь с bazel.
А сюда добавьте ещё и ингеграционные тесты для сервера. Там где надо вместе с сервером нужно запускать ещё и какого-нибудь клиента. Гораздо проще это делать если у вас есть нативный Java клиент (уже имеем 4 платформы: JRE, Android, iOS, Web).
Цена, которую приходится платить за это удовольствие, тоже есть. Это люди, которые поддерживают крос-платформенную инфраструктуру. Не думаю, что вне гугла найдётся много команд, которые смогут полноценно пользоваться J2CL.SergejKiller
21.11.2018 18:10Забыл добавить. На J2CL пишут незначительную но критическую чать приложения. Обычно это бизнес логика. А весь UI пишется используя нативные языки и фрэймворки.
Так же стоит понимать, что не смотря на то, что у Гугла становится всё больше и больше Open Source проектов, ещё большая часть спрятана от публики. И очень часто без этих кусочков не реально запустить проект в продакшн. Посмотрите на closure-compiler, вы увидите что много лет в нём живёт j2cl код, хотя сам j2cl был опубликован недавно. Как Вы думаете, сколько похожих приватных интеграций внутри j2cl? И сколько j2cl фич всё ещё остаётся недоступно вне гугла.
maxzh83
После работы с GWT теперь каждый раз, когда слышу про идею делать фронт на Java, у меня начинает дергаться глаз.
konsoletyper
Может, проблема не в том, что Java для написания фронта плоха, а в том, что плох GWT?
maxzh83
Случай с GWT — это прям шампунь и кондиционер в одном флаконе, т.е. и GWT плох и Java тоже не радует. Тут стоит пояснить почему Java — не самый лучший вариант. Помимо того, что она оочень многословна, она еще и далека от JavaScript по синтаксису. И вроде бы что тут плохого, вы ведь не хотим знать JS? А придется. Рано или поздно придется лезть в отладку и смотреть что происходит под капотом.
Поэтому зашел TypeScript и пока не сильно заходят Kotlin и ScalaJs (но тут, по крайней мере, потенциально есть языковые плюшки). Помимо этого, тулинг и процесс разработки на JS сильно вырос по сравнению с тем временем, когда стартовал GWT. И применительно к фронту, он стал гораздо проще чем на Java. И тут сложно что-то сделать, т.к. всегда будут накладные расходы на получение JS из Java. Разве что, c взлетом WebAssembly что-то поменяется, но и тогда я бы взял лучше Котлин.
konsoletyper
Думаю, что для тех, кому Java очень многословна, она и на бэкэнде не нужна. Есть полно других языков, которые менее многословны. Думаю, что те, кто выбирают Java, выбирают её не за краткость. Вот, например, лично мне "многословность" Java не мешает. Всё равно львиная доля времени уходит на обдумывание задачи, уточнение требований, отладку, тестирование. А код IDE помогает писать. И аргумент с тем, что более краткий код является более лаконичным, тоже сомнительный. Вспомним языки J и K. Очень читабельный на них код?
Java, например, очень далека по синтаксису от систем команд x86/x64 и ARM. Разве это кому-то мешает писать бэкэнд и мобильные приложения на ней и потом давать на откуп JVM или ART трансляцию эти платформы?
Отладку какую? В браузер с source maps или прямо в сгенерированный JS? С первым чем это отличатся от просто подебажить Java в IDE? Второе — ну это как дизассемблировать. Такое редко но делают, в основном, когда натыкаются на баги в JVM, и хотят сами разобраться в деталях вместо того, чтобы сразу писать багрепорт.
А что поменяется? Вместо относительно понятного JS будет генериться совсем низкоуровневый код, похожий на ту же систему команд процессора. Как раз в этом смысле генерация JS даже выигрывает.
maxzh83
Сама по себе многословность не основная проблема, да, это дело вкуса. Но часто, например на бэке вариантов сменить язык нет по разным причинам, там Java пока что стандарт.
Кусок страницы, которая рисуется динамически, не отображается или отображается некорректно или в одном браузере норм, в другом — нет. И вот начинаются танцы с браузером, который работает с JS.
JS станет не главным языком, на котором все крутится, а «одним из», на равных условиях. Вот тогда ваша аналогия с x86/x64 будет уместна, ну и неизбежно в браузерах появятся средства отладки не привязанные к языку (сейчас что-то есть, но не в том объеме).
konsoletyper
Помню, такое бывало в далёком 2008-м. Но в 2018-м? Первый раз слышу. К тому же, опять приведу аналогию с нативным миром — это всё равно, что забиндить к Java через JNI какой-нибудь GTK, и потом пересесть на C, только потому, что приходится в процессе разбираться с устройством этого GTK, который написан на C.
Ну так JSNI/JSInterop позволяет взять и писать на JS. Это же небольшое количество нативного кода. Помню, сам в проекте на 200К строк Java-кода понаставил несколько грязных хаков на JSNI (это в далёком 2014-м, когда корпоративные клиенты всё ещё сидели на IE8), но в совокупности их там и на 200 строк не набралось бы.
Что-то не разделяю я вашего оптимизма. Как разработчики браузеров не сделали нормальных тулов для транспайлеров, так они и для компиляторов в wasm ничего не сделают. Вроде уже года полтора как зарелизили MVP, но до сих пор по дебагу ничего нет, кроме весьма куцых сорсмапов.
Foror
>Java — не самый лучший вариант. Помимо того, что она оочень многословна
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
>она еще и далека от JavaScript по синтаксису
Вы следите за развитием ECMAScript и современным фронтендом, чтобы так утверждать? С 2010 года очень многое поменялось на фронтенде, если что.
>накладные расходы на получение JS из Java
Нет этих расходов, по крайне-мере они не меньше и не больше, чем получение JS из TypeScript. Другой вопрос, что GWT не умеет это делать правильно. Но, тогда повторю выше обозначенный вопрос, причём тут Java?
maxzh83
Я бы не брал никаких альтернатив, а брал бы именно JavaScript. Только не надо говорить про строгую типизацию, уже не смешно (мне понравилась ваша аргументация). Ну если непременно хочется альтернатив, то TypeScript и на совсем крайний вариант Котлин.
Разумеется, в 2010 я был за GWT обеими руками, а сейчас вот нет.
Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
Foror
>Только не надо говорить про строгую типизацию
Извините, но мы тут в топике про статическую типизацию, GWT и вот это всё, не распиваем смузи с другими бородачами падкие на всё блестящее и модное?
>Ну если непременно хочется альтернатив, то TypeScript
Вы серьёзно предлагаете писать бекенд на TypeScript? Я полагаю вы понимаете, что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
>крайний вариант Котлин
А вы случайно за груви не топили, когда он был в трендах? CoffeeScript может использовали? Нет, делайте свои пет проекты на чём хотите, я не осуждаю.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок, из-за которого нужно заново всё переписывать, а заказчик не корпорация типа Твиттера, готовая оплачивать смузихлебам развлечения с модным ЯП?
>Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
В процессе. Скоро в этих ваших интернетах и на хабре в частности.
maxzh83
Вы спросили что бы я выбрал, я ответил. Я серьезно считаю, что лучше фронт писать на чистом js, в котором после написания строчки браузер тут же отображает изменения (даже страницу обновлять не надо) и в дебаге ты спокойно видишь ровно то, что писал. А не долгие пересборки с последующей декомпиляцией в голове.
Где я такое говорил? Я предлагал на нем писать фронт, если что. Хотя, думаю вы прекрасно поняли о чем я.
Вы сами-то со смузи не балуетесь?
Нет не топил, предлагаю встретиться где-то на хабре лет через 5 и посмотреть кто на чем будет писать.
А я думал мы говорим не о кровавом энтерпрайзе, где поменять цвет надписи в стиле занимает пару часов.
Короче, желание писать все на Java и хрен класть на все остальное — оно кажется красивым, но на практике выглядит утопично. Пишем фронт на Java с криком «нам не нужен JS», но при этом все равно вынуждены его знать. Пишем слой DAO на хибере с криком «нам не нужен SQL», но все равно вынуждены его знать и т.д.
Foror
Нам, тут в Сибири, не до смузи )
Вы опять не в ту сторону. Я говорю о простых людях, малом и среднем бизнесе, которым нужно просто чтобы работало и у них нет денег на ваши развлечения с модными технологиями.
maxzh83
С какими модными-то? Обычный JS, куда уж проще? Фронтенд разработка это отдельная специфичная отрасль и не надо это пытаться скрыть. Искать js разработчика будет стоить гораздо дешевле (к вопросу о деньгах) чем джавера на фронт. Заменить его будет также проще, как и расширить команду и т.д.
Foror
А вы искали? Расширяли команду, чтобы вот это всё утверждать? Или думаете зачем столько транспайлеров к JavaScript напили со статической типизацией, от нечего делать?
maxzh83
Угу, искали. От GWT в лучшем случае воротят нос, в худшем шарахаются как от прокаженного. С JS проблем вообще никаких. Даже если кто-то не знает TypeScript, обычно не против изучить, потому что это будущее для этих людей. А GWT — прошлое и никто не хочет тратить время, связываясь с тем, что подыхает.
Foror
Понятно, мы опять пришли к вопросу — Причём тут Java? ) Нет, я согласен, что для джавы сейчас нет нормального фреймворка для фронтенда, как у TypeScript. Но я, например, работаю над этой проблемой.
maxzh83
При том, что у всех языков есть свое назначение. На C++ никто не пишет крупный backend в здравом уме, не потому что язык плохой, а потому, что он для другого. Тут такая же история и с Java.
Искренне желаю успехов
Foror
>И вроде бы что тут плохого, вы ведь не хотим знать JS? А придется. Рано или поздно придется лезть в отладку и смотреть что происходит под капотом.
Вижу с вами не всё потеряно ) Кстати, если уж быть точнее то джава не многословна, а как сказал Гослинг — у нас в джаве плохо сделаны умолчания.
maxzh83
Это вопрос терминологии. Умолчания ли это или многословность, результат один — дофига букв, которые не очень нужны. Именно поэтому таки добавили var и именно поэтому lombok становится таким популярным.
Foror
>добавили var
И сегодня я плююсь, когда вижу джава код с гитхаба в окне браузера. Я не против var для определенных кейсов. Но люди этого не понимают (также как вы, наверное против многословности — против, чтобы только быть против?), теперь без IDE чтение кода замедлилось, я просто не могу тут же увидеть тип переменной, нужно искать объявление метода.
maxzh83
Мне кажется это ваши личные трудности. Всем не угодишь.
Foror
Нет, не только мои. Здесь был топик недавно и там на это жаловались. Причём жаловались не джуны, а дяди, занимающиеся известными в узких кругах проектами. Вплоть до запрещения использования var в коде.
Джуны и мидлы не видят проблему в перспективе. Им бы только меньше букв написать, но они не понимают, что проект нужно будет поддерживать через 5 лет и через 10 лет. И чем больше времени будет уходить на чтение кода средним программистом «где меньше букфф», тем больше затрат будет нести компания.
maxzh83
Это старпёрство. А жаловались всегда и на все. На функциональщину в 8 Джаве, даже на for по коллекции.
Ну вот нормальный ход, если серьезным дядям не нравится, то пусть запрещают. А чтобы наверняка, лучше еще и не обновляться, сидеть на Java 6.
Господи, вы в блокноте что ли кодите по старинке?
Foror
>lombok становится таким популярным
Ну вот, вы сами решили проблемы многословности джавы ) Зачем вам котлин? Хотя я конечно бы не рекомендовал использовать ломбок не в пет проектах… Но с другой стороны если осмелились на котлин, то тогда уж лучше ломбок )
maxzh83
Null safety, корутины. На самом деле я как писал на Java, так и пишу. Просто не понимаю, почему такой негатив к Котлину. Это не Groovy с нестрогой типизацией и не надмозгная Scala.
Ни разу с ним проблемы не было, не пет проекты
Foror
>Null safety, корутины
Всё это есть в новых джавах, корутины в процессе. Хотя, как я понимаю, в котлине они не настоящие, а тупо эмулируются на тредах. Поэтому для джавы можно написать библиотеку и иметь такие же корутины.
>почему такой негатив к Котлину
Фрагментация. Он не даёт особых преимуществ перед джавой, но фрагментирует платформу и повышает энтропию. Тот же MapDB мог быть написан на джаве, но разработчик решил выпендриться…
maxzh83
Нету даже близко. Optional ни разу не это, если что. Если интересно — kotlinlang.org/docs/reference/null-safety.html
В Java 14?
Да все можно, дьявол кроется в деталях, которых дофига всплывает.
Как по мне так конкуренция скорее. С появлением альтернативы на JVM, стали чаще выкатываться фичи, которые уже давно есть в других языках. Если бы не они, сейчас бы не было ни лямбд ни стримов. Гоняли бы for, зато все читабельно, даже без IDE.
Вы контрибьютили туда что ли?
Foror
>Нету даже близко. Optional
Optional как раз «близко».
>Да все можно, дьявол кроется в деталях, которых дофига всплывает.
Я думаю такие фреймворки есть, просто я не сталкивался. Как минимум, недавно были модны фреймворки обменивающиеся иммутабельными объектами. Забыл уже как этот паттерн называется.
>С появлением альтернативы на JVM
Вот точно не с Котлин брали примеры в новую джаву. Скорее из Go и Rust, может со Скалы что-то утащили, но скорее с функциональных идей, а не с конкретной реализации.
>Вы контрибьютили туда что ли?
Нет, использовал как-то в проекте. Но оно сильно тормозило, открыл я код в Eclipse посмотреть, а там какие-то крякозябры. По итогу выкинул и поставил решение написанное на джаве (кстати, от молодого человека, которого вы выше старпером назвали). И это решение на порядки было быстрее и очень экономно кушало память, как будто на Си писанная, но всё было на джаве.
maxzh83
Нет, не близко. Optional это практически монада Option из Scala. А в Котлин притащили что-то близкое к C#
Если речь про akka, то это тоже из Scala мира и с корутинами мало чего общего имеет, разве что внутренняя реализация близка, так там по другому и не сделать.
Нет не с Котлина, вы невнимательно читаете. Альтернативы — это еще и Scala (в первую очередь) и Groovy и Clojure. А функциональные идеи давно друг у друга тырят.
А если бы было на Джаве, то что автоматом летало бы что ли? Все от программиста же зависит.
Я никого старпером не обзывал, я назвал подход старперским. Запретить, не пущать.
Foror
>Разве что, c взлетом WebAssembly что-то поменяется
Поменяется всё, каждый будет пилить код на чём захочет. Я буду на джаве с openjdk, вы на котлине и все будут счастливы )
maxzh83
Я только за, если что. А пока браузеры дружат только с js, увы так не получится.
Foror
Получится. WASM 2.0 пилят, никто из корпов не против его доставить потом в браузеры.
foal
А чем так плох GWT? Вот пример сайт на GWT — www.friseur-termin.eu, а вот демка библиотеки (Material Design) dominokit.github.io/domino-ui-demo
konsoletyper
На вопрос, чем плох GWT, пусть отвечают создатели GWT, которые его успешно похоронили и теперь делают J2CL. А так же многочисленные пользователи GWT, которые в нём почему-то разочаровались. Лично от себя могу добавить следующие моменты:
Короче, проблема номер два решалась выпиливанием старой библиотеки виджетов и написанием нормального Angular/Java (ведь написал же гугл форки для TS и Dart, чего бы Java не осилить?), а не выкидыванием всего GWT и заменой его на J2CL
Throwable
Я бы не сказал, что это проблемы.
Настоящие проблемы, которые точно также остались у J2CL:
konsoletyper
Всё это весьма и весьма кривое и неудобное. После Angular 2+/TypeScript реально неуклюжим кажется.
В JavaScript тоже нет никаких возможностей таких. Вот для этого и прикрутили JSX/TSX.
Либо прикручивается сторонний темплейтер, поддерживающий типизированные байндинги, вроде этого.
А чего в плане интероперабельности не хватает в JSInterop?
mbait
Создатели GWT дружно ушли из гугла какое-то время назад. О причинах я не знаю, но могу догадываться. Стоны про UI в GWT мне никогда не были понятны. GWT это прежде всего компилятор, который позволяет писать сложный, но надёжный клиент-серверный код.