Современная Web-платформа: как расслабиться и получать удовольствие? Практическое руководство, часть 1

  • Tutorial

Всем привет!


Помните эту статью? Раньше мы могли быстро собрать статичную HTML-страничку в каком-нибудь FrontPage и сайт был готов. С этим мог справится любой студент. В более сложном случае, мы писали пару строк на PHP и получали уже целый портал, собранный из разных элементов шаблона на сервере. Затем мы захотели, чтобы наш сайт как-то выделялся на общем фоне и умел чуть-чуть больше. Трон занял его-величество jQuery. Теперь же, мы оказались погребены под завалами фреймворков и библиотек, инструментов сборки, менеджеров зависимостей, препроцессоров и постпроцессоров, особых форматов, языков и стилей программирования, чтобы иметь возможность стряпать простые лэндинги. Все стало слишком сложно. Спикеры на конференциях стали соревноваться в изощренности того, каким еще образом можно сломать нам мозг. Как мы докатились до жизни такой? Чем «раньше» так сильно отличается от «сейчас»? Что нас ждет «потом»? Есть ли в современной веб-разработке некий дзен-стайл, блюдя который, можно, как в старые добрые времена, собрать себе уютный сайтик «на коленке» за пару вечеров, без ковыряния в документации десятка хипстерских технологий-однодневок? Насколько доступны нам простые решения в серьезной промышленной разработке? Куда движется веб-платформа? Предлагаю разобраться.

Для того, чтобы поэкспериментировать с практической частью, вам понадобится любой удобный редактор кода (например Visual Studio Code) и актуальная версия браузера Chrome. Для начала этого будет вполне достаточно. Впоследствии (я планирую целый цикл публикаций на эту тему), все неминуемо усложнится, но мы будем стараться оставаться «в рамках» — это наша цель.

Предпосылки и решение


Когда я делал свои первые сайты (в конце 90-х — начале 2000-х), первое, что мне показалось странным и ужасно неудобным в обычном HTML — невозможность описать «заголовок», «подвал» и «главное меню» сайта в одном месте для всех страниц сразу. Я мог вставить одну картинку или один скрипт во многих местах, но не банальный кусок разметки. Также, я не мог описать общий макет страницы, без необходимости повторять его в каждом отдельном HTML-файле. Я думаю, многих эти-же причины подтолкнули к первым экспериментам с серверными технологиями. Но для всего серверного нужен соответствующий сервер, а это новый уровень усложнения задачи, казавшейся сперва такой простой. Так или иначе, эта проблема решалась множество раз и множеством способов. Мы пытались использовать iframe, пытались динамически управлять видимостью фрагментов, содержащихся на одной странице; как только не издевались над собой и здравым смыслом. В итоге, мы пришли к современному набору мета-платформ типа React или Vue.js, которые, среди прочего, позволяют нам создать структуру модулей, отражающую структуру того, что мы видим на экране. Но и сама веб-платформа не стоит на месте и, о чудо, теперь у нас есть нативная возможность создавать больше чем просто многократно используемые куски разметки: теперь мы можем создавать свои собственные настоящие HTML-теги! Причем, каждый такой тег может быть как примитивным контейнером, содержащим только необходимое оформление (или быть интерактивным UI-элементом), так и макетом всей страницы. Он даже может содержать в себе целое сложное приложение с кучей, необходимой вам, клиент-серверной логики. Да, я говорю о новом стандарте Custom Elements (Living Standard). И он действительно многое меняет.

Пробуем на вкус


Для первого знакомства давайте воспроизведем вышеописанный кейс с общим макетом, хедером, футером и навигационным меню, в самом примитивном виде:

Файл index.html:

<html>
  <head>
    <script src="elements/my-layout.js"></script>
    <script src="elements/my-header.js"></script>
    <script src="elements/my-footer.js"></script>
    <script src="elements/my-menu.js"></script>
  </head>
  <body>
    <my-layout>
      <my-header slot="header">Hi, I am your header.</my-header>
      <div slot="content">Hello World! This is content.</div>
      <my-menu slot="menu"></my-menu>
      <my-footer slot="footer">And I am your footer.</my-footer>
    </my-layout>
  </body>
</html>

Обратите внимание на именование кастомных тегов: по стандарту оно обязательно должно содержать дефис (один или более). Также, вы, наверное, заметили атрибут «slot» — о нем немного позже.

Теперь перейдем к файлу, описывающему основной макет страницы elements/my-layout.js:

class MyLayout extends HTMLElement {
  constructor() {
    // Сперва вызываем конструктор суперкласса HTMLElement:
    super();
    // Cоздаем ShadowDOM элемента - его локальную,
    // закрытую от внешнего мира область разметки, но доступную для JS:
    this.attachShadow({
      mode: 'open',
    });
    // присваеваем нашему элементу свой шаблон:
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
        }
        .header {
          position: fixed;
          top: 0;
          left: 0;
          right: 0;
          height: 40px;
          line-height: 40px;
          padding-left: 20px;
          padding-right: 20px;
          background-color: #000;
          color: #fff;
        }
        .menu {
          position: fixed;
          top: 0;
          bottom: 0;
          right: 0;
          width: 240px;
          padding: 20px;
          background-color: #eee;
          box-shadow: 0 0 8px rgba(0, 0, 0, 0.4);
          z-index: 1000;
        }
        .content {
          padding-top: 60px;
          padding-bottom: 60px;
        }
        .footer {
          position: fixed;
          left: 0;
          right: 0;
          bottom: 0;
          height: 40px;
          line-height: 40px;
          padding-left: 20px;
          padding-right: 20px;
          background-color: #eee;
          border-top: 2px solid #000;
        }
      </style>
      <div class="header"><slot name="header"></slot></div>
      <div class="content"><slot></slot></div>
      <div class="menu"><slot name="menu"></slot></div>
      <div class="footer"><slot name="footer"></slot></div>
    `;
  }
}
// Регистируем созданный элемент:
window.customElements.define('my-layout', MyLayout);
// Теперь браузер знает о существовании нового тега <my-layout>.

Прошу прощения за избыток стилей в данном примере: они нужны только для наглядности при отображении результата в браузере.

В части шаблона, где находится сама разметка, мы снова встречаем слово «slot» — это специальный тег, который работает в сочетании с ShadowDOM — он определяет позиции в разметке для частей контента нашего элемента. Соответствие определяется тем самым атрибутом «slot», который я упомянул ранее. Если у тега «slot» нет атрибута «name» — в него попадет контент «по умолчанию», который, в свою очередь, не имеет атрибута «slot». Это очень простой, но очень мощный нативный инструмент шаблонизации на «клиент-сайде».

Хозяйке на заметку
VS Code — пока не умеет автоматически подсвечивать HTML-синтаксис внутри ES6-строк. Для работы с большими участками разметки внутри JS-файлов, вы можете временно переключать синтаксис открытого файла в режим HTML (нижний правый угол окна): вам станет доступна подсветка, подсказки и автодополнение в HTML и CSS.

Создадим остальные элементы. Файл elements/my-menu.js:
class MyMenu extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({
      mode: 'open',
    });
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
        }
        a {
          display: flex;
          align-items: center;
          justify-content: center;
          background-color: #fff;
          cursor: pointer;
          height: 40px;
          text-decoration: none;
          color: currentColor;
          font-size: 1.2em;
          margin-bottom: 4px;
          border: 1px solid #fff;
        }
        a:hover {
          border: 1px solid currentColor;
        }
      </style>
      <a href="pages/page1.html">Page 1</a>
      <a href="pages/page2.html">Page 2</a>
      <a href="pages/page3.html">Page 3</a>
    `;
  }
}
window.customElements.define('my-menu', MyMenu);

Файл elements/my-header.js:

class MyHeader extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({
      mode: 'open',
    });
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
        }
        span {
          font-size: 0.8em;
          opacity: 0.6;
        }
      </style>
      <span>Text inside ShadowDOM.  </span>
      <slot></slot>
    `;
  }
}
window.customElements.define('my-header', MyHeader);

И последний файл нашего нано-проекта elements/my-footer.js:

class MyFooter extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({
      mode: 'open',
    });
    this.shadowRoot.innerHTML = `
      <style>
        :host {
          display: block;
        }
        ::slotted(*) {
          display: inline-block;
        }
        span {
          color: #f00;
          font-size: 0.8em;
        }
      </style>
      <slot></slot>
      <span> © 2018, Vasya Pupkin</span>
    `;
  }
}
window.customElements.define('my-footer', MyFooter);

Та-дам! Можно открывать наш index.html в браузере. Внимательный читатель заметил, что стили для тега «span» были напрямую определены сразу в двух местах (для разных элементов), однако они не повлияли друг-на-друга и отобразились правильно.

Что мы увидели?


Мы увидели пример настоящей модульной разработки без подключения каких-либо внешних библиотек, без настройки окружения, без ожидания сборки проекта, даже без необходимости запускать локальный сервер. В инструментах разработчика браузера мы видим непосредственно свой JS-код и свою собственную разметку, а не результат работы скриптов, создающих за нас DOM. Контент нашего главного HTML-файла находится в нем-же и сразу доступен, опять-же, без какого-либо предварительного рендера. Мы можем повторно использовать наши кастомные теги в этом-же проекте или в любых других. Мы не загрузили ничего лишнего и отобразили страницу практически мгновенно. Объем дополнительного JS-кода, который нам понадобился для этого — микроскопический. При этом, каждый наш новый элемент — это такой-же полноправный DOM-элемент как и любой стандартный div. Для него доступны те-же самые стандартные атрибуты, свойства, события и методы типа addEventListener, appendChild, remove и т. д. Это то, чего мы так долго хотели? По моему, да.

Дальше — больше


В дальнейшем мы рассмотрим следующие темы (не обязательно в указанном порядке):

  • Жизненный цикл Custom Element в DOM
  • Тег template
  • Оптимизация производительности, динамическое обновление
  • Custom Elements и ООП
  • HTML-атрибуты, работа с общими данными
  • ShadowDOM и CSS: инкапсуляция, селекторы, нативные CSS-переменные, нативные CSS-выражения
  • SVG и Custom Elements — практические советы
  • Организация и структура кода: модули, точки подключения, динамическая загрузка, http/2 Server Push
  • Новый подход к прототипированию, созданию, тестированию и внедрению дизайна
  • Нестандартные стандарты: браузеры, полифиллы, ShadyDOM, HTML-imports
  • Существующая экосистема: библиотеки и готовые компоненты, реальные проекты
  • Custom Elements и серверный рендеринг
  • Custom Elements и SEO
  • PWA

Спасибо за внимание!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 73

    0

    Все делают сложно, давайте я научу как делать сложно.
    Тут больше про css, но мне кажется все уже изобретено https://youtu.be/CaDnbOjXjRg

      +2

      Я целиком согласен с докладчиком в этом видео и сам говорю примерно о том-же. Не понимаю в чем именно вы увидели контраст с тем, что я написал и где вы увидели "сложно".

        0
        Мне тоже интересно, почему вместо того, чтобы воспользоваться чем-то вроде SSI для решения проблемы автор пишет, что
        нужен соответствующий сервер, а это новый уровень усложнения задачи, казавшейся сперва такой простой
        А что мешает использовать программу SSI генератор статики, если под рукой нет сервера?
          +1

          А в чем принципиальная разница? Речь о том, что не хватало базового набора из HTML, CSS и JS, нужен был некий дополнительный инструмент, новая сущность — усложнение там, где его видеть не хочется.

            –3
            Инструмент вставок-подстановок чаще всего называют шаблонизатором. Включение синтаксиса шаблонизатора непосредственно в сам HTML было бы архитектурно избыточным, т.к. HTML это исключительно язык разметки т.е. по сути это схематические данные для описания структуры страницы и не более того. Вариантов реализации шаблонизатора может и должно быть неограниченное количество и SSI это только один из них. Т.е. для нормальной «Web-платформы» (в терминах автора поста) необходимы четыре разных инструмента:
            • HTML для описания структуры страницы на клиенте.
            • CSS для описания правил рендеринга элементов страницы на клиенте.
            • JS для описания динамического поведения и управления элементами страницы на клиенте.
            • Шаблонизатор для описания правил сборки страницы на сервере или на клиенте.

            И с моей точки зрения очень плохо, что чем дальше — тем больше происходит смешение этих функций между инструментами описанными выше, например CSS используют для описания поведения элементов, JS для функций шаблонизатора и т.п.
        0
        Все так просто, что хочется спросить: «В чём подвох?»

        А подвох в том, что это работает на одном браузере, и то в каком-то экспериментальном режиме.

        Автору, конечно, спасибо, добавлю статью в закладки. Но во фронтенд-разработку в ближайший год я всё равно не пойду.
          +1

          Нет, это работает в обычном режиме в Chrome, Opera и Safari. То есть, как минимум, в самом популярном браузере и на самых распространенных мобильных платформах. Про остальные браузеры — я еще напишу, это тема объемная, смешивать все сразу в кучу не хотелось. Вкратце: этот вопрос решается.

            0
            Увы, не работает на FF 55. Хотя со временем заработает, наверное, раз уж гугл по ключевым словам «Shadow DOM» и «Custom elements» посылает на MozDev. Но это надо подождать.
              +2

              FF работает, но пока только с полифиллом. Да, конечно, картина от этого становится не такой радужной, но следует учитывать главное: спецификация Custom Elements — это уже принятый стандарт а не черновик или экспериментальная технология. Это значит, что разработчики FF обязаны реализовать поддержку (она уже есть, но пока за флагом). Сами разработчики FF оправдывают отсутствие поддержки тем, что они ждали пока стандарт устаканится, теперь у них оправданий нет.

              0
              Каких версий?
            0
            Прошу прощения за избыток стилей в данном примере: они нужны только для наглядности при отображении результата в браузере.

            А в реальном приложении вы куда стили отправите? Выносить в отдельный CSS не вариант, потому что Shadow DOM и стили только для одного компонента. А import в браузерах может импортировать только JS, а CSS не поддерживается

              +1

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

                +2

                Да, пожалуйста, расскажите об этом.

                  0
                  В реальном проекте как раз с этим проблемы. В контексте конструктора компонента документ равен основному документу, и как следствие относительные пути не работают. Так что, чтоб создать действительно переносимый компоненты приходится парсить цсс и дом (src картинок и т.п.) и менять все пути на абсолютные во время создания.

                  Подскажите, если нашли более элегантное решение данной проблемы.
                0
                Опять происходит смешивание HTML-разметки и js-а.
                  +1

                  В этом конкретном примере — да, я смешал для компактности. Не вижу в этом проблемы. Там, где это важно, и тем, кого это беспокоит — можно хранить разметку в HTML, специально для этого есть тег template.

                    +3

                    На эту тему есть хорошая картинка у Кристиана Хайльмана:
                    image

                      +1

                      Ну вот почему у Microsoft в середине нулевых не возникло этой проблемы при проектировании XAML? У всех элементов управления отдельно логика, отдельно разметка. И всё скинуется и стилизуется как угодно.

                        +1

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

                          0

                          Ну вот у вас на картинке режут на столбцы и строки, там сразу нарезали на ячейки.

                            +1

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

                            0

                            К сожалению, это не совсем так. Да, custom elements, shadow dom и html import решили часть проблем, сильно упростив некоторые вещи. Я вот сижу уже с полгода на Polymer, и могу сказать, что для простых задач это именно что просто. Но проблемы с организацией проекта никуда не делись. Многих вещей сильно не хватает. Flex все еще вспоминается с ностальгией.

                              +1

                              Я работал с Polymer начиная с версии 0.5, знаю его (и всю экосистему) довольно прилично и делал с ним достаточно сложные вещи. Можете сказать чего именно не хватает и что именно "не совсем так"? Может что-нибудь смогу посоветовать.

                                0

                                Полимер тут почти не при чем. Проблемы (некоторые) есть в самом веб, как платформе в целом. Вот некоторые из них, для примера:


                                • не прижились namespaces и XHTML. На мой взгляд, именно отсюда растут странные ограничения, что имя custom element-а должно состоять из двух слов, разделенных дефисом. И отсюда же растут определенные сложности с выбором имени, чтобы избежать конфликтов. Скажем, в том же Flex/Flash, этого всего и близко нет, а есть пакеты и нормальные namespaces, внутри которых есть классы (они же де-факто MXML элементы. И ничто не мешает в одной сборке использовать две разные версии одного виджета, сделав им разные namespaces.
                                • отсюда же следуют определенные проблемы с поддержкой SVG внутри template (я подозреваю, что если вам захочется скажем MathML — то будут такие же проблемы и с ним).
                                • вы все еще не можете легко помешать какому-то custom element-у сослаться на нечто по относительному URL вида ../../.., и получить в итоге непредвиденные проблемы, потому что в вашем проекте там лежит немного не то. И потому что автор считал, что все обязательно пользуются bower.

                                Или наоборот, сослаться на некий ресурс (типично скажем для Roboto font) по URL абсолютному, http://..., который в интранете недоступен.


                                Опять же, в случае с Flash эти проблемы решались и решаются во время компиляции и сборки SWF, и такая сущность, как пакеты и классы, существуют на уровне SWF/SWC, и подключение ресурсов как правило тоже при сборке, статически. В принципе, серверный сборщик вероятно мог бы решить все эти проблемы и в случае полимера, но для этого как минимум не хватает некоторых соглашений о структуре проекта (и как мне кажется — не хватает и желания такие соглашения установить).

                                0
                                Флекс, MVC и прочие архитектурные паттерны никак не противопоставляются компонентной модели Custom Elements, это вообще перпендикулярные явления. Архитектурную организацию приложения Полимер не обеспечивает, потому что это не фреймворк, а лишь библиотека компонентов, вам самому решать, как хранить состояние и распространять его изменение по приложению. Полимер / Custom Elements поможет лишь коробками и клеем, которым они склеиваются, а фигуры, которые вы будете клеить из этих коробок, и содержимое этих коробок — на вашей совести.
                                  0

                                  Во-первых, полимер это все-таки в первую очередь фреймворк, а не библиотека/набор компонентов. И к самим компонентам как раз претензий меньше всего — они бывают лучше или хуже, но в целом ими вполне можно пользоваться. Претензии именно к полимеру как фреймворку.


                                  А во-вторых, я вовсе не о состоянии говорил (и тут я соглашусь, что это просто не задача полимера). Да, полимер это не обеспечивает (и еще вон то не обеспечивает), оставляя очень многое разработчику компонентов и сборщику приложения из них. И к сожалению, проблема в том, что в итоге это (благодаря такому хорошему свойству, как гибкость :) позволяет построить как хорошую, так и плохую архитектуру.


                                  Что до Flex, то я не уверен, что вы поняли, о чем я. Как он попал у вас в один ряд с MVC и архитектурными паттернами?

                                    0
                                    > Претензии именно к полимеру как фреймворку.

                                    Это не фреймворк, это библиотека, и именно так и написано на сайте Полимера (и в куче других обсуждениях в интернете). Претензии у вас к Полимеру именно потому, что он не фреймворк.

                                    > И к сожалению, проблема в том

                                    Это проблема вытекает из того, что Полимер — не фреймворк и не задаёт жёсткой структуры приложения. За эту проблему несёт ответственность программист, использующий Полимер.

                                    > Что до Flex, то я не уверен, что вы поняли, о чем я.

                                    Поясните, что вы имели ввиду, может, вы не имели ввиду Flex, который из Фейсбука?

                                    >Как он попал у вас в один ряд с MVC и архитектурными паттернами?

                                    Потому что он и сам является архитектурным принципом, определяющим схему потоков данных в приложении, наравне с MVC.
                                      –1

                                      Вы можете называть это как хотите, но полимер это не только компоненты. Это средство для создания компонентов в первую очередь. И он вполне диктует структуру компонента, жизненный цикл определяет, и т.п., то есть в этой части является типичным фреймворком.


                                      не задаёт жёсткой структуры приложения

                                      Ну так это и плохо. Я еще раз уточню — это не претензия к полимеру, это скорее констатация того факта, что custom elements в целом и полимер как пример этой технологии не решают (и не призваны) решать все проблемы, что собрать из них кривое приложение можно точно также легко, как и до их появления. При всех их однозначных плюсах, кстати.


                                      Я вот вспоминаю, как несколько лет назад мне пришлось делать приложение на основе iWidgets и dojo. Так самое первое, что у меня тогда получилось сделать — это сломать весь портал, просто задеплоив туда свой самый обычный виджет. Сегодня в полимере изоляция компонентов друг от друга уже на порядок лучше, и как правило приложение все-таки сразу не ломается, если мы в одном компоненте накосячили.


                                      Flex — это Adobe (сегодня Apache Flex).

                                        0
                                        > Вы можете называть это как хотите, но полимер это не только компоненты.

                                        Это набор компонентов и легковесная библиотека для их написания. А вы можете называть как хотите, воюя со всем миром за вашу терминологию.

                                        > И он вполне диктует структуру компонента, жизненный цикл определяет

                                        Верно, жизненный цикл компонента, а не приложения.

                                        > Flex — это Adobe (сегодня Apache Flex).

                                        Ок.
                                          0

                                          Когда есть ограничения со стороны "библиотеки" на структуру и API компонента, есть жизненный цикл компонента — большинство людей (включая например википедию) все же называет такое фреймворком.


                                          Да, легковесным — потому что большую часть делает "родной" API custom components. Да, структуру не приложения, а только компонент.


                                          Впрочем, это совершенно не предмет для спора, и воевать тут не за что (все равно термин достаточно размазанный), пусть зовут как хотят.


                                          Я пытался сказать о том, что тот же Flex накладывает намного больше ограничений на структуру приложения, и в тоже время, я не слышал, чтобы кто-то жаловался, будто эта структура ограничивает его фантазию.

                                            –1
                                            > Когда есть ограничения со стороны «библиотеки» на структуру и API компонента, есть жизненный цикл компонента — большинство людей (включая например википедию) все же называет такое фреймворком.

                                            Вы явно не очень понимаете, о чём говорите. Не пытайтесь меня убедить, лучше попробуйте усомниться в собственном понимании :).

                                            > Я пытался сказать о том, что тот же Flex накладывает намного больше ограничений на структуру приложения

                                            Выбирайте себе фреймворк с удобными для вас ограничениями (или пилите самостоятельно, с Полимером это даже приятно и быстро делается), прикручивайте к нему Полимер, и вперёд. Вы всё ещё продолжаете требовать от Полимера свойств фреймворка. Ну что за капризы, нужно просто принять действительность, Полимер — НЕ фреймворк. Называйте его как хотите, но от этого в нём не появится свойств, обычно подразумеваемых в веб-фреймворках (и на отсутствие которых вы как раз и жалуетесь).
                                              0
                                              Вы явно не очень понимаете, о чём говорите.
                                              Да-да, конечно. Делать мне больше нечего, как кого-то в чем-то убеждать. Я знаю, зачем мне такое определение, которого я придерживаюсь. Мне этого более чем достаточно.
                                                0
                                                Если вы не участвуете в коллективных проектах или в обсуждениях (как, например, тут), то, конечно, вам хватит и своей ни с кем не совместимой терминологии и картины мира. Не обижайтесь на меня, пожалуйста, за то, что ломаю ваши шаблоны, в этом нет ничего личного, и уже завтра я даже не вспомню вашего никнейма :).
                                                  0

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

                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1

                                                ИМХО, вы оба-трое по своему правы. Когда библиотеки или фреймворки разрастаются до стадии экосистем — они приобретают некие фрактальные признаки: начинают походить то на фреймворк, то на библиотеку на разных уровнях. Формально — Polymer — это, конечно, библиотека.

                          0
                          Какие, на Ваш взгляд, тенденции и
                          решения в серьезной промышленной разработке
                          могут произойти через 3-5 лет?

                          Удельный вес проектов на Angular / Vue / React будет расти, а текущие инструменты будут
                          только совершенствоваться, или есть вероятность, что выстрелит нечто принципиально новое?

                          Спасибо, — статья понравилась. Интересно Ваше мнение, в чём есть главная проблема,
                          преодолев которую, в веб-разработке станет 'совсем всё хорошо'?
                            0

                            Нативные CSS-переменные и выражения — уже поддерживаются браузерами: Sass/Less/Stylus — стали не нужны. ShadowDOM экранирует стили внутри элементов: громоздкий BEM — уже не нужен. ES6+ синтаксис, уже поддерживается браузерами напрямую и транспиляция становится не нужна. Кастомные элементы решают проблему структуры/модульности, повторного использования кода, удобно тестируются и внедряются — это делает лишними такие библиотека как React или Vue. HTTP/2 умеет пушить файлы на клиент до того, как сам браузер сделает запрос — многие инструменты сборки становятся не нужны. Это все, на мой взгляд, очень сильно изменит стандартный набор инструментов обычного веб-разработчика в самое ближайшее время. Pабота с данными, ИМХО, потребуют новых решений и внимание разработчиков библиотек сосредоточится в этой области. Того, что делают такие вещи как Redux — уже совсем не достаточно, мне кажется, популярность наберет нечто работающее с графовыми структурами, и компостировать мозги на конференциях нам станут чем-то подобным. Мне все происходящее — нравится, я вижу выравнивание линии графика общей сложности разработки, в начале которого — все совсем просто.

                              0
                              Кастомные элементы решают проблему структуры/модульности

                              Хм. Вы я думаю прекрасно представляете, что есть минимум два подхода к структуре и модульности — один, где в основе лежит HTML (и кастомные элементы), и приложение мы собираем путем вкладывания одних элементов в другие. И второй — где в основе скорее javascript, и сборка происходит на базе какого-нибудь API (или JSON, например). При этом как правило второй подход гораздо более гибкий, и позволяет применять разные знакомые разработчику средства композиции (как ООП, так и например разную функциональщину). Причем как по отдельности, так и вместе.


                              Я по своему опыту вам честно скажу — в большинстве случаев такая штука как <iron-ajax>, это как бы перебор. И это еще мягко сказано. Потому что если вам нужно, например, собрать что-то из двух AJAX-запросов, то к вашим услугам много вариантов — синхронные запросы, callbacks, promices, async/await как минимум. Вот расскажите нам, как вы будете объединять в одно целое два таких элемента, как <iron-ajax>, которые запускают некий параллельный процесс, а потом асинхронно получают ответ, и отдают его куда-то в приложение? Я знаю два варианта — и они оба не идеальны.


                              Ну и кстати, если вам нужно собрать что-то из элементов, набор или параметры которых неизвестны заранее, вы можете конечно создать кастомные элементы программно, но это уже будет совершенно другая структура приложения. Ну или как вариант — у вас где-то появится в шаблонах if и циклы (как это имеет место в полимере). Т.е. логика внутри языка разметки. И это зачастую (особенно по мере развития приложения) становится совсем не красиво.

                                +1

                                Custom Element — это просто контейнер, одно из основных свойств которого — наличие экземпляров в DOM, непосредственно в дереве HTML-документа. Эта жесткая связь помогает структурировать части представления и делить между ними ответственность. Как контейнер, имеющий наглядное воплощение в интерфейсе — он очень удобен для привязки определенного типа логики в определенных местах, позволяет решать вопрос декомпозиции интерфейса удобным образом. Но это не абсолютная абстракция, как, например, класс в js, это возможная точка привязки таких абстракций, если таковые вообще имеются. К примеру, Custom Element — не имеет прямого отношения к работе с данными, но он может управлять потоками данных согласно своему положению в структуре документа, передавать их потомкам или родителям, и реагировать на изменения. Если это необходимо разработчику. В остальных случаях — все зависит от сложности решаемой задачи, это может быть уже совсем другой историей. Похожая структурная схема сделала популярным React — его компоненты хорошо делят общую "кашу" на куски и подсказывают где что. Но может быть и другой уровень, никто не говорит, что эта технология — панацея для всего на свете. Я это все к тому, что такие штуки как iron-компоненты — это просто хак для подключения внешней логики, удобный декларативный способ вклиниться в рантайм через DOM. Но, в чуть более сложных случаях, на мой взгляд, это плохая практика. Лично я предпочитаю делать такие вещи как, к примеру, слой работы с данными — в своем отдельном "загончике" и создавать к этому загончику удобный интерфейс, доступный уже для компонентов, а сами компоненты — могут служить, своего рода картой. Именно это я имел в виду, когда говорил о решении проблемы структуры/модульности.

                                  0

                                  Это хороший, взвешенный ответ.


                                  Кстати, не хотите сделать проект на базе полимера (ну точнее, есть прототип на полимере 1.х, а дальше можно с ним делать все что угодно, включая полную переделку с нуля)?


                                  Если интересно, или можете порекомендовать кого-то — свистите в личку. Зарплата достойная, заказчик в Москве, можно делать удаленно (но вряд ли из другого города), можно работу на время проекта, можно постоянно.

                            +3
                            Спасибо за статью! Жду продолжения.

                            Давно хотелось чего-то простого для создания мастер-страниц с использованием только нативных средств
                              0
                              Вы забыли, что создание сайтов на HTML стало простым только с появлением визуальных редакторов вроде Macromedia (позже Adobe) Dreamweaver. Вместо того, чтобы кодить в CoffeeCup, стало возможным реально дизайнить сайт в HTML. Ваш подход это снова возврат к кодингу, простотой тут и не пахнет.

                              А главное — зачем? Контент среднего размера сайтов не поменялся, те же картинки/видео/текст. И с помощью HTML+ php include все задачи решаются так же, как и раньше. Реакт для этого не нужен.

                              А та «матрешка», которую вы нагородили — к HTML подключается JS, внутри которого снова создается элемент, в конструкторе которого HTML, CSS и текстовые данные вперемешку! Это абсолютное зло, и вы никаким вынесением стилей во внешние файлы её не разгребёте — вся простота порушится. Ну не должен текст про Vasia Pupkin быть в скрипте, принципиально.

                              И, в результате — для какого, например, сайта все это может понадобиться? Простой сайт делается на Tilda. Сложный — на шаблонах CMS-ок. А ваш подход — для чего?
                                +1

                                Я ничего не забыл, я просто категорически с этим не согласен.


                                Что касается остального: Вы всерьез полагаете, что PHP и шаблоны CMS-ок — это просто, я то о чем написал я — сложно? Вы всерьез не видите разницы в количестве используемых технологий и необходимых действий в каждом из подходов? А вы видели, что там внутри у Tilda? А внутри панелей управления CMS-ок? Вы когда-нибудь пытались сделать простенький визард, состоящий из нескольких форм? Или банальную страницу авторизации? Знаете что такое SPA? Что существует более чем оправданный, во многих случаях, подход, когда сервер должен отдавать только чистые данные а не плеваться одинаковыми шаблонами?


                                HTML, CSS и текстовые данные вперемешку!

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

                                  0
                                  Вы всерьез полагаете, что PHP и шаблоны CMS-ок — это просто

                                  встряну в диаолог. как мне видится, проблема не в просто/сложно… проблема в том, что какой бы сайт Вы не делали, без сервер-сайда не обойтись. если это сложная CRM — тут ясно, обычным firebase не обойтись. а в случае с одностраничными лендингами — просто необходим SSR. поисковые боты не особо следуют новым трендам, в отличии от браузеров. а такие сйты чаще всего для ботов и делаются.
                                  поэтому вопрос — какую, по вашему, нишу нацелена занять эта технология?
                                    +1

                                    Основной момент, от которого следует плясать дальше: Custom Elements — это не очередной взгляд на шаблонизацию, не попытка исключить из оборота сервер или переложить ответственность. Custom Element — это добавление дополнительного измерения в изначально "плоский" HTML, проекция на обычную разметку решений дополнительных произвольных задач. Это расширение возможностей браузера при обработке им разметки, статичной или динамической — не важно. Вы можете использовать эту технологию в сочетании с практически любым подходом к архитектуре приложения: от совсем архаичных статичных страниц, до супер-пупер-турбо-систем реального времени. В одном случае, поисковой бот увидит просто-напросто статичный HTML-файл с контентом, в котором некоторые теги могут быть незнакомы, но тексты и картинки — самые обыкновенные. В другом случае — все ложится на совесть архитектора, и того, какие перед ним стоят задачи.

                                      0
                                      Ну, возможно, в недалеком будущем, когда этот подход обзаведется экосистемой, появятся архитектурные решения и лучшие практики, он найдет применение… В данный момент, в том виде, в котором Вы его преподносите, как упрощение(я так и не понял чего), мне кажется инфа чисто для ознакомления, чтобы быть «в тренде». Применения она в ближайшее время не найдет…
                                      Хотя, учитывая нынешние темпы развития фронт-енда, это недалекое будущее может наступить прямо завтра :)
                                        +1
                                        Это упрощение уровня того, которое пыталась сделать Microsoft со своим COM/ActiveX — создание универсальных, стандартизованных, совместимых как детальки LEGO контейнеры для компонент (только Microsoft это делала в рамках своей экосистемы, а не глобально для веба, и при этом сильно заоверинженерила концепцию, что постепенно отвернуло от неё разработчиков и привело к новой попытке — .Net), инкапсулирующих внутренности этих контейнеров и технологии их создания (в перспективе, с WebAssembly). Всего этого локально можно добиться, конечно, настроенным Вебпаком, препроцессорами и шаблонизаторами, но ценность WebComponents именно в стандарте, жёстко зашитом в самой платформе. В перспективе, когда Васюки переименуют в Москву, прикладной программист будет собирать приложение из глобальной библиотеки компонентов, которые пишутся разными людьми на разных технологиях на разных экономических условиях, с небольшим скриптом конфигурирования под свои бизнес-процессы и темизацию, уверенный, что все компоненты загружаются и работают универсальным способом и точно не сломают ничего внутри друг друга (RAD).
                                          +1

                                          Уже есть и серьезная экосистема, и практический опыт и опробованные модели применения. Именно об этом я и собираюсь тут рассказывать. Начать мне хотелось, с чего-то предельно простого, для затравки, но, как я вижу по комментариям, многие упорно не хотят "видеть за деревьями — леса". Но другие многие — хорошо видят. Именно они и возглавят тренды ближайшего времени.

                                    +3
                                    Уважаемый mSnus, если я правильно понял выше изложенную идею, в механизме cusom elements реализация тех же мастер-страниц упрощается в разы.

                                    Давайте представим ситуацию: вы начинаете писать веб-приложение (для абстракции примера пишем приложение в блокноте — «сайт на коленках»), естественное желание сделать его одновременно и простым, и привлекательным на вид.
                                    Вы используете таблицы стилей без препроцессоров и клиентские скрипты без сторонних библиотек. А теперь хотите сделать так, чтобы один и тот же набор элементов, который встречается у вас на нескольких страницах (например, шапка с менюшкой или подвал), редактировался только в одном месте. Как вы будете решать эту задачу?

                                    И тут начинаются танцы с бубном, потому что «просто» эту задачу не реализовать — будет либо много кода, либо придется использовать сторонние решения (библиотеки, фреймворки и т.д.)

                                    а тут вы в одном месте объявляете новый тип элемента, который имеет свою компоновку, использует свои стили (которые вынесены в те же *.css) и свои скрипты (которые вынесены в те же *.js). А потом двумя строчками вставляете его на те страницы, где он нужен. Всё. Профит. Редактирование происходит в одном месте. Никаких сложностей, никаких сторонних решений. Все счастливы))
                                      +1
                                      Через SSI или через PHP include в одну строчку. Без всего того, что вы написали в последнем абзаце. Зачем все так усложнять?
                                        +1

                                        А если ваш сервер отдает вам только статику и голые данные (Firebase какой-нибудь)? А как посмотреть на результат локально? Дополнительно установить — настроить — запустить сервер? Да, поднять LAMP вроде не сложно, но зачем? А повторно использовать вашу библиотеку UI-элементов в другом проекте, который на другом стеке? А если в вашем ТЗ — явно указано — делаем SPA?
                                        Нет уж, SSI — это привет из прошлого: он может теплый и ламповый, но не вписывается в реалии современных задач фронтенда никак.

                                          +1

                                          И да, хотелось бы еще раз подчеркнуть: Custom Elements — это не очередной способ шаблонизации, он может органично решать этот вопрос на базовом уровне, но это чуть более глубокая тема. Custom Element — это не кусок разметки: у него есть как собственная (теневая) разметка так и содержимое как у обычного HTML-тега. Это разные вещи и ведут они себя по разному. Вы можете, к примеру, использовать Custom Element в сочетании с любым серверным шаблонизатором, просто как один из доступных тегов с расширенными возможностями.

                                      +1

                                      x

                                        –2

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

                                          +1

                                          https://habrahabr.ru/post/335510/ — Это же ваша статья? Проснулись не с той ноги?

                                            –3

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

                                              +1

                                              Осталось Вам, для приличия, внимательно прочесть мой. Чтобы не пороть ерунды. Ну и хамство на Хабре — это антипатерн. Удачи.

                                                –2
                                                Мы увидели пример настоящей модульной разработки без подключения каких-либо внешних библиотек, без настройки окружения, без ожидания сборки проекта, даже без необходимости запускать локальный сервер.

                                                Ерунду ты в статье описал, с гордым заголовком про удовольствие. Твой подход, на текущий момент не будет работать у большинства пользователей в их относительно древних браузерах, которые не умеют классы, шаблонные строки и т.д
                                                Без транспиляции твоего кода вниз не обойтись, следовательно необходимо все прогонять через babel как минимум, а это уже требует настройки окружения разработки, подключение внешних библиотек, и сборку проекта.
                                                Без этого, все что ты описал никому не нужно. Потому что спрос на рабочие продукты, а не на поделку из 3 строк чисто для хрома! Можешь не соглашаться, считать это хамством, жаловаться и минусовать.

                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    –2

                                                    Вы заказчику так же говорите, когда он в требованиях указывает 11IE ?

                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                        –2

                                                        Да, я как заказчик удивлюсь и найду других разработчиков.

                                                          +1

                                                          Понятное дело, можно и IE11 поддержать, но то время, что будет потрачено на фиксы для IE можно потратить и более эффективно, на новые фичи, например.


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

                                                            –3
                                                            Заказчику абсолютно все равно что вы используете флексы, гриды, кастом элементс и все вот эти вот модные фичи, которые он не видит. При разработке какого-то более-менее рабочего приложения под конкретную бизнес задачу, тот способ который описан в статье, подарит массу гемороя даже в последних версиях популярных браузеров. На устранение всех косяков будет уходить масса времени, а заказчик будет вынужден расплачиваться за «фичи разработчика», и в итоге все придет к тому, что код будет переписан с нуля! А заказчик потеряет деньги как минимум 3 раза:
                                                            1. Регулярная оплата исправления ошибок, вина которых, полностью лежит на разработчике
                                                            2. Потеря дохода от аудитории тех браузеров, которую просто выкинули ради фич и желания разработчика
                                                            3. Потеря средства на разработку проекта с нуля.
                                                              +2
                                                              Заказчику абсолютно все равно что вы используете флексы, гриды

                                                              Совершенно верно, но тем не менее заказчику важны сроки. То, что на флексах верстальщик накидает за пару дней (условно), на флоатах займет больше времени. Опять-таки возвращаемся к выбору "вам побыстрее или с поддержкой IE"


                                                              Потеря дохода от аудитории тех браузеров, которую просто выкинули ради фич

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

                                                          • НЛО прилетело и опубликовало эту надпись здесь
                                                              –3
                                                              Посмотри какие браузеры поддерживают Custom elements, потом делай свои философские выводы.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                  –3
                                                                  Сравнил полимер с каким то великом…
                                            0
                                            сразу хочется добавить туда евенты и смотри у нас новый react! )
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                +1

                                                Именно. Только без привязки к мета-платформе.

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

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