LINUX.ORG.RU
ФорумTalks

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

 , ,


1

4

Привет!

После изучения HTML и какого-то зачаточного знакомства с тогдашним JavaScript лет 20 назад я сознательно избегал всего этого «около-веба». Тем временем оно росло, цвело, раскидисто раскидывалось и заняло приличный кусок рынка.

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

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

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

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

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

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



Последнее исправление: ahdenchik (всего исправлений: 1)

Куда движется Web?

В Адъ.

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

Мы уже не помним, кто мы такие и откуда мы. Но идём мы в Адъ. Что будет через 10 лет - страшно подумать.

Chord ★★★★
()
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от instant

делать на этом гуи оч удобно

По сравнению с жс фреймворками, в особенности со svelte, не очень-то удобно.

Если к серверному проекту вопросов нет, то на любой комплексной страничке wasm рантайм ощутимо тормозит, а уж сколько там интеропа с жс под капотом и сколько тебе самому придется написать это уже что-то за гранью удобства.

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

ritsufag ★★★★★
()
Ответ на: комментарий от tiinn

Ну мужику в этом году 72 стукнуло. Уже год как он ничего не делает.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Просто писать веб на C# не очень продуктивно

А почему так? C# очень продуктивный язык вообще-то

Они более низкоуровневые чем современный ширпотребный веб.

Пример сможешь привести?

Я считаю что современные языки типа вот C# очень широкий охват имеют, они и низкоуровневые и очень высокоуровневые

ahdenchik
() автор топика
Ответ на: комментарий от ahdenchik

А почему так? C# очень продуктивный язык вообще-то

В сравнении с си или C++ безусловно. В сравнении с очень продуктивными языками (python, js может lisp-о образные языки, вроде Closure, не знаю на лиспообразных не доводилось даже хеллоуворлды делать) оно совершенно не продуктивно в плане скорости разработки и получения результата за меньший объём кода. Про то насколько быстро код будет работать - другой разговор.

Пример сможешь привести?

Тебе надо узнать как на c++ или си можно веб делать? Можно, представь себе, тут даже на ЛОР-е пара челиков есть которая такое выкидывала, ЕМНИП там простая идея как доска - бек можно писать на любом языке через условный FastCGI т.е. если у тебя ЯП сокеты поддерживает то ты можешь веб на этом ЯП делать. С фронтом чуть интереснее, но любой ЯП который конвертится в LLVM байткод можно через Emscripten докомпилить в web assembly. Ну а в LLVM байткод у нас вроде как все ЯП в которые clang умеет соберутся (поправьте если я не прав, я не особо шланговскую архитектуру изнутри представляю, может что-то он и собирает без LLVM байткода на этапе компиляции, хотя я сомневаюсь, это не gcc всё же у которого с внутренней архитектурой беда). Так что можешь дерзать и писать веб хоть на сишке, хоть на растишке, было бы желание и море времени.

Я считаю что современные языки типа вот C# очень широкий охват имеют, они и низкоуровневые и очень высокоуровневые

Нет, тут всё просто на самом деле. Смотря как смотреть на термин высокоуровневый/низкоуровневый (тут опять маркетологи всё засрали и внесли путаницу). Если смотреть с точки зрения железа то есть ЯП которые после компиляции работают напрямую на процессоре, т.е. код собирается в инструкции для процессора вот они и есть низкоуровневые, есть ЯП которые собираются в байт коды разной степени паршивости и разными способами (какие-то заранее какие-то на лету), для них уже программа нужна которая их выполнять будет, есть ЯП которые вообще тупо по строкам интерпритируются ни в какой байткод не собираясь даже. А есть маркетинговый взгляд на высокоуровневость, который связан с тем, сколько абстракций накрутили и очень часто обе этих точки зрения совпадают. Как пример C# среднего уровня что по абстракциям, что по тому как он работает, а JS высокого уровня (примеры когда подтягиваются сотни библиотек абстрагирующихся друг над другом ради какой-то одной строчки в коде конечного сайта это не шутка, так в вебе бывает). Ну а связано это совпадение с тем фактом что чтоб накрутить высокоуровневые абстракции в яп который работает на низком уровне надо дофига умный компилятор делать или процессор дофига сложный. Потому трудозатраты на то чтоб сделать условный js, который будет в эффективный машинный код собираться огромны, хотя теоретически это возможно для любых языков полных по Тьюрингу. С такими трудозатратами можно выпустить с нуля пяток языков типа раста и потрировать их на все компиляторы во все ОС, включая малоизвестные, вроде KolibriOS.

peregrine ★★★★★
()

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

Согласно второму закону термодинамики вообще всё движется в одном направлении от меньшей энтропии к большей. Просто забей ;)

slackwarrior ★★★★★
()
Ответ на: комментарий от peregrine

Тебе надо узнать как на c++ или си можно веб делать? Можно

+1. А если не похоронили либы, то ещё как можно.
Более того иногда случается, что не можно, а весьма предпочтительно.

anc ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)