2024: Куда движется Web и с какого конца на него смотреть?

Да.

я сознательно избегал всего этого «около-веба»

не слежу вообще за темой

и ты хочешь, чтобы тебе сейчас подробно и в красках рассказали историю огромного пласта технологий за последние 20 лет? Избегай дальше, не надо оно тебе

Именно так хочу, да. Точнее, не так подробно, но в 2-3-4 абзаца

Если вы этого не можете в пару-тройку абзацев объяснить значит мне действительно не нужно в это лезть. Потому что со стороны выглядит так что не произошло ничего кроме какого-то двадцатикратного глупого переписывания уже написанного кода, при том что лет за 20 (ну ок, за 10) веб лучше не стал

Переизобретается ли раз за разом велосипед, который едет подпитываемый неофитами, которые не помнят даже того, что было год назад, по одним и тем же граблям?

По ощущениям - да, с жесточайшим Nih-синдромом. Огромные усилия тратятся, и новые фреймворки создаются, чтобы веб стал легче, быстрее, но вместо этого он становится только жирнее и тормознее.

Почему мы не пишем Web GUI на обычных нормальных языках, используя обычные нормальные библиотеки?

Потому что природа веба асинхронна.

Потому что на обычных нормальных языках, используя обычные нормальные библиотеки 90% нового софта создаётся по калькам 40-летней давности, не используя многопоточность и даже ООП. С вебом приходится делать по-другому. То, о чём вы говорите - на обычных нормальных языках, используя обычные нормальные библиотеки - пытался сделать Microsoft со своим ASP.Net, но не взлетело.

Почему примерно раз в полгода появляется новый правильный фреймворк который точно станет будущим, но через год про него все забывают?

Ajax, Vue, Flutter, TypeScript, React

Из перечисленного забыт ну разве что аякс.

ЮПочему не произошло отделение языка (JavaScript, TypeScript, Flutter) от реализаций библиотек которые рисуют эти ГУИ?

Flutter как раз такой как ты хочешь

Почему не взлетел(?) WebAsm?

очень даже взлетел
о чем хорошо знает широкий круг лиц узкой специализации

Почему мы не пишем Web GUI на обычных нормальных языках, используя обычные нормальные библиотеки?

да хер его знает почему вы такие

Flutter как раз такой как ты хочешь

Да нет же, он полностью прибит гвоздями к Dart

Я больше всего именно Flutter и имел ввиду когда написал это. Очень хорошо помню когда он появился была куча презентаций, мол: во какой гуй у нас будет! А потом оказалось что ради этого нужно будет изучить ещё один ничем не примечательный язык (и все восприняли это как норму от чего я обалдел)

Вопрос: кто-нибудь понимает куда оно движется?

Если начать отвечать серьёзно, то можно уйти в запой. Все покатилось по наклонной после того как вьюноши с горяшими глазами потащили js в бекенд и бизнес логику. Потом деградация вместе с СДВГ ускорилась и люди, не осилившие базу решили что они знают лучше, и начали пилить фреймворки как они видят. С тех пор мы в реальности велосипедов без сидений на любой вкус и цвет как главного средства двигания прогресса куда-то туда.

да хер его знает почему вы такие

Ок, покажи пальцем в написанный на C++ гуёвый фронтенд. Только не в кодек или типа того, а чтобы там полноценно кнопочки рисовались, обрабатывались формы и вот это вот всё

Но а почему же Отцы и прочие разные корифеи не выкатят нормальное идеологически- и расово-верное? С обоснованиями почему вот так правильно, а остальное - ересь?

Им (Отцам) сайты не нужны?

Но а почему же Отцы и прочие разные корифеи не выкатят нормальное идеологически- и расово-верное?

Так все есть, клиентская часть на html+css+js которая общается (sync/ async) с северной частью от PHP до Срр через REST API интерфейс. Классическая система с горизонтальным и вертикальным масштабированием отделяющая мух от котлет. JS потащили в бекенд потому что новым поколениям программистов которые писали клиентский код «было сложно понимать» что-то кроме js.

Почему примерно раз в полгода появляется новый правильный фреймворк который точно станет будущим, но через год про него все забывают?

Примерно с 2015 года большая тройка веб-фреймворков: React, Angular, Vue. Она не меняется уже много лет. То, что кто-то изобретает очередной фреймворк — обычный процесс творчества. То, что называет прорывным — маркетинг. Будет что-то новое популярное — будут на нём писать. Не будут — умрёт или останется нишевым.

Да, есть отдельные нестандартные решения типа Svelte или HTMX, но я бы назвал их нишевыми.

Ajax, Vue, Flutter, TypeScript, React - сходу навскидку называю, при том что не слежу вообще за темой

Ajax — не фреймворк, а общая концепция, что из веб-фронтенда можно делать запросы к бекенду без перезагрузки страницы.

Vue, React — «фреймворки», а точнее — библиотеки для более удобного взаимодействия с DOM страницы в браузере плюс функции для реализации реактивности (способ сильно зависит от библиотеки).

TypeScript — язык программирования, основан на JavaScript, в который добавили строгую типизацию. Напрямую интерпретироваться не может, компилируется в обычный JavaScript.

Flutter — кроссплатформенный фреймворк для GUI. основанный на языке Dart. В основном на нём пишут мобильные приложения, а не веб.

Почему не произошло отделение языка (JavaScript, TypeScript, Flutter) от реализаций библиотек которые рисуют эти ГУИ?

Реализации написаны на этих языках, но никто не заставляет этими библиотеками пользоваться. Что не так? Сейчас это выглядит как вопрос «Почему не произошло отделение отделение C++ от реализации библиотеки Qt?»

Почему не взлетел(?) WebAsm? Почему мы не пишем Web GUI на обычных нормальных языках, используя обычные нормальные библиотеки?

WASM изначально разрабатывался как дополнительная числодробилка для приложений на JS. Это отдельная виртуальная машина, которая даже прямого доступа к API браузера не имеет, функции нужно специально пробрасывать из JS или реализовывать на JS обёртку, из которой пробрасывать отдельные функции в WASM.

Теоретически можно написать GUI на обычном Qt или GTK и скомпилировать в WASM. Это даже будет работать. Но фактически, внутри WASM интерфейс рендерится в картинку, которая затем выводится в canvas браузера. Отсюда соответствующие недостатки: приложение должно самостоятельно реализовать весь процесс рендеринга, начиная с растеризации шрифтов, для браузера этот GUI просто картинка, поэтому не будут работать ни возможности перевода, ни скринридеры для слепых, приложение получается тяжелее и медленнее, потому что WASM всё-таки низкоуровневый.

Если же пробросить в WASM функции API браузера, то придётся делать новый фреймворк. API браузера крайне неудобен, чтобы писать на нём сложные приложения без дополнительных обёрток.

Переизобретается ли раз за разом велосипед, который едет подпитываемый неофитами, которые не помнят даже того, что было год назад, по одним и тем же граблям?

Новые «фреймворки» — это довольно широкое понятие. Это либо экспериментальные поделки, которые реализуют некоторую абстракцию над DOM API, либо каркасы-обёртки для React, либо библиотеки организации потока данных (типа потоков Rx или обсерверов-компьютедов), либо что-то нестандартное. Если есть список каких-либо фреймворков, можно сказать конкретнее. Большинство же повторяют уже существующие подходы, но это примерно как с зоопарком мини-GUI-библиотек для C/C++.

Есть ли понимание каким должен быть идеальный веб и если да то какая часть этой инженерии наиболее правильно движется в эту сторону?

Активисты, у которых есть своё понимание идеального веба, как правило и начинают писать очередной 100500-й фреймворк :)

А вообще, направление развитие веба диктуется разработчиками браузеров. Все остальные только лишь используют предоставленный ими API.

Абажди. Никто не пишет на JS уже ведь? Используют нечто, что транспилится в JS.

И это вот «общается с серверной частью» - оно ведь теперь как-то запрятано, ведь неправильно это каждый раз его переизобретать? Так ведь?

JS потащили в бекенд, потому что он в целом ничем не хуже других скриптовых языков, уже существовавших на бекенде, таких как PHP, Python, Ruby (и даже превосходит Python и Ruby по скорости выполнения), и вдобавок позволял переиспользовать код с фронтенда, в том числе для SSR. Последнее и оказалось киллер-фичей.

Абажди. Никто не пишет на JS уже ведь? Используют нечто, что транспилится в JS.

Еще как пишут. Да, наиболее догадливые пытаются обойти недостатки js и пишут на ts, но там родовая травма и все равно на выходе js.

И это вот «общается с серверной частью» - оно ведь теперь как-то запрятано, ведь неправильно это каждый раз его переизобретать? Так ведь?

А его никто и не переизобретает, есть объект XMLHttpRequest которые даёт js возможность отправлять запросы. Все остальное просто обертка которая предоставляет другой синтаксис и добавляет базовые проверки для удобства. В этом плане мы почти 30 лет стоим на месте.

Абажди. Никто не пишет на JS уже ведь? Используют нечто, что транспилится в JS.

А какая разница: JS или TS. Последний скомпилируется в тот же JS, который выполнится Node.js. Синтаксически TS — это тот же JS, только расширенный указанием типов. То есть с точки зрения вызовов API Node.js ничего не изменилось, с точки зрения вызовов API стандартной библиотеки — тоже ничего не изменилось.

И это вот «общается с серверной частью» - оно ведь теперь как-то запрятано, ведь неправильно это каждый раз его переизобретать? Так ведь?

Куда запрятано? Наоборот, раньше нужно было делать обёртки над неудобным XMLHttpRequest, а теперь даже появился стандартный метод fetch, который одной строкой вызов на бекенд сделает.

Во, очень интересный момент затронут!

WASM изначально разрабатывался как дополнительная числодробилка для приложений на JS. Это отдельная виртуальная машина, которая даже прямого доступа к API браузера не имеет, функции нужно специально пробрасывать из JS или реализовывать на JS обёртку, из которой пробрасывать отдельные функции в WASM.

А почему его разрабатывали только как числодробилку? Ведь очевидно что добавить туда низкоуровневый API к DOM - раз плюнуть. И это будет очень безопасно - для вызовов к DOM легко проверить корректность, гораздо легче чем сделать целиком безопасным высокоуровневый JS.

И вообще, можно было одновременно с WebAsm вообще выкинуть поддержку JavaScript - пусть её желающие вкрячивают сами в виде WebAsm-бинарников.

Если же пробросить в WASM функции API браузера, то придётся делать новый фреймворк. API браузера крайне неудобен, чтобы писать на нём сложные приложения без дополнительных обёрток.

Ой, ну подумаешь, ещё один Vue получится, но уже на нормальном языке типа C++ написанный

он в целом ничем не хуже других скриптовых языков

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

Это все не располагает для создания бизнес систем на стороне сервера.

А его никто и не переизобретает, есть объект XMLHttpRequest которые даёт js возможность отправлять запросы. Все остальное просто обертка которая предоставляет другой синтаксис и добавляет базовые проверки для удобства. В этом плане мы почти 30 лет стоим на месте.

А, ну вот я и интересуюсь что там сдвинулось на эту тему. Значит, ничего

А вообще, направление развитие веба диктуется разработчиками браузеров.

Вот. This. Все проблемы от того, что не было одной-единственной фирмы, которая подмяла бы весь веб под себя, и диктовала единые требования, как Microsoft. Потому что, например, под виндой, несмотря на зоопарк мини-GUI-библиотек для C/C++, GUI-программы, написанные с использованием разных библиотек, выглядят плюс-минус одинаково.

И не надо мне тыкать засильем ишака на рубеже веков, потому что это Микрософт подмял под себя ишак, но не web на базовом уровне - и оформление каждый лепил всё равно под себя.

А какая разница: JS или TS

TS как язык меньшее говно чем JS

И это вот «общается с серверной частью» - оно ведь теперь как-то запрятано, ведь неправильно это каждый раз его переизобретать? Так ведь?

Куда запрятано? Наоборот, раньше нужно было делать обёртки над неудобным XMLHttpRequest, а теперь даже появился стандартный метод fetch, который одной строкой вызов на бекенд сделает.

Это и называется «запрятано», ведь метод fetch не встроен в браузер, а чем-то высокоуровневым предоставляется

вдобавок позволял переиспользовать код с фронтенда

попався, яваскриптизер. Это максимально тупой аргумент повторяемый адептами js как попугаями.

На клиенте запросы и манипуляция дом деревом, на сервере - бизнес логика и расчёты. Единственное переиспользование которое возможно в этом случае это if, else и foreach, чего собсно js адепты и добивались тк серверные языки осилить были не в состоянии.

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

Согласен, но до того люди и с PHP как-то жили, и опыт показал, что при должной аккуратности всё же можно жить с этим. А там и TS появился, который помогает справиться с приведением типов.

в целом не развитая возможность работы со структурами данных

Большинству хватает стандартных объектов (ассоциативных массивов) и обычных массивов. Есть и поддержка ООП. Остальное решается библиотеками.

покажи пальцем в написанный на C++

а причем тут кресты, когда я за флаттер топлю, стесняюсь спросить?

ещё один ничем не примечательный язык

в контексте гуя - дохера чем примечательный, но это вникать надо

но до того люди и с PHP как-то жили

И продолжают жить. Последняя версия PHP вообще, один из лучших вариантов для реализации логики на сервере, этот не тот php который был 10-15 лет назад. А js - тот же самый, что и был тогда, он не осилил эволюцию, просто засрали бекенд.

А, сорян, просто в моём понимании нормальные языки это, как минимум, компилируемые языки

А Dart это вообще какой-то язык не имеющий никаких преимуществ в разработке. Просто язык созданный ради создания языка

А Dart это вообще какой-то язык не имеющий никаких преимуществ в разработке

он интересен в комплекте с флаттером, а как сам по себе - ну такоэ

Ведь очевидно что добавить туда низкоуровневый API к DOM - раз плюнуть.

В том и дело, что не раз плюнуть. DOM API основан на ООП и требует автоматического управления памятью. Описать сишный интерфейс для работы с такими объектами не так-то просто.

И вообще, можно было одновременно с WebAsm вообще выкинуть поддержку JavaScript - пусть её желающие вкрячивают сами в виде WebAsm-бинарников.

И поломать все существующие сайты? На это бы никто из разработчиков браузеров не пошёл.

Ой, ну подумаешь, ещё один Vue получится, но уже на нормальном языке типа C++ написанный

Только получится Vue, React, Angular и ещё 100500 велосипедов. Далее декартово умножаем это на множество «нормальных» языков.

метод fetch не встроен в браузер, а чем-то высокоуровневым предоставляется

нет, он давно уже встроен в браузер, как и XMLHttpRequest и остальные API

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

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

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

Но Dart компилируемый.

На клиенте запросы и манипуляция дом деревом, на сервере - бизнес логика и расчёты.

В том и дело, что от сервера иногда нужен вывод HTML. Вот эту шаблонизацию и предложили через JS делать тем же кодом, что и на фронтенде.

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

а адепты серверных языков часто js не могут осилить, что ж теперь?

Dart позиционируется в качестве замены/альтернативы JavaScript

https://dart.dev/assets/dash/svg/3-1-aot-compile.svg

а адепты серверных языков часто js не могут осилить, что ж теперь?

Это не недостаток же

Гадание на картах Таро или гомеопатию тоже не все могут осилить

Жорожо, Dart в моих глазах вырос на 1 пункт из 50

Последняя версия PHP вообще, один из лучших вариантов для реализации логики на сервере, этот не тот php который был 10-15 лет назад.

У них теперь нет проблем с приведением типов? И что насчёт Java или C#?

и является оберткой которая возвращает промисы вместо дергания коллбеков. Не более того.

Почему не произошло отделение языка (JavaScript, TypeScript, Flutter) от реализаций библиотек которые рисуют эти ГУИ?

TypeScript это надмножество над JS где можно прописать явно типы для проверки на стадии трансляции. TypeScript можешь использовать везде вместо JS, хоть с react, хоть с чем угодно.

Почему не взлетел(?) WebAsm? Почему мы не пишем Web GUI на обычных нормальных языках, используя обычные нормальные библиотеки?

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

в моём понимании нормальные языки это, как минимум, компилируемые языки

ну тогда это просто все ЯП

апатамушта железный конь пришел на смену крестьянской лошадке и всякое такое

срываю покровы
гугли по graal truffel
канпеляция а так же межъязыковое взаимодействие, профайлер, отладчик, блэкджек и шахматистки, всё как мы любим

ю-ху-у-у

и является оберткой которая возвращает промисы вместо дергания коллбеков. Не более того.

Хотите сказать, что в браузерном движке под капотом дёргается XMLHttpRequest?

У них теперь нет проблем с приведением типов?

Уже лет 8 как все чётко по правилам и приоритетам операндов.

И что насчёт Java или C#?

Java надо сильно уметь готовить чтобы не тормозила и не текла по памяти как сучка, а C# не является специализированным языком под веб тк в базе +/- пара гигабайт озу там где php обойдётся 15 мегабайтами такой себе вариант.

Гадание на картах Таро или гомеопатию тоже не все могут осилить

В отличие от Таро и гомеопатии, JS всё-таки работает здесь и сейчас. Поэтому на нём и пишут :)

Кстати, кажется, единственными попытками протащить альтернативный язык в браузеры были Майкрософт со своим VBScript, и Гугл с Dart. Разумеется, пользоваться такими вендорлоками почти никто не стал. Какой-то либо общепринятый язык протаскивать никто и не пытался.

я хочу сказать что fetch API не написан с нуля, а построен на том что было, те xhr с добавлением промисов.

Я бы хотел им пользоваться, но не хочу ради только лишь этого изучать новый язык - это максимально глупое разбазаривание ресурсов мозга

вчера по скорой привезли одного
выход из запоя
обоссанный, обосранный, вонючий, все отделение заблевал
попросил попить, ему налили
Он - я надеюсь это вода не из под крана?

не ссы, мозговое вещество на обучение не расходуется

Почему не произошло отделение языка (JavaScript, TypeScript, Flutter) от реализаций библиотек которые рисуют эти ГУИ?

TypeScript это надмножество над JS где можно прописать явно типы для проверки на стадии трансляции. TypeScript можешь использовать везде вместо JS, хоть с react, хоть с чем угодно.

Это не ответ на мой вопрос

Почему не взлетел(?) WebAsm? Почему мы не пишем Web GUI на обычных нормальных языках, используя обычные нормальные библиотеки?

Наследие, нельзя просто взять и отказаться от всего что было сделано до этого.

Именно это веб-программисты и делают с регулярностью, достойной лучшего применения

С другой стороны ты действительно хочешь чтоб тебе загружался блоб состоящий из байткода?

А в чём проблема? У тебя и сейчас загружается обфусцированный JS-блоб который ты точно так же не можешь ни прочитать ни исправить

Ну допустим, только многие привычные библиотеки работать не будут потому как исполняются в песочнице, а там нет ни трушных потоков, ни прямого доступа к вводу/выводу.

Такие 1) не скомпилируются 2) будут работать как работают сейчас в нативе

Демагогия

А как можно в принципе реализовать что-либо другое для той же самой операции? Даже CURL API в принципе такой же.

И да, в некоторых хитрых случаях между fetch и xhr есть различия в поведении.

Уже лет 8 как все чётко по правилам и приоритетам операндов.

Думаешь в JS не специфицированы приоритеты операндов и правила преобразования типов?

C# не является специализированным языком под веб тк в базе +/- пара гигабайт озу там где php обойдётся 15 мегабайтами такой себе вариант

А что насчёт реальных больших приложений? Сколько PHP сожрёт? И его научились демонизировать или всё так же PHP is meant to die? Относительно дотнета реквестируется lovesan