jershell

1. Перевести проект на gradle. Для этого сначала ставим этот самый градл, потом создаем папку, переходим туда в консоли и пишем
gradle init
Будет что-то такое.

Starting a Gradle Daemon (subsequent builds will be faster)

Select type of project to generate:
  1: basic
  2: application
  3: library
  4: Gradle plugin
Enter selection (default: basic) [1..4] 2

Select implementation language:
  1: C++
  2: Groovy
  3: Java
  4: Kotlin
  5: Swift
Enter selection (default: Java) [1..5] 4

Select build script DSL:
  1: Groovy
  2: Kotlin
Enter selection (default: Kotlin) [1..2] 2

Project name (default: rm_me): moy_proekt

Это сгенерирует дефолтный проект gradle для kotlin

2. Далее мы можем подключать любые зависимости, какие захотим. Для этого в сгенерированном проекте открываем файл build.gradle.kts и в секцию dependencies добавляем

dependencies {
  implementation("io.ktor:ktor-server-netty:1.3.2")
}

тут более подробно, но используется gradle синтаксис, а не kts
https://ktor.io/quickstart/quickstart/gradle.html

и почти всё тоже самое, но чуть чуть подробнее тут https://github.com/jershell/kotlin_slow_start
В общем сама цель перевести сначала проект на gradle, поскольку у котлина зависимости почти все через него и подключаются.

В интернете гуляет слух, что Wayland + Plasma ужасно работают на видеокартах Nvidia.

Не гуляет, а так и есть. Мы говорим про Wayland, следовательно он работает c драйвером через буферный API. Их несколько, от Intel & amd - GBM, а от nvidia EGLStreams. Nvidia отказалась от поддержки GBM, сославшись...это долгая история длится вот уже 3-й год. В общем, что сейчас мы делаем на лине, покупаем карты AMD и не знаем проблем. Драйвер открытый и отлично интегрирован в системы (ubuntu/manjaro, про отстальные не знаю)
Или не трогаем wayland и ждем когда композиторы научатся работать с EGLStreams(kde вот научилась) или когда б***ская nvidia поддержит GBM(никогда).

Большинство примеров в интернете образуют связку WebSocket+Ajax,

Первая причина. Чаще всего уже есть сервер, который имеет какой-то rest api и тут приходит необходимость в нотификациях или что-то подобное, вот и прикручивают ws справа.

Вторая. Вебсокет немного сложнее чем http. Надо учитывать, как шарить вызовы между инстансами сервера, ведь вебсокет может жить очень долго, в отличии от http, который выполняется не больше минуты. А так же учитывать блокировку, если какой-то метод залочит поток в котором обрабатываеся вызов, то будет большая беда. Поэтому вызовы при обработке должны быть неблокирующими(suspend, async, etc) или выполнять каждое действие в отдельном потоке, но тут потоков не хватит, да и дорого потоки плодить. В общем зависит от среды выполнения.

Третья. Формат сообщения. В вебсокете не предусмотрен какой-то один формат сообщения, каждый должен выбрать его сам. Это или json-rpc или grpc или graphql или что-то подобное, что явно говорит, что ваш вызов №X завершился с результатом Y. В противовес http, который имеет параметры и какой-то ответ на эти праметры. Один, всегда.

Четвертое. сопутствующие проблемы инфраструктуры. Часто используется nginx, и в проде вы подключаетесь не к своему(им) http серверу, а к nginx, который и держит соединение. Если отваливается одна из сторон, то вторая об этом никак не узнает сразу(а иногда и вовсе) Это решается настройкой nginx, требует знаний, в противовес http, где по умолчанию настройки минимальны. Отсюда проблема пингов и понгов, они есть в протоколе, но ими невозможно управлять из браузера. Люди просят API чтоб можно было хоть как-то обработать или pong или отправить ping, но увы и ах, этого нет. Поэтому появляются такие реализации как socket.io где ребята запихали свои самописные пинги.

Как я уже сказал, ws сложнее чем http, но не столь критично, некоторые сложности опустил в виду того, что они зависят уже от инструментов реализации, ну или просто забыл. Ну и на ваш вопрос мало ответов, потому что как вы могли заметить тема оооочень обширная.

React Native - проблемы в отладке как были так и есть, невнятные стектрейсы.
Flutter быстрее, чем React native и у flutter типы из коробки(dart). В общем Flutter лучше.
А если хочется как в властелине колец, одно кольцо чтоб править всеми, то есть kotlin multiplatform, нативная разработка на одном языке под все платформы.
Если надо вот прям совсем срочно взять и написать, то flutter на текущий момент лучшее решение.