Выглядит очень симпатично. Такая штука была бы полезна не только для Go, но и для инфраструктур на других языках (писать, естественно, можно на Go). Заходишь, такой, на машину, восстанавливаешь сеанс tmux, а у тебя там сразу все метрики видны.
самого ожидаемого комикс-гиками фильма последних лет
Не смешите мои гражданки. В DC не знают что делать со своими персонажами, начихали на прекрасные фильмы о Бетмене, запилили перезапуск, столкнули нового бета с суперменом, не объясняя ничего, никакой предыстории и хотят всё это запихнуть в один фильм. Лигу не осилили.
С другой стороны у нас MCU, где всё чётко-чётко, один фильм вытекает из другого, впереди будут всяческие Войны Бесконечности и Гражданки, а вы тут такое говорите, эх…
Можно и так сказать. Я считаю, возможности обширнее, и задача шире. Можно привести всю асинхронщину к одному знаменателю. И это не только в рамках идеологии MVC. Например, я вполне могу представить cli программы, которые представляют собой единый поток от stdin к stdout со всякими фильтрами, асинхронными запросами на сторону итд.
А вообще, главное достижение FRP в том, что этот подход делает потоки данных более явными. Это лучше промисов (которые уже очень хороши) и уж точно лучше пачки ивент-эмиттеров. Промисы уже сделали очень и очень большой шаг в направлении явных потоков данных (в улучшении архитектуры, приведении её к явному виду), FRP продолжает этот путь, вводя постоянные потоки (в противовес промисам, где функция порождает новый промис при каждом вызове).
У V иногда может быть своя M для внутренних состояний
Вы всё абсолютно верно говорите, это состояние, но в данном случае не модели, а представления, и его ещё называют ViewModel. Автор Мифрила, кстати, в своей документации упоминает ViewModel и эта библиотека прекрасно работает с идеей VM.
По поводу контроллеров и FRP, то оно там и будет использоваться. Просто контроллер по-хорошему должен быть очень тонким, по сути, простая прослойка, вызывающая функции модели и отправляющая сформированные чанки данных во View. Большинство проверок и всю логику данных следует класть в модель, потому что они и относятся к модели данных. А контроллер здесь только приводит ответы вида error или ok к виду, в котором View может его употребить. По сути, FRP и будет использоваться в контроллере: скажем Model является источником некоторого потока, контроллер его фильтрует/приводит к нужному виду и отправляет во View. То же самое в обратную сторону.
Лично в моём коде контроллеры выполняют минимальные вещи. Это положительно влияет на логику кода и его читаемость. Если не используется FRP, а есть какие-то ивент-эмиттеры (а это почти всегда), то я стараюсь их сделать более явными, приблизить их по качеству к потокам данных. Если есть промисы, то хорошо. Максимум асинхронщины в промисах, это позволяет более чётко отлавливать все ситуации. Далее — декомпозиция и функциональные преобразования. То есть по сути, FRP, но на коленке. Если FRP уже есть, то хорошо.
Да, кстати, для Мифрила есть свой аналог JSX, называется, естественно, MSX.
Для полноты картины стоит здесь упомянуть React Native. Интересный подход на базе virtual DOM, по сути, приложение выступает в роли конструктора UI, на вход которому подаётся виртуальные элементы интерфейса (как это работает и в браузерном React, только сами виртуальные элементы другие, а подход тот же).
Это не совсем «открытый веб» на мобильном устройстве, хотя и гибридное приложение. Обещают хорошую производительность, засчёт того что графический слой нативный. Логика же приложения на JS.
Мне по нраву WebView-приложения и возможность использовать всю мощь открытого стека веб-технологий, но, к сожалению, оратор выше прав. Баги кордовы, тормоза, различия в браузерах на самых неожиданных местах, краши JS в разных браузерах. Всё это умножается на пока что слабую отладку и малый запас собранных граблей на SO. Разработка WebView-приложений сейчас напоминает десктопный веб лет пять-семь назад, те же сложности. Но, надеюсь, у гибридного подхода есть будущее и он переборет свои детские проблемы.
Матрешка не заставляет использовать определенную структуру кода, и не принуждает пользоваться хорошими, но, возможно, не самыми удачными решениями. Вы сами выбираете паттерны проектирования и структурирования приложения. Хоть Матрешка и позиционируется, как фреймворк, но, скорее, это библиотека, уменьшающая объем предстоящей работы.
Это мудро и честно. Хотя и требует большей дисциплины.
Две вещи вызывают некоторое опасание:
1. Использование собственных коллекций. Я понимаю, это нужно для более прямолинейной реализации биндинга через аксессоры, но множество других библиотек подобного типа умудряются делать такие вещи подкапотно (дельты / dirty-checking), так что модели пользователя (программиста) не трогаются. Я лично считаю, что очень важно уровень данных оставлять максимально независимым от библиотек. Это намного более лучшая интеграция и меньше отторжения у пользователя. Мне лично не нравится, что каждая либа считает вправе указывать мне какие модели использовать и как строить архитектуру.
2. Вызывает опасение этот код: this.on( 'change:x', function() {, а именно строковой литерал. Каждый раз, как архитектура становится достаточно сложной, приходится конструировать эти строки, соединять все эти change/пространства имён/идентификаторы и тому подобное. Строковой литерал должен быть строковым литералом и лучше в строках важные детали архитектуры не хранить. То есть здесь явно две сущности: change — имя события, x — конкретное имя биндинга. Минимальное что можно сделать, это разбить их на два аргумента, тем более, я уверен, под капотом это всё равно делается.
Да, не считайте это негативной критикой. Это просто мнение. Проект интересный, развивайте его дальше и желаю вам успехов.
Это правда. Так что внимательный читатель мануалов уже был тогда подкован в этом вопросе. Правда манаулов особо ни у кого не было :)
Кстати, тип атаки называется grooved spines. То есть прямым текстом написано, что это иглы или шипы. Но с локализацией первого СК тогда была большая беда и «бороздчатые иглы» превратились в «трубчатый позвоночник». А ещё тогда же появился мем «надмозг» :)
Решаю похожую проблему в Booth. Это Node.js/CommonJS библиотека, поверх вебсокета предоставляет два интерфейса: PubSub (у меня это названо realtime) и request-response (названо requests). Реализация двусторонняя: как сервер, так и клиент могут выступать одновременно и в качестве источника и приёмника потоков данных, также обе стороны могут обращаться друг к дружке с запросами.
Запросы имеют promise API, а реалтайм — callback. Есть планы по реализации FRP для реалтайма на основе какой-нибудь существующей библиотеки, например, симпатичной мне либы Highland.
Symbol это не костыль, а весьма мощный подход для создания примесей. Символы позволяют примешивать в объект методы и связанные с ними состояния, при этом не оголяя состояния. Если символов нет, в худшем случае придётся вести отдельную мапу, в которой будут храниться некоторые искуственные id для объектов и связанные с ними значения стейста примеси (и поддерживать актуальность мапы), в более лучшем варианте WeakMap, где вместо ключа уже выступает сам объект. Но символ решает эту задачу чище, позволяя хранить стейт прямо в объекте и при этом не засоряя никакие ключи (коллизий нет в принципе). Также символ автоматически решает задачу освобождения памяти — как только объект с примесью уничтожается, состояния примесей также уничтожаются, потому что они хранятся в объекте.
Символы (вместе с WeakMap-ами) позволят лучше организовать вещи, наподобие jQuery.data, разрешат некоторые ситуации с ивентами а также будут отличным подспорьем в FRP, помогая решить ситуации с текущей памятью. Символы решат много интересных задач в библиотечном коде. В коде приложения символы же можно использовать как простой enum, например. Уверен, найдутся и другие применения.
И да, в отличие от многих других фич нового стандарта (от которого я далеко не в восторге), Symbol не является сахаром. 80% остальных нововведений это либо сахар, либо вещи, которые уже давно прекрасно реализуются библиотеками.
Вот именно, в этом и состоит моя мысль, что это неправильно. Почему-то бытует мнение, что если у софта есть бесплатная версия/подписка, и его мощностей уже не хватает, то вместо того чтобы просто взять и купить этот софт, изыскивают способы обхода ограничений. При этом другие статьи расходов могут в десятки-сотни раз превышать стоимость этого софта. Наверно это вопрос привычки.
С другой стороны у нас MCU, где всё чётко-чётко, один фильм вытекает из другого, впереди будут всяческие Войны Бесконечности и Гражданки, а вы тут такое говорите, эх…
А вообще, главное достижение FRP в том, что этот подход делает потоки данных более явными. Это лучше промисов (которые уже очень хороши) и уж точно лучше пачки ивент-эмиттеров. Промисы уже сделали очень и очень большой шаг в направлении явных потоков данных (в улучшении архитектуры, приведении её к явному виду), FRP продолжает этот путь, вводя постоянные потоки (в противовес промисам, где функция порождает новый промис при каждом вызове).
По поводу контроллеров и FRP, то оно там и будет использоваться. Просто контроллер по-хорошему должен быть очень тонким, по сути, простая прослойка, вызывающая функции модели и отправляющая сформированные чанки данных во View. Большинство проверок и всю логику данных следует класть в модель, потому что они и относятся к модели данных. А контроллер здесь только приводит ответы вида error или ok к виду, в котором View может его употребить. По сути, FRP и будет использоваться в контроллере: скажем Model является источником некоторого потока, контроллер его фильтрует/приводит к нужному виду и отправляет во View. То же самое в обратную сторону.
Лично в моём коде контроллеры выполняют минимальные вещи. Это положительно влияет на логику кода и его читаемость. Если не используется FRP, а есть какие-то ивент-эмиттеры (а это почти всегда), то я стараюсь их сделать более явными, приблизить их по качеству к потокам данных. Если есть промисы, то хорошо. Максимум асинхронщины в промисах, это позволяет более чётко отлавливать все ситуации. Далее — декомпозиция и функциональные преобразования. То есть по сути, FRP, но на коленке. Если FRP уже есть, то хорошо.
Да, кстати, для Мифрила есть свой аналог JSX, называется, естественно, MSX.
Это не совсем «открытый веб» на мобильном устройстве, хотя и гибридное приложение. Обещают хорошую производительность, засчёт того что графический слой нативный. Логика же приложения на JS.
1. Использование собственных коллекций. Я понимаю, это нужно для более прямолинейной реализации биндинга через аксессоры, но множество других библиотек подобного типа умудряются делать такие вещи подкапотно (дельты / dirty-checking), так что модели пользователя (программиста) не трогаются. Я лично считаю, что очень важно уровень данных оставлять максимально независимым от библиотек. Это намного более лучшая интеграция и меньше отторжения у пользователя. Мне лично не нравится, что каждая либа считает вправе указывать мне какие модели использовать и как строить архитектуру.
2. Вызывает опасение этот код:
this.on( 'change:x', function() {, а именно строковой литерал. Каждый раз, как архитектура становится достаточно сложной, приходится конструировать эти строки, соединять все эти change/пространства имён/идентификаторы и тому подобное. Строковой литерал должен быть строковым литералом и лучше в строках важные детали архитектуры не хранить. То есть здесь явно две сущности: change — имя события, x — конкретное имя биндинга. Минимальное что можно сделать, это разбить их на два аргумента, тем более, я уверен, под капотом это всё равно делается.Да, не считайте это негативной критикой. Это просто мнение. Проект интересный, развивайте его дальше и желаю вам успехов.
Кстати, тип атаки называется grooved spines. То есть прямым текстом написано, что это иглы или шипы. Но с локализацией первого СК тогда была большая беда и «бороздчатые иглы» превратились в «трубчатый позвоночник». А ещё тогда же появился мем «надмозг» :)
Запросы имеют promise API, а реалтайм — callback. Есть планы по реализации FRP для реалтайма на основе какой-нибудь существующей библиотеки, например, симпатичной мне либы Highland.
Символы (вместе с WeakMap-ами) позволят лучше организовать вещи, наподобие jQuery.data, разрешат некоторые ситуации с ивентами а также будут отличным подспорьем в FRP, помогая решить ситуации с текущей памятью. Символы решат много интересных задач в библиотечном коде. В коде приложения символы же можно использовать как простой enum, например. Уверен, найдутся и другие применения.
И да, в отличие от многих других фич нового стандарта (от которого я далеко не в восторге), Symbol не является сахаром. 80% остальных нововведений это либо сахар, либо вещи, которые уже давно прекрасно реализуются библиотеками.