c
Ну понятно что логика работает с DOM API, для этого и в Angular, и в React есть рефы
то есть пользуемся НАТИВНЫМ апи через костыли
Size: a a a
2020 June 05
c
то есть ты берешь фреймворк, а он отбирает у тебя пачку нативных возможностей и необходимостей
🚀🚀
Ну понятно что логика работает с DOM API, для этого и в Angular, и в React есть рефы
нет, мы пишем клиентские приложения для dom api. он значительно превышает возможности выраженные в html, они попросту не совпадают
P
нет, мы пишем клиентские приложения для dom api. он значительно превышает возможности выраженные в html, они попросту не совпадают
Svelte под капотом создает нативные элементы, никакого VDOM
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
P
В большнистве кейсов этого не надо
🚀🚀
Svelte под капотом создает нативные элементы, никакого VDOM
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
это не имеет значения, речь не про то как библиотеки работают, разумеется они в конечном счёте имеют биндинг к дом апи, я не про них
P
А в чем тогда проблема?
🚀🚀
я про то, как они представляют эти абстракции нам
c
html не предоставляет никаких возможностей по управлению handlers, visibility, также никак не управляются текстноды и чайлды
jsx дает только одну возможность — handlers, но вообще не так как это дает dom, через дичайшую прослойку
при этом отбирает апи для data-аттрибутов
jsx дает только одну возможность — handlers, но вообще не так как это дает dom, через дичайшую прослойку
при этом отбирает апи для data-аттрибутов
c
Svelte под капотом создает нативные элементы, никакого VDOM
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
надо работать с нативными эвентами - ты можешь взять реф и подписаться явно на элемент
зачем брать фреймворк, если для полноценной работы мне нужно использовать обходные пути
P
зачем брать фреймворк, если для полноценной работы мне нужно использовать обходные пути
Эм, ну не надо - не бери)
P
Для большинства задач Svelte дает удобные абстракции
🚀🚀
одна из главных особенностей эффектора в том, что между самым простым и наилучшим путём он выбирает второе
ЕГ
Эм, ну не надо - не бери)
отвергать свою же платформу не вариант
c
Эм, ну не надо - не бери)
так в этом и прикол
forest — это отсутствие необходимости в компиляции и при этом минимальный набор ограничений с dom api
forest — это отсутствие необходимости в компиляции и при этом минимальный набор ограничений с dom api
🚀🚀
я ни на секунду не сомневался в том, какую реакцию увижу на предложение об отказе от неверных абстракций в ui
P
Ну типа если тебе не нравится писать <button …>, то можешь использовать document.createElement
🚀🚀
нет, не можешь
🚀🚀
не хватает реактивности
c
Ну типа если тебе не нравится писать <button …>, то можешь использовать document.createElement
h(‘button’)
при этом не теряя ни капли реактивности
не добавляя сложности в виде предварительных ласк компилятора фреймворка
стандартные для экосистемы babel + rollup/webpack/parcel и достаточно
но можно и без них
при этом не теряя ни капли реактивности
не добавляя сложности в виде предварительных ласк компилятора фреймворка
стандартные для экосистемы babel + rollup/webpack/parcel и достаточно
но можно и без них