Комментарии 37
Ну да, есть, только они к сожалению не модульные, эти технологии хорошие, но сделаны для других целей. Для доставки — да, не для компоновки.
В процессе разработки нового YouTube, ребятам пришлось создать over чем 400 специальных Custom Elements. В принципе — не так много для YouTube, только все они попали в глобальную область видимости. Согласитесь — отсутствие модульности это проблема.
Вы точно знакомы с веб-компонентами? Если написаны соответствующим образом, то они такие модульные, что дальше некуда. Можно комбинировать вместе компоненты от разных разработчиков не переживая за несовместимость фреймворков. Ни о какой глобальной области видимости речи тоже нет, у каждого компонента отдельное состояние, отдельное изолированное теневое дерево со своими, ни с чем не конфликтующими, стилями.
W3View — если хотите, -это то, что я ждал от Web Components, но не дождался.
Каждый модуль в W3View имеет свой собственный нейм спейс и при подключении в другой модуль экспортирует его (как модуль в JS). Исключаются конфликты имён.
У веб-компонентов тоже есть пространства имен в виде префикса, именно для этого в стандарте веб-компонентов в именах регистрируемых компонентов должны быть -
.
Таким образом на том же YouTube компоненты с префиксами youtube-
и/или google-
не будут конфликтовать с компонентами других производителей, если только кто-то не будет намеренно использовать те же префиксы.
Так что проблема потенциально существует в теории, но отсутствует на практике.
Если существует возможность, значит существует опасность
Вы сами, -не находите, что приведённый Вами аргумент выглядит не убедительно и даже наверное смешно?
Я повторюсь — Web Components — это хорошо но для других целей.
По-моему аргументы вполне адекватны и однозначно не смешные.
Вот вы говорите что веб-компоненты плохи для компоновки, но ни я ни те несколько людей что прочли статью и поставили +1 моему комментарию не поняли чем же ваше решение лучше для этой задачи. У меня сложилось впечатление что вы создаете те же веб-компоненты (например, <hello-world>Hello first</hello-world>
), но:
1) Способом что не соответствует уже принятым и достаточно распространенным стандартам
2) Без инкапсуляции DOM событий и стилей
Возможно не хватает какого-то примера для сравнения подходов, но лично меня вы совершенно не убедили.
2. Библиотека не предназначена заменить собой Web Components.
3. Она может помочь при создании Shadow Root. Способом полностью основанным на давно принятых и действующих стандартах.
4. Она так-же может быть использована и вне контекста Web Components.
5. Инкапсуляция стилей не является задачей W3View, см. пп. 2 и 3
6. Возможно мне действительно стоит добавить примеры кода в статью, или написать ещё одну статью с развёрнутым how to, дабы снять в дальнейшем подобные недопонимания.
Для сравнения лучше подойдёт Polimer или React
Позволяет православно создавать переиспользуемые компоненты, но разве этого мало?
Однако для любого мало-мальски серьезного проекта одних лишь компонентов не достаточно и в этом контексте лично я не понимаю зачем мне тащить в проект лишние n-Кб, если я могу не тащить ничего лишнего.
Контекст скрипт-тега указывает на узел DOM, являющийся экземпляром компонента, к этому легко привыкнуть.
Библиотека не предназначена для замены/альтернативы Web Components.
2 kB — это не не так много, раз в 10 меньше, чем обычно тянут для такого-же назначения
Вы создаёте Shadow Root с помощью document.CreateElement? — уважаю, я тоже люблю настоящий хардкор.
— Svelte — годная идея компилить всё в JS, я от неё отказался — чтобы в бандле было меньше килобайтов, оставил все эти createElement и appendChild в библиотеке.
— shared.js — тоже не ноль наверное, что ни будь да весит.
— Синтаксис пожалуй в пару абзацев не уложить.
В прочем зачётный выбор, благославляется.
— Svelte — годная идея компилить всё в JS, я от неё отказался — чтобы в бандле было меньше килобайтов, оставил все эти createElement и appendChild в библиотеке.
А с чего вы взяли что у вас в бандле от этого будет меньше килобайтов? Наоборот, он скорее всего будет даже больше.
— shared.js — тоже не ноль наверное, что ни будь да весит.
Конечно, это и есть фактически «библиотека», только фишка в том, что туда попадает только тот функционал, который реально используется. Причем для всех компонентов сразу и дублирования кода нет. Если интересно узнать какой оверхед для каждого компонента присутствует, можете почитать тут.
Утомились поди читать, даже синтаксис увидели где-то :)
Синтаксис пожалуй в пару абзацев не уложить.
Ну вы сравнили возможности Svelte и вашей поделки. Там и кастовые события, и обсерверы, и вычисляемые свойства и еще куча всего, без чего на реальных проектах туго приходится. На самом деле вот этой статьи достаточно, чтобы начать писать на нем.
Как применить вашу либу к реальному проекту, лично я не знаю. DOM API крайне скуден, да и работать c DOM напрямую давно уже считается анти-паттерном. Чтобы написать реальные проект на W3View придется его со всех сторон обвешать дополнительными либами. Зачем это нужно при наличии все тех же Web Components или тем более Svelte, я тоже не в курсе. Расскажете?
Круто! Это библиотека была бы очень крутой году эдак в 2001-м. Жаль, что на дворе уже 2018-й
Либа не провоцирует создание лишнего кода, зато провоцирует декомпозицию.
Нарезал шаблон, навесил обработчики. Нарезать можно с любой требуемой гранулярностью, конфликты имён исключены.
осторожнее с пет проектами на W3View :), Вас может начать тошнить от %ваш_любимый_фреймворк% — проверено лично.
То есть ваше направление — правильное. Но пользоваться им никогда не стану
W3View — библиотека на Javascript, для которой был создан HTML