W3View — библиотека на Javascript, для которой был создан HTML

Да, ещё одна новая библиотека на JS, хочу поделиться. Фидбека жажду, любого, лучше конечно позитивного конструктивного.


Программирую я с тех незапамятных времён, когда мониторы были глубокие и пузатые, а сервера могли потягаться с нынешними телефонами. Приходилось писать на разных языках и фронт и бэк от GUI до SQL и обратно.


Javascript очаровал меня ещё тогда, когда его применяли только для подсвечивания кнопок (CSS был не всегда). DOM API обещал сделать процесс программирования пользовательского интерфейса легким и непринуждённым делом, почти развлечением. Я прямо видел светлое, красивое будущее. Ну вот оно и наступило.


DOM API — самый правильный UI framework для браузера


Можете не соглашаться, но это так, и лечить я никого не собираюсь. Да, я прекрасно знаю о его недостатках, но достоинства перевешивают. Он самый быстрый, — мантры против этого бессильны.


Всё, чего не хватает (мне) для комфортной разработки — это возможности создания
переиспользуемых модулей с библиотеками составных компонентов. Все наши попытки создать такую возможность порождают радиоактивных монстров и велосипеды с Угловатыми колёсами.
Мы хотим малого и много делаем для этого, а получаем неудобства и тормоза.


Вы скажете — есть ведь Web Components...


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


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


W3View позволяет создавать переиспользуемые, модульные библиотеки компонентов


И даёт вам полный контроль над происходящим, реальный, без танцев с бубнами. У вас остаётся в руках вся мощь DOM API и над вами не нависают сомнительные концепции. Вам не нужно терпеть уродливый синтаксис темплетного языка, извращённый JSX или заклинательный data binding, у вас просто HTML, как он есть, такой, каким его задумал создатель.


// библиотека компонентов началась!
// описание компонента "hello-world"
<div as="hello-world">
    <h1 ref="content"></h1>
    <input ref="input" placeholder="type your name here">
    <h1>Hello <span ref="name">Anonimous</span>!</h1>

    <script type="javascript">
        this.ref.input.onkeydown =
                this.ref.input.onkeyup = function(e){
            me.setData(me.ref.input.value);
        };
        this.onSetData = function(data){
            me.ref.name.innerText = data || 'Anonimous';
        };
    </script>
</div>

// описание компонента "сдвоенный hello-world" - это будет рут
<div as="double-hello-world">
    <hello-world>Hello first</hello-world>
    <hr>
    <hello-world>Hello second</hello-world>
</div>

Когда вы подключите "double-hello-world" на страницу, вы увидите hello-world в действии.
Вот ещё пример, чуть посложнее. Ну и куда-же без TodoMVC? (все делают, и я сделал).


В приведённых примерах библиотеки компонентов очень маленькие и встроены прямо в тело страницы, но вы можете загружать их как модули с разрешением зависимостей на лету, или подключать предварительно сформированный JS бандл.
Бандл загружается чуть быстрее и его можно минифицировать.


W3View не навязывает вам ничего, просто расширяет ваши возможности


Вы можете применить любую структуру приложения, — MVC, MVP, MVVM или Flux. Можете использовать всяческие обсерверы и диспетчеры, — всё что вашей душе угодно. Вы можете проектировать бизнес-модель совершенно не зависящую от навязываемых фреймворками правил. Вам не нужно будет размазывать логику обновления UI по шаблону и выражать её невыразимыми способами, бродить обходными путями, заниматься тонкой настройкой, искать ответы на странные вопросы (should этот компонент update или не should?) и ночевать на
форумах с огромными комьюнити, чтобы ни дай бог не пропустить вечно ускользающую и единственную ИСТИНУ. Без этого всего можно жить, — правда, можно.


Размер имеет значение, (что — бы ни говорила бабушка)


  • Основная библиотека занимает целых 378 строк нормально структурированного кода.
  • Сама (без moduleLoader) весит около 10.5 kB в исходниках и всего 2.1 kB minify + gz.
  • Исходники moduleLoader + httpreader добавят вместе ещё ~2.8 kB.

В заключение


Если вас заинтересовала эта штуковина — вы можете зайти на GitHub или установить её через npm


npm install -s w3view

(и то и другое бесплатно)


Наверное ещё есть что доработать в W3View: подключение JS модулей например, loader для webpack, наверняка что-то можно оптимизировать. Я обязательно, чуть позже, займусь этим, или кто-нибудь мне поможет (импорто-замещение всётаки).


Если вам понравилось или не понравилось то, что я уже сделал — не стесняйтесь,
пишите комментарии, любые подойдут.


Спасибо.

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

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

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

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

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


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


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

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

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

            +1

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


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


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

              +1
              1. То, что Вы не поняли в чём моё решение — полностью моя вина, признаю и каюсь, эпистолярный жанр -не относится к моим сильным сторонам.
              2. Библиотека не предназначена заменить собой Web Components.
              3. Она может помочь при создании Shadow Root. Способом полностью основанным на давно принятых и действующих стандартах.
              4. Она так-же может быть использована и вне контекста Web Components.
              5. Инкапсуляция стилей не является задачей W3View, см. пп. 2 и 3
              6. Возможно мне действительно стоит добавить примеры кода в статью, или написать ещё одну статью с развёрнутым how to, дабы снять в дальнейшем подобные недопонимания.
                0
                Делайте статью. Мне, например, ваш подход нравится, но я нифига до конца не понял.
        0
        Наверное не очень правильно сравнивать W3View с Web Components, слишком разное назначение, и приложения собранные на W3View тоже можно оформить и дистрибьютировать в виде Web Component.
        Для сравнения лучше подойдёт Polimer или React
          0
          Polymer это и есть Web Components так то.
        0
        >>Наверное ещё есть что доработать в W3View

        Наверное есть, но то что уже есть впечатляет — спасибо
          +1
          Либа эта ещё что-то умеет, кроме своего собственного синтаксиса веб-компонентов?
            0
            Нет, даже своего собственного синтаксиса не имеет :) использует простой HTML и DOM API.
            Позволяет православно создавать переиспользуемые компоненты, но разве этого мало?
              0
              Ну как это не имеет? Ваш синтаксис компонентов отличается от стандарта. Используются не стандартные аттрибуты типа «as», контекст скрипт-тега не очевиден и много других «собственных» велосипедов. Чтобы уж совсем православно, лучше для этого веб-стандарты использовать. У вас реализована лишь часть функционала веб-компонентов.

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

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

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

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

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

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

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

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

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

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

                  0
                  Да, идея возникла именно в начале двухтысячных, но тогда не было принято делать подобные вещи, мы тогда генерировали HTML на сервере.
                  0
                  однозначно эта либа не даст мне «скорости» в разработке
                  а так для пет проекта можно попробовать
                    0
                    С чем сравниваем?
                    Либа не провоцирует создание лишнего кода, зато провоцирует декомпозицию.
                    Нарезал шаблон, навесил обработчики. Нарезать можно с любой требуемой гранулярностью, конфликты имён исключены.
                      0

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

                      0

                      Поясните, как сделать цикл и условия в ваших "шаблонах"? Можно ли передавать тип компонента в рантайме?

                        0
                        Циклы и условия в «шаблонах» -это то, чего я старался избежать, как и самих «шаблонов».
                        Логика должна реализовываться в скрипте. Для отображения списков специально предусмотрен встроенный компонент array-iterator он принимает на входе массивы.
                        Тип компонента можно передавать в рантайме.
                          +1

                          А можете примеры привести?

                            0

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

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

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

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое