yaml как-то освоили, и pug освоили, и sass освоили, даже python освоили, а тут видите ли трансцендентный синтаксис.
Интересно, что в среде фронтендеров в целом подобный синтаксис не прижился: pug нишевый, sass уступил scss'у, coffeescript забыли с приходом es6. Интересно также, что один из ваших последователей — как раз человек с питоновским бэкграундом. Так может тогда вам с $mol исключительно на эту аудиторию таргетироваться?
Типа, если вокруг много говноедов, то надо и самому начать производить и потреблять ту же субстанцию?
Кстати это тоже демагогический приём — сведение к абсурду, не говоря уже об уважении к аудитории. Но получается, что если массы — исключительно говноеды, и вам с ними не по пути, то зачем вы их постоянно переубеждаете?
И даже если можно инкапсулировать, это надо делать самому.
Нет, инкапсуляцию контрола делал сам разработчик контрола. Например, dropdown или datepicker: наружу выставлялись методы для настройки, установки значения и подписки на результат. То же самое, что и в десктопных фреймворках.
полноценные десктопные приложения, в виде html-страницы
Десктопные приложения, которые выглядят как html-страницы или html-страницы, которые выглядят как десктопные приложения? У вас мысль нечётко сформулирована.
Кстати я наверное понимаю, почему вы пропагандируете именно классическую модель работы с компонентами: в простых приложениях кажется, что она проще и понятнее, но это вызывает сильную связность компонентов, которые начинают зависеть не от данных, а от других компонентов.
Вот предположим: есть простая форма с вводом суммы и двух выпадаек: исходная валюта и конечная валюта. Приложение должно делать конвертацию в реальном времени: периодически загружаются новые биржевые курсы валют, введённая сумма также пересчитывается. В классическом подходе получится, что будут нужны метод расчёта и метод вывода конечной суммы. При этом метод вывода будет вызываться из четырёх мест: при изменении начальной суммы, при выборе валют и при обновлении курсов, и будет вызывать метод расчёта суммы, который будет собирать данные из всех контролов. В итоге, даже для такого простого случая вам понадобится явно подписаться на все источники событий, а также на все данные, которые они порождают. В реактивном же подходе вы просто создадите функцию расчёта значения, а всё остальное сделает система реактивности.
В разных странах разные ПДД, и хотя часть из них некоторым образом гармонизирована Венской и Женевской конвенциями, однако они всё равно различаются в мелочах. Но это хотя бы более-менее чёткие правила, а от комитетских документов под названием «Структура парадигм взаимодействия» вы не дождётесь никакой конкретики, там будут максимально обтекаемые формулировки, бесполезные чуть менее, чем полностью.
Странный аргумент. Зачем же отказываться от реактивности, если с ней намного удобнее? Это показывает и пример десктопов (тот же WPF), и мобил (Jetpack Compose и SwiftUI), и самого веба. Но приходит человек, который говорит: «Я когда-то что-то делал на Делфи, поэтому считаю, что вы тут все неправы, выходите из зоны комфорта». Кажется, это выглядит довольно абсурдно.
А модель OSI добилась большего. Весь мир бегает по ее «указке».
Это просто принято так считать. Эксперты же полагают, что это просто абстрактная модель, которая мало соотносится с реальностью, включая реализацию TCP/IP, в которой 5 слоёв. Некоторые предлагают 3-слойную модель, а RFC 3439 вообще считает слои вредным усложнением.
Так что модель OSI существует только в книжках для студентов, поэтому ссылаться на неё как успешный пример единого глобального дизайна не стоит.
Я и не говорил, что это прям пхпшный синтаксис. С другой стороны, фронтендеры всё равно знают JS и TS, поэтому разные типы скобок для них привычны. А так-то фигурные скобки для атрибутов и в CSS есть.
Пхпшники живут же с ассоциативными массивами с квадратными скобками или array(), и ничего. Наоборот, здесь подчёркивается строгая последовательность элементов, которые будут выводиться в списке, в отличие от атрибутов компонента.
только мешают изучению новых концепций
Незнакомый и непривычный синтаксис создаёт дополнительную когнитивную нагрузку. Из мнемоничности же в нём только стрелки потока данных.
Если развивать эту мимикрию под JS
Не обязательно мимикрировать под JS, язык может быть более кастомный, но попытка выхолащивать синтаксис не идёт ему на пользу, и об этом говорят многочисленные критические комментарии.
На самом деле мне неизвестно, есть ли в интерфейсе сложных программ какая-либо реализация реактивности.
Также стоит посмотреть на классические интерфейсы мобильных iOS/Android приложений.
Изначально там не было реактивности, но и приложения были довольно простыми. Потом же в Android стали использовать RxJava, а потом ушли к реактивности на Compose с корутинами и MVVM. В iOS тоже сначала появился ReactiveCocoa, затем RxSwift, а теперь официально рекомендуется реактивность на SwiftUI + Combine.
В браузерах работа с UI осложнена тяжеловесностью DOM API, в котором нужно делать точечные манипуляции над элементами для нормальной производительности. Напрямую манипулировать элементами никто не мешает, но это очень неудобно. Поэтому, например, в React придумали делать Virtual DOM, который сам вычисляет и применяет изменения элементов, а разработчику нужно только построить этот VDOM с опциональной мемоизацией поддеревьев. Конечно, это очень неэффективно. В SolidJS решили по-другому: обернуть каждый DOM-элемент реактивной обёрткой, так что система реактивности сама должна наиболее эффективно вычислить минимально необходимые изменения в DOM.
На более высоком уровне реактивность как будто бы так сильно и не нужна, но если она есть — жить с ней намного легче, чем манипулировать данными императивно.
На самом деле в вашем случае действительно лучше подошё кастомный формат, но ему бы следовало быть более человекочитаемым. Например, использовать хотя бы двоеточие для обозначения наследования, квадратные скобки для списков и так далее. Да, может быть сложнее написать парсер, зато его когнитивно проще воспринимать и, в том числе, проще такой формат продать.
Конечно это возможно. Но Дмитрий совершает логическую ошибку. Сначала он придумывает формат tree как универсальный структурированный формат для данных на замену XML, JSON, YAML, объявляя его самым эффективным в общем случае. Затем он использует его для описания интерфейсов, тем самым создав подмножество view.tree. Логическая ошибка в том, что этот формат также неявно объявляется самым эффективным, то есть имеет место ошибочная апелляция к общему (fallacy accident).
Какое отношение Реакт имеет к модели OSI? То, что выполняется где-то на прикладном уровне? Но это абстрактное знание никак не помогает решить практические задачи.
Отлично, значит остаётся только продавать питонистам
Интересно, что в среде фронтендеров в целом подобный синтаксис не прижился: pug нишевый, sass уступил scss'у, coffeescript забыли с приходом es6. Интересно также, что один из ваших последователей — как раз человек с питоновским бэкграундом. Так может тогда вам с $mol исключительно на эту аудиторию таргетироваться?
Кстати это тоже демагогический приём — сведение к абсурду, не говоря уже об уважении к аудитории. Но получается, что если массы — исключительно говноеды, и вам с ними не по пути, то зачем вы их постоянно переубеждаете?
Нет, инкапсуляцию контрола делал сам разработчик контрола. Например, dropdown или datepicker: наружу выставлялись методы для настройки, установки значения и подписки на результат. То же самое, что и в десктопных фреймворках.
Десктопные приложения, которые выглядят как html-страницы или html-страницы, которые выглядят как десктопные приложения? У вас мысль нечётко сформулирована.
Кстати я наверное понимаю, почему вы пропагандируете именно классическую модель работы с компонентами: в простых приложениях кажется, что она проще и понятнее, но это вызывает сильную связность компонентов, которые начинают зависеть не от данных, а от других компонентов.
Вот предположим: есть простая форма с вводом суммы и двух выпадаек: исходная валюта и конечная валюта. Приложение должно делать конвертацию в реальном времени: периодически загружаются новые биржевые курсы валют, введённая сумма также пересчитывается. В классическом подходе получится, что будут нужны метод расчёта и метод вывода конечной суммы. При этом метод вывода будет вызываться из четырёх мест: при изменении начальной суммы, при выборе валют и при обновлении курсов, и будет вызывать метод расчёта суммы, который будет собирать данные из всех контролов. В итоге, даже для такого простого случая вам понадобится явно подписаться на все источники событий, а также на все данные, которые они порождают. В реактивном же подходе вы просто создадите функцию расчёта значения, а всё остальное сделает система реактивности.
Так ведь даже jQuery позволял инкапсулировать любые контролы и затем работать с ними в ООП-стиле. Сколько тех же Select на нём было.
В разных странах разные ПДД, и хотя часть из них некоторым образом гармонизирована Венской и Женевской конвенциями, однако они всё равно различаются в мелочах. Но это хотя бы более-менее чёткие правила, а от комитетских документов под названием «Структура парадигм взаимодействия» вы не дождётесь никакой конкретики, там будут максимально обтекаемые формулировки, бесполезные чуть менее, чем полностью.
Ну то есть вы предлагаете фронтендерам вернуться куда-то во времена jQuery и Backbone, и тогда-то всё станет хорошо.
Странный аргумент. Зачем же отказываться от реактивности, если с ней намного удобнее? Это показывает и пример десктопов (тот же WPF), и мобил (Jetpack Compose и SwiftUI), и самого веба. Но приходит человек, который говорит: «Я когда-то что-то делал на Делфи, поэтому считаю, что вы тут все неправы, выходите из зоны комфорта». Кажется, это выглядит довольно абсурдно.
Так я же и говорю, что она не от хорошей жизни потребовалась.
Нужен именно по типу дельфовского VCL или дотнетного WinForms, потому что простые формочки из 3 полей удобно было мышкой программировать?
Это просто принято так считать. Эксперты же полагают, что это просто абстрактная модель, которая мало соотносится с реальностью, включая реализацию TCP/IP, в которой 5 слоёв. Некоторые предлагают 3-слойную модель, а RFC 3439 вообще считает слои вредным усложнением.
Так что модель OSI существует только в книжках для студентов, поэтому ссылаться на неё как успешный пример единого глобального дизайна не стоит.
Я и не говорил, что это прям пхпшный синтаксис. С другой стороны, фронтендеры всё равно знают JS и TS, поэтому разные типы скобок для них привычны. А так-то фигурные скобки для атрибутов и в CSS есть.
В стиле Jetpack Compose (причём сохраняем синтаксис <=):
Пхпшники живут же с ассоциативными массивами с квадратными скобками или array(), и ничего. Наоборот, здесь подчёркивается строгая последовательность элементов, которые будут выводиться в списке, в отличие от атрибутов компонента.
Незнакомый и непривычный синтаксис создаёт дополнительную когнитивную нагрузку. Из мнемоничности же в нём только стрелки потока данных.
Не обязательно мимикрировать под JS, язык может быть более кастомный, но попытка выхолащивать синтаксис не идёт ему на пользу, и об этом говорят многочисленные критические комментарии.
На самом деле мне неизвестно, есть ли в интерфейсе сложных программ какая-либо реализация реактивности.
Изначально там не было реактивности, но и приложения были довольно простыми. Потом же в Android стали использовать RxJava, а потом ушли к реактивности на Compose с корутинами и MVVM. В iOS тоже сначала появился ReactiveCocoa, затем RxSwift, а теперь официально рекомендуется реактивность на SwiftUI + Combine.
В браузерах работа с UI осложнена тяжеловесностью DOM API, в котором нужно делать точечные манипуляции над элементами для нормальной производительности. Напрямую манипулировать элементами никто не мешает, но это очень неудобно. Поэтому, например, в React придумали делать Virtual DOM, который сам вычисляет и применяет изменения элементов, а разработчику нужно только построить этот VDOM с опциональной мемоизацией поддеревьев. Конечно, это очень неэффективно. В SolidJS решили по-другому: обернуть каждый DOM-элемент реактивной обёрткой, так что система реактивности сама должна наиболее эффективно вычислить минимально необходимые изменения в DOM.
На более высоком уровне реактивность как будто бы так сильно и не нужна, но если она есть — жить с ней намного легче, чем манипулировать данными императивно.
dicto simpliciter или accident fallacy
На самом деле в вашем случае действительно лучше подошё кастомный формат, но ему бы следовало быть более человекочитаемым. Например, использовать хотя бы двоеточие для обозначения наследования, квадратные скобки для списков и так далее. Да, может быть сложнее написать парсер, зато его когнитивно проще воспринимать и, в том числе, проще такой формат продать.
В какой-то степени выглядит похоже на Jetpack Compose.
Конечно это возможно. Но Дмитрий совершает логическую ошибку. Сначала он придумывает формат tree как универсальный структурированный формат для данных на замену XML, JSON, YAML, объявляя его самым эффективным в общем случае. Затем он использует его для описания интерфейсов, тем самым создав подмножество view.tree. Логическая ошибка в том, что этот формат также неявно объявляется самым эффективным, то есть имеет место ошибочная апелляция к общему (fallacy accident).
К сожалению, нет, и он будет с нами ещё долго. Кроме того, область применения Next.js более ограничена, чем React.
Тут вся статья состоит из характерных для ИИ оборотов и форматирования.
А можно больше конкретики, чтобы можно было хотя бы предметно разговаривать? Если будет пример кода, демонстрирующий реактивность — ещё лучше.
Цитаты выглядят как заголовки кликбейтных политических новостей на Ютубе
Какое отношение Реакт имеет к модели OSI? То, что выполняется где-то на прикладном уровне? Но это абстрактное знание никак не помогает решить практические задачи.