Pull to refresh

Comments 37

Ну да, есть, только они к сожалению не модульные, эти технологии хорошие, но сделаны для других целей. Для доставки — да, не для компоновки.

В процессе разработки нового YouTube, ребятам пришлось создать over чем 400 специальных Custom Elements. В принципе — не так много для YouTube, только все они попали в глобальную область видимости. Согласитесь — отсутствие модульности это проблема.

Вы точно знакомы с веб-компонентами? Если написаны соответствующим образом, то они такие модульные, что дальше некуда. Можно комбинировать вместе компоненты от разных разработчиков не переживая за несовместимость фреймворков. Ни о какой глобальной области видимости речи тоже нет, у каждого компонента отдельное состояние, отдельное изолированное теневое дерево со своими, ни с чем не конфликтующими, стилями.

Конечно, каждый компонент имеет своё теневое дерево, но я имел в виду то, что все Custom Elements регистрируются в единой области, и это несколько мешает, например при внутренней декомпозиции.
W3View — если хотите, -это то, что я ждал от Web Components, но не дождался.
Каждый модуль в W3View имеет свой собственный нейм спейс и при подключении в другой модуль экспортирует его (как модуль в JS). Исключаются конфликты имён.

У веб-компонентов тоже есть пространства имен в виде префикса, именно для этого в стандарте веб-компонентов в именах регистрируемых компонентов должны быть -.


Таким образом на том же YouTube компоненты с префиксами youtube- и/или google- не будут конфликтовать с компонентами других производителей, если только кто-то не будет намеренно использовать те же префиксы.


Так что проблема потенциально существует в теории, но отсутствует на практике.

Если существует возможность, значит существует опасность

Вы сами, -не находите, что приведённый Вами аргумент выглядит не убедительно и даже наверное смешно?
Я повторюсь — Web Components — это хорошо но для других целей.

По-моему аргументы вполне адекватны и однозначно не смешные.


Вот вы говорите что веб-компоненты плохи для компоновки, но ни я ни те несколько людей что прочли статью и поставили +1 моему комментарию не поняли чем же ваше решение лучше для этой задачи. У меня сложилось впечатление что вы создаете те же веб-компоненты (например, <hello-world>Hello first</hello-world>), но:
1) Способом что не соответствует уже принятым и достаточно распространенным стандартам
2) Без инкапсуляции DOM событий и стилей


Возможно не хватает какого-то примера для сравнения подходов, но лично меня вы совершенно не убедили.

1. То, что Вы не поняли в чём моё решение — полностью моя вина, признаю и каюсь, эпистолярный жанр -не относится к моим сильным сторонам.
2. Библиотека не предназначена заменить собой Web Components.
3. Она может помочь при создании Shadow Root. Способом полностью основанным на давно принятых и действующих стандартах.
4. Она так-же может быть использована и вне контекста Web Components.
5. Инкапсуляция стилей не является задачей W3View, см. пп. 2 и 3
6. Возможно мне действительно стоит добавить примеры кода в статью, или написать ещё одну статью с развёрнутым how to, дабы снять в дальнейшем подобные недопонимания.
Наверное не очень правильно сравнивать W3View с Web Components, слишком разное назначение, и приложения собранные на W3View тоже можно оформить и дистрибьютировать в виде Web Component.
Для сравнения лучше подойдёт Polimer или React
Polymer это и есть Web Components так то.
UFO just landed and posted this here
Либа эта ещё что-то умеет, кроме своего собственного синтаксиса веб-компонентов?
Нет, даже своего собственного синтаксиса не имеет :) использует простой HTML и DOM API.
Позволяет православно создавать переиспользуемые компоненты, но разве этого мало?
Ну как это не имеет? Ваш синтаксис компонентов отличается от стандарта. Используются не стандартные аттрибуты типа «as», контекст скрипт-тега не очевиден и много других «собственных» велосипедов. Чтобы уж совсем православно, лучше для этого веб-стандарты использовать. У вас реализована лишь часть функционала веб-компонентов.

Однако для любого мало-мальски серьезного проекта одних лишь компонентов не достаточно и в этом контексте лично я не понимаю зачем мне тащить в проект лишние n-Кб, если я могу не тащить ничего лишнего.
Стандарт не запрещает кастомные атрибуты, использование стандартных атрибутов типа «name» или «id» в данном ключе ещё более неправославно, префикс «data» семантически не соответствует назначению.
Контекст скрипт-тега указывает на узел DOM, являющийся экземпляром компонента, к этому легко привыкнуть.
Библиотека не предназначена для замены/альтернативы Web Components.
2 kB — это не не так много, раз в 10 меньше, чем обычно тянут для такого-же назначения
Вы создаёте Shadow Root с помощью document.CreateElement? — уважаю, я тоже люблю настоящий хардкор.
Ну вот видите, вы уже 2 абзаца рассказываете мне о том, какой у вас синтаксис.))))

Я юзаю SvelteJS и тащу за собой 0Кб дополнительного кода.
Утомились поди читать, даже синтаксис увидели где-то :)
— Svelte — годная идея компилить всё в JS, я от неё отказался — чтобы в бандле было меньше килобайтов, оставил все эти createElement и appendChild в библиотеке.
— shared.js — тоже не ноль наверное, что ни будь да весит.
— Синтаксис пожалуй в пару абзацев не уложить.
В прочем зачётный выбор, благославляется.
— Svelte — годная идея компилить всё в JS, я от неё отказался — чтобы в бандле было меньше килобайтов, оставил все эти createElement и appendChild в библиотеке.

А с чего вы взяли что у вас в бандле от этого будет меньше килобайтов? Наоборот, он скорее всего будет даже больше.

— shared.js — тоже не ноль наверное, что ни будь да весит.

Конечно, это и есть фактически «библиотека», только фишка в том, что туда попадает только тот функционал, который реально используется. Причем для всех компонентов сразу и дублирования кода нет. Если интересно узнать какой оверхед для каждого компонента присутствует, можете почитать тут.

Утомились поди читать, даже синтаксис увидели где-то :)

Синтаксис пожалуй в пару абзацев не уложить.

Ну вы сравнили возможности Svelte и вашей поделки. Там и кастовые события, и обсерверы, и вычисляемые свойства и еще куча всего, без чего на реальных проектах туго приходится. На самом деле вот этой статьи достаточно, чтобы начать писать на нем.

Как применить вашу либу к реальному проекту, лично я не знаю. DOM API крайне скуден, да и работать c DOM напрямую давно уже считается анти-паттерном. Чтобы написать реальные проект на W3View придется его со всех сторон обвешать дополнительными либами. Зачем это нужно при наличии все тех же Web Components или тем более Svelte, я тоже не в курсе. Расскажете?
Походу поспешил с благословением, за шаблоны-незачёт
Вы же понимаете, что ваше благословение никому не нужно? ))) Лично мне удобнее работать с шаблонами. Да и в итоге то в Svelte не шаблоны генерируются, так что никаких минусов нет.
Насчёт «собственных» велосипедов, если уже зашла речь, — эта библиотека скорее самокат (поэтому много велосипедов в ней не поместилось), и уж точно не содержит термоядерных мега-костылей, которыми полны «чужие» велосипеды.

Круто! Это библиотека была бы очень крутой году эдак в 2001-м. Жаль, что на дворе уже 2018-й

Да, идея возникла именно в начале двухтысячных, но тогда не было принято делать подобные вещи, мы тогда генерировали HTML на сервере.
UFO just landed and posted this here
С чем сравниваем?
Либа не провоцирует создание лишнего кода, зато провоцирует декомпозицию.
Нарезал шаблон, навесил обработчики. Нарезать можно с любой требуемой гранулярностью, конфликты имён исключены.

осторожнее с пет проектами на W3View :), Вас может начать тошнить от %ваш_любимый_фреймворк% — проверено лично.

UFO just landed and posted this here
Циклы и условия в «шаблонах» -это то, чего я старался избежать, как и самих «шаблонов».
Логика должна реализовываться в скрипте. Для отображения списков специально предусмотрен встроенный компонент array-iterator он принимает на входе массивы.
Тип компонента можно передавать в рантайме.
UFO just landed and posted this here

если правда интересно, -в статье есть ссылки, постараюсь развёрнуто ответить на Ваш вопрос сегодня вечером.

Я пожалуй ещё статейку накропаю, мне понравилось
Тем, что вообще не похоже?
Ничем, оно другое совсем и для других целей
В этом году ожидается появление Angular Elements. На входе вся мощь Angular, а на выходе — «нативный компонент».
То есть ваше направление — правильное. Но пользоваться им никогда не стану так как не модно.
Похоже сейчас только ленивый не копирует идею SvelteJS.

Друзья, написал HowTo, как сумел.
Там в комментариях постараюсь отвечать на вопросы, если таковые возникнут

Sign up to leave a comment.

Articles