Comments 155
Эй, читатель! Помоги выбрать веб-фреймворк? Требования: модный, молодежный, популярный, качественный фреймворк, и чтобы им кто-то действительно пользовался в проде
Spring Boot :) Простите.
Так вот. Без знаний Java/spring собрал весьма работающий pet-project REST API с помощью Boot. Всего-то погуглил статьи/доки за несколько вечеров. Итого: security, actuator (вырубил там всё, кроме endpoints/health), data rest. Работает, как часики.
Чего не хватает: той «легкости» работы с зависимостями, которая есть в npm/composer. Конечно, maven/gradle + idea делают своё дело, но порой слишком много времени тратил на поиск нужных «пакетов».
Кроме того вы уж меня простите, а что нужно от фреймворка? Я как то плохо стал понимать смысл этих монструозных махин при условии того что весь бек — rest api.
Мне понравился Spark. Маленький, простенький и все есть)
Нужно взять IDE и посмотреть использование аннотации по коду Спринга.
Зачастую через пару минут становится понятно, что происходит.
Мануалы искать бессмысленно хотя бы потому, что их тупо нет. То что дается в доках по Spring и Hibernate — это некий высокоуровневый Overview с перечислением корневых компонентов. К сожалению.
У Java в этом огромное преимущество перед JS, например. В джаве с помощью IDE можно найти что угодно, прицельно, быстро. В JS нужно делать все то же самое, но приходится целиком читать код библиотек.
Ну и раз уж вы решились ответить: вся эта махина, она зачем?) Какая килер фича вынуждает тащить этого монстра даже в простейшие api?
К сожалению.
Очень жаль, ибо я лично хочу знать как это работает до мельчайший подробностей. Потому как тот ужас с быстродействием который получается у людей меня не устраивает.
А туторы совсем плохи: везде происходит магия которую никто не собирается объяснять
Жека Борисов и его доклад «Спринг-потрошитель» в двух частях доступен на ютубе черт знает сколько уже. Рекомендую!
Всего несколько лет назад гугл выдавал мне чудное количество релевантных ссылок на английском со всем чего я желал по яве. А нынче мало того что поисковики научились подсовывать русские статейки на английский запрос, дак еще и 100500 howto для нубов превращают поиск чего либо в некий адЪ
Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё
А что мешает собрать «вот это все» где-то отдельно, после чего уже полученный итог положить туда, где у вас в проекте статика хранится?
Вот есть у меня сущность — мост между фронтом и сервером. Мне как пользователю (пользователю фреймворка) только один гемор, менеджить отдельно реактовую модель, DTOшки на стороне джавы, и проброс по какому-то протоколу между ними. Это три сущности, каждая из которых ломабельна. Если это будет один монолитный фасад, будет проще всё, начиная с интеграционного тестирования. (Но при этом, конечно, не стоит опускаться до идеи что «вы пишете только на джаве, жс не должен волновать» — потому что жс волновать должен, но по-другому, осмысленно)
Опять же если говорить об nginx, то его конфиг тоже можно сгенерить, например по джавовым аннотациям. И весь nginx тащить с собой в maven. Многие так и делают. А может, попробовать JNI? (не знаю чтобы кто-то так делал, но в чем проблема?) То есть, то, что внутри статику отдает nginx никак не отменяет строгой инкапсуляции этого nginx внутри джавового фреймворка.
Настройки, повторюсь, можно вывести из Java-кода все. Написать вывод настроек из Java-кода — это считаные минуты (либо дни, если хочется качественно). Любой школьник с этим справится, ни о каких нцать лет речи не идет :-)
Низкоуровневые движки уже для всего есть. Сейчас самому измерять лень, поэтому легкий гуглинг нашел как создатель фреймворка Xitrum измерял Netty vs Nginx и получил одинаковую производительность, т.е. производительность была ограничена скорее железом. Прикрутить кэширование опять же можно любое! (Первый результат запроса в гугле по кейвордам "netty file cache")
Ну и да, написание фреймворка занимает год(ы). И что, ничего теперь не писать? Может, вообще с Java предложите сбежать и писать сразу на nodejs? )))
сайтик с фронтом на реакте
JS управлять через Maven.
Если небольшой соло проект или статику зачем-то обязательно надо собирать в war/jar, можно взять webjars. Я пробовал, не всегда в репе есть нужные версии, бывает, что версии debug и prod это разные dependency, добавляешь debug, war становится похож на директорию node_modules. В случае же не маленького веб-проекта и команды, если захочется сделать больно фронтендерам, то webjars это прям годнота, но «моднее, молодёжнее» управлять api на Java через maven/gradle/etc., а react-ом через package.json/bower/grunt/etc. Всё равно это всё собирать в докеры и деплоить отдельно, а не в одном war-e.
Например, пишем мы сайтик с фронтом на реакте. Значит нужно внутрь maven-проекта запихать ноду, вебпак, собрать это всё. А эндпоинты, отдающие статику можно сделать джавовыми, и тогда можно будет управлять модульностью страниц джавовым образом — например, тот же JS управлять через Maven. А если это не просто приложуха, а десктопная софтина с гуем на Electron? Как раз огромный простор для построения велосипедов для интеропа с JS, JS-фреймворками (пробрасывание модели из NoSQL в React), WebComponents, WebAssembly, и так далее
Веб-девелоп в какой-то момент свернул куда-то не туда…
И что, за эту плевую работу еще и деньги получают? )
По вопросу — видимо, автор olegchir рассматривал только те фреймворки, что находятся в вышеупомянутом рейтинге. Насчет Takes — что-то интересное, но лично, например, я ни разу не слышал
Не попал в десятку из ZT Index :)
Ясно. Он достоин отдельного обзора!
У Егора есть своя книжка — Elegant Objects. Я сам не читал, потому что надо её заказывать на Амазоне и ждать до пенсии (месяц?). Но я вживую общался с Егором, он переполнен хорошими идеями, и книжка должна быть стоящая.
Этот фреймворк (takes) судя по всему, написан Егором и единомышленниками. Соответственно, это образец правильного ООП дизайна (насколько такой дизайн вообще можно сделать в Java) и является живым воплощением идей из книжки.
Хотя бы за это стоит этот фреймворк если не использовать, то по крайней мере — ознакомиться с базовыми идеями
Книжку можно купить на территории РФ, Украины, Беларуси и ближайшего зарубежья минуя Амазон. Нужно написать емейл на shop@yegor256.com.
Кстати, что думает о нём Егор Бугаенко?Ничего хорошего, я уверен :D
<p>Hello, {{username}}</p>(выше это не Thymeleaf, я не помню, какой там синтаксис)
Я бы предложил https://github.com/reactor/reactor-netty.
Модно реактивно современно и легко.
и да и нет, сравните зависимости
https://mvnrepository.com/artifact/io.projectreactor.ipc/reactor-netty/0.7.2.RELEASE
https://mvnrepository.com/artifact/org.springframework/spring-webflux/5.0.2.RELEASE
Да эти либы все от одного создателя, pivotal. И вторая использует первую. Но используя reactor-netty необязательно вообще использовать spring, даже как dependency injection.
Spring можно заменить например на https://github.com/SalomonBrys/Kodein + подключить graphql и получить мога модное и современное приложение на сегодня, с минимальными зависимости.
Да, многие из нас работают в банках, и там всё на GWT. Но, оглядываясь назад на этот долгий-долгий путь, давайте честно признаем: управлять JavaScript из Java — наиболее дурацкая и деструктивная идея, которая когда-либо приходила в голову.
В GWT Java не управляет Javascript-ом. Java управляет DOM-ом, точно также как это делает Kotlin.js, Scala.js, TypeScript, Dart и вообще любой кросс-компилятор в JavaScript. Более того, это то, что должно было мейнстримом по причине ущербности JavaScript-а, но внезапно успело подрасти поколение JS-рунов, которым ущербность языка и динамическая типизация стало норм.
Для сложных клиентских приложений использование GWT очень даже оправдано.
GWT-проект очень нетривиально подготовить для воркбенча (вкратце пускайте вручную com.google.gwt.dev.DevMode.main(args)), но работает сносно и инкрементально компилится достаточно быстро.
Ну, тут целой статьи мало будет, если рассматривать все косяки языка и его интергации с браузером. Для меня основным недостатком является динамическая типизация. При нескольких кодерах и растущем функционале код постепенно превращается в натуральное дерьмо, отрефакторить которое будет очень нетривиальной задачей. Как правило количество тупых тестов в JS-проектах зашкаливает, которые тестируют не функционал, а тупо правописание. Для меня основное преимущество статический типизации не в раннем обнаружении ошибок при компиляции, а в поддержке IDE:
- индикация описок, и ошибочных идентификаторов
- подстрочник: подсказки при вызове методов
- элементарный рефакторинг
- простая навигация по коду (своему и библиотечному), позволяющая отследить всю цепочку вызовов
- контрактный стиль программирования
- различные тулзы для статического анализа кода
- умные хинты и варнинги от IDE
- кодогенерация и умные темплейты
Typescript?
Как раз-таки наоборот, это GWT изобретает Java рантайм в браузере на JS. А зачем тащить тяжелый рантайм, когда нужна всего лишь строгая типизация, которая проверяется в compile-time и выкидывается из бандла?
Выходит довольно приемлемо и Hello World занимает столько же, сколько делать его на чистом ES6. Я даже планирую отказаться от JSON и обмениваться сжатыми сериализованными POJO между фронтендом и бекендом.
А можно поподробнее узнать, почему вы решили, что нормально ложится? Например, this.a в JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству. При транспиляции придётся что-то делать с именами, чтобы не пересекались. И таких случаев ещё много.
А ещё у Java и JS разный набор методов в нативных объектов, поэтому по-любому придётся тащить их имплементацию в рантайм, как минимум коллекции, как это делает Kotlin to JS
Такие случаи редки. И для них есть воркараунды при трансляции в ES6. Я не говорил, что на выходе получите 100% как на джаве, но код будет очень похож.
>придётся тащить их имплементацию в рантайм
Используется только то, что может W3C API и ECMAScript Specification. Основная сложность это как быть с битовыми операциями на примитивных типах. Есть конечно идея инлайнить их в WebAssembly или может TypedArray.
>как это делает Kotlin to JS
Собственно, как это делает GWT, такой подход устарел, да и изначально это было глупое решение. Из-за него джава сильно отстала на фронтенде.
Возьмем такой фрагмент Java-кода:
List<String> items = new ArrayList<>();
items.add("A");
items.add("B");
items.add("C");
items.stream()
.filter(s->s.contains("B"))
.forEach(System.out::println);В какой JS это превратится? Особенно интересно что станет со stream().
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 спецификации. Т.е. в джава коде нужно создать новые методы с разными функциональными интерфейсами (на один и два аргумента).
По итогу будет так:
Array<String> items = new Arrays<>("A", "B", "C");
items.filter((String s) -> S.includes(s, "B")).
.forEach(console::log);
В ES6 коде будет примерно так:
let items = new Array("A", "B", "C");
items.filter((s) => s.includes("B")).
.forEach((s) => console.log(s));
А чем это отличается от jSweet?
— Более проработанная система типов, фактически ручная подготовка классов и методов из ECMAScript Specification
— jSweet умеет только IE API, а точнее то, что там лежит в репозитории тайпскрипта. У меня на данный момент готово Chromium API, на подходе Firefox, ну и IE будет легко спарсить. И опять же, более качественная система типов, без многоэтажных дженериков и any.
— Окончательно хочу полностью распарсить W3C веб-сайт и создавать javadoc на каждый класс и метод.
О каких API вы говорите? DOM-API — вещь стандартная и описаная в документации.
Если какие-то отдельные браузеры поддерживают дополнительные методы, лучше их не использовать в продакшене, потому что их могут внезапно задепрекейтить и выпилить.
1. Я работаю в IDE и мне не удобно держать отдельное окно и искать в нём документацию на метод или поле класса.
2. Ваша ссылка не всегда поспевает за W3C документацией. И тем более отстает от того, что сейчас реализовано в браузерах. Плюс я бы хотел иметь срез фич W3C в виде JAR библиотеки еще не реализованных в браузерах.
> лучше их не использовать в продакшене
Я разрабатываю не только веб-сайты, но и расширения и веб-приложения. В хроме есть набор специфичного API для этих нужд.
То есть код написанный в таком стиле нельзя будет запустить в JVM на бекенде? Тогда теряется основное преимущество написания кода не на JS — возможность переиспользовать серверный код на клиенте.
Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
В чем смысл такого подхода?
2. Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер название методов из Java в ES6. Т.е. если в джаве map#put, то его нужно конвертнуть в map#set при транспилинге.
По хорошему можно развить идею конвертера и переиспользовать более сложный код, но пока этого нет в ближайших планах.
>Кроме того, ни Guice, ни Guava, ни другие полезные Java-библиотеки в коде использовать не выйдет.
Не выйдет и слава богу, я не хочу на лендинге грузить клиенту мегабайты джава библиотек. Для этого придумали GWT.
>В чем смысл такого подхода?
Разрабатывать фронтенд и бекенд полностью на джаве без пересечения джаваскриптом (или с минимальным пересечением).
1.Все пишется на одном ЯП со статической типизацией и качественными IDE
Typescript же, ну. Уже обсудили, что ни типизация, ни удобство IDE не являются эксклюзивом для Java.
2.Вы сможете переиспользовать POJO, с возможностью объявлять поля типа List, Set, Map или любым другим типом для которого напишете специальный конвертер
А как предлагается обрабатывать аннотации? О Lombok можно в принципе забыть?
Невозможно переиспользовать POJO.
Да и так или иначе мне нужно делать кучу доп. работы, тот же парсинг W3C или исходников Chromium. Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки, который может пропасть с радаров как допилят вебассембли и в браузер полезут все возможные ЯП со своими рантаймами.
>А как предлагается обрабатывать аннотации?
Пока они игнорируются, да и зачем они на фронтенде? Как-то жили без них. Если кому-то уж очень будет нужно можно впилить в виде скрытого поля в ES6 классе.
>О Lombok можно в принципе забыть?
Пожалуйста, серьезно, не используйте Lombok. Я считаю это очень плохая идея.
Лучше я сделаю это для ЯП, который имеет прошлое и будущее, чем для непонятного однодневки
На самом деле код будет писаться не на Java, а на каком-то усеченном диалекте, который понимается транслятором.
И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft
Код будет писаться на джаве, поддерживаться будет весь синтаксис джавы. Просто что-то может игнорироваться и не транспилиться на фронтенд.
Да, не будет поддержки JDK, но так на фронтенде совсем другое API, нужно изучать его, как изучают Андроид, кому нужно под него делать приложения.
>И однодневкой здесь является именно ваш транслятор, а не Typescript, уже несколько лет разрабатываемый такой крупной компанией, как Microsoft
Вот не нужно тыкать крупными компаниями, Гугл вон пытался протолкнуть дарт, даже в браузер его впилил, но не полетело.
И тайпскрипт может ждать та же судьба, когда в wasm добавят GC и прочие фичи, когда сюда придут питоны, руби, джава, сишарпы, go и т.д.
Пока они игнорируются, да и зачем они на фронтенде?
В аннотациях хранятся правила валидации. Будет полезно, чтобы @NotNull, например, работал и на клиенте.
P.S. для переиспользования моделей с север-сайда я бы не изголялся с компиляторами и трансляторами, а описал бы схему в XSD/JSON Schema, чтобы клиент-сайд генерировал себе классы и интерфейсы на любом удобном языке.
Вы опять теряете основной посыл проекта — сделать разработку фронтенда полностью на джаве, не на тайпскрипте, не на кофескрипте, не на *скрипте.
Переиспользование POJO это лишь один из плюсов, который он принесёт.
А про аннотации что скажете? Как переиспользовать правила валидации?
Валидация происходит на сервер-сайде, т.е. отправляется ajax запрос проверить валидность POJO (текущей веб-формы). На клиенте валидации нет.
Но как я и говорил, когда я всё выложу в opensource и кому-то будут нужны аннотации на клиенте — это не проблема. Может даже к тому времени аннотации можно будет транспилить сразу на клиента с поддержкой во всех браузерах.
Я сейчас точно не помню, но NotNull по моему у меня обрабатывается на клиенте. Я просто очень долго уже работаю над основной базой и точно не помню деталей реализиации веб-фреймворка. Более того, сейчас нет четких критериев как всё будет выглядеть в итоге.
Typescript даже близко по статике не стоял со статичной жабой.
Ломбок — это очень плохая идея.
То что декораторы в Javascript начинаются с @ не делает их аннотациями.
Они в принципе работают по-другому, больше похожи на декораторы в Питоне (отсюда и название). Декораторы вызываются при инициализации объекта и позволяют переопределить поведение метода или целого класса. Никаких getElementsAnnotatedWith и myClass.getAnnotations() здесь нет.
так напиши сам! Делаешь декоратор, сигнатура — как у Object.defineProperty, дефайнишь проперти отдельно. Лукап по пропертям делаешь отдельно. Понимаешь на что намекаю? Точно то же самое в питоне.
с классами то же самое, только получается фабрика. По сути это то же самое, что в спринге, только более убогое (меньше свободы метапрограммирования). А как ты уже на практике знаешь, в спринге через биндефинишенфактори, итп можно сделать любую супермагию, и уж точно можно сделать аннотации (лучше чем джавовые аннотации). Куда ткнуть хз, глянь «spring потрошитель», и видосы с Барухом, когда они spring-context поднимали не из xml или аннотаций, а из ini-файла
так напиши сам! Делаешь декоратор, сигнатура ...
Я понимаю, что все мы здесь программисты и сможем решить поставленную задачу. Только вот декораторы здесь вам не помогают. Метод getAnnotations может с тем же успехом использовать JSDoc комментарии, имя функции или имена аргументов, чтобы достать необходимую мета-информацию. Декораторы в виде фичи языка здесь не помогают никак. reflect-metadata proposal может помочь, а декораторы в их текущем состоянии — нет.
По сути это то же самое, что в спринге, только более убогое
То, что у декораторов другая механика не делает их лучше или хуже. Они другие. С ними сложее заниматься метапрограммированием, зато легче обернуть (e.g. задекорировать) метод или класс. Как в Java заимплементировать @Memoized, @Readonly или @Time через аннотации?
По аннотации генерим прокси-класс, который будет всё это декорировать. При этом, от одной аннотации можно генерить совершенно разные прокси, в зависимости от параметров аннотации или контекста выполнения, например. Это как декораторы, только лучше, потому что из за тебя пишет компилятор.
Так работает Spring из коробки. Нужно гуглить BeanPostProcessor, BeanFactoryPostProcessor, BeanDefinitionRegistryPostProcessor, и другие соответствующие классы. Любой пользователь Spring это знает.
Хорошо рассказывает Женя Борисов на докладах на Joker/JPoint/JBreak в докладах типа «spring-потрошитель»: www.youtube.com/watch?v=BmBr5diz8WA
> Метод getAnnotations может с тем же успехом использовать JSDoc комментарии
Нельзя, потому что это ударит по перфомансу. В PHP вот это сделали, в мои времена это был такой перфоманс хит, что пользоваться было невозможно (может быть, сейчас починили?). В мои времена, создатели ORM Doctrine по этому поводу пилили пулл-риквест с нативной поддержкой аннотаций, но пыхеры отклонили.
А в жабе — язык достаточно статический, поэтому информация о типах используется для ускорения кода на всех этапах. Например, в жабе используется такая штука как верификатор байткода, поэтому сразу после верификации (после загрузки класса) мы можем выбросить все проверки на соответствия типов, а js будет проверять их вечно. Даже если этот js запустят под JVM на GraalVM — проверки всё равно никуда не денутся (но будут не строить граф заново, а деоптимизироваться в случае изменения типа).
Если мы реализуем Java поверх JS, надо понимать, что от аннотаций потребуется максимальный перфоманс. Если можно как-то заюзать для этого нативные возможности V8/Servo, обязательно нужно это сделать.
Если мы реализуем Java поверх JS, надо понимать, что от аннотаций потребуется максимальный перфоманс. Если можно как-то заюзать для этого нативные возможности V8/Servo, обязательно нужно это сделать.
Вот только максимальный перфоманс будет совсем не при эмуляции аннотаций через декораторы (а в ESNext декораторы сделаны крайне неудобно для этой задачи). Чтобы получить максимальный перфоманс — надо просто записать всю дополнительную метаинформацию в статическое поле в виде литерала объекта. Что может быть быстрее чтения константы?
По аннотации генерим прокси-класс, который будет всё это декорировать. При этом, от одной аннотации можно генерить совершенно разные прокси, в зависимости от параметров аннотации или контекста выполнения, например.
То есть нужно либо самому генерировать прокси-класс (в байт-коде!), либо поручить это дело библиотеке (которая будет сама генерировать прокси класс в байт-коде). Или же использовать Proxy, устроив тем самым своему коду проседание производительности.
Декораторы же умеют делать это все из коробки.
Это как декораторы, только лучше, потому что из за тебя пишет компилятор.
Вот тут вообще не понял. Допустим, у меня нет библиотеки которая реализует @Memoized. Чем именно компилятор мне поможет в этой ситуации?
Например, this.a в JS сможет обратиться к супер-классу, а в Java только к своему собственному свойству.Это как? (при условии, что поле a не приватное)
// A.java
class A {
public String property = "A";
String getParentProp() {
return property;
}
}
// B.java
class B extends A {
public String property = "B";
String getChildProp() {
return property;
}
}
//где-то в коде...
B b = new B();
System.out.println(b.getParentProp()); // A
System.out.println(b.getChildProp()); // Bclass A {
property = "A";
getParentProp() {
return this.property;
}
}
class B extends A {
property = "B";
getChildProp() {
return this.property;
}
}
const b = new B();
console.log(b.getParentProp()); // B
console.log(b.getChildProp()); // BGWT абсолютно ничего не имеет общего с Java-рантаймом. Это распространенное ошибочное мнение. У него есть определенная Runtime Library Emulation, чтобы можно было работать с коллекциями, строками, стримами, лямдами, etc как в Java. Но в рантайме GWT не таскает с собой вообще никакие библиотеки. Вместо этого он анализирует весь код приложения начиная от EntryPoint, включая только те функции из всей кодовой базы, которые используются въявную (а для 100% явности была выпилена reflection). Остальной шлак жестко шринкается. Дополнительными бонусом идет минимизация и обфускация. В итоге для функционального приложения код получается меньше, чем на нативном JS, т.к. последний грузит все используемые JS-библиотеки полностью со всем функционалом. Кстати, GWT поддерживает SourceMaps при запуске в DevMode, поэтому можно дебажить вживую в Chrome или Firefox, а в SourceMaps показывается только Java-код, который GWT оставил после шринкинга, т.е. то, что реально будет в рантайме.
Насколько GWT-код может быть минимальным полностью зависит от того, что вы будете использовать. Откажитесь от стандартных GWT-виджетов и UiBinding, используйте библиотеку Elemental, и Overlay Types. Для манипуляции с DOM-ом для GWT есть аналог JQuery — GwtQuery.
Достаточно написать в своем приложении myList.addAll(items) и вы уже получите немалую часть java.util.* По сравнению с ванильным JS myArray.concat(items) вы получаете значительный оверхед.
Сравнивать этот оверхед с весом какого-нибудь реакта не буду, просто заметил, что от простого использования Java вместо Typescript вы уже получите рантайм-нагрузку.
Впрочем, если даже запилят такой рантайм и он будет занимать скажем 50 Кб (очень сомневаюсь), то всё равно остается вопрос портирования W3C API классов и методов в виде JAR библиотеки и Javadoc. А мой фреймворк решает эту задачу. Мне по сути нужно будет выкинуть только часть отвечающую за транспилинг джавы в es6. А всё остальное будет по прежнему актуально. Хотя будет обидно, что я потратил полгода на реализацию такого транспилинга )
Сейчас на васме толком не запилить джавы, можно конечно, но получится страшный монстр с загрузкой на клиента нескольких мегабайт кода. А когда подойдет wasm 2.0 не известно, можете еще лет 5 ждать.
Опять же, мой проект уже поддерживает WebAssembly (частично). Есть демка. И полноценное openjdk очень долго качать, даже очень сильно порезанное — всё равно несколько мегабайт. В TeaVM это решается достаточно умным dead code elimination, который умудряется для hello world оставить примерно 60кб от всего JDK. Правда, достигается это путём отказа от reflection (и запиливания своей альтернативы, которая хорошо дружит с DCE).
Затащить JDK таким обhазом можно и в JS, причём WebAssembly пока непонятно какие преимущества даёт в этом плане. Там ни GC нет (пришлось свой написать), ни человеческого интеропа с DOM, а в плане размера бинарника и скорости WebAssembly совсем пока не радует.
А сама TeaVM входит в эти 60кб или загружает свои мегабайты отдельно?
Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?
Затем, что в итоге получается более выразительный язык чем джава.
Typescript наверное хорош как замена JS, но зачем изобретать джаву заново?
- для нормального взаимодействия с JS библиотеками
- для нормально совместимой с JS системой типов, поддерживающей вывод типов
- для поддержки уже написанного кода
- для легкого поиска новых разработчиков и быстрого переучивания имеющихся
- для того чтобы можно было писать хотя бы так github.com/tastejs/todomvc/blob/gh-pages/examples/typescript-react/js/todoItem.tsx, а не так github.com/tastejs/todomvc/blob/gh-pages/examples/gwt/src/com/todo/client/ToDoCell.java
Видите, сколько причин? Выберете сами, какая вам больше нравится.
И да, ни одну из причин вы своим wasm не отменили.
И вообще, ЯП — это мелочь, по сравнению со знаниями фреймворков. Akka Java vs Spring — это 2 разных мира, со своими подходами и принципами. ЯП уже не играет особой роли.
-
На текущий момент TypeScript решает все перечисленное (ну понятно, что по библиотекам легко не походишь они же на JS), придется конечно поработать со сборкой всего этого и с npm и прочим, но это в разы лучше чем то, что получается когда несколько человек правят JS даже в рамках одной страницы.
Для них — вполне вероятно.
А вот для публичных веб-сайтов с кастомным дизайном ИМХО GWT еще какое зло.
Кстати, раз уж речь зашла о GWT, то хочу напомнить, что в качестве альтернативы есть ещё и мой проект. Там и вкусненький фреймворк есть, напоминающий Angular, и проблем с подготовкой воркбенча меньше.
Это изначально неверный посыл. Тот кто занимается фронтендом обязан знать HTML, CSS, SVG, JavaScript и весь прочий W3C API. Но не обязан программировать его на JavaScript. В этом плане Typescript интересно придумали. Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK.
Я думаю джава должна последовать примеру тайпскрипта, без загрузки на клиента мегабайтов JDK
TeaVM как раз и ставит задачу: сделать Java на клиенте достаточно лёгкой, чтобы не тащить за собой мегабайты JDK (как это делает, скажем, какой-нибудь CheerpJ). Hello World на чистом DOM сейчас занимает порядка 30 кб (на System.out чуть побольше, ибо надо тащить кусок java.io). Это, конечно, не сотня байт, как в случае ES или TS, но уже и не пара мегабайт. Скажем, какой-нибудь TodoMVC занимает всего 125 кб, сравните с TS + Angular 4. Кстати, справедливости ради, GWT такой же: если отказаться от его (весьма ущербной) библиотеки виджетов и писать на чистом JSInterop, то результирующий JavaScript очень радует своими размерами.
С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.
>Кстати, справедливости ради, GWT такой же
А в чем преимущества в вашем проекте, если «GWT такой же»?
С этим нет смысла сравнивать, пока вы не скажите какой фреймворк был использован в вашем TodoMVC.
Самописный, идеологически напоминающий Angular. Посмотрите сайт проекта, там про всё это написано
А в чем преимущества в вашем проекте, если «GWT такой же»?
А в том, что в отличие от GWT можно писать на Java, Kotlin и Scala. А ещё есть несколько приятных фишек, отсутствующих в GWT (например, эмуляция тредов на корутинах). Ну и собственно, упомянутый фреймворк, которого для GWT нет.
А есть у тебя какие-нибудь дополнительные документы, кроме короткой документации на глагне? Про внутреннюю архитектуру и решения.
Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)
Чувак, так это твой проект? Дай пожму тебе обе ноги. Это волшебно.
Спасибо
А есть у тебя какие-нибудь дополнительные документы, кроме короткой документации на глагне? Про внутреннюю архитектуру и решения.
На глагне вверху есть ссылочка на раздел Docs, там много всего. Можно и больше, но для этого мне нужно понимать, какие вопросы возникают у людей.
Про внутреннюю архитектуру есть совсем немного на wiki в github. Там проще не статьи писать, а сразу послать читать Мучника + дать ссылок на несколько имеющихся статей по оптимизациям на SSA.
Олсо, можно забуриться внутрь и написать по этому проекту еще один пост на Хабр? Третий :)
Можно, но я не буду этого делать. Раздел "Я пиарюсь" мало кто читает, а правила Хабра запрещают где-либо ещё публиковать статьи. Я хотел написать статью про то, как я делал online TeaVM (который на самом деле является просто javac, скомпиленным в JS), но буду публиковать на англоязычных платформах, скорее всего.
Для сложных клиентских приложений использование GWT очень даже оправдано.GWT — это COBOL начала 21 века для веба. (С)
Эй, читатель! Помоги выбрать веб-фреймворк
В зависимости от того что вам нужно/чего достаточно. Если PHP-style request->db->response и пользователей будет 2k-потолок то и Spring Boot хватит с головой.
Если данные либо имеют потоковую природу или request->response, но уже с болше чем 2k планируемых пользователей то Play! По его API — там сейчас новые фичи (некоторые) пилятся сначала на Java, а уже потом портируются в Scala. Для остальных есть правило: вы не можете отправить пулл с фичёй в Play только для одного из API — вам нужно будет давать поддержку вашей фичи как для Java так и дл Scala. Лично я не понимаю зачем это правило ввели — всегда отличто пользовался Java кодом из Scala и Scala кодом из Java.
Детальнее можно почитать тут. Оно то рекламный whitepaper, но там описаны как сильные так и слабые стороны и почему надо и когда не надо.
Если к спрингу прикипели, а более 2k всё равно надо — то Netty и Spring Boot Webflux поверх. Только не сервлет 3.0. Почему — всё в том же whitepaper.
Фреймворков нет. Есть tapestry5, но он как всегда отстаёт на 5 лет от того, что нужно разработчикам сейчас на фронтенде.
Поэтому я пилю новый фреймворк для разработки современного фронтенда на джаве. В том числе и веб-приложений с портированием на андроид. У меня в этой теме лет 10 опыта с отслеживанием трендов, так что не очередной реактивный MVC фреймворк с гитхаба.
Проблема лишь в том, что не всегда удается выделять время. Из-за чего все очень медленно развивается.
Готовы ли вы вложить собственные деньги, если скажем я все подробно распишу и запущу краудфандинг компанию на кикстартаре? Сколько бы вы вложились — $100, $1000, или вложились бы в крипте более существенные средства?
Если (когда) ты захочешь написать сиквел про хорошие фреймворки, не забудь посмотреть на ratpack.
Full stack development скорее мертв, чем жив. Технологии шагнули далеко вперёд. React + REST по удобству и скорости работы на порядок превосходит все эти Java web фреймворки.
Дело то в том, что frontend технологии развивают все подряд, а Java web фреймворки — только java сообщество.
Есть подозрение, что у значительной части Java-сообщества есть мечта: свалить с Java на что угодно другое.
Человек сначала ставит перед собой задачу: свалить из Java, и потом уже придумывает список аргументов.
Аргументы в таком варианте нужны не чтобы что-то аргументировать, а чтобы выглядеть социально-одобряемым способом. Хейтить Java на работе Java-программистом, или хотя бы даже в блоге Java на Хабре — это не социально-одобряемая активность. Но вот если сформулировать это как-то другими словами, уже может проканать :)
А дело в том, что Java изначально семантически очень плохо приспособлена для декларативных конструкций и DSL-ей. Фреймворки, построенные на аннотациях — это некий компромисс между декларацией и исполнением, причем очень фиговый по сравнению с тем же DSL. В бекенде еще как-то прокатывает, но во фронтенде, где приходится создавать иерархические конструкции (напр. DOM), в императивном стиле на Java это превращает код в линейную кашу. Поэтому на Java никогда не было и не будет нормальных html-темплейтеров, тем более type-safe как на скале или котлине. Хотя попытки есть: https://j2html.com/
Согласен. Но на самом деле, даже в Wicket можно открыть несколько вкладок. Например, можно на каждый таб начинать новую сессию, но при этом сделать signle sign on для всех этих сессий. Или перехватить AjaxNewWindowNotifyingBehavior и сделать setResponsePage(getPage().getClass()). Другое дело, что создатели фреймворка подумали об этом в последнюю очередь, и при попытке применить это в хайлоаде, результат скорей всего опечалит (даже не дебажная версия страницы как нефиг делать может внезапно вырасти до нескольких мегабайтов). А еще, мало кто смотрел как работает фреймворк, и не в курсе о значительной части "возможностей, о которых подумали в последнюю очередь" — а ведь никто о них не скажет.
Разработка тяжеловесных компонентов — сложная вещь, и если это сделано на отлично в Spring, какой смысл изобретать велосипед и использовать что-то еще? Тем более уже понятно, что не разработаешь ты что-то лучше, тупо времени не хватит.
2) Ну возьмешь ты какой-то левый Java Web-framework, ну начнешь ты нам нем что-то писать. Где по итогу ты возьмешь людей на проект? И так людей компетентных сложно найти, а если искать на какой-то непопулярный фрейм, то забей сразу.
3) Смешивать front и back в коде — это мужеложство. Если очевидно, что потребуется что-то сложнее, чем пропихнуть переменные через шаблонизатор в html, то надо разделять front и back и пихать все через Rest.
Отсюда все Java фреймворки, которые пытаются дать генерацию фронта через бек — это убожество, которое дает результат уровня 2010 года.
4) Я понимаю, что у многих мужиков появляются желания сменить своего партнера и попробовать что-то новое, неизведанное, запретное, но зачем такой подход тащить в разработку? К чему такое яростное желание уйти от Spring?
Он решает задачи и делает это хорошо. Он идеально подходит для современного веба, если его завязывать исключительно на бек. Он стабилен и надежен. Вон те же .net-разработчики сидят на одной платформе и не парятся, даже везде кричат, что .net — это легкий выбор стека, а java — это пьяная драка в коммуналке.
я буду искать не senior framework coder, а senior software engineer. То есть человека, который программирует на идеях, а не на конкретных реализациях. Тогда конкретную реализацию можно будет выбирать в зависимости от ситуации. А ситуации бывают разные (иначе всех программистов можно было бы автоматизировать по-Грефовски)
-
github.com/mraible/history-of-web-frameworks-timeline
Каждый наверное спрашивал себя, почему у них на руби/пхп/шарпе все так легко? Там уже все сделали, а вы еще настраиваете проект и конфигурируете самолет? (Или поддерживаете что-то на тапестри 4.2)
Даже если взять для примера Core.Net (а можно рельсы там или еще что), то в нем уже практически все готово для веб и на блюдечке, садись пиши страницы, рест апи, сервисы, что хочешь, даже в той же самой идее, которая Rider.
Перечисляешь модули, какие тебе надо, на выходе — работающий проект
Даже для Викета такая страница где-то там на их сайте есть
Рельсы имхо плавно умирающая технология
Работающий проект — это мягко говоря не совсем так.
Чтобы ощутить разницу, можно попробовать накидать в этом конструкторе работающий рест сервис с поддержкой JWT токенов или например добавить SSO Keycloak через SAML протокол в проект с серверным рендерингом. Если не помогло — заменить контейнер со спринга на джус, шучу, но в коре так можно, он не завязан на конкретный контейнер.
Если из этого конфигуратора вырезать то, что покрывает EntityFramework, Razor, WebApi и несколько других пакетов (предельно (!) простых в установке и настройке), то выбирать будет практически нечего, а это значит что все работают со стандартными инструментами, компонентами, апи и так далее.
Да, в конце результат будет похожий, но затраты времени сильно отличаются.
А вообще надеюсь в net.core, ибо на .net писать веб-сервисы приятней, чем на Java, но из-за отставания эко-системы и лока на Windows — сфера разработки крайне ограничена.
Jooby из коробки имеет достаточно большое количество модулей (для работы с различными БД, pac4j, оптимизация статики и многое другое), которые помогают быстро создать проект (как REST так и рендерить html). Что не мало важно — данный проект имеет хорошую документацию.
А так же стоить упомянуть что в качестве embedded веб сервера можно выбрать netty/undertow/jetty и с удобной системой конфигов это все легко настроить.
Как итог приложение упаковывается в fatJar. Так что если нужен веб на java — люто советую использовать Jooby (ну или как упоминали SparkJava/Spring Webflux).
Если говорить про фреймворк на бекенде. А чем vert.x не угодил? В отличии от Spring Boot 1.x он не такой тяжёлый. Стартует гораздо быстрее. Есть интеграция со множеством middleware, БД, внешними сервисами. Шустрый (используется неблокирующая и асинхронная Netty
под капотом), реактивный. Не всем это правда нужно. Больше подходит для высоконагруженных микросервисов. Отсюда и не популярный.
Блеск и нищета джавовых веб-фреймворков