Комментарии 13

Я обычно презентую $mol, выпущенный пару лет назад, как фреймворк будущего. Давайте посмотрим, куда движется Vue..


3.0 будет поддерживать компоненты на основе классов изначально

Что было изначально в $mol. Любой компонент — не более чем класс, реализующий определённый АПИ.


Кодовая база 3.x сама будет написана на TypeScript и обеспечит улучшенную поддержку TypeScript.

Что было изначально в $mol. Даже шаблоны проверяются TS компилятором.


чтобы избежать глобального вмешательства в прототип Vue при установке плагинов. Вместо этого плагины будут применены и привязаны к дереву компонентов.

Что было изначально в $mol. К любому компоненту можно приаттачить набор плагинов и использовать их для расширения функциональности.


Ленивое наблюдение по-умолчанию.

Что было изначально в $mol. Более того, ленивое не только наблюдение, но и все вычисления, позволяя, например, не загружать данные, которые не нужны для рендеринга в текущий момент.


Меньше: новая кодовая база спроектирована с нуля как tree-shaking friendly.

Что было изначально в $mol. Более того, вместо того, чтобы подключать пакет, а потом вырезать лишнее с помощью tree-shaking, в $mol лишний код не подключается изначально. А всё потому, зависимостями управляет автоматика, а не вручную.


рендеринг поддерева в другой части DOM, а не внутри компонента

Что было изначально в $mol. Без всяких порталов можно любой компонент отрендерить в любом другом или вообще в стороне от приложения. Вся фишка в том, что компоненты в $mol — самодостаточные, не зависящие от окружения. Любой компонент может быть приложением, а любое приложение — компонентом.


все слоты, созданные с помощью компилятора, теперь являются функциями и вызываются во время вызова рендеринга дочернего компонента.

Что было изначально в $mol. Более того, тот же принцип действует в любых направлениях. Например, часть родителя может быть функцией от свойств детей, что активно применяется для ленивого рендеринга.


Размер новой runtime библиотеки <10kb в gzip.

Что было изначально в $mol. Точнее не так, как такового рантайма в $mol нет, просто в бандл попадают те модули, которыми воспользовались. Но реактивный "привет мир" как раз 10кб и занимает.


Так что использовать $mol становится всё меньше и меньше поводов, что является весьма позитивной тенденцией.

Вы уверены, что так назойливо рекламируя свой мол достигнете своей цели? Я уже давно *заставляю* себя читать ваши посты в которых упоминается мол. Как правило не читая можно предсказать все что вы напишете: «Вы тут все не цените — ах какая у меня конфетка».

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


Ухты! Выглядит, как необычный способ выстрелить себе в ногу, но, не смотря на это, интересно, как это реализовано. Выходит так, что
— свойства детей могут быть изменены не только родительским компонентом (если нет, то почему бы родителю просто не опираться на эти свойства, которые он и прокидывает детям)?
— родительский компонент как-то подписывается на свойства детей?
Или как-то иначе?

И ещё вопрос: детектится ли как-то при этом зацикливание? Например, когда родитель, реагируя на изменение свойства ребёнка, меняет его другое свойство, а ребёнок отрабатывает это изменение и меняет первое свойство, на которое опять реагирует родитель, и так до бесконечности.

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


Компоненты — просто классы со свойствами, а свойства уже автоматически трекают зависимости друг между другом благодаря ОРП. В VueJS тоже свойства через орп синхронизируются, но оно гвоздями прибито к компонентам.


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

НЛО прилетело и опубликовало эту надпись здесь
Да, член у меня маленький. Вы правда находите это смешным?
НЛО прилетело и опубликовало эту надпись здесь
Вы задали всего три вопроса. Два риторических и один про члены.

Дмитрий, вас то кто заставил заниматься $mol? Я ни разу не использовал $mol но думаю что он хорош. Точно лучше Angular и React, но уже не лучше Vue Я также думаю, что если бы в основе лежал jsonnet он был бы всё ещё лучше, но это был бы уже не $mol, потому что идеи заложенные в архитектуре $mol на мой взгляд исчерпаны

Дмитрий, вас то кто заставил заниматься $mol?

Просто я мазохист. Люблю боль и страдания. А $mol доставляет мне их максимальное количество на единицу кода.


Я ни разу не использовал $mol но думаю что он хорош.

Ну зачем вы обманываете себя? Попробуйте использовать и сразу поймёте, что у него непонятные шаблоны, все компоненты кривые, все демки тормозят, а документации так вообще нет.


Точно лучше Angular и React, но уже не лучше Vue

Если бы $mol был лучше, чем Angular или даже, прости господи, React, то звёздочек у него было бы куда больше, чем у них. Однако у $mol звёздочек в 1000 раз меньше! Выводы, думаю, очевидны.


Я также думаю, что если бы в основе лежал jsonnet он был бы всё ещё лучше

Это же просто генератор json-а. При чём тут фреймворки? Этим jsonnet-ом можно для любого фреймворка данные подготовить.


идеи заложенные в архитектуре $mol на мой взгляд исчерпаны

Да какая там архитектура? Просто навалили в корень репозитория кучу модулей без какой-либо группировки лишь бы их имена в глобальном (!) скоупе были короткими. Это ж надо было додуматься в 2k18 использовать неймспейсы вместо нативных модулей.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.