Вот и все, еще одна версия этого проекта, которая началась в 2014 году. Глядя на начало этого проекта, многое изменилось, но основная цель осталась прежней.

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

Уроки, извлеченные из других версий

  1. Никто не будет писать простой код только с помощью Jails, нужно найти время, чтобы помочь в обучении с этой библиотекой. Я думал, что раз он проще, то и приложения будут проще, но на практике оказывается не так.
  2. Сообществу JS еще есть куда расти, я думал, что все, что мне когда-либо понадобится, будет доступно в какой-то библиотеке с открытым исходным кодом javascript. Кажется, это не так, только morphdomиспользованный в этом проекте был достаточно зрелым и постоянно обновлялся. Есть несколько хороших проектов, которые заброшены или им не хватает мотивации для продолжения.
  3. Рендеринг — это самое сложное, что нужно сделать на 100%. Есть много краевых углов, и довольно сложно о них знать, и я считаю, что это самая важная часть библиотек компонентов и фреймворков.

Что изменилось в этой последней версии?

Система шаблонов

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

Основная система

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

В процессе переписывания я только что понял, что управляю жизненным циклом вручную, и кажется, что API пользовательского элемента уже есть в большинстве браузеров, поэтому меня озарила эта идея:

Что, если я использую API-интерфейс определения пользовательского элемента? У него уже есть собственный жизненный цикл для html-элемента, и он будет более близок к веб-стандартам в том смысле, что компонент Jails теперь будет настраиваемым элементом, а не обычным html-элементом с некоторыми data-component на нем…

Это работало как шарм… Я удалял код из исходников, делая его более простым, разумным и элегантным. Кроме того, его можно использовать как веб-компонент. Большой!

Текущее состояние веб-разработки

Jails всегда был направлен на то, чтобы отделить ваш js-код от вашего html, все дело было в разделении задач, все было в том, чтобы все было просто.

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

  1. Производительность и SEO ухудшились по сравнению с прошлыми годами, принесенными идеей SPA, и теперь большинство новых идей пытаются вернуть эти проблемы.
    Эти проблемы никогда не касались Jails, потому что я всегда делал ставку на разделение задач, а это означает, что Javascript для поведения, другие языки для рендеринга.
  2. Сложность. Большую часть времени вы будете видеть больше кода и больше диалектов фреймворков для решения тех же самых проблем, с которыми мы сталкивались 10-12 лет назад, но более сложных: Redux, Redux Saga, useMemo, useCallback, и этот список можно продолжить… Возможно. мы идем далеко…

Джейлс по-прежнему на правильном пути…

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

Эти идеи возвращают лучшие практики, которые мы изучили в прошлом:

  1. Многостраничное приложение вместо одностраничного для быстрых страниц и SEO-совместимости.
  2. По возможности выбирать генерацию статических страниц, чтобы вы могли предвидеть ошибки во время сборки, экономить деньги на хостинге.
  3. Джемстек. Сохранение бизнес-логики в центре API, чтобы вы могли отделить репозиторий внешнего интерфейса и отделить его от внутренней разработки, чтобы вы могли писать интерфейс с любой инфраструктурой, которую хотите.
  4. монорепо. В настоящее время существует тенденция, которая говорит вам, что иногда лучше хранить все в одном месте для простоты, и теперь есть несколько инструментов, которые помогут вам в этом, а также yarn и npm уже дают вам собственный способ управления вашими зависимостями. в одном проекте.
  5. Островная архитектура. Идея о том, что поведение javascript добавляется в ограниченную область вашей страницы, а не монтируется во всем приложении. Эта стратегия островной архитектуры может помочь вам уменьшить размер пакета и сложность приложения.

Все эти вещи уже были в философии Jails, я работал с этой библиотекой в ​​нескольких производственных приложениях и некоторых современных головных болях, с которыми мне никогда не приходилось сталкиваться.

Кажется, что Jails, как и хорошая книга, показывает свою истинную ценность с годами.

Спасибо.