Похоже что, что-то недоустановилось капитально, у вас всё в порядке с JDK на компьютере? Мы пока не поддерживаем запуск на JDK 9. Если вы её устанавливали, то она могла остаться дефолтной JRE.
Смотря что реализовывать, мы делаем инструмент для разработчиков, а не чат. Там большая часть памяти уходит на JVM и реализацию функциональности, а Electron тратит всего 70-100 MB памяти, что раз в 5 меньше памяти для основных фич приложения.
Вот это не классно, у вас случаем не JDK 9/10? Если что, заглядывайте к нам на форум: www.cuba-platform.ru/discuss Нам тоже хотелось бы понять в чём дело
Очень странно, что вы не считаете утечкой мозгов работу на иностранного дядю. То что человек присутствует в стране, не значит, что его идеи и возможности здесь. Задница то тут, а мозги там.
Мы сейчас мигрируем всё на Vaadin 8.3. На Vaadin 10 пока не планируем миграцию, но будем на него смотреть. К сожалению, проект Vaadin Flow (10) ещё очень сырой и не покрывает даже 50% возможностей Vaadin Framework (7/8), кроме того, его применение ограничено самыми свежими веб-браузерами. В IE 11 есть проблемы, в Safari тоже.
От фреймворка впечатления позитивные, саппортом давно пользовались, но перестали, поскольку есть своя большая экспертиза, почти 7 лет активной разработки, расширения и сопровождения своего форка Vaadin.
Vaadin как фреймворк для бизнес приложений лучше GWT в плане скорости разработки, сильно быстрее можно делать приложения и достаточно просто интегрировать JS компоненты без специальных языков и компиляции Java в JS. Ну и не нужно с сервера открывать доступ к веб-сервисам, что даёт большую безопасность данных, поскольку в браузер отправляются только данные, видимые на экране.
Мы пользуемся уже более 5 лет. По факту этот багтрекер очень нравится техническим людям в проектах, а руководители и заказчики его не очень любят, он как то больше ориентирован на процесс разработки в отличие от Jira, которая для всего подряд.
В платформе, которую мы разрабатываем, есть похожий механизм с названием Views. Для запросов можно указать дерево требуемых полей и связей (а точнее имя одного из представлений, зарегистрированных на сервере). Front-end разработчики довольны и могут вытаскивать из REST-API данные с нужной детализацией.
К сожалению разобрать байт код нельзя, потому что, чтобы его получить, нужно скомпилировать код. А зависимости мы ищем как раз для того, чтобы этот самый код скомпилировать.
Вы читаете мой комментарий или сразу отвечаете? Я спросил только про Build Tool. SBT один из самых противоречивых инструментов сборки, который даже в родном Scala сообществе воспринимается как нечто не в меру странное. Чуть ли не половина разработчиков на Scala используют не его, а Gradle.
От фреймворка впечатления позитивные, саппортом давно пользовались, но перестали, поскольку есть своя большая экспертиза, почти 7 лет активной разработки, расширения и сопровождения своего форка Vaadin.
Vaadin как фреймворк для бизнес приложений лучше GWT в плане скорости разработки, сильно быстрее можно делать приложения и достаточно просто интегрировать JS компоненты без специальных языков и компиляции Java в JS. Ну и не нужно с сервера открывать доступ к веб-сервисам, что даёт большую безопасность данных, поскольку в браузер отправляются только данные, видимые на экране.
Пример кода:
Пример в доке: https://doc.cuba-platform.com/manual-6.5/rest_api_v2_ex_get_entities_list.html
Так что совсем не обязательно внедрять GraphQL, можно использовать существующие языки, дополнительно лишь описывая требования к глубине детализации.