Не совсем Они там много го*** намутили с Qt

а причем тут QT вообще?

или разобраться в чем прелесть подхода с гипертекстом и как альтернатива когда все хардкодиться на клиенте

Телеграм кстати на ресте было бы жестко делать, у них огромное количество данных

Это разные вещи. Можно сделать всё гибко, но без гипертекста.

короч, не хочешь - не разбирайся, это лично твое дело.

В чём?

но похрену, REST всё равно достаточно плох

а ты потом начал какую-то чушь про qt и SPA-ный клиент телеграмма выставлять за web

SPA не web? Почему?

Что такое Web? Набор HTTP+HTML и все прилагающиеся JS + CSS, разве нет?

если очень сильно упростить то SPA можно описать как очень яркое проявление code on demand из rest. Когда у тебя в гипертексте есть элемент <My-cool-app /> и все. На этом web часть заканчивается и начинается классическое обычное приложение которое просто эксплуатирует средства браузера для рендринга UI.

при этом спроси любого фронтендера у которого есть опыт с тем же qt - web-стандарты такой себе UI фреймворк. Вспомнить хотя бы <input type=date и уже хочется плакать

но внутри элемента же обычный DOM (да хоть canvas)?

да но это не web, это просто DOM. А canvas - ты можешь сделать фулскрин канвас и отрисовывать весь UI там. Но это не будет web уже. Это по сути просто приложение которое скачивается на клиент по запросу. Грань тонка но не настолько что бы разницу не видеть.

Вот! К этому клоню.

в каком смысле «не web»?

я это больше говоря к вопросу что не может быть rest api. Rest это про unified interface и code on demand если unified interface не закладывает какие-либо детали поведения. То есть пример rest-а банален. Ты открываешь браузер, и заходишь в гугл. Тебе высвечивается форма. Браузер умеет эту форму показывать но в сам браузер не вшито ничего специализированного чисто под эту страничку. Ты жмакаешь "искать" и происходит переход (то что подразумевается под State transfer из аббривиатуры REST). Там ты видишь уже новую страничку опять же о которой браузер ничего не знал до этого. И там ссылки на другие странички и т.д. То есть идея в том что бы все знания о том как пользоваться чем были инкапсулированы на сервере а клиент лишь знал как отображать те или иные штуки (или же опять же, если мы хотим отобразить сложную форму фасеточного поиска которая по хитрому формирует запрос - мы можем воспользоваться code on demand и вшить javascript код в страничку что бы та чего машнила). Вжух в результате всего этого мы имеетм web. То есть бесконечно скейлящаяся система, для которой не нужно версионирование (разве что для протоколов оно все же надо), где все работает за счет content negitiaton, гипертекста, hateoas. URI и прочих стандартов которые в сумме и дают тебе WEB. А когда ты делаешь приложение мобильное или SPA ты уже не с гипертекстом работаешь. Ты работаешь с фиксированными структурами данных, обычно в виде json. И так или иначе твое приложение должно знать что-то о сервере. Обычно ты все эндпоинты так или иначе хардкодишь. Я видел попытки сделать autodiscovery для API но в этом случае всеравно тебе надо на клиенте запилить че как дискаверить + всеравно есть структуры данных которые фиксированные.

Минуточку. Для изменения функционала не нужно патчить браузер, но нужно менять фронт, который исполняется браузером и в данном контексте является приложением.

при этом спроси любого фронтендера у которого есть опыт с тем же qt - web-стандарты такой себе UI фреймворк. Вспомнить хотя бы <input type=date и уже хочется плакать

Сомнительно

это ничем не отличается от скажем... операционной системы где ты можешь поставить приложение))

Сомнительно

да, отличается только то, что всё равно приходится использовать HTML/JS, и это всё портит

да ну? UI-компоненты в вебе очень ограниченные и стрёмные

я писал на qt в последний раз в 2010-ом году. По сравнению с ним ваять приложения в web было адской болью и слезами.

А ты думаешь, что в Qt слишком лучше? Тебе, в целом, там хватит пару тройку компонентов, но если нужно будет что-то уникальное, то ты намучаешься

А ты думаешь, что в Qt слишком лучше? Тебе, в целом, там хватит пару тройку компонентов, но если нужно будет что-то уникальное, то ты намучаешься

да но ты там сможешь это сделать. Ну и сегодня все не так плохо, у меня травма с 10-ого года осталась))

Чтобы написать свой компонент в HTML, нужно либо под капотом использовать DOM, либо ручками нарисовать на канве. Любой нормальный UI-фреймворк позволяет экстендить или аггрегировать существующие компоненты и расширять/переопределять их функционал.

сегодня ты тоже в этом не ограничен (в рамках платформы только)

webassebly

не понял

Ну да, написать с нуля то, что существовало в 80-90х.

ну то есть блин сегодня ты можешь написать свой UI фреймворк на opengl и C++ или rust и скомпилить его через webassebly и рэндрить в канве

Не понимаю, почему не JVM. Изобретут новых критических уязвимостей при сэндбоксинге :)

Извращенцы

ты сможешь на своем любиом хаскеле/идрисе/кложе/лиспе писать датапикеры, че

Дарте!

без каких-либо проблем) хоть на ассемблере

ну можешь java код компилить в webassembly

Не, там же ещё толстый рантайм нужен. Я о другом, что уже есть хорошая песочница с годной производительностью и поддержкой кучи языков, ОС и архитектур процессоров.

еще лет через 10 можно будет в целом убрать миллионы строк C++ из шиндовс на другие миллионы строк C++ из Edge

Кстати, а с каких пор здесь в будущее заглядывают?

REST это архитектурный стиль который был использован для WEB. По поводу как узнать rest или не rest - если тебе для добавления какого-то метода API надо хоть что-то править на клиенте - это не rest а просто rpc via http (юзаешь ты там чето свое, юзаешь ли http как протокол апликейшен уровня или транспортный, или ты юзаешь тот же gprc, или odata или graphql.... суть одна и та же).

Хау эбаут rest через вебсокет?

в конечном итоге у тебя http как-то через сокеты ж работает))

Мне нравится, что в вебсокетах всё очень быстро, без лишних заголовков. Но бэкэнды говорят, что stateful-соединения — боль.

как же им бедняшкам удается избегать stateful соединения с любыми протоколами которые юзают TCP?)

TCP stateful, а HTTP, построенный поверх него, — нет.