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

куда оно движется

Не движется, а катится. Известно куда — в светлое будущее.

А чем в данном контексте отличается framework for organizing от model?

Если честно, мне надоело общение с вами. Вы сами в состоянии загуглить фразу model and framework difference.

и TTFB это поможет победить?

Вы сами в состоянии загуглить фразу model and framework difference.

Выше мы уже выяснили, что Гугл тупой. Нагугливается только разница в контексте научных исследований.

Фигасе хитрых, загрузи фетчем большой файл и чтобы прогресс отслеживался

Это, кстати, тоже возможно: https://stackoverflow.com/a/64123890/3840567

Но я не об этом. В случае хитрых запросов fetch немного по-другому интерпретирует хедеры. Возможно, из-за политик CSP.

Борланд VCL представил в 1995, по его принципам дофига наделано, включая WinForms и кучу кроссплатформы. Вот так и надо писать, а не верстать UI через ж.пу автогеном на текстовом препроцессоре.

Я вот полюбил Wx для UI и любые формошлёпные извращения на web, которые раньше делали на flash, на Wx делать быстрее, проще и приятнее.

Что ж вы творите, просто вынуждаете ставить два чая пяти звездам.

Ну и где же какой-нибудь браузер для подобного великолепия, чтобы я мог набрать в нём example.com, и открылось бы «правильное» приложение?

Знаете, иногда бывает нечего ответить. Отвечу анекдотом:

На выставке с макетом электростанции и потребителя у Эдисона спрашивают:

- всё это очень интересно, но как от станции керосин к лампочкам поступает?

Или мне нужно устанавливать каждое приложение каждого сраного магазина?

Страдания пенсионеров, редактироваших ХаТээМэЛ в Ворд Пад понятны, но бессмыссленны и бесполезны.

Фрэймворки, как и ЯП, рождаются и умирают, но тот же Ангулар как был популярен 10 лет назад, так и сечас в авангарде.

Typescript практически победил и голый JS можно увидеть только у совсем упертых.

Гуй в браузере вытеснил рисование страничек разного уровня безумства фрэймворками, которые пытались все делать на серыере, в том числе генерировать JS и SPA.

Все довольны.

ПС.
недольны несколько застрявших в 90х старперов, но это было всегда и никогда не изменися. Всегда найдется несколько людей у которых при Брежневе/Путине было лучше так как буй стоял…

Я уже когда-то высказывался в толксах, поищи у меня в темах. Если коротко: браузер с самого начала был пускалкой программ (флеш и прочие апплеты) и ей же остаётся (прокаченный js, wasm). Ибо в один клик и кроссплатформа. Столяров и иже с ним могут удристаться, но такова реальность и под наши хотелки она не подстраивается. SPA, онлайн игры / программы — всё это действительно удобно как для юзера, так и для дистрибьютера. Кодеров тоже никто не спрашивает, как бизнес скажет —, так и будет.

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

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

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

Так пишем же. Игровые движки, кроссплатформенные гуй тулкиты. Оно не всегда компилится в wasm, но часто.

На самом деле сейчас альтернатив веб технологиям в части GUI нет вообще. Я сам не люблю js, но те возможности и скорость которую предоставляет связка v8 + js + react не чем не перебить.

Просто попробуйте сделать какой-нибудь helloworld на реакте и поймёте почему технологии ушли в эту сторону

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

Просто попробуйте сделать какой-нибудь helloworld на реакте и поймёте почему технологии ушли в эту сторону

реакт не стоит рекомендовать — им только распугивать

поясни, почему?

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

Вот еще. За три копейки пусть программисты делают, Вася не для того ПТУ заканчивал.

5 страниц и никто не сказал волшебное слово spring + jquery + ajax.

поясни, почему?

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

• смешение логики и разметки в компоненте;

• в шаблонах тоже смешана разметка, операторы JS и функции типа map и reduce;

• виртуальный DOM создаёт множество объектов, что перегружает кучу и GC;

• система провайдеров контекста (а значит и использующих её глобальных сторов типа redux) вызывает ререндер всего дерева компонентов при любом изменении;

• требуется вручную мемоизировать компоненты, чтобы избежать ререндеринга всего дерева компонентов;

• хуки требуют вручную указывать зависимости данных;

• API хуков в целом не способствует прозрачности сложной логики, особенно завязанной на жизненный цикл компонента;

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

• современные стилевые библиотеки компилируют стили в рантайме или из строк (styled components), или из объектов (emotion, jss), что не даёт браузеру загрузить их заранее;

• вышеперечисленное ожидаемо приводит к тому, что реакт уступает по производительности многим конкурентам, даже ангуляру и особенно vue.

Всё это будет выглядеть крайне дико для разработчика с опытом на классических технологиях. Поэтому я бы не рекомендовал его в качестве демонстрации преимущества «современного веба».

5 страниц и никто не сказал волшебное слово spring + jquery + ajax

зачем jquery в 2024 году?

зачем jquery в 2024 году?

Посмеяться, конечно же. Мы на юмористическом сайте или где.

да он не понимает о чем пишет вообще, его бессмысленно слушать. он либо жирный тролль либо конкретно тупой

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

• Visual Basic 1.0 — 1991 год
• Access 1.0 — 1992 год
• Delphi 1.0 — 1995 год
• FrontPage 1.0 — 1995 год

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

Два чаю. Новый язык имеет смысл изучать, если он несёт с собой какие-то новые* и потенциально полезные идеи. Лисп там, форт, эрланг с прологом. Какой смысл учить по шестнадцатому разу одну и ту же мейнстримную С-подобную PLOP*-дрисню, отличающуюся только цветом пуговиц набором ключевых слов?

* или старательно игнорируемые старые
* PLace-Oriented Programming

смешение логики и разметки в компоненте

Логика генерации разметки и должна быть поближе к этой самой разметке. Те же, кто тащит в представление (визуальные компоненты) какую-то другую логику — нехорошие люди. Причём от языка и используемых библиотек это не зависит.

в шаблонах тоже смешана разметка, операторы JS и функции типа map и reduce

Какие ещё шаблоны в реакте? Хотел плюнуть в реакт, а попал во Vue? %)

современные стилевые библиотеки компилируют стили в рантайме или из строк

Tailwind и ему подобные (UnoCSS, например) ничего не компилируют в рантайме. Плевок опять пролетел мимо.

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

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

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

Реакту бы больше подошло что-то типа ClojureScript. Собственно, наверное, поэтому в кложаскрипте никакими вуями и не пахнет — зато обёрток над реактом немереные кучи.

Какие ещё шаблоны в реакте? Хотел плюнуть в реакт, а попал во Vue? %)

Под шаблоном я подразумевал собственно содержимое функции рендера.

Tailwind и ему подобные (UnoCSS, например) ничего не компилируют в рантайме. Плевок опять пролетел мимо.

Tailwind концептуально говно. Что же касается «статичности», то атомарные классы тоже эффективно не распарсятся.

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

Они вот уже 10 лет пытаются оптимизировать изначально неправильное архитектурное решение. Если бы сразу взяли обсерверы (для которых уже был prior art в виде knockout.js), то давно бы уже всё было эффективно.

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

Вот именно. Потому-то и лучше хотя бы его было порекомендовать.

какой-нибудь helloworld

Я паскаль не люблю, но попробуй сделать helloworld в лазарусе.

простой объектный синтаксис?

Так мне нравится читать треды, в которых вы все дружно вместе обсуждаете мой Веб. Если бы вы только знали.

Перечитываю все треды многолетней давности вновь и вновь. Каждый раз с нетерпением жду новых.

Ах, как это трепетно, быть столь популярным.

Спасибо вам.

Весь DOM API и так в стиле ООП написан. Тем более querySelector и querySelectorAll давно уже есть.

Tailwind концептуально говно

Верю. Я поверил.

то атомарные классы тоже эффективно не распарсятся

Щто

Они вот уже 10 лет пытаются оптимизировать изначально неправильное архитектурное решение

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

обсерверы

Хорошее дело обсервером не назовут %)

мой Веб

Веб (и весь остальной интернет) принадлежит котам. Работай, негр, солнце ещё высоко.

Оно довольно марсианское

на обычных нормальных языках

Ещё один илитарий, с пропуканого дивана. Что конкретно ты написал за последние 20 лет на «нормальных языках», чтобы тут сидеть рассуждать о проблемах галактики? С голодухи на философию попёрло?

То есть когда выкладывают библиотеку leftpad, которая реализовывала маленькую, но нестандартную на тот момент фичу, — фу-фу-фу, оно легко пишется, а когда выкладывают обёртку над стандартными getAttribute/setAttribute/removeAttribute, из которой автоматически не будут удалён неиспользуемый код — кайф, наконец-то нормальное API.

5 страниц и никто не сказал волшебное слово spring + jquery + ajax

зачем jquery в 2024 году?

Старый добрый проверенный временем инструмент, знакомый всем. Любой бэкэндщик напишет html+js+jquery+ajax+thymeleaf для проверки бэка и не надо пачкаться об angular/react. При этом работает. Правилный вопрос - зачем придумали что-то еще?

Так претензии к leftpad были в другом.

angular хорош. А react придумали потому, что не хотели большого секса с вёрсткой в неожиданных местах.

так ведь Blazor (WASM режим) - это то, о чём ты пишешь

там приложение пишется на .NET совместимом языке (C#, F# или др.), потом оно компилируется, в итоге клиенту прилетает WebAssembly блоб, который делает интерактивность

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

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

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

Оно уже лет 8 никуда не движется, есть три основных фреймворка, один от гугла - Ангуляр, один от фесбука - Реакт, и один нормальный Vue. И нода для бекенда. Всё больше ничего нет.

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

Тебе разве кто-то запрещает сокетнуться на 80-й порт твоей любимой СИшечкой, отлавливать POST\GET и парсить их содержимое?

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

Идеальным веб будет после WWIII, я надеюсь. Когда не будет ни гугла ни майкрософта, а один только гипертекстовый фидонет.

+++ Да, это и есть вполне правильный вариант бэка. Разве nginx не так работает? Ну и get/post сначала, а дальше - бинарный поток через вебсокет. А на фронте - канвас для картинки с сервера и js, чтоб сказать серверу куда юзер на канвасе ткнул. Т.е. вариант будущего - это браузер в роли телека с обратной связью, а сервер - генератор потока картинок.

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

Дёргается в своей помойке туда-сюда, жиреет от потребления кучи мусора

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

Взлетел там где его ниша, т.е. когда веб пишут на условном C# то вот этот C# компилируют в веб асм, как вариант. Просто писать веб на C# не очень продуктивно, но если надо быстро то пожалуйста, тот же blazor web assembly из коробки умеет, бери и обмазывайся.

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

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

пытался сделать Microsoft со своим ASP.Net, но не взлетело

Как минимум знаю ИРЛ одного человека который вполне себе делал сайты под заказ на ASP.NET

Если мы про формошлёпство сферическое в вакууме где веб ака электрон используют вместо традиционного GUI, то я всё же считаю что быстрее чем на WindowsForms и C# в связке с VisualStudio простые проекты нельзя сделать альтернатива дельфи. Тупо потому что пока ты будешь xml/html писать я уже всё накидаю мышкой на форму. Другое дело как оно себя поведёт при масштабировании - там WindowsForms проиграет тому же WPF/Avalonia (потому как модель MVVM более приспособлена к росту приложения, чем MVC, правда цена за это то что надо в начале больше действий руками делать и городить огород из абстракций). Веб тут ещё более продуктивен ценой низкой производительности.

DOM это вообще уродец, на которого пошли вынужденно, потому как более простого для кожаных мешков способа работы с древовидными бесконечно вложенными структурами которыми является xml и html пока никто не придумал и вряд ли придумает. При том проблема там именно во вложенности, хороший пример  и  теги. Мне они были как-то нужны и я хотел посмотреть как можно реализовать их произвольную вложенность друг в друга. Оказалось что только мейнстримные браузеры в это умеют, потому что там такое говно внутри прячется, что кажущаяся простой задачей задача на самом деле пипец какая непростая и DOM для представления этого внутри структуры по сути единственное рабочее решение.