Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Кстати, AngularDart использует Shadow DOM вместо ngTransclude для шаблонов компонентов, и есть подтвержденные планы о переносе этого же подхода в AngularJS в следующих версиях. Что вы об этом думаете?
Использовать Shadow DOM само по себе похвально, но вопрос во-первых в том, что это все сведется до ie10+, так как верстать(точнее применять стили) одновременно под shadow dom и не под shadow dom — смерти подобно. А во-вторых возникнет довольно неприятный диссонанс: web components нацелены на то, чтобы объединить различные варианты исполнения библиотек под одним стандартом, а библиотеки ангуляра вряд ли с ним точно совместимы, и визуальные компоненты для ангуляра будут развиваться парралельно.
Я сам все хочу перейти на dart — одни только строковая интерполяция и честные Maps чего стоят. И веб-компоненты, я надеюсь, позволят это сделать в ближайшее время (планируем несколько ie10+ проектов). Но на мой взгляд — лучше одновременно использовать polymer в качестве движка компонентов и анимаций, и angular для именно что логики приложения. Субьективно — им стоит в первую очередь подключить поддержку тэга template (я не знаю, возможно, они уже сделали, я честно не успеваю за всем развитием следить), чтобы Пользовательские Тэги могли безболезненно держаться в шаблонах. А сам по себе shadow DOM, насколько помню, убыстряет работу рендера (за счет того что тэги внутри теневого DOM не учитываются в querySelector, а внутри себя их хранится совсем немного), так что да, начинание замечательное. По моей опять же субьективной оценке — доля старых ie в большинстве сегментов снизится до 1-2% суммарно приблизительно к лету, если судить по динамике, и большинство команд будет иметь возможность работать со всем стеком Веб Компонентов.
Я сам все хочу перейти на dart — одни только строковая интерполяция и честные Maps чего стоят. И веб-компоненты, я надеюсь, позволят это сделать в ближайшее время (планируем несколько ie10+ проектов). Но на мой взгляд — лучше одновременно использовать polymer в качестве движка компонентов и анимаций, и angular для именно что логики приложения. Субьективно — им стоит в первую очередь подключить поддержку тэга template (я не знаю, возможно, они уже сделали, я честно не успеваю за всем развитием следить), чтобы Пользовательские Тэги могли безболезненно держаться в шаблонах. А сам по себе shadow DOM, насколько помню, убыстряет работу рендера (за счет того что тэги внутри теневого DOM не учитываются в querySelector, а внутри себя их хранится совсем немного), так что да, начинание замечательное. По моей опять же субьективной оценке — доля старых ie в большинстве сегментов снизится до 1-2% суммарно приблизительно к лету, если судить по динамике, и большинство команд будет иметь возможность работать со всем стеком Веб Компонентов.
Вот сколько я смотрю на вэбкомпонетны, все эти shadow dom и иже с ними, ну это же просто нормально реализованный asp.net на javascript.
Все развивается по спирали.
ASP.NET был громоздким, не гибким, медленным, но у него был отличный фреймворк. Все его хаяли. И поэтому родился ASP.NET MVC.
JS был легким, быстрым, гибким, но все надо было писать самому и с нуля. Все его хаяли. И поэтому рождалось все больше фреймворков.
Чувствую скоро будет та точка, где они пересекутся.
И обнимутся все, и заплачут.
ASP.NET был громоздким, не гибким, медленным, но у него был отличный фреймворк. Все его хаяли. И поэтому родился ASP.NET MVC.
JS был легким, быстрым, гибким, но все надо было писать самому и с нуля. Все его хаяли. И поэтому рождалось все больше фреймворков.
Чувствую скоро будет та точка, где они пересекутся.
И обнимутся все, и заплачут.
Я может быть чего-то не понимаю про эти компоненты, но W3C получается додумалась до .htc?
Сегодня WebComponents это buzzword как раньше был HTML5. Это прекрасная идея кастомного HTML элемента (которая существовала с эпохи Web 2.0) и несколько API, которые делают жизнь чуть-чуть проще. Я думаю, что для вас не секрет, что каждый первый web-UI-движок так или иначе позволяет создавать такой элемент, что BEM Tools, что React, что jQueryUI. Совсем другое дело это какой интерфейс будет на выходе и на сколько сложно в него вникнуть.
Не думаю, что тут стоит употреблять «закостылять». Сегодня эти «костыли» помогают создавать приложения под все платформы, позволяют писать компоненты, которые можно реиспользовать в рамках ваших договоренностей. Просто нужно их понять как и любой другой API в том числе Web Components.
Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.
«Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.
Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.
W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.
Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
Не думаю, что тут стоит употреблять «закостылять». Сегодня эти «костыли» помогают создавать приложения под все платформы, позволяют писать компоненты, которые можно реиспользовать в рамках ваших договоренностей. Просто нужно их понять как и любой другой API в том числе Web Components.
Я считаю, что утверждение «стандарт построения кастомного HTML элемента спасет мир» — это миф. Опять будет тасяча галерей, просто написанных на WebComponents API. И, я уверен, что вы напишете свою потому как чужие галереи несут такой невероятные оверхэд по количеству поддерживаемых фичей из-за того, что их создатель не понимает KISS.
«Прописал импорт компоненты с CDN и вуаля» — так не будет. Мы и через 10 лет будем пытаться сокращать количество запросов. Как обычно скачаем все компоненты и будем использовать инструменты для сборки этих компонент.
Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.
W3C молодцы, что выделили эту часть HTML5 в отдельное понятие Web Components. По крайней мере теперь разработчики будут копаться в этом слове (Components) и начнут осознавать, что жирные библиотеки вроде jQuery нужно заменять маленькими компонентами(модулями), которые будут использоваться на 100%.
Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
Понимаете, дело именно в том, что я отказался от собственного аналогичного решения, поняв, что оно идет к x-tags. Причем об x-tags я узнал тогда, когда не только api обоих библиотек совпадало процентов на 70, но и общий внутренний поток выполнения (там есть много спорных интересных моментов, я изучал именно из-за этого) был приближен настолько, насколько он может быть приближен у библиотек с разными механиками. И в общем-то за те несколько месяцев, что знаком с x-tags, испытал определенные, пусть и не очень значительные, проблемы с оставшимися 30%.
Все те решения, которые сделаны в рамках спеки Веба Компонентов, я прочувствовал на своей личной шкуре в ходе разработки реальных проектов, и получил тот опыт, который нельзя получить, просто сидя и рассуждая об этом всем.
Консорциум молодцы именно в том плане, что для создания единой спецификации регистрирования зависимых изолированных объектов, привязываемых к DOM, учли все ошибки предыдущих подобных архитектур, и то, что есть сейчас в этой спецификации, в общем-то можно сказать что выстрадано.
Я хотел рассказать именно о том, почему были приняты именно такие решения в спецификации, почему они важны для компонентов, и почему это лучшее из того, что есть среди множества вариантов. Ну и, конечно, ответить на кучу еще не заданных вопросов.
Не можем. Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child {margin-right: 20px}, потому что ему надо у всех конечных элементов отступы делать, и все полетит к чертям. Да, это проблема вебмастера, а не разработчика компонента, но лучше бы этой проблемы не было вообще. Мы все делаем решения для людей, а люди могут ошибаться. Поэтому в любом случае нужно подключать shadow DOM, если есть возможность. Вам дают возможность подстелить соломку, так воспользуйтесь ей.
Если честно, я вообще обычно 90% времени на vanilla пишу, если это работа с DOM. Ну это так, лирическое отступление.
Честно говоря, я не могу точно определить, какую вы мысль хотели сказать, но в общем и целом — я скорее склонен согласиться. Нет, Веб Компоненты — это не buzzword, потому что он достаточно сильно ограничен по спецификации, вы не можете взять и воткнуть его куда-то (хотя я верю в то, что продажники в веб-студиях и с этим справятся), в отличии от HTML5, который охватывает такое количество стандартов, что куда не плюнь — всюду он. Анимации, новые интерфейсы, css3, es5, кастомные тэги, канвас, вебгл, сокеты — это все подпадает, и трудно понять, о чем ведет диалог человек. Веб Компоненты же это новый вариант создания модулей, который позовляет получить (почти) гарантированную инкапсуляцию кода, верстки, и стилей, и получить действительно удобный и стандартизированный интерфейс к ним. Именно об этом я и говорю — можно пользоваться БЭМ, React, но в итоге все действительно сведется к нативным вещам, потому что они действительно одновременно более удобные, безопасные, быстрые, и наиболее легкопереносимые. Это факт, и с ним придется мириться тем же фанатам БЭМ, например.
Все те решения, которые сделаны в рамках спеки Веба Компонентов, я прочувствовал на своей личной шкуре в ходе разработки реальных проектов, и получил тот опыт, который нельзя получить, просто сидя и рассуждая об этом всем.
Консорциум молодцы именно в том плане, что для создания единой спецификации регистрирования зависимых изолированных объектов, привязываемых к DOM, учли все ошибки предыдущих подобных архитектур, и то, что есть сейчас в этой спецификации, в общем-то можно сказать что выстрадано.
Я хотел рассказать именно о том, почему были приняты именно такие решения в спецификации, почему они важны для компонентов, и почему это лучшее из того, что есть среди множества вариантов. Ну и, конечно, ответить на кучу еще не заданных вопросов.
Shadow DOM и Scoped CSS поможет избежать конфликтов «Встраиваемым приложениям» (Disqus например). В прочем, мы можем и так можем свести количество конфликтов к 0, используя кастомные теги (как делают API Яндекс Карт) и методологию BEM.
Не можем. Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child {margin-right: 20px}, потому что ему надо у всех конечных элементов отступы делать, и все полетит к чертям. Да, это проблема вебмастера, а не разработчика компонента, но лучше бы этой проблемы не было вообще. Мы все делаем решения для людей, а люди могут ошибаться. Поэтому в любом случае нужно подключать shadow DOM, если есть возможность. Вам дают возможность подстелить соломку, так воспользуйтесь ей.
Начните пользоваться Компонентами (без Web-) и начните забывать слово Библиотека, например, попробуйте выкинуть jQuery и заменить его на что-то более изящное.
Если честно, я вообще обычно 90% времени на vanilla пишу, если это работа с DOM. Ну это так, лирическое отступление.
Честно говоря, я не могу точно определить, какую вы мысль хотели сказать, но в общем и целом — я скорее склонен согласиться. Нет, Веб Компоненты — это не buzzword, потому что он достаточно сильно ограничен по спецификации, вы не можете взять и воткнуть его куда-то (хотя я верю в то, что продажники в веб-студиях и с этим справятся), в отличии от HTML5, который охватывает такое количество стандартов, что куда не плюнь — всюду он. Анимации, новые интерфейсы, css3, es5, кастомные тэги, канвас, вебгл, сокеты — это все подпадает, и трудно понять, о чем ведет диалог человек. Веб Компоненты же это новый вариант создания модулей, который позовляет получить (почти) гарантированную инкапсуляцию кода, верстки, и стилей, и получить действительно удобный и стандартизированный интерфейс к ним. Именно об этом я и говорю — можно пользоваться БЭМ, React, но в итоге все действительно сведется к нативным вещам, потому что они действительно одновременно более удобные, безопасные, быстрые, и наиболее легкопереносимые. Это факт, и с ним придется мириться тем же фанатам БЭМ, например.
> Какой-нибудь шибанутый (простите) вебмастер может залихватски сделать что-нибудь вроде footer :last-child
Вот именно, что всегда говорят о разных уровнях вэба. Есть сайт портфолио, или gmail подобное приложение. В последнем я очень сомневаюсь, что будет ситуация когда `шибанутый вэбмастер`, потому что это совсем разного уровня приложения и зачастую разного уровня люди их делают.
И разумеется, я с вами о shadow dom согласен — это здорово. Но подобный аргумент удивил :)
Вот именно, что всегда говорят о разных уровнях вэба. Есть сайт портфолио, или gmail подобное приложение. В последнем я очень сомневаюсь, что будет ситуация когда `шибанутый вэбмастер`, потому что это совсем разного уровня приложения и зачастую разного уровня люди их делают.
И разумеется, я с вами о shadow dom согласен — это здорово. Но подобный аргумент удивил :)
Веб Компоненты могут убрать эту фрагментированность: все компоненты будут совместимы друг с другом, потому что это будет просто HTML.Я согласен, что они будут работать. Однако вы не будете использовать компоненты написанные на «чужом языке» и сделанные «чужим инструментом» потому как эти компоненты могут тянуть какие-то тяжелые зависимости (платформу), вы не будете понимать как они устроены и напишете свой. Да они будут скомпилированы в CSS, HTML и JS но сорцы их будут на Stylus, Jade и например TypеScript с примесью React.
А вам правда часто нужно править чужую библиотеку? Воспринимайте это не как часть сайта, но как его изолированный блок. Как… ну, лайки фейсбука. Или Disqus. Вполне возможно, что Disqus сделан на JSX+stylus или Dart+less. Вы ведь не думаете об этом, правда? Ну, вот и тут то же самое. Оно просто работает. Ну, еще надо добавить конфигурацию.
Вэб компоненты крутые, в силу того, что шаблон проектирования `Компонент` очень классный и никак не наоборот. И для построения большого вэб приложения им одним «сыт» не будешь. В этой шумихе все, как и вы — огромный акцент делают на `third-party components` — как бы — «подключил и забыл». Но имея также огромный опыт работы с компонентами я пришел к выводу, что очень сложно сделать универсальный компонент. Поэтому мы будем все равно преимущественно иметь «локальные» компоненты, и только несколько вендорных. В силу этого и разговор нужно вести в этом направлении. Как Вэб компоненты помогают структурировать приложение, как выглядит сборка приложения, какие паттерны скрыты в Компоненте (инкапсуляция html, css конечно же одна из самых классных, что я вижу) и прочее.
очень простой пример. Просто посмотрите на то количество библиотек для jQuery, которое используют люди. Тот же jQuery UI. Фактически любой из них можно просто и непринужденно превратить в автономный компонент, который можно будет подключать даже верстальщику.
И это действительно очень важно. Визуальная составляющая вновь отходит в ведование верстальщиков, а фронтэнд-разработчики становятся именно разработчиками.
Я бы вел весь диалог скорее вот в этом направлении.
И это действительно очень важно. Визуальная составляющая вновь отходит в ведование верстальщиков, а фронтэнд-разработчики становятся именно разработчиками.
Я бы вел весь диалог скорее вот в этом направлении.
можете посмотреть, библиотека CornerJS. Я начал ее вести от директив ангуляра, там был похожий синктаксис: имя директивы — колбэк.
Директива — тэг, стиль или атрибут (с префиксом directive или data). Со временем (где-то полгода) это преобразилось в реально подобие x-tags: колбэк на добавление директивы в дом-дерево (оох я намучался с добавлением или удалением класса к существующему элементу), колбэк на деструктор, колбэк на смену атрибута. На создание тэга это было нереально в силу особенностей реализации: если конструктор-колбэк для HTMLCustomElement может быть создан, то на добавление класса или атрибута это слабореализуемо.
К моей радости, у нас появилось достаточно большое количество джуниоров, которые открыты к новым концепциям. Особенности и механики CornerJS они освоили за часа четыре, после этого появился небольшой внутренний репозиторий директив: удобный скроллбокс, несколько дропдаунов, обертка для mediaelement.js, слайдер, попапы, в общем стандартный базовый набор.
На x-tags мы перешли на днях, у ребят по первому проекту на них. Говорят, даже удобнее, правда немного путаются с колбеками на инициализацию. Думаю, следующий проект у каждого из них будет ie10+, и можно будет дать нативные тэги и немножко полимер.
Относительно «какие сайты делаем» — разброс большой. В портфолио много промо-проектов, но вот конкретно сейчас я отвечаю за разработку видеопортала/социальной сети для видеомейкеров (не знаю как это правильно назвать). Сейчас где-то на две трети уже все готово, запущено, работает. Если посмотреть по распределению количества кода на фронтэнде: 10% ядро приложения, 40% скомпилированные шаблоны, 40% — директивы. 10% — вендорные либы. Больше кода нет. Суммарно это весит где-то 800кб, в гзипнутом состоянии — 220кб. Там, к сожалению, шаблоны не жмутся даже через простейший компрессор, просто перестают отрабатывать, поэтому так хорошо жмется. Пока не успеваю сесть и разобраться в чем дело, а так — в сжатом состоянии оно выходило около 400кб, ну и жалось до 150.
Ладно, это долгая история, и ей тоже место на хабре, но когда во-первых ядро выползет в опенсорс (я сейчас этим занимаюсь, будет простейший изоморфный express-мимикрирующий фреймрорк), а во-вторых мы закончим этот проект. Сейчас он по скорости работает быстрее чем ютуб, и это уже с учетом того, что мы при запуске немного накосячили, и теперь ориентированный на русскую команду сайт хостится в ДЦ амазона Северной Вирджинии. Думаем перевести в Ирландию в следующем месяце. Ладно, это долгая история, куда-то меня не туда понесло.
В общем, я хотел сказать, что на опыте нескольких команд, работающих с совершенно разными как по контенту, так и по формату сайтами, и работая на немного разных языках (треть команды пишет на coffeeScript, это считается ок, плюс лично я заигрываю с TypeScript и Dart), мы используем 20-40% написанных в прошлых проектах директив. Правда, они не считаются за компоненты, и они могут играть вполне прикладную роль, в том числе роль «костыля» — например, есть директива, которая закрывает попап через n секунд после появления, соответственно в попап добавляется эта директива, и по его появлению начинает работать.
К тэгам сразу же заложено более аккуратное отношение инициативой сверху.
Директива — тэг, стиль или атрибут (с префиксом directive или data). Со временем (где-то полгода) это преобразилось в реально подобие x-tags: колбэк на добавление директивы в дом-дерево (оох я намучался с добавлением или удалением класса к существующему элементу), колбэк на деструктор, колбэк на смену атрибута. На создание тэга это было нереально в силу особенностей реализации: если конструктор-колбэк для HTMLCustomElement может быть создан, то на добавление класса или атрибута это слабореализуемо.
К моей радости, у нас появилось достаточно большое количество джуниоров, которые открыты к новым концепциям. Особенности и механики CornerJS они освоили за часа четыре, после этого появился небольшой внутренний репозиторий директив: удобный скроллбокс, несколько дропдаунов, обертка для mediaelement.js, слайдер, попапы, в общем стандартный базовый набор.
На x-tags мы перешли на днях, у ребят по первому проекту на них. Говорят, даже удобнее, правда немного путаются с колбеками на инициализацию. Думаю, следующий проект у каждого из них будет ie10+, и можно будет дать нативные тэги и немножко полимер.
Относительно «какие сайты делаем» — разброс большой. В портфолио много промо-проектов, но вот конкретно сейчас я отвечаю за разработку видеопортала/социальной сети для видеомейкеров (не знаю как это правильно назвать). Сейчас где-то на две трети уже все готово, запущено, работает. Если посмотреть по распределению количества кода на фронтэнде: 10% ядро приложения, 40% скомпилированные шаблоны, 40% — директивы. 10% — вендорные либы. Больше кода нет. Суммарно это весит где-то 800кб, в гзипнутом состоянии — 220кб. Там, к сожалению, шаблоны не жмутся даже через простейший компрессор, просто перестают отрабатывать, поэтому так хорошо жмется. Пока не успеваю сесть и разобраться в чем дело, а так — в сжатом состоянии оно выходило около 400кб, ну и жалось до 150.
Ладно, это долгая история, и ей тоже место на хабре, но когда во-первых ядро выползет в опенсорс (я сейчас этим занимаюсь, будет простейший изоморфный express-мимикрирующий фреймрорк), а во-вторых мы закончим этот проект. Сейчас он по скорости работает быстрее чем ютуб, и это уже с учетом того, что мы при запуске немного накосячили, и теперь ориентированный на русскую команду сайт хостится в ДЦ амазона Северной Вирджинии. Думаем перевести в Ирландию в следующем месяце. Ладно, это долгая история, куда-то меня не туда понесло.
В общем, я хотел сказать, что на опыте нескольких команд, работающих с совершенно разными как по контенту, так и по формату сайтами, и работая на немного разных языках (треть команды пишет на coffeeScript, это считается ок, плюс лично я заигрываю с TypeScript и Dart), мы используем 20-40% написанных в прошлых проектах директив. Правда, они не считаются за компоненты, и они могут играть вполне прикладную роль, в том числе роль «костыля» — например, есть директива, которая закрывает попап через n секунд после появления, соответственно в попап добавляется эта директива, и по его появлению начинает работать.
К тэгам сразу же заложено более аккуратное отношение инициативой сверху.
нет, почему? рендеринг может быть на обоих сторонах: это может быть полностью-фронтэнд сайт (ангуляр без модуля для express,), правда в этом случае будут некоторые небольшие тонкости в связи с шаблонами, классический с перезагрузкой между страницами, и stateless (не знаю как правильно назвать) с первоначальной загрузкой уже отрендеренной страницы и дальнейшими динамическими переходами.
Спасибо за отличную статью, с ее помощью в голове все уложилось лучше чем от прошлой. Даже понял, что был не совсем корректен сравнивая Dojo Widgets и Web Components.
Но JavaScript API работы с компонентами так и не понял. Если JS внутри компонента изолирован, то как компонент общается с внешним миром? Выставляет set/get/watch? Судя по статье на html5rocks он вообще ничего не предоставляет и set/get и методы работы с дочерними компонентами нужно описывать самому. Polymer позволяет регистрировать созданные виджеты и выставлять их свойства в качестве атрибутов, но в описании Web Components я ничего такого не нашел.
Абсолютная самостоятельность компонентов может быть очень вредна. Без механизма наследования и зависимостей мы рискуем получить сайты, которые подключают десятки надерганных из разных мест компонентов, которые на 90% имеют дублирующий код. Собственно как сейчас часто происходит с JQuery плагинами.
Но JavaScript API работы с компонентами так и не понял. Если JS внутри компонента изолирован, то как компонент общается с внешним миром? Выставляет set/get/watch? Судя по статье на html5rocks он вообще ничего не предоставляет и set/get и методы работы с дочерними компонентами нужно описывать самому. Polymer позволяет регистрировать созданные виджеты и выставлять их свойства в качестве атрибутов, но в описании Web Components я ничего такого не нашел.
Абсолютная самостоятельность компонентов может быть очень вредна. Без механизма наследования и зависимостей мы рискуем получить сайты, которые подключают десятки надерганных из разных мест компонентов, которые на 90% имеют дублирующий код. Собственно как сейчас часто происходит с JQuery плагинами.
ну, я просто не понаслышке знаком с этими механизмами, и хотел попытаться объяснить, почему все сделано именно так — в меру моего понимания. Это не официальная точка зрения, просто я самостоятельно ко всему этому пришел с другой стороны вообще, и вижу теперь причины сложных решений.
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут. В статье $.whenLive я начал, хотел расписать поподробнее, и вот что вышло)
Насчет инкапсуляции JS — гхм, ну тут не совсем корректно говорить именно про инкапсуляцию. Суть в том, что все сводится к HTMLCustomElement.prototype. Вы можете создавать любые элементы, при этом у них будет общий интерфейс: новые методы и свойства нативных элементов, это будет ожидаемо, и будет нормально работать умная IDE, подсказывая методы.
Относительно механизма наследования и зависимостей — вопрос решается CDN и централизованным репозиторием, не пакетным менеджером даже.
Подход простой: 1 тэг == 1 html import до него. Все зависимости так же подключаются импортами. Дальше в дело вступают нативные механизмы кэширования браузера, и в итоге подсасывается минимум библиотек. В идеале — на таком CDN должно быть выставлено «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша. Это немного замедлит загрузку одиночных сайтов, но значительно ускорит веб в целом.
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут. В статье $.whenLive я начал, хотел расписать поподробнее, и вот что вышло)
Насчет инкапсуляции JS — гхм, ну тут не совсем корректно говорить именно про инкапсуляцию. Суть в том, что все сводится к HTMLCustomElement.prototype. Вы можете создавать любые элементы, при этом у них будет общий интерфейс: новые методы и свойства нативных элементов, это будет ожидаемо, и будет нормально работать умная IDE, подсказывая методы.
Относительно механизма наследования и зависимостей — вопрос решается CDN и централизованным репозиторием, не пакетным менеджером даже.
Подход простой: 1 тэг == 1 html import до него. Все зависимости так же подключаются импортами. Дальше в дело вступают нативные механизмы кэширования браузера, и в итоге подсасывается минимум библиотек. В идеале — на таком CDN должно быть выставлено «вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша. Это немного замедлит загрузку одиночных сайтов, но значительно ускорит веб в целом.
Статья вообще начиналась про то, что писать свои костыли для запуска кода на появление элемента в dom-дереве моветон, и хотел рассказать о том, какие косяки всплывут
Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.
нормально работать умная IDE, подсказывая методы
умные IDE это и сейчас умеют. Для сторонних фреймворков проблема решается созданием словаря API виджетов во время сборки проекта и скармливанием его движку autocomplete-a IDE. В нашем фреймворке так и делаем.
Про импорты не понял. Например, сейчас у меня есть миксин _FormValue от которого наследуются все инпут-виджеты. Кто-то из них оставляет отнаследованный метод, кто-то его оверрайдит. Как такой же механизм может быть реализован в компонентах?
«вечное» кэширование, и единожды загруженный элемент будет загружаться всегда из кэша
веб постоянно меняется. Если компонент не брошен своим автором, то в нем постоянно будет что-то меняться. И жесткий кеш будет только мешать.
Никогда не понимал зачем такое может понадобится. Даже с появлением mutationobserver это лишняя нагрузка на браузер и выглядит как ошибка в логике приложения.
Я тоже, но за последнюю неделю видел две таких библиотеки, одна в посте тут с пятидесятью с лишним плюсами, другую — в trending гитхаба. Потому и хотел обьяснить неправильность.
С наследованием — там все проще некуда, по сути это «почти-честные-классы». У элемента обьявляются методы и свойства. Если другой элемент его расширяет — методы-свойства родителя наследуются. Ну как всегда, все довольно предсказуемо.
Там же вроде бы достаточно сильный акцент был сделан на расширение встроенных классов, чтобы можно было буквально в двадцать строк сделать свой x-form и x-input.
веб постоянно меняется. Если компонент не брошен своим автором, то в нем постоянно будет что-то меняться. И жесткий кеш будет только мешать.
Вы с google hosted libraries разве не работали?
Посмотрите на пример пути и все сами поймете
//ajax.googleapis.com/ajax/libs/angularjs/1.2.10/angular.min.js
Как то всё очень сложно. Мне кажется веб всё дальше превращают в крайне сложную и наслоеную архитектуру. По моему в рамках HTML/CSS/JS не надо ничего придумывать, надо найти замену для этого зоопарка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Web Components — это единственное светлое будущее веба. Смиритесь