Архитектура приложения на Akili framework

Спасибо за интерес =)

А мы разве не должны их отделять?

Под стереть грань имеется ввиду декларативный подход к html разметке.

class Hello extends Akili.Component {
  created() {
     console.log(this.scope);
  }
}

<hello> ${ console.log(this) } </hello>

this.scope в компоненте тот же самый объект, что и this в разметке. Я считаю это очень удобно.

Можете описать подробнее? Как именно происходит синхронизация вашего реактивного стейта и тех изменений в DOM, которые может вносить какой-то 3rd-party модуль, например Jquery plugin.

Все биндинги в разметке привязаны к конкретным DOM узлам и не мешают работать с другими узлами. То есть можно легко совмещать компонентную систему фреймворка и стандартные фишки javascript. Вещи типа такого являются нормальными:

class Hello extends Akili.Component {
  compiled() {
     if(this.attrs.hideDiv) {
       $(this.el).find('.jquery').hide();
     }     
  }
}

<hello hide-div="true">
  <div class="jquery"></div>
</hello>

Понятно, что это просто пример. Скрыть элемент можно гораздо "правильнее" в рамках фреймворка, но суть надеюсь передал.

В каком месте Redux прост?

А что в нем сложного? По сути обычный event emitter с парочкой методов )

Можете пояснить по этим пунктам?

Под resolving data имеется ввиду, что указывая маршрут, мы в его обработчике можем вернуть Promise с данными. И вложенные маршруты не будут обработаны, пока не зарезолвится текущий.

router.add('app', '/app', {
  handler: (transition) => {
    return Promise.resolve('my app data')
  }
});

Абстрактные маршруты — это маршруты, у которых нет шаблона. То есть просто в обработчике делаешь что-то, что тебе нужно и все. Они могут быть частью иерархии маршрутов тоже.

Ну это скорее минус. Это реализовано отдельным модулем? Можно как-то выпилить удобно?

Можно просто не использовать его. Код этого сервиса занимает несколько килобайт.

Гидрировать разметку на клиенте умеет? Нужно передавать весь стейт, а как иначе?

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

В сравнении с чем?

В сравнении с другими фреймворками. Не хочется просто показывать пальцем )

Это еще лаконичнее и удобнее.

Дело в том, что в выражение можно добавлять глобальные переменные. Например, там уже есть event, utils, console и.т.д. А можно вообще любые свои:

Akili.options.globals = { my: 1 }

${ my + this.x } 

Как вы будете синхронизировать состояние данные в скоупе с теми манипуляциями DOM, которые производит DataTables и в обратном направлении.
Например, мы добавили новый элемент в массив данных через ваш скоуп и DataTables также обновился.

http://jsfiddle.net/vjarL1t6/50/
Пара комментариев к примеру.

• Я не нашел как в DataTables получить чистый измененный массив. Пришлось пройтись циклом лишний раз, чтобы очистить лишние ключи.
• Нужно иметь ввиду, что если бы DataTables работал не с копией переданного массива, то вообще ничего не надо было бы делать. Данные обновлялись бы сами, поскольку все объекты скоупа это Proxy.

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

Не согласен. Его "сложность" мягко говоря преувеличена.

Разве такое не умеет любой нормальый роутер

Это много. Лучше вообще не ключать его в стандартную сборку и шипить как отдельный модуль.

Это просто обычные сервисы, позволяющие реализовать SPA. Понятно, что в них не будет ничего сверх-нового, альтернатив масса. Смысл тут в том, что Akili это фреймворк. У человека должна быть возможность просто подгрузить один файл и написать полноценное приложение без зависимостей.

Иными словами, когда код выполняется на клиенте он заново производит рендеринг всех компонентов, которые уже были отрендерены на сервере. Видимо и запросы дергает все. Тогда это фигня, а не поддрежка SSR.

Я не концентрировался на этой задаче достаточно, но:

• код на сервере исполняется полностью, без необходимости ничего переписывать/ добавлять. Пара строк и все готово.
• Можно делать асинхронные операции в компонентах, они все тоже будет обработаны
• Уже реализована система кэширования запросов. То есть в ближайшее время добавлю в SSR передачу этих данных, и запросы не будут выполняется на клиенте больше.
• Что касается остального состояния, то это очень сложно сделать, может быть даже невозможно до конца. Потому что в идеале нам нужны не только данные, которые можно сериализовать и отправить.

Такать не надо, просто интересно, что вы имеете ввиду под «магическими надстроеками к разметке или коду», которых у вас, как я понимаю, нет. Можно просто пару примеров.

• react — jsx
• angular1 — своя модульная система, DI
• angular 2+ — своя модульная система, своя разметка, DI, typescript

Это не значит, что все это не нужно и плохо. Но можно не хуже и без этого.