Да, это один из проектов, который навел на мысли и вдохновил на создание. Но как я уже писал в статье, у ipfs слишком много минусов. Можно сказать museria — более функциональная, гибкая и удобная реализация этого всего.
Процент можно поделить между всеми же. Внезапно, даже создатель этого глобального сайта может себе брать небольшую комиссию :)
Нода упала — контент пропал из сети, но не узла. Если узел вернется, то все восстановится.
Если узлов больше 1, то у всех песен будет как минимум один дубликат. Чем больше узлов, тем больше дубликатов. Кол-во дубликатов настраивается, сейчас стоит как корень из размера сети. Поэтому если в сети 9 узлов, скажем, то 2 любых могут падать, ничего не поменяется. Тут главное — постоянная циркуляция песен. Тогда все будет ок.
Вы сделали такой себе API, который шлет всем нодам find и возвращает список ссылок
Если очень упростить, то да. Но роль кэша тут велика. Если песни часто тянутся, то в основном ссылки будут приходить без обхода сети. Ты не можешь получить несколько разных ссылок с разными вариантами. Приходит ссылка с наибольшим совпадением.
По поводу хэшей, ключей и названий.
Хэш тут мало роли играет, именно в музыкальном хранилище. Ключом является название песни, потому что это убивает сразу всех зайцев: дает уникальность песне, обладает человекоперевариваемым видом, легко копируется и.т.д.
Единственное узкое место в этой схеме то, что название может не соответствовать содержанию. Но в ближайшем будущем это, впринипе, кажется нерешаемая проблема.
Я решил удерживать качество путем разделения людей от роботов. Человеческий контент приоритетнее. Поэтому если ты, например, увидел не очень качественную или левую песню в хранилище, то можешь перезаписать ее в режиме модератора. А робот не может (в теории).
Тема спама в открытых сетях это одно из самых узких мест.
В том и смысл, чтобы упростить все это, сделать границу между автором, слушателем и его донатом минимальной. В идеале везде, где ты будешь слушать какую-то песню, рядом будет кнопочка доната. Нужно лишь, чтобы большинство следовало этому алгоритму.
Сейчас пара нод, правда, я еще могу прикупить парочку допустим, я не миллионер пока, это да. Но смысл открытых децентразиванных проектов, в том, чтобы в нем учавствовали все желающие. Вот вы можете тоже взять и поднять узел, например.
По поводу мусора. Сеть настроена на циркуляцию. Если места не хватает, то наименее приоритетные и редкоиспользуемые песни удаляются, чтобы освободить место. Даже если будет всего один мой узел (200gb), он может обсуживать около 20000 песен.
20 узлов — это уже 400000 песен за вычетом копий.
По поводу открытого ip. Сейчас работает тестовая сеть, пока не сильно заморачиваюсь с блокировками возможными. В любом случаи в качестве адреса может быть любой домен в итоге, и сеть автоматически перерегистрирует узел если надо. А поводу механизмов скрытия можете написать мне в телеграмм или хотя бы скинуть ссылки интересные. Я рассматриваю возможные варианты.
Но киллер-фича Svelte в том, что это компилятор и у него нет runtime.
И что программист, которому надо просто на этом написать сайт или пользователь приложения от этого получают в итоге? Надо делать киллер-фичу ради киллер-фичи?
умудряются вбирать в себя все лучшие практики других фреймворков
Он умеет все что нужно
Похоже на "слова велосипедистов", как вы писали ранее ) Так можно написать про любой фреймворк, который человеку подходит для решения какой-то задачи.
что купить «Noname» авто вместо проверенный «Toyota»
Я специально не проигнорировал цитаты выше. Потому что весь их смысл как раз вот в этой, последней цитате. Как вы думаете кто-то еще "заглянул бы в салон" кроме вас, если бы, скажем, vue еще не был написан, но его бы сейчас выложил я? Можете не отвечать на этот риторический вопрос ))
Но я не отрицаю, что если написать что-то действительно инновационное, то это может стать популярным и у "нонейма" =)
Вы когда машину покупаете, тоже спрашиваете продавца в чем киллер-фича или все-таки садитесь в салон, рассматриваете, пробуете покататься и в итоге выбираете ту, которая подходит именно вам?
Для начала, там они возвращаются не строкой, а полноценным JS объектом в window.DATA. При большом желании он может содержать и фукнции, только смысла в этом нет.
Они в любом случаи возвращаются с сервера строкой. Поэтому функции он содержать не может, как и экземпляры классов и некоторые другие вещи, которые могут быть в стейте.
Главное чтобы клиентский и серверный код был общий, а стейт данных, которые использовались сервером для SSR были переданы на клиент. Однако, насколько я понял, в вашем случае она усложняется выбором кривых подходов к фреймворку в целом.
Это не касается конкретно моего фреймворка, а вообще любого.
В вашем стейте, который возвращается в демке только простые данные, которые можно вернуть строкой, поэтому кажется, что все ок.
И демка почему-то отрисовывается дважды. Не стал вникал с чем именно это связано, но явно не нормальное поведение.
Сравнил. Код на Ractive похож на конфигурацию. А в Akili выглядит гибким и расширяемым.
Если вам нравится строить структуру как это предлагает Ractive или Vue тот же, то смысла использовать Akili нет. Мне такой подход не очень близок.
К какому-то моменту я написал больше кол-во проектов на разных фреймворках на наемной работе. Но однажды, когда мне нужно было выбрать, что-то для реализации своего проекта, я долго думал и понял, что ни на чем из этого я не хотел бы писать.
Akili был сделан с основной целью — получать удовольствие от процесса.
Стоп, у вас скоуп родительского компонента доступен в дочернем? А как же инкапсуляция и изоляция?
Это никак не мешает изоляции компонента. Зато является удобной фишкой для многих кейсов, когда изоляция не нужна.
Не понимаю, сохранение куда? Зачем их сохранять в разметку? У вас либо какой-то супер уникальный подход, либо вы что-то делаете не так.
А почему у вас сервер возвращает какую-то ересь? SSR должен рендерить обычный HTML, без ваших конструкций. А гидрация просто жизнено необходима, потому что никому не хочется рендерить приложение и на сервере и на клиенте. Уж извините.
Нет никаких конструкций. Это обычный html. Рендерить не хочется, но гидрация не сможет восстановить правильное состояние в некоторых случаях. Это конечно не значит, что ее реализовать совсем не нужно. На данный момент это достаточно трудоемкая задача, с не самым высоким приоритетом.
И что? Одно другому не мешает. Можно организовать приоритизацию резолвинга выражений. Если выражение не найдено в контексте текущего компонента, ищем в глобалах. Хотя в целом глобалов все же лучше избегать.
Приоритезация уже и так есть. Каждый скоуп наследуется от родительского. Поэтому впихивание сюда еще и глобальных переменных нарушило бы логику.
Под кэшированием запросов вы подразумеваете сбор ответов в некую единую структуру для ее отпраки на клиент вместе со страницей или же настоящее кэширование ответов с сервера?
Будет сделано так, чтобы все http запросы выполнялись только один раз и во время серверного рендеринга. Ближе к делу я буду думать над точной реализацией. Но уже сейчас понятно, что это сделать не сложно.
Похоже что так. Вы так и не рассказали что у вас с гидрацией (hydrate)? Без этого SSR становится кривой надстройкой. Если вдруг не в курсе, можете почитать здесь.
А какие еще данные нам нужны? Можете привести пример?
Например, сохранение в переменные/свойства: функций, классов, экземпляров классов и.т.д.
Дело в том, что в выражение можно добавлять глобальные переменные. Например, там уже есть event, utils, console и.т.д. А можно вообще любые свои:
Akili.options.globals = { my: 1 }
${ my + this.x }
Как вы будете синхронизировать состояние данные в скоупе с теми манипуляциями DOM, которые производит DataTables и в обратном направлении.
Например, мы добавили новый элемент в массив данных через ваш скоуп и DataTables также обновился.
Я не нашел как в DataTables получить чистый измененный массив. Пришлось пройтись циклом лишний раз, чтобы очистить лишние ключи.
Нужно иметь ввиду, что если бы DataTables работал не с копией переданного массива, то вообще ничего не надо было бы делать. Данные обновлялись бы сами, поскольку все объекты скоупа это Proxy.
В использовании Redux очень сложен, так как весьма многословен и требует тонны бойлерплейта.
Не согласен. Его "сложность" мягко говоря преувеличена.
Разве такое не умеет любой нормальый роутер
Это много. Лучше вообще не ключать его в стандартную сборку и шипить как отдельный модуль.
Это просто обычные сервисы, позволяющие реализовать SPA. Понятно, что в них не будет ничего сверх-нового, альтернатив масса. Смысл тут в том, что Akili это фреймворк. У человека должна быть возможность просто подгрузить один файл и написать полноценное приложение без зависимостей.
Иными словами, когда код выполняется на клиенте он заново производит рендеринг всех компонентов, которые уже были отрендерены на сервере. Видимо и запросы дергает все. Тогда это фигня, а не поддрежка SSR.
Я не концентрировался на этой задаче достаточно, но:
код на сервере исполняется полностью, без необходимости ничего переписывать/ добавлять. Пара строк и все готово.
Можно делать асинхронные операции в компонентах, они все тоже будет обработаны
Уже реализована система кэширования запросов. То есть в ближайшее время добавлю в SSR передачу этих данных, и запросы не будут выполняется на клиенте больше.
Что касается остального состояния, то это очень сложно сделать, может быть даже невозможно до конца. Потому что в идеале нам нужны не только данные, которые можно сериализовать и отправить.
Такать не надо, просто интересно, что вы имеете ввиду под «магическими надстроеками к разметке или коду», которых у вас, как я понимаю, нет. Можно просто пару примеров.
react — jsx
angular1 — своя модульная система, DI
angular 2+ — своя модульная система, своя разметка, DI, typescript
Это не значит, что все это не нужно и плохо. Но можно не хуже и без этого.
Под стереть грань имеется ввиду декларативный подход к 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. Вещи типа такого являются нормальными:
Понятно, что это просто пример. Скрыть элемент можно гораздо "правильнее" в рамках фреймворка, но суть надеюсь передал.
В каком месте Redux прост?
А что в нем сложного? По сути обычный event emitter с парочкой методов )
Можете пояснить по этим пунктам?
Под resolving data имеется ввиду, что указывая маршрут, мы в его обработчике можем вернуть Promise с данными. И вложенные маршруты не будут обработаны, пока не зарезолвится текущий.
Абстрактные маршруты — это маршруты, у которых нет шаблона. То есть просто в обработчике делаешь что-то, что тебе нужно и все. Они могут быть частью иерархии маршрутов тоже.
Ну это скорее минус. Это реализовано отдельным модулем? Можно как-то выпилить удобно?
Можно просто не использовать его. Код этого сервиса занимает несколько килобайт.
Гидрировать разметку на клиенте умеет? Нужно передавать весь стейт, а как иначе?
Сейчас он просто выполняет код на сервере, потом происходит повторная инициализация фреймфорка уже на клиенте. В ближайших планах передавать еще кэш всех запросов с сервера и стейт хранилища. Но со всем остальным гораздо все сложнее.
В сравнении с чем?
В сравнении с другими фреймворками. Не хочется просто показывать пальцем )
Спасибо за концентрацию внимания на этом моменте, я добавил возможность биндинга функции в шаблоне и по изменению аргументов и по телу. Теперь ваш пример должен работать.
С какими пиратами бороться собрались? Пираты с пиратами не борятся))
Можете в телеграмм написать по поводу песни, если что.
Нода упала — контент пропал из сети, но не узла. Если узел вернется, то все восстановится.
Если узлов больше 1, то у всех песен будет как минимум один дубликат. Чем больше узлов, тем больше дубликатов. Кол-во дубликатов настраивается, сейчас стоит как корень из размера сети. Поэтому если в сети 9 узлов, скажем, то 2 любых могут падать, ничего не поменяется. Тут главное — постоянная циркуляция песен. Тогда все будет ок.
Если очень упростить, то да. Но роль кэша тут велика. Если песни часто тянутся, то в основном ссылки будут приходить без обхода сети. Ты не можешь получить несколько разных ссылок с разными вариантами. Приходит ссылка с наибольшим совпадением.
По поводу хэшей, ключей и названий.
Хэш тут мало роли играет, именно в музыкальном хранилище. Ключом является название песни, потому что это убивает сразу всех зайцев: дает уникальность песне, обладает человекоперевариваемым видом, легко копируется и.т.д.
Единственное узкое место в этой схеме то, что название может не соответствовать содержанию. Но в ближайшем будущем это, впринипе, кажется нерешаемая проблема.
Я решил удерживать качество путем разделения людей от роботов. Человеческий контент приоритетнее. Поэтому если ты, например, увидел не очень качественную или левую песню в хранилище, то можешь перезаписать ее в режиме модератора. А робот не может (в теории).
Тема спама в открытых сетях это одно из самых узких мест.
Сейчас пара нод, правда, я еще могу прикупить парочку допустим, я не миллионер пока, это да. Но смысл открытых децентразиванных проектов, в том, чтобы в нем учавствовали все желающие. Вот вы можете тоже взять и поднять узел, например.
По поводу мусора. Сеть настроена на циркуляцию. Если места не хватает, то наименее приоритетные и редкоиспользуемые песни удаляются, чтобы освободить место. Даже если будет всего один мой узел (200gb), он может обсуживать около 20000 песен.
20 узлов — это уже 400000 песен за вычетом копий.
По поводу открытого ip. Сейчас работает тестовая сеть, пока не сильно заморачиваюсь с блокировками возможными. В любом случаи в качестве адреса может быть любой домен в итоге, и сеть автоматически перерегистрирует узел если надо. А поводу механизмов скрытия можете написать мне в телеграмм или хотя бы скинуть ссылки интересные. Я рассматриваю возможные варианты.
И что программист, которому надо просто на этом написать сайт или пользователь приложения от этого получают в итоге? Надо делать киллер-фичу ради киллер-фичи?
Похоже на "слова велосипедистов", как вы писали ранее ) Так можно написать про любой фреймворк, который человеку подходит для решения какой-то задачи.
Я специально не проигнорировал цитаты выше. Потому что весь их смысл как раз вот в этой, последней цитате. Как вы думаете кто-то еще "заглянул бы в салон" кроме вас, если бы, скажем, vue еще не был написан, но его бы сейчас выложил я? Можете не отвечать на этот риторический вопрос ))
Но я не отрицаю, что если написать что-то действительно инновационное, то это может стать популярным и у "нонейма" =)
Вы когда машину покупаете, тоже спрашиваете продавца в чем киллер-фича или все-таки садитесь в салон, рассматриваете, пробуете покататься и в итоге выбираете ту, которая подходит именно вам?
Они в любом случаи возвращаются с сервера строкой. Поэтому функции он содержать не может, как и экземпляры классов и некоторые другие вещи, которые могут быть в стейте.
Это не касается конкретно моего фреймворка, а вообще любого.
В вашем стейте, который возвращается в демке только простые данные, которые можно вернуть строкой, поэтому кажется, что все ок.
И демка почему-то отрисовывается дважды. Не стал вникал с чем именно это связано, но явно не нормальное поведение.
Сравнил. Код на Ractive похож на конфигурацию. А в Akili выглядит гибким и расширяемым.
Если вам нравится строить структуру как это предлагает Ractive или Vue тот же, то смысла использовать Akili нет. Мне такой подход не очень близок.
К какому-то моменту я написал больше кол-во проектов на разных фреймворках на наемной работе. Но однажды, когда мне нужно было выбрать, что-то для реализации своего проекта, я долго думал и понял, что ни на чем из этого я не хотел бы писать.
Akili был сделан с основной целью — получать удовольствие от процесса.
Это никак не мешает изоляции компонента. Зато является удобной фишкой для многих кейсов, когда изоляция не нужна.
Нет никаких конструкций. Это обычный html. Рендерить не хочется, но гидрация не сможет восстановить правильное состояние в некоторых случаях. Это конечно не значит, что ее реализовать совсем не нужно. На данный момент это достаточно трудоемкая задача, с не самым высоким приоритетом.
Приоритезация уже и так есть. Каждый скоуп наследуется от родительского. Поэтому впихивание сюда еще и глобальных переменных нарушило бы логику.
Будет сделано так, чтобы все http запросы выполнялись только один раз и во время серверного рендеринга. Ближе к делу я буду думать над точной реализацией. Но уже сейчас понятно, что это сделать не сложно.
Например, сохранение в переменные/свойства: функций, классов, экземпляров классов и.т.д.
Как гидрация тут поможет? Сервер рендерит и возвращает:
Пользователь кликает на див и ?
Дело в том, что в выражение можно добавлять глобальные переменные. Например, там уже есть event, utils, console и.т.д. А можно вообще любые свои:
http://jsfiddle.net/vjarL1t6/50/
Пара комментариев к примеру.
Не согласен. Его "сложность" мягко говоря преувеличена.
Это просто обычные сервисы, позволяющие реализовать SPA. Понятно, что в них не будет ничего сверх-нового, альтернатив масса. Смысл тут в том, что Akili это фреймворк. У человека должна быть возможность просто подгрузить один файл и написать полноценное приложение без зависимостей.
Я не концентрировался на этой задаче достаточно, но:
Это не значит, что все это не нужно и плохо. Но можно не хуже и без этого.
Спасибо за интерес =)
Под стереть грань имеется ввиду декларативный подход к html разметке.
this.scope в компоненте тот же самый объект, что и this в разметке. Я считаю это очень удобно.
Все биндинги в разметке привязаны к конкретным DOM узлам и не мешают работать с другими узлами. То есть можно легко совмещать компонентную систему фреймворка и стандартные фишки javascript. Вещи типа такого являются нормальными:
Понятно, что это просто пример. Скрыть элемент можно гораздо "правильнее" в рамках фреймворка, но суть надеюсь передал.
А что в нем сложного? По сути обычный event emitter с парочкой методов )
Под resolving data имеется ввиду, что указывая маршрут, мы в его обработчике можем вернуть Promise с данными. И вложенные маршруты не будут обработаны, пока не зарезолвится текущий.
Абстрактные маршруты — это маршруты, у которых нет шаблона. То есть просто в обработчике делаешь что-то, что тебе нужно и все. Они могут быть частью иерархии маршрутов тоже.
Можно просто не использовать его. Код этого сервиса занимает несколько килобайт.
Сейчас он просто выполняет код на сервере, потом происходит повторная инициализация фреймфорка уже на клиенте. В ближайших планах передавать еще кэш всех запросов с сервера и стейт хранилища. Но со всем остальным гораздо все сложнее.
В сравнении с другими фреймворками. Не хочется просто показывать пальцем )