Комментарии 25
при изменении данных нужно было вручную найти нужный элемент через document.querySelector
ну до того, как появился querySelector, приходилось ставить id и искать по getElementById, или что еще хуже искать по tagName и className, вот это был ужас. А потом появился jQuery с его крутыми селекторами, и это было глотком свежего воздуха.
Хорошее верхнеуровневое описание для общего понимания - мне, как задовику (back-ender) понравилось. Подозреваю, правда, что там везде есть ещё много деталей, в которых черти прячутся, конечно, но мне, вроде как, с ними непосредственно не работать.
Интересно, есть ли какая-то связь или преемственность между браузерными фреймворками и десктопными UI-фреймворками? Ведь последние создавались гораздо раньше браузерных и существовали уже долгие годы. Логично было бы проанализировать лучшие варианты и воплотить их идеи в браузере.
Про фреймфорки не знаю, но про GUI мне есть, что сказать.
Браузер - это убогая фигня по сравнению с нативными (!!!) десктопными GUI.
Элементарный пример - вывести в что-то типа селекта (пофиг нативный браузерный или кастомный на li / div) ~35000 опций. И таких десяток на экране. Браeзерный список/нативный селект будет тупить, подлагивать при скролле, при первом открытии будет показывать радикально черный фон на несколько секунд и, вообще, ВСЁ на экране будет тормозить (пользоваться как-то можно, конечно, НО...). И нет, это не зависит от процессора и RAM. Там есть какой-то потолок, после которого наращивание мощностей не оказывает заметного влияния на производительность.
Теперь про клиентскую софтину, написанную на Решетке (здесь могу ошибаться, но точно не на Электроне, релиз был в 2009 году), с которой мне довелось работать. Там таких контролов на одном экране (не совсем - длинное полотнище со скроллом без подзагрузок) больше 10 могло быть с таким же кол-вом элементов (~35000), иногда меньше, иногда даже больше. Так вот, первоначальная загрузка (показывает лоадер) Value Lists могла тупить 10-20 сек. Сохраненные локально Value Lists НЕ создавали видимого лага. Более того, в этих контролах работала фильтрация по значениям из списка БЕЗ лагов. И да, в десктопном приложении кол-во RAM очень даже влияло на все, но 8GB было достатточно.
Вообще, преимущества браузерных бирюлек над нативными десктопными приложениями нужно искать с фонарями.
Интересно, это какие-то принципиальные ограничения платформы или банальная криворукость разработчиков всяких хромиумов?
Вообще-то, насколько я знаю, сейчас в браузерах вылизано все очень неплохо. А первоначальная загрузка у любого списочного контролами может идти двумя способами - в цикле добавление элемента и тут же перерисовка (добавление по умолчанию) или добавление всех элементов и только потом перерисовка, и это на порядки быстрее для очень длинных списков. Так что, возможно, не в браузере дело.
Кстати.
Value Lists могла тупить 10-20 сек.
И пипл хавал? Странно, терпеливые вам попались. Если брать данные из БД, то передать 35К коротких записей, это намного меньше 10-20 секунд. Но даже если бы это было 5-6 секунд, это уже плохо. В таких случаях пишут свой кастомный виртуальный контрол, который никогда не показывает все данные, а показывает только подмножество (часто даже и не все подмножество), когда пользователь начинает искать. Плюс, начальная загрузка в фоне. Лишние 2-4 дня разработки, зато супербыстро и удобно для пользователей.
Зачем 2-4 дня разработки, если в $mol это из коробки?
Ха, 2-4 дня, чтобы доработать один контрол или NNN дней, чтобы перейти на новый фреймворк. А точнее, сначала ещё MMM дней, чтобы убедить тимлида, его начальника и его начальника.
Но спасибо за статью, я понял, кажется, отличие UI в Windows, например, и UI в браузере. В Windows все контролы это вещи в себе, как однострочный или многострочный редактор текста, или выпадающий список, или сложная таблица. Их структура и внутренняя иерархия не видна общему оконному движку. В браузере же все контролы, кроме (как я понял) редактора текста, это не вещи в себе, а подструктуры глобального DOM. Таким образом, если в обычном UI окне десктопного приложения десятки, ну максимум сотня объектов иерархии, которая управляется системой окон, то в DOM этих объектов легко могут быть тысячи и десятки тысяч. Это нехорошо, я считаю. В Виндах каждый контрол можно сделать кастомным, например испольющим виртуальный скролинг, и легко включить его в любой UI-фреймворк, потому что он имеет общий для всех интерфейс для работы с ним оконного движка. Надо было давно сделать так же в браузерах.
2-4 дня на каждый тривиальный контрол и 2-4 недели на каждый нетривиальный. Или потратить пару недель на изучение $mol и начать новый проект сразу на нормальном фреймворке.
$mol компоненты вы точно так же можете включить в любой фреймворк, не потеряв виртуализацию рендеринга.
Уже сделано - Web Components.
А на вкладке Network что творится?
Нет конекта к сокетам wss://sync-pmzz.onrender.com/ и wss://sync.hyoo.ru/
Нет, фронтендеры никогда на десктоп не смотрели, а всё переизобретали заново.
Чтобы взять какие-то стоящие идеи с декстопа, надо быть хорошим разрабом десктопа, а потом сменить специализацию на фронтенд. Таких разработчиков сильно меньше, чем тех, кто сразу начинал с веба, поэтому и преемственности практически не было.
Интересно, есть ли какая-то связь или преемственность между браузерными фреймворками и десктопными UI-фреймворками?
Microsoft попробовала в ASP.NET WebForms перенести идеологию разработики для десктопа в веб (правда, строго говоря, там речь шла не о front-end, а создании HTML на севере, это, похоже на нынешний SSR, но жестче - клиент был пассивным). Получилось плохо.
Нужно ли знать историю фронтенда, если просто пишешь на React? Да, и вот почему