>Будет полезно, чтобы NotNull, например, работал и на клиенте.
Я сейчас точно не помню, но NotNull по моему у меня обрабатывается на клиенте. Я просто очень долго уже работаю над основной базой и точно не помню деталей реализиации веб-фреймворка. Более того, сейчас нет четких критериев как всё будет выглядеть в итоге.
На базе этого проекта делаю веб-фреймворк отвечающий как за фронтенд (что-то типа Angular, но значительно легковеснее и проще), так и за бекенд (на Undertow на данный момент).
Валидация происходит на сервер-сайде, т.е. отправляется ajax запрос проверить валидность POJO (текущей веб-формы). На клиенте валидации нет.
Но как я и говорил, когда я всё выложу в opensource и кому-то будут нужны аннотации на клиенте — это не проблема. Может даже к тому времени аннотации можно будет транспилить сразу на клиента с поддержкой во всех браузерах.
>я бы не изголялся с компиляторами и трансляторами
Вы опять теряете основной посыл проекта — сделать разработку фронтенда полностью на джаве, не на тайпскрипте, не на кофескрипте, не на *скрипте.
Переиспользование POJO это лишь один из плюсов, который он принесёт.
Проверил в хроме — не работает ) Я всё таки хочу вариант работающий в текущих браузерах. Но в целом, я и говорил, что по итогу можно код чуть-ли не строка к строке транспилить в каком-нибудь ближайшем будущем )
>Typescript же, ну
Невозможно переиспользовать POJO.
Да и так или иначе мне нужно делать кучу доп. работы, тот же парсинг W3C или исходников Chromium. Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки, который может пропасть с радаров как допилят вебассембли и в браузер полезут все возможные ЯП со своими рантаймами.
>А как предлагается обрабатывать аннотации?
Пока они игнорируются, да и зачем они на фронтенде? Как-то жили без них. Если кому-то уж очень будет нужно можно впилить в виде скрытого поля в ES6 классе.
>О Lombok можно в принципе забыть?
Пожалуйста, серьезно, не используйте Lombok. Я считаю это очень плохая идея.
1. Все пишется на одном ЯП со статической типизацией и качественными IDE
2. Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер название методов из Java в ES6. Т.е. если в джаве map#put, то его нужно конвертнуть в map#set при транспилинге.
По хорошему можно развить идею конвертера и переиспользовать более сложный код, но пока этого нет в ближайших планах.
>Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
Не выйдет и слава богу, я не хочу на лендинге грузить клиенту мегабайты джава библиотек. Для этого придумали GWT.
>В чем смысл такого подхода?
Разрабатывать фронтенд и бекенд полностью на джаве без пересечения джаваскриптом (или с минимальным пересечением).
>DOM-API — вещь стандартная и описаная в документации
1. Я работаю в IDE и мне не удобно держать отдельное окно и искать в нём документацию на метод или поле класса.
2. Ваша ссылка не всегда поспевает за W3C документацией. И тем более отстает от того, что сейчас реализовано в браузерах. Плюс я бы хотел иметь срез фич W3C в виде JAR библиотеки еще не реализованных в браузерах.
> лучше их не использовать в продакшене
Я разрабатываю не только веб-сайты, но и расширения и веб-приложения. В хроме есть набор специфичного API для этих нужд.
— Код сразу транспилится в ES6 классы
— Более проработанная система типов, фактически ручная подготовка классов и методов из ECMAScript Specification
— jSweet умеет только IE API, а точнее то, что там лежит в репозитории тайпскрипта. У меня на данный момент готово Chromium API, на подходе Firefox, ну и IE будет легко спарсить. И опять же, более качественная система типов, без многоэтажных дженериков и any.
— Окончательно хочу полностью распарсить W3C веб-сайт и создавать javadoc на каждый класс и метод.
Это ни во что не превратится, ваш код должен быть таким:
Array<String> items = new Arrays<>("A", "B", "C");
// предположим у нас Java 10 и уже можно _
items.filter((String s, _, _) -> S.includes(s, "B")).
.forEach((String s, _, _) -> console.log(s));
Выглядит это не совсем круто, но мне пока не до красоты. Хотя в этом случае добавить красоты можно переопределив стандартные методы Array из ECMAScript спецификации. Т.е. в джава коде нужно создать новые методы с разными функциональными интерфейсами (на один и два аргумента).
>И таких случаев ещё много.
Такие случаи редки. И для них есть воркараунды при трансляции в ES6. Я не говорил, что на выходе получите 100% как на джаве, но код будет очень похож.
>придётся тащить их имплементацию в рантайм
Используется только то, что может W3C API и ECMAScript Specification. Основная сложность это как быть с битовыми операциями на примитивных типах. Есть конечно идея инлайнить их в WebAssembly или может TypedArray.
>как это делает Kotlin to JS
Собственно, как это делает GWT, такой подход устарел, да и изначально это было глупое решение. Из-за него джава сильно отстала на фронтенде.
Интересно. Особо интересно склеить это с джавой...
Для джавы, опять же, можно существенно ускорить (в разы) некоторые тесты, если дать определенные ключи JVM, про которые могут быть в курсе даже джуны.
Но всё равно полезно посмотреть, что примерно может каждый ЯП.
Очень здорово, посмотрим как будет на практике.
Я сейчас точно не помню, но NotNull по моему у меня обрабатывается на клиенте. Я просто очень долго уже работаю над основной базой и точно не помню деталей реализиации веб-фреймворка. Более того, сейчас нет четких критериев как всё будет выглядеть в итоге.
Валидация происходит на сервер-сайде, т.е. отправляется ajax запрос проверить валидность POJO (текущей веб-формы). На клиенте валидации нет.
Но как я и говорил, когда я всё выложу в opensource и кому-то будут нужны аннотации на клиенте — это не проблема. Может даже к тому времени аннотации можно будет транспилить сразу на клиента с поддержкой во всех браузерах.
Вы опять теряете основной посыл проекта — сделать разработку фронтенда полностью на джаве, не на тайпскрипте, не на кофескрипте, не на *скрипте.
Переиспользование POJO это лишь один из плюсов, который он принесёт.
Код будет писаться на джаве, поддерживаться будет весь синтаксис джавы. Просто что-то может игнорироваться и не транспилиться на фронтенд.
Да, не будет поддержки JDK, но так на фронтенде совсем другое API, нужно изучать его, как изучают Андроид, кому нужно под него делать приложения.
>И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft
Вот не нужно тыкать крупными компаниями, Гугл вон пытался протолкнуть дарт, даже в браузер его впилил, но не полетело.
И тайпскрипт может ждать та же судьба, когда в wasm добавят GC и прочие фичи, когда сюда придут питоны, руби, джава, сишарпы, go и т.д.
Невозможно переиспользовать POJO.
Да и так или иначе мне нужно делать кучу доп. работы, тот же парсинг W3C или исходников Chromium. Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки, который может пропасть с радаров как допилят вебассембли и в браузер полезут все возможные ЯП со своими рантаймами.
>А как предлагается обрабатывать аннотации?
Пока они игнорируются, да и зачем они на фронтенде? Как-то жили без них. Если кому-то уж очень будет нужно можно впилить в виде скрытого поля в ES6 классе.
>О Lombok можно в принципе забыть?
Пожалуйста, серьезно, не используйте Lombok. Я считаю это очень плохая идея.
2. Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер название методов из Java в ES6. Т.е. если в джаве map#put, то его нужно конвертнуть в map#set при транспилинге.
По хорошему можно развить идею конвертера и переиспользовать более сложный код, но пока этого нет в ближайших планах.
>Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
Не выйдет и слава богу, я не хочу на лендинге грузить клиенту мегабайты джава библиотек. Для этого придумали GWT.
>В чем смысл такого подхода?
Разрабатывать фронтенд и бекенд полностью на джаве без пересечения джаваскриптом (или с минимальным пересечением).
1. Я работаю в IDE и мне не удобно держать отдельное окно и искать в нём документацию на метод или поле класса.
2. Ваша ссылка не всегда поспевает за W3C документацией. И тем более отстает от того, что сейчас реализовано в браузерах. Плюс я бы хотел иметь срез фич W3C в виде JAR библиотеки еще не реализованных в браузерах.
> лучше их не использовать в продакшене
Я разрабатываю не только веб-сайты, но и расширения и веб-приложения. В хроме есть набор специфичного API для этих нужд.
— Более проработанная система типов, фактически ручная подготовка классов и методов из ECMAScript Specification
— jSweet умеет только IE API, а точнее то, что там лежит в репозитории тайпскрипта. У меня на данный момент готово Chromium API, на подходе Firefox, ну и IE будет легко спарсить. И опять же, более качественная система типов, без многоэтажных дженериков и any.
— Окончательно хочу полностью распарсить W3C веб-сайт и создавать javadoc на каждый класс и метод.
Выглядит это не совсем круто, но мне пока не до красоты. Хотя в этом случае добавить красоты можно переопределив стандартные методы Array из ECMAScript спецификации. Т.е. в джава коде нужно создать новые методы с разными функциональными интерфейсами (на один и два аргумента).
По итогу будет так:
В ES6 коде будет примерно так:
С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.
>Кстати, справедливости ради, GWT такой же
А в чем преимущества в вашем проекте, если «GWT такой же»?
Такие случаи редки. И для них есть воркараунды при трансляции в ES6. Я не говорил, что на выходе получите 100% как на джаве, но код будет очень похож.
>придётся тащить их имплементацию в рантайм
Используется только то, что может W3C API и ECMAScript Specification. Основная сложность это как быть с битовыми операциями на примитивных типах. Есть конечно идея инлайнить их в WebAssembly или может TypedArray.
>как это делает Kotlin to JS
Собственно, как это делает GWT, такой подход устарел, да и изначально это было глупое решение. Из-за него джава сильно отстала на фронтенде.