Comments 31
вся эта жесть (рядом стоящее DOM-дерево) всегда вызывало у меня недоумение
сперва они нарисовали dom
потом они стали компоненты описывать своим языком разметки (собственные теги)
и получили html over dom over html
когда-то в Фидо существовал мем: фидошники долго пытались использовать видеомагнитофоны для хранения комп данных
так вот однажды чувак опубликовал пост: "у меня наконец получилось записать туда видеофайл!"
на что ему ответили: "бро, ты только что научился смотреть видео с видеокассеты!"
вот так и эта реактивность
Не совсем
Он записал видео в цифре, а значит, качество останется оригинальным, пока лента не придет в негодность. И качество не будет зависеть от проигрывающего устройства.
Видеомагнитофоны часто использовали для архива
На одну кассету VHS помещалось около 4Гб данных - огромадный для того времени объем, соответственно, дешевизна хранения. Это эпоха сидиромов и 760Мб дисков - недешевых и часто портящих данные
Так что смеяться над тем "чуваком" как минимум глупо.
Еще один интересный круг: в начале нулевых все браузеры поддерживали микрософтовский VBScript. Он был сложнее JavaScript, потому что там была типизация (не строгая, но была), поэтому от него отказались. Сейчас все переходят на TypeScript, именно из-за наличия в нем типизации. Причём язык, опять-таки, разрабатывается MS-ом.
.. и, кстати, VBScript изначально "из коробки" работал на сервере :)
Насколько помню [VisualBasic]Script не поддерживался в Netscape Navigator
В любом случае, политика Микрософт тогда была такая агрессивная и нечестная, что ее технологии вряд ли бы согласились сделать стандартом.
Не помню на счет нулевых, но году в 2010 VBScript удалось использовать только в IE, в остальных работать отказывался. Но на нем ещё тогда можно было с файловой системой взаимодействовать. Уязвимостей много было, да и в целом на JS по-приятнее было писать.
Еще аналогия - серверный рендеринг. Сначала веб-сервера выдавали html-ку, потом стали рендерить веб страницу на клиенте с помощью JS. Теперь запускают этот JS на сервере, рендерят им html-ку и опять отдают клиенту готовую веб-страницу.
Этот костыль связан с импотенцией поисковых систем, думаю у них это пройдет.
Это не импотенция поисковых систем - SEO вполне достигается другими неизвращенными способами типа пререндеринга или отделного статичного контента для поисковиков. Да и умеет Google в SPA уже
Это попытка фронтов захвтатить сервер
В SPA может и умеет, а вот в вебсокеты - нет.
Google не умеет в SPA - точнее любой классический сайт сверстанный семантично и отданный с помощью SSR будет выше в поисковой выдаче чем SPA. Так что SSR или SSG незаменимы если речь идёт о поисковом продвижении. Причем если вы клиенту и боту будете отдавать разные страницы, можно ещё и банан получить за попытки делать дорвеи
точнее любой классический сайт сверстанный семантично и отданный с помощью SSR будет выше в поисковой выдаче чем SPA
Откуда это утверждение?
Ссылки на пруфы, плз, про преимущество [гидратированного?] SSR
Раньше VDOM подавался как крутая фича фреймворка. Говорили "React крут, потому что там VDOM и это позволяет оптимизировать отрисовку и уменьшить количество медленных DOM-операций, потому что сравнивать объекты дешевле".
А последнее время стали говорить иначе. DOM-операции на самом деле не такие уж и медленные, как оказалось. Браузеры делают кучу оптимизаций на уровне движка. Но DOM-операции нужно правильно готовить (кеширование, батчинг, отложенные обновления и тд).
VDOM уже начал всем мешать и сейчас наоборот, фишкой фреймворка является отсутствие VDOM. И новые фреймворки идут туда же. Да и старые тоже (Vapor Vue, Angular Incremental DOM). Тот же Lit не использует VDOM и по сухому бенчмарку выигрывает троицу. Так что да, VDOM как будто потихоньку отходит как концепция.
VDOM Изначально бесполезная фича, которую популяризировала секта реакта. Просто реальных конкурентных преимуществ перед полноценными фреймворками у реакта нет, был придуман миф мол он быстрее. А на деле производительности что бы крутить сайты много не надо. Проблемы только в огромных списках, но и для них есть virtual scroll. Сама концепция VDOM изначально не очень, зачем нужен виртуальный DOM когда просто можно не засерать обычный, и вообще откуда в нем столько изменений вдруг взялось что прям не успевает браузер рендерить картинки с текстом.
VDOM Изначально бесполезная фича
Не то чтобы совсем бесполезная. Когда он только появился, он как-будто решал свою задачу. DOM действительно мог быть медленным на больших объёмах данных или при слишком частых обновлениях.
Но с тех пор выросли аппаратные мощности устройств и браузеры постоянно совершенствуют механизмы работы DOM и оптимизирующие движки для JS. А некоторые фреймворки показали, что точечная работа с DOM при грамотном подходе работает быстрее VDOM.
А на деле производительности что бы крутить сайты много не надо
Обычные сайты и не надо на фреймворках делать. Генерировать страницу сервером и отдать в браузер, или заранее нагенерировать статических файлов и раздавать их с CDN. А некоторым сайтам и вовсе JS не нужен, не говоря уже о том, чтобы тащить рантайм фреймворка и вебпака и рисовать всё на клиенте. Но конечно от сайта зависит.
и вообще откуда в нем столько изменений вдруг взялось что прям не успевает браузер рендерить картинки с текстом.
А оно появилось, когда перестали рендерить картинки с текстом, а стали рендерить дата-гриды на сотни строк с сортировкой, фильтрацией и реалтайм-обновлением стока акций раз в 500мс, или когда начали рендерить онлайн-редактор документов с совместным доступом на редактирование.
А что современное не изотерическое посоветуете, чтобы бандл минимальный (соглашусь на два разных фреймворка для двух разных кейсов: для большого приложения, например 1000 компонентов и для маленького: десятки копмонентов) и в бенчмарках быстрый.
solid.js
jquery
У первого сломанная система реактивности, у второго вообще её нет. При этом первый тянет в бандл 20кб, а второй даже без обвесов - 30. Прекрасные рекомендации.
Для сравнения, весь todomvc вместе со стилями на $mol весит меньше 30кб. Про перфоманс я вообще молчу:
Нет плохих и хороших технологий. Их можно правильно использовать, а можно не правильно.
Буквально несколько дней назад сделал проект, в котором вместе используются web components и react.
У react есть свои плюсы (хотя не люблю использовать как библиотеку на которой весь сайт делаю) и у web components свои (это основнаятехнология которую я использую)
Не могу найти, но видел сравнение размера бандлов svelte (или solid.js) (не vdom) и vue ( vdom )
На "hello world" - 5Кб и 60Кб, при росте размера прикладного кода через некоторое время бандл svelte начинает сильно превышать бандл vue. Соответственно, скорость тоже возможно падает
Так что размер приложения очень важен для оценок. Небольшое можно и на document.querySelector самому написать, а для большого vdom - сильное спасение
На "hello world" - 5Кб и 60Кб, при росте размера прикладного кода через некоторое время бандл
svelteначинает сильно превышать бандлvue. Соответственно, скорость тоже возможно падает
Скорость вряд ли. А по размеру вполне очевидная закономерность.
На небольшом проекте генератор будет выигрывать комбайн. Т.к. количество генериуемого кода будет меньше кода комбайна.
На больших проектах будет выигрывать комбаин, потому что переиспользование функций будет уменьшать объём. Но скорость от этого не увеличиться, т.к. это доп вызовы функций и "разархивирование" всего того, что в него заложено.
Есть SolidJS и SvelteJS, вероятно, вы сможете подрезать оттуда пару идей для развития своего Фреймворка.
SolidJS интересен синтаксисом JSX, который максимально напоминает React, для этого используется кастомный JSX (если кто не в курсе, то JSX это просто синтаксис записи объектов в XMLподобном виде, Babel превращает все эти теги и атрибуты в объекты и их поля)
Здравствуйте! Синтаксис jsx не используется в фреймворке по причине достижения максимально возможной скорости работы. Если бы он использовался - он, конечно, очень удобен, но, сам по себе загоняет в определённые рамки + "конкуренция" с jsx фреймворками просто огромная. Я предполагаю, что есть перспектива сделать свой template с расширением конкретным для удобной работы, но, я пока не думаю, что это сейчас необходимо.
Для чего вот свой template изобретать? По моему эта штука должна решать проблему того, что вам необходимо применять например свои специальные атрибуты или как-то обернуть многословность там, где она есть.
В свое время выбрал vue, вместо react просто потому что ломать голову этим jsx было совсем неприятно, а раздел шаблона в компонентах vue сильно напоминал какой-нибудь jinja
Изобретать свой велосипед без надобности не нужно - это я понимаю. Сейчас, я не думаю, что стоит делать шаги в данном направлении по причинам, описанным выше в комментариях. Добавлю только, что в целом я считаю, что попробовать сделать template можно только лишь для удобства. Чтобы вместо html подсвечивался бы синтаксис чуть другой. Но, это действительно много работы и, боюсь, в одиночку я уже такое не потяну. Всё, что сейчас в фреймворке над html'ем - это минимальная необходимость для современной работы (да и то пока не хватает многого). Но, зато хоть всё работает реально очень быстро благодаря этому)
Почему реактивность без VDOM (с реальным DOM) лучше, чем реактивность с VDOM?