Веб-компоненты как Human API к фронтенд библиотекам

>

Смотрю я на вновь оживший тренд по веб-компонентам и на обсуждения вокруг этого, и понимаю что не видать еще лет 5-ть минимум упрощения во фронтенд разработке. А тем временем требования к приложениям становятся всё сложнее.

Теперь это не просто html страничка с ajax запросами на нажатия кнопочек, а полноценное развесистое приложение в браузере, с поддержкой WebSockets для двусторонней связи, с обработкой файлов прям из js на стороне клиента, да еще и оффлайн работой.

Каждую неделю выходит ~30 различных библиотек со схожим функционалом что и предыдущие 300. Каждый тянет одеяло на себя вместо того что бы объединить усилия и черт возьми наконец-то разгрести этот ад что творится во фронтенде. Мне сложно представить как в это время новенькие вообще могут успешно стартануть в веб разработке при таком количестве разнообразных путей для решения одной и той же задачи.

И не удивительно что люди уже не способны выбрать нужный инструмент под задачу, потому что искать в океане поделок можно очень долго, и не факт что найденное решение внутри окажется нормальным. Тут конечно еще играет свою роль факт что люди идиоты и когда читаешь наезды типа – «ангуляр плохой потому что тормозит на 2000-ях биндингах», да конечно тормозит! потому что ты идиот! в нормальном приложение не должно быть так. А потом появляется FLUX архитектура которая как раз вот для задач когда эти самые 2000 биндингов нужны, но нет! мы будем писать meduza.io на React для отображения 27 статических новостей на страничке (на самом деле это круто что кто-то может себе позволить так поиграться в продакшене).

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

  1. Добавить все необходимые стили
  2. Подключить все js зависимости + еще в нужно порядке (нормальных импортов то нет)
  3. Добавить в документ какой-либо <div id="my-cool-chart"></div> с нужным id
  4. Написать с десяток строк когда для создания нужного графика с данными

В самом просто варианте выглядит это примерно так:

<script src="Chart.js"></script>
<canvas id="myChart" width="400" height="200"></canvas>
<script>
    var data = {
        labels: ['mon','tue','wed','thu','fri','sat','sun'],
        datasets: [
            {
                data: [10,14,20,25,13,9,40]
            },
            {
                data: [40, 9, 13, 25, 20, 14, 10]
            }
        ]
    };
    var ctx = document.getElementById("myChart").getContext("2d");
    var myNewChart = new Chart(ctx).Line(data);
</script>

Человек просто хотел добавить графики в свой бложик, а в итоге вынужден программировать на html/css/javascript.

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

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

Возвращаясь к примеру с графиками, с веб-компонентами это будет уже выглядеть намного проще:

<link rel="import" href="chart-elements.html">
<chart-line
    width="400" height="200"
    labels="['mon','tue','wed','thu','fri','sat','sun']"
    values="[[10,14,20,25,13,9,40], [40, 9, 13, 25, 20, 14, 10]]">
</chart-line>

Никакого программирования, только необходимые данные (но как и весь фрондент => всё также уродливо ^_^ )

Коротко:

  • Можно добавлять новые примитивы в html и заниматься складыванием кирпичиков, а не программированием каждого отдельного кирпича
  • Веб-компоненты это не про написание приложений, а про расширение функционала html. Вместо того что бы подключать библиотеку для создания табов, можно будет использовать <tabs></tabs> прямо в вёрстке
  • Писать компоненты больно => templates/decorators/custom elements/shadow DOM (ангуляровцы будут как дома)
  • Веб-компоненты это очень, очень сыро и еще сто раз поменяют спецификацию
  • Любые попытки сделать универсальное решение сказываются на Human API и уши разухабистого внутреннего API будут выглядеть еще хуже чем 20-ть строк кода на js