Эх, я очень старался, честно.))) Возможно сыграло то, что все посылы оригинальной статьи были так или иначе направлены на меня. Только в более завуалированной форме. Я предпочитаю открытость и честность.
При компиляции в Web Components, который состоит из нескольких стандартов, среди которых Custom Elements и Shadow DOM, Svelte пытается использовать максимум возможностей встроенных в браузер. Иными словами компоненты получаются с использованием Shadow DOM для их изоляции. В этом ишаке предлагается, чтобы это поведение можно было настраивать.
В целом думаю было бы не плохо иметь такую возможность. Однако так как компиляция в веб-компоненты не является приоритетной для Svelte, а переделывать это видимо не просто, думаю это предложение имеет не очень высокий приоритет.
Было бы не плохо использовать какие-то конкретные примеры для аргументации. Насколько я помню, большая часть протагонистов просто выдавала свои субъективные мнения за объективную реальность, требуя «правильных» ответов взамен тех, которые им давали.
Я пишу статьи не для того, чтобы давать людям субъективно правильные на их взгляд ответы, а чтобы рассказать об инструменте и своем опыте с ним.
Странно приходить из React во Vue и с порога требовать, условно говоря, делать `this.setState({ foo: 1 })`, а не `this.foo = 1;`. А если оказывается что setState вовсе не нужен и есть способ лучше, уходить ворча, что все не так, да не эдак.
В телеграм чат часто приходят с готовым решением задачи, которое нужно срочно натянуть на Svelte, даже если оно натягивается с трудом. Такова природа человека — сперва мы пытается работать так как привыкли. Я и другие ребята в чате, кто активно юзает Svelte, всегда предлагаем говорить о сути задачи и стараемся предложить более подходящее решение. Собственно об этом я написал в разделе «Про (НЕ)осознанность». Если есть возможность перечитать — сделайте это пожалуйста.
Я так понял, статью вы не осилили. Жаль, я так старался для вас. Если кратко — все что вы написали, в той или иной степени, НЕ соответствует действительности и является лишь плодом ваших собственных мироощущений.
Вы даже не в курсе, что конкретно он предлагает или не предлагает. Демонстрируете полное не понимание как Svelte, так и других фреймворков. Да и вообще того, как работает OSS.
Я кстати не автор Svelte, но занимаюсь его евангелизмом и причем совершенно бесплатно. Есть такая штука open-source и чаще всего он community-driven. Слышали о таком? Там нет денег и никто вам ничего не должен. Каждый сам решает чем ему помочь или просто пройти мимо.
Вы, как я понял, все переводите в деньги. Но если бы никто не пробовал решения на свой страх и риск и не рассказывал об этом, то дальше не было бы ни большого коммьюнити, ни проверки продакшеном, ни экосистемы, ни ваших любимых работы и денег.
К сожалению или к счастью, но это данность. Раньше сообщество вообще находилось в Gitter. Потому когда переезжали, мы предлагали Телеграм, но англоязычные ребята выбрали Discord. Как-то так и повелось. Думаю все же это хорошо, потому что многие ребята из сообщества очень мотивированы общаться именно по-русски. Да и спросить помощь, понять помощь проще на родном языке, как ни крути. А что конкретно смущает по этому поводу?
Ради Бога, прошу вас изучите вопросы о которых планируете вести беседы, прежде чем позорится!
Так правда ли, что тот механизм, который используется в Svelte не совместим с нативными веб-компонентами? Т.е. например если после фаната Svelte кто-то добавит в проект компонент, взаимодействующий с компонентом Svelte, то он может поиметь проблем?
Со Svelte однозначно проблем не будет, потому что он html-first фреймворк. За тот же React ручаться нельзя, там реально с поддержкой стандартов плохо.
Я намеренно рассматриваю Shadow DOM и Virtual DOM как одно и то же в данном контексте. Потому что для меня это способ ускорить рендеринг в случае множества реактивных зависимостей и их обновления. Для этого используется в том числе ручное обновление, типа Deferred updates d Knockout.
Проблема в том, что это не одно и тоже НИ В КАКОМ КОНТЕКСТЕ. Более того, если про Virtual DOM можно с натяжкой сказать, что он «ускоряет рендеринг» (хотя это совершенно не так). То Shadow DOM не то что рендеринг НЕ ускоряет, а наоборот замедляет его в большинстве случаев. Все потому что Shadow DOM это про сокрытие (изоляцию) части DOM дерева. То есть про инкапсуляцию компонентов, а не про рендеринг вообще.
Про Virtual DOM тоже советую почитать. Однако постараюсь объяснить вам вкратце: нет и не может быть ничего быстрее чем рендеринг с помощью DOM API. А знаете почему? Потому что финальной точкой любого рендеринга все равно является использования DOM API и Virtual DOM точно также делает это. По сути Virtual DOM — это не про рендеринг вовсе, а про change detection.
Какой способ ускорения операций с DOM используется в Svelte?
Выше я уже написал, что нет никакой возможности ускорить операции DOM сами по себе. Браузер дает нам апи и даже если оно тормозное, как многие думают, другого у нас нет. Задача на самом деле звучит так: как нам делать меньше DOM операций на каждое изменение.
Вот как работает Virtual DOM:
То есть до того, как он непосредственно пишет в DOM, сперва происходят несколько подготовительных этапов в памяти.
Svelte работает проще:
Мне кажется что даже вам должно быть очевидно, что 4 кружка будут работать дольше чем 2 кружка. Но остается вопрос, куда же Svelte девал change detection и если все так просто, почему Virtual DOM просто не уберет Rerender/Reconcile?
Если совсем просто — инновация Svelte в том, что он взял эти дополнительные кружки и перенес их в buildtime, то есть на этап компиляции. Сделал он это за счет статического анализа и AoT компиляции.
Если вы хоть немного ферштейн по инглиш, то он всей души советую вам посмотреть внимательно видео: «Rethinking reactivity». Там вам расскажут про принципы работы Svelte лучше меня, а также про отличия от VDOM.
Либо вы утверждаете, что это был не случайный баг, а запланированный breaking change в минорной версии (что конечно недопустимо). Либо утверждаете, что в других фреймворках не бывает случайных багов, которые затесались в минорах. И то, и другое, имхо, что-то на грани фантастики.
Реакт топ-1 не просто так, а в том числе и потому, что на более традиционных устройствах работает достаточно хорошо, чтоб никто не считал себя дискриминированым.
Если вы правда так считаете, то это ваше право. Лично я вижу все больше переходов с React на другие решения именно по причине что он работает не так уж и хорошо.
Не взяли и не взяли. Дело ваше, проблем нет. Если вы умеете оценить свои потребности и риски, это отлично. У меня другой опыт, мы наоборот не взяли LitElement вот по каким причинам: 1) веб-компоненты не везде, полифилы работают коряво; 2) LitElement в сравнении со Svelte намного более громоздкий; 3) Svelte в любой момент можно скомпилировать в web components, на случай если они захавают мир (очень сомневаюсь).
Svelte не взял потому, что во-первых, как вы сами ниже написали, «cинтаксис у всех трех разный и не совместим» — получить в проде устаревшую версию потому, что завтра кому-то захочется несовместимый Svelte v4 мне не улыбается совсем.
Есть такое дело, но я ни раз уже отвечал почему так произошло — это были поиски аутентичного подхода в рамках агрессивной среды навязанных мнений. Считаю что поиски окончены. Интересно то, что мы сами можно сказать «пострадали» от этого и пришлось заложить некоторые время на реврайт приложения со Svelte 2 на Svelte 3. В итоге мы не пожалели, реврайт прошел без проблем и на половину был автоматическим.
Во-вторых — нет родной поддержки тайпскрипта, и сопротивление тайпскрипту по идеологическим причинам в стане svelte меня очень сильно напрягает, потому что это в чистом виде приоритет «шашечек» над «ехать». В проде я хочу строго обратного.
Нет никакого сопротивления. Есть мое мнение что TS нужен не всем, которое я время от времени высказываю и есть объективные причины почему внедрить TS в Svelte не просто. Большая часть этих причин связана с самим TS. Если бы их не было, Vue и Svelte давно бы уже обзавелись поддержкой TS, а Angular-у не понадобилось бы делать форк. Даже тот факт, что сам Svelte написан на TS говорит о том, что никакого сопротивления нет.
Ну и в-третьих, меня напрягает, что компонент svelte (если не билдить в веб-компоненты, а если билдить — то svelte тоже не нужен, проще сразу делать веб-компоненты) толком не доступен в рантайме для низкоуровневого доступа (там, в DOM влезть, например, или подобные вещи), и коммьюнити на обсуждения этого реагирует через «а вы просто так не пишите» — это всё прекрасно, когда всё пишется с нуля на svelte и так делать действительно не нужно, но не когда ты прикручиваешь в проект готовые библиотеки и решения, в том числе и довольно старенькие (но прекрасно работающие)
Прозвучит странно, но вы реально не разобрались. Наоборот, то что Svelte использует обычный DOM есть все средства делать с ним что угодно. Кроме встроенных рефок, всевозможных биндингов и оберток-экшенов, можно просто манипулировать им из DOM API. Другое дело, увлекаться этим не стоит.
PaulMaly ни одной статьи не написал с позиции «смотрите, мы вот тут решали вот такую проблему, и у нас вышло вот так с помощью svelte». Даже когда он касался своего опыта — это было написано в обратной последовательности: «смотрите, какой крутой svelte, и верьте мне, потому что я его тут юзаю для телевизоров и касс». Короче, не рассказы о реальных проблемах, а реклама с упоминанием реального опыта ради авторитетности.
Предлагаю оставить стиль и предпосылки повествования его авторам. Есть много других статей, от других авторов в хабе Svelte, стиль которых возможно придется по душе. Да и моих собственных статей о Svelte не там много на самом деле. 50/50 это переводы, а уж в их повествование лезть дело вообще не благодарное.
Ну и в любом случае, от разбора конкретно такой проблемы — особо большого выхлопа и не будет, потому что сколько-сколько в % от всего фронтэнда пишется для телевизоров и касс?
На самом деле это восходящий тренд, но пока он дошел не до всех. Да и не стоит дискриминировать юзеров более традиционных устройств, они также хотят быстрые и качественные приложения.
Странные утверждения, учитывая что примеры написанные автором этого «гениального» фреймворка всеми этими чертами ни разу не обладают. Ладно, думаю в этом кейсе дополнительная дискуссия не требуется.
Блин, вот почему все диалоги с тобой заканчиваются отмазками из разряда «я д'артаньян»? Задаю тебе вопрос об одном, ты переводишь тему на другое.
Короче делаю вывод — $mol спроектирован так, что не дает возможности переиспользовать готовую верстку и стили, без предварительной адаптации. Этот подход априори не подойдет 99% разработчиков, которые имеют отлаженный процесс разработки.
Странная логика. А если заказчик предоставит такой дизайн и структуру сайта, ты видимо откажешься и сразу уволишься? Смысл этого проекта в том что одно и тоже приложение делается на разных технологиях, но реализация на $mol не может участвовать в сравнении и она бесполезна.
Сдаётся мне что дело не в «религии», а в том что использовать готовую html вёрстку в $mol либо слишком сложно/больно, либо невозможно.
Эх, я очень старался, честно.))) Возможно сыграло то, что все посылы оригинальной статьи были так или иначе направлены на меня. Только в более завуалированной форме. Я предпочитаю открытость и честность.
В целом думаю было бы не плохо иметь такую возможность. Однако так как компиляция в веб-компоненты не является приоритетной для Svelte, а переделывать это видимо не просто, думаю это предложение имеет не очень высокий приоритет.
Я пишу статьи не для того, чтобы давать людям субъективно правильные на их взгляд ответы, а чтобы рассказать об инструменте и своем опыте с ним.
Странно приходить из React во Vue и с порога требовать, условно говоря, делать `this.setState({ foo: 1 })`, а не `this.foo = 1;`. А если оказывается что setState вовсе не нужен и есть способ лучше, уходить ворча, что все не так, да не эдак.
В телеграм чат часто приходят с готовым решением задачи, которое нужно срочно натянуть на Svelte, даже если оно натягивается с трудом. Такова природа человека — сперва мы пытается работать так как привыкли. Я и другие ребята в чате, кто активно юзает Svelte, всегда предлагаем говорить о сути задачи и стараемся предложить более подходящее решение. Собственно об этом я написал в разделе «Про (НЕ)осознанность». Если есть возможность перечитать — сделайте это пожалуйста.
Почему? Все ответы есть в статье.
Вы, как я понял, все переводите в деньги. Но если бы никто не пробовал решения на свой страх и риск и не рассказывал об этом, то дальше не было бы ни большого коммьюнити, ни проверки продакшеном, ни экосистемы, ни ваших любимых работы и денег.
Со Svelte однозначно проблем не будет, потому что он html-first фреймворк. За тот же React ручаться нельзя, там реально с поддержкой стандартов плохо.
Источник: custom-elements-everywhere.com
Проблема в том, что это не одно и тоже НИ В КАКОМ КОНТЕКСТЕ. Более того, если про Virtual DOM можно с натяжкой сказать, что он «ускоряет рендеринг» (хотя это совершенно не так). То Shadow DOM не то что рендеринг НЕ ускоряет, а наоборот замедляет его в большинстве случаев. Все потому что Shadow DOM это про сокрытие (изоляцию) части DOM дерева. То есть про инкапсуляцию компонентов, а не про рендеринг вообще.
Про Virtual DOM тоже советую почитать. Однако постараюсь объяснить вам вкратце: нет и не может быть ничего быстрее чем рендеринг с помощью DOM API. А знаете почему? Потому что финальной точкой любого рендеринга все равно является использования DOM API и Virtual DOM точно также делает это. По сути Virtual DOM — это не про рендеринг вовсе, а про change detection.
Выше я уже написал, что нет никакой возможности ускорить операции DOM сами по себе. Браузер дает нам апи и даже если оно тормозное, как многие думают, другого у нас нет. Задача на самом деле звучит так: как нам делать меньше DOM операций на каждое изменение.
Вот как работает Virtual DOM:
То есть до того, как он непосредственно пишет в DOM, сперва происходят несколько подготовительных этапов в памяти.
Svelte работает проще:
Мне кажется что даже вам должно быть очевидно, что 4 кружка будут работать дольше чем 2 кружка. Но остается вопрос, куда же Svelte девал change detection и если все так просто, почему Virtual DOM просто не уберет Rerender/Reconcile?
Если совсем просто — инновация Svelte в том, что он взял эти дополнительные кружки и перенес их в buildtime, то есть на этап компиляции. Сделал он это за счет статического анализа и AoT компиляции.
Если вы хоть немного ферштейн по инглиш, то он всей души советую вам посмотреть внимательно видео: «Rethinking reactivity». Там вам расскажут про принципы работы Svelte лучше меня, а также про отличия от VDOM.
И вот это:
Либо вы утверждаете, что это был не случайный баг, а запланированный breaking change в минорной версии (что конечно недопустимо). Либо утверждаете, что в других фреймворках не бывает случайных багов, которые затесались в минорах. И то, и другое, имхо, что-то на грани фантастики.
Если вы правда так считаете, то это ваше право. Лично я вижу все больше переходов с React на другие решения именно по причине что он работает не так уж и хорошо.
Мой доклад по мотивам изысканий: «Web Components, или Туда и обратно». Отличная статья по Web components: «Почему я не использую веб-компоненты»
Есть такое дело, но я ни раз уже отвечал почему так произошло — это были поиски аутентичного подхода в рамках агрессивной среды навязанных мнений. Считаю что поиски окончены. Интересно то, что мы сами можно сказать «пострадали» от этого и пришлось заложить некоторые время на реврайт приложения со Svelte 2 на Svelte 3. В итоге мы не пожалели, реврайт прошел без проблем и на половину был автоматическим.
Нет никакого сопротивления. Есть мое мнение что TS нужен не всем, которое я время от времени высказываю и есть объективные причины почему внедрить TS в Svelte не просто. Большая часть этих причин связана с самим TS. Если бы их не было, Vue и Svelte давно бы уже обзавелись поддержкой TS, а Angular-у не понадобилось бы делать форк. Даже тот факт, что сам Svelte написан на TS говорит о том, что никакого сопротивления нет.
Прозвучит странно, но вы реально не разобрались. Наоборот, то что Svelte использует обычный DOM есть все средства делать с ним что угодно. Кроме встроенных рефок, всевозможных биндингов и оберток-экшенов, можно просто манипулировать им из DOM API. Другое дело, увлекаться этим не стоит.
Предлагаю оставить стиль и предпосылки повествования его авторам. Есть много других статей, от других авторов в хабе Svelte, стиль которых возможно придется по душе. Да и моих собственных статей о Svelte не там много на самом деле. 50/50 это переводы, а уж в их повествование лезть дело вообще не благодарное.
На самом деле это восходящий тренд, но пока он дошел не до всех. Да и не стоит дискриминировать юзеров более традиционных устройств, они также хотят быстрые и качественные приложения.
Короче делаю вывод — $mol спроектирован так, что не дает возможности переиспользовать готовую верстку и стили, без предварительной адаптации. Этот подход априори не подойдет 99% разработчиков, которые имеют отлаженный процесс разработки.
Сдаётся мне что дело не в «религии», а в том что использовать готовую html вёрстку в $mol либо слишком сложно/больно, либо невозможно.