Pull to refresh

Comments 25

На мой взгляд — идеологически они сильно похожи. На micronaut я не писал сколько-нибудь масштабный и сложных проектов, поэтому мне сложно сейчас сложно рассуждать о плюсах и минусах этих фреймворков. Явное отличие — в Quarkus нет Application.java :-)
UFO just landed and posted this here
Конечно, сложно предугадать, выстрелит фреймворк или нет. Много факторов: привычность/удобство использования, стабильность, поддержка, скорость развития, количество интеграций, сообщество. Посмотрим, что получится с Quarkus. Что меня привлекает — они полагаются на существующие фреймворки, просто убирают boilerplate. А так, если до этого вы использовали Hibernate/JAX-RS/CDI, то переезд на quarkus не должен занять много времени.
Пока нет. Слишком много неопределенности, чтобы этот фреймворк тащить в платформу.

Что меня больше всего настораживает во всех этих катапульт-фреймфорках — это то, что потом любое изменение "не по плану" всегда оборачивается жуткой головной болью. И в что мы экономим? Лишних полчаса, чтобы собрать проект из явных зависимостей?

Spring Boot — это катапульт-фреймворк? Он тоже позволяет быстро клепать приложения для backend и не прописывать явные зависимости. Однако, в его случае, похоже, польза от применения перевешивает жуткость головной боли. Судя по всему, quarkus, да и micronaut идут по тому же пути, как spring boot. На мой взгляд, они довольно расширяемы, и, как мне кажется, в 90% случаев их стандартной функциональности достаточно для разработки разных видов приложений (у Quarkus, конечно, меньше всяких расширений сейчас). А экономим мы усилия по написанию всякого сервисного кода и сдруживанию разных зависимостей, которые не всегда можно быстро сдружить.
В отличии от других фреймворков, к Spring доверия больше. Т.к. он доказал, что гибкий и умеет приспосабливаться к современным трендам.
Расплата же конечно, в его «тяжеловестности».

Spring Boot — это самая настоящая катапульта. Она позволяет быстро написать приложение "Хелло ворлд" с кучей подключенных технологий, абсолютно не задумываясь о том, как это все работает. Реализация какой-то специфической задачи, не входящей в стандартный стек решений, уже не так тривиальна: требуется вдумчиво читать документацию, зазубривать конвеншны и @Заклинания, смотреть в кинотеатре сагу от Евгения Борисова и сильно уметь копаться в коде спринга. И все это в том случае, если программа более-менее написана грамотно.


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

Зачастую это кажущаяся экономия. Катапульты пытаются охватить сразу весь типовой стек решений (config + IoC + rest + database + integration + etc...). Однако интегрировать новую зависимость во фреймворк бывает на порядок сложнее, нежели в кастомном коде. А зачастую головную боль создают ограничения фреймворка, которые приходится грязно обходить. В особенности, когда не знаешь как оно внутри там вертится...

Как раз Spring framework по минимум мешает делать «свой велосипед».
Из всех @Заклинаний, можно знать только @SpringBootApplication, @Configuration и Bean. А дальше можно писать свои «велосипеды» как хочешь.
Не, ну можно выучить все @Заклинания, но это если нравиться «магия», когда произнеся «заклинание» делаешь пол проекта :-)
Странная статья. Я так понял, основная фича Quarkus — поддержка GraalVM, но на эту тему нет ни одного примера. Из того, что приведено, не вижу преимуществ по сравнению с тем же Spring Boot. Там сейчас есть все тоже самое: Spring Data, асинхронность, netty, docker, поддержка Котлина и т.д.
Просто hibernate единственная «нормальная» имплементация JPA.
С этим не спорю, но запросы генерит часто тяжелые и много лишних.
Сайт случайно не на фреймворке сделан? А то там при нажатии на ссылку 5 секунд задержка до отображения.
Зачем он нужен?
Пользуюсь чистым Vert.x, никаких проблем не испытываю.
Значит, Vert.x отлично ложится на привычные абстракции, который есть у вас в голове :-) Но есть же люди, которые думают не совсем так, как вы, а как разработчики Quarkus. И им, может быть, невыносимо неудобно пользоваться vert.x, а quarkus зайдет отлично :-)

Кому-то нравится писать hello world так:
public class Server extends AbstractVerticle {
  public void start() {
    vertx.createHttpServer().requestHandler(req -> {
      req.response()
        .putHeader("content-type", "text/plain")
        .end("Hello from Vert.x!");
    }).listen(8080);
  }

а кому-то — так:
@Path("/hello")
public class GreetingResource {

   @GET
   @Produces(MediaType.TEXT_PLAIN)
   public String hello() {
       return "hello from quarkus";
   }
}

Вопрос даже не в этом.
Понятно, что Springовый подход к разработке сильно проник в головы.
Непонятно, зачем тянуть 100500 тяжеленных зависимостей, чтобы отображать в браузере текст?
100500 тяжеленных зависимостей
обычно тянут не чтобы показать 2 строчи текста в браузере, а чтобы 100ГБ исходных данных превратить в 2 строчки осмысленного текста.
Sign up to leave a comment.