LiquidLava MVC Framework

[fancy]

Единственное, что мне нравится в React это самая идея с отложенным рендеренгом.
В одном фреймворке после большого обновления появились огромные тормоза, столько туда всяких паттернов добавили.
Все жаловались.
Они думали думали, ну и через год сделали следующее.
Так как все ООП, есть возможность сначала собраться все для рендеринга, а потом разом все на какое то событие отобразить.
И проблема с производительностью была решена.
Не знаю как они там это сделали, может через виртуальный дом, но врят ли, их код такое не позволял.
Кстати, потом один из сотрудников этой фирмы, Team Lead ушел в facebook, может это и была его идея сделать React.
Но я думаю реализация не получилась.

[Safort]

fancy,

Но на деле, полный rerender редко когда нужен.
И никто не будет каждые 1-5 секунд делать rerender 5000 + строк для table например.

Я совсем-совсем не спец. в Реакте, но, вроде бы, у них как раз наоборот, рендерятся только нужные части.

[melky]

Этот flux все равно слишком многое делает сложно.
Скорее у меня более красивый подход внутренней RIA либы
на которой вконтакт работает.
При желание можете покопаться как у них там что)))

Только у меня все в разы красивей ))
И я не пользуюсь require как они, нет необходимости.
хотя им без require никак.

посмотреть бы что ли

Вот и вам и ответ на виртуализацию DOM, которая в React.

сколько раз уходили от использования innerHTML, сколько было разговоров на тему, почему это плохо для SPA ... разве не достаточно?

Помню у меня была своя fx либа - css3 не решает до сих пор всех моментов, приходится иметь свое решение.

модуль анимаций CSS3 слаб. помимо того, он очень медленный.

я изучал тему анимаций довольно глубоко. тоже писал свою либу для анимаций. получалось по скорости так же (разница в 5 FPS в мою сторону), как и у GSAP.

правда , фич у меня было меньше - либу я писал как реализацию CSS3 Animations на JavaScript.

но потом я увидел стандарт Web Animations и понял, что я занимаюсь хрен пойми чем. в итоге залил "то, что было" на гитхаб, и уже год ищу свободное время на переписывание либы под этот новый стандарт.

... только как обычно, свободного времени нету )

Это тоже самое что CoffeeScript только не в стиле ruby и только ради того чтобы писать вот это

я к JSX привык через 15 минут.

в JSX - сила React... и его уродство.

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

не интересовался. предлагаю погрузиться в тему но моя приложуха на реакте не тормозит

Повторюсь их заявление, что типа мы берем и просто все перерендерим.
Что это значит?

перерисовываем в VDOM все компоненты, которые требуют перерисовки. требует ли компонент перерисовки - он решает сам - это метод shoudComponentUpdate

далее находим те части в VDOM, что изменились\добавились\удал ились и синхронизируем эти действия с реальным DOM.

Это значит что еще надо заново поставить dom события.

они вроде делегируются на корневой элемент

Они такой гемор*** делают из очень простой задачи.

на самом деле - нет. попробую обьяснить:
в ES6 введена система модулей, как мы знаем. теперь мы просто должны делить код на модули. т.о. соблюдается закон деметры.
у реакта компонент - та же атомарная единица. каждый компонент полностью описывает только себя (как и модуль)
если применить webpack, то получится, что модуль будет сам цеплять в проект свой CSS\остальное.
получается просто отличная реализация закона деметры (повторюсь)

мы можем запросто компоновать огромную систему через маленькие компоненты (подход снизу-вверх) через композицию.
и при этом имеем серверную отрисовку.

в React нет медиатора (паттерн), как в Angular. лично мне это плюс, потому что не нужно в голове держать кучу объектов.

единственная проблема - желание учиться и пробовать новое, не так ли? на этом отбрасывается большинство инородных идей. (это я лично про себя)

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

не совсем понял, о чём тут речь

вангую в 2015 дальшейшее распространение реакта или его переосмысление в другом фреймворке (жирное - вероятней)

_______________________
ещё я бы хотел сказать про FLUX - это обычная система событий (с вытекающими минусами типа цепочки событий), но она синхронна и одностороння, и с глобальными моделями и упрощёнными контроллерами.

и FLUX для меня лично был труднее в изучении, чем любой из MVC \ MVVM \ MV*. а фейсбуковцы говорят, что он (flux) - супер простой. врут

[fancy]

посмотреть бы что ли

В фирме используется.
Очень мощная вещь размером за 1 мб на нем работает.
Исходники показать не могу
Может в будущем.

сколько раз уходили от использования innerHTML, сколько было разговоров на тему, почему это плохо для SPA ... разве не достаточно?

Есть такие вещи, которые просто хорошо работают
А уж плохо это или нет, другой вопрос.

Плохо использовать глобальные переменные?
Да.
У вк, там им столько используется - штук 500.
И дает выигрышь в скорости.
Но применять можно только у себя на сайте.
Никому такое не нужно.

модуль анимаций CSS3 слаб. помимо того, он очень медленный.

Да...

я изучал тему анимаций довольно глубоко. тоже писал свою либу для анимаций. получалось по скорости так же (разница в 5 FPS в мою сторону), как и у GSAP.

И я делал как на css3 так и постаринке.
css3 - пока сыроват для полного перехода на него.
Легче постаринке.
Часто просто нужно решение.
Изучать все новые и новые фреймворки, фичи и прочее физически не хватает времени.

[nerv_]

в React нет медиатора (паттерн), как в Angular. лично мне это плюс, потому что не нужно в голове держать кучу объектов.

1. Ну а зависимости ты чем собрался разруливать? Я в реакт пока не погружался. При беглом просмотре - это только view.

Их есть у вас?

MyClass
   require: [
       Foo,
       Bar
   ]

https://yadi.sk/i/7nRX8MRZdbeoA

2. где няшки вроде promise/deferred из коробки?

Дьявол кроется в мелочах.

[melky]

Ну а зависимости ты чем собрался разруливать? Я в реакт пока не погружался. При беглом просмотре - это только view.

у меня есть CommonJS в браузере (webpack, это типа browserify короч).
модуль грузит свои дочерние модули, что он использует.

да, это только view

Их есть у вас?

нi, нету. и не надо

в ngApp я писал по 2 раза зависимости - сначала грузил сам модуль, затем прописывал его же в ангуляровский DI. и тупил от того, зачем я так делаю

в angular 2 DI кое-как изменится, и мб такой гемор уберут.

где няшки вроде promise/deferred из коробки?

свобода выбора, ёпть

npm i -S bluebird

я наигрался с bluebird, Q. теперь думаю заюзать when.

то же самое (выбор модулей) с роутером и т.д. и даже либа для флюкса (оффициальная, reflux, fluxxor... тысячи их)

да, понадобилось время для того, чтобы собрать инструментарий в кучу, но ...

... но у меня одинаковый код, стиль кода и одинаковые либы на сервере и клиенте. это просто супер.

Дьявол кроется в мелочах.

react - kiss. angular - не kiss.




nerv_, а как ты переиспользуешь код? как грузишь третьи зависимости (типа jquery или добавочных плюх angular)?


PS не подумай, что я не люблю angular - мне просто сравнивать особо не с чем

[kogarashisan]

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

Вы предлагаете мне именовать переменные в классе так же как методы - как тогда отличать методы от переменных? Если смешаны методы и переменные - то код превращается в мусорку.
Плохие примеры: JQuery, Grunt.

Другие фреймворки - это какая-то закрытая фигня которая делает что-то за вас.
И вам говорят: чтобы получить переменную из конфига - напечатайте "grunt.config(name)".
И вы не должны знать что там внутри.

Здесь все не так. Код, который вы пишете под Lava - является частью фреймворка. Вы расширяете фреймворк своей функциональностью. Поэтому, здесь никогда не будет Lava.config() - здесь будет только то, что вы можете переопределить и повторно использовать.

Разделение кода и данных - это хорошо.
Надеюсь, не слишком абстрактно.

************************************

Придется дилетантски опять объяснять и повторить то что писал.
Если есть кто помнит исправьте.
Вроде именно private методы принято начинать с _.
Т.е. этот метод точно не будет для API.
Но я таким подходом не пользуюсь.
даже private методы у меня идут без _.
А у вас, как было ранее сказано методы для API c _.

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

Почему их нельзя вызывать извне? Потому что тогда нарушается целостность класса,
нарушаются алгоритмы, по которым он работает. Для этого и придумали ключевые слова protected и private в типизированных языках.

Поскольку в JavaScript нет понятия приватности - их принято именовать с подчеркиванием.
И это свойсво может быть учтено, скажем, при сжатии - их можно свободно переименовать
внутри класса и его наследниках, так как извне они вызываться не должны.

А API - это все члены класса. И свойства и функции, и публичные и приватные.
Ты можешь определить приватное свойство _properties в своем виджете,
и ты будешь иметь к нему полный доступ. Ты можешь переопределть приватный метод _renderContent, который определен во view.Abstract. И все это называется API. Здесь нет мертвого кода, который используется только внутри фреймворка.

Про $

Если переименовывать родительские методы - то делать это по какому-то алгоритму.
Мой текущий алгоритм: <название_родителя> + "$" + <название_метода>.
Есть другие варианты?

Можно ввести внутри фреймворка список кратких названий переменных.

А можно как в EXT.JS - там сотни всяких alias'ов. Тем кто уже не первый год этой фигней страдает, тем конечно хорошо, а вот новичкам не очень.

То, что ты считаешь "красивым" - я не считаю красивым. Потому что тогда пользователям придется помнить все эти "красивые" имена. Либо во всем фреймворке нужно заменить слово "element" на "el", а иначе, если часть написана полностью, а часть сокращена - то люди будут путаться. Это не есть красиво.

И вообще, какой аргумент чтобы сокращать названия? Печатать меньше? У меня PhpStorm подсказывает названия большинства методов и переменных, так что не проблема (аргументы типа "я герой мазохист пишу в блокноте" - не принимаются). От сокращения названий код станет более уродливым, а не красивым. Мой фреймворк - для всех, а не для "избранных", и стиль кода я выбрал соответствующий.

Код меньше весит? Так для этого есть компрессоры. Я сейчас скажу не про тебя конкретно, а вообще: если программист на своем блоге говорит, что нужно писать короткие имена в ущерб понятности - то это говно программист, потому что не умеет пользоваться компрессорами. А код нужно уметь писать такой, который сжимается компрессором (или еще можно написать компрессор, который умеет сжимать твой код).

Я пока не углублялся в эту тему, но слово self после компрессии должно превратиться в одну букву. Если не превратилось - значит либо компрессор плохой, либо код.

Итак, промежуточный вывод: сокращать имена для уменьшения кода - это не правильно. Не правильно перекладывать на человека то, что должна делать машина. Правильно использовать компрессоры. У меня самого код сейчас очень плохо сжимается, в частности из-за переименований родительских методов и карт методов в visitor паттернах - поэтому пока не могу использовать advanced компрессию. Но эту проблему я решу.

Слово "me" вместо self - это тоже хорошо, но переименовывать не буду по причинам выше. Тем более, это слово у меня всего раз 10 использовано.

Я их код вдоль и поперек изучил))

Код, который они выдают в браузер? Что там за fx, можно ли как-то посмотреть без гемора?

P.S.
Дискуссия по react и прочему это кажись меня не сильно касается, поэтому просто почитаю.

[fancy]

Я оставляю свою схему именования через подчеркивание, так как это является хорошей практикой.

Хотя бы один пример, где это является хорошей практикой.
В php?
Да в php это хорошая практика.

Тогда потом не удивляйся, что никто им не пользуется.
У нас в фирме, тоже приходится приспосабливаться под заказчика.
Пользуются они Dojo и начинаю требовать более интегрированной поддержки с Dojo, приходится делать.

Вы предлагаете мне именовать переменные в классе так же как методы - как тогда отличать методы от переменных? Если смешаны методы и переменные - то код превращается в мусорку.
Плохие примеры: JQuery, Grunt.

Я не предлагаю делать в стиле JQuery и прочих. Исходники и плагины на JQuery действительно похожы на мусор (:
Надеюсь никого не обидел.

Здесь все не так. Код, который вы пишете под Lava - является частью фреймворка. Вы расширяете фреймворк своей функциональностью. Поэтому, здесь никогда не будет Lava.config() - здесь будет только то, что вы можете переопределить и повторно использовать.

Звучит как просто добавить в прототип метод.
Ну нормально.

Поскольку в JavaScript нет понятия приватности - их принято именовать с подчеркиванием.
И это свойство может быть учтено, скажем, при сжатии - их можно свободно переименовать
внутри класса и его наследниках, так как извне они вызываться не должны.

Ты хорошо объяснил, что у меня не получилось.
Если оно будет учтено при сжатии, то зачем эту функции в API добавлять.
О чем весь разговор, что принято именновать подчеркиванием приват.
А у тебя все приват получается.

Про $

Если переименовывать родительские методы - то делать это по какому-то алгоритму.
Мой текущий алгоритм: <название_родителя> + "$" + <название_метода>.
Есть другие варианты?

Сообщение от fancy

Можно ввести внутри фреймворка список кратких названий переменных.

А можно как в EXT.JS - там сотни всяких alias'ов. Тем кто уже не первый год этой фигней страдает, тем конечно хорошо, а вот новичкам не очень.

alias - это алтернативное название класса.
Пример:
Ext.Panel, Ext.panel.Panel
Оно скорее нужно, просто для удобства. и проблемы нет никакой в этом.

Про сокращенные именования.
Это просто для удобства.

Ну если тебе так не удобно, то ладно.
Если вот это удобно...

removeGlobalHandler: function(listener) {

		var event_name = listener.event_name,
			index = this._event_handlers[event_name].indexOf(listener);
		if (Lava.schema.DEBUG && index == -1) Lava.t();
		this._event_handlers[event_name].splice(index, 1);

		this._event_usage_counters[event_name]--;

		if (this._event_usage_counters[event_name] == 0) {

			this._shutdownEvent(event_name);

		}

	},
        _createEventWrapper: function(event_name) {

		var self = this,
			freeze_protection = this._freeze_protected_events.indexOf(event_name) != -1;

		// I'm not sure about this, but looks like the argument should be specifically named "event"
		// [url]http://stackoverflow.com/questions/11188729/jquery-keyup-event-trouble-in-opera[/url]
		// see also this to understand the roots of such behaviour:
		// [url]http://stackoverflow.com/questions/4968194/event-keyword-in-js[/url]
		return function(event) {
			self._onDomEvent(event_name, event, freeze_protection);
		};

	},
       _initEvent: function(event_name) {

		this._event_listeners[event_name] = this._createEventWrapper(event_name);

		if ((event_name in this._dom_event_support) && this._dom_event_support[event_name].delegation) {

			Firestorm.Element.addDelegation(window, event_name, '*', this._event_listeners[event_name]);

		} else {

			Firestorm.Element.addListener(window, event_name, this._event_listeners[event_name]);

		}

	},

Мне такой вариант, не айс...

Думаю больше я тебе никаким советом помочь не смогу.
Не надо, ну значит не надо
На данном этапе я твоим продуктом пользоваться не буду как минимум
потому что
1 - API - жесть
2 - Что-нибудь расширить добавить - это возиться с пунктом 1.
3 - Ошибки в работе даже с тем примером который на странице.


Про другие пункты.
Короче делай как хочешь, успехов
В любом случае наберешься опыта.

[bes]

ну, что хочется добавить - классика: чем больше слов, тем меньше смысла

[nerv_]

в ngApp я писал по 2 раза зависимости - сначала грузил сам модуль, затем прописывал его же в ангуляровский DI. и тупил от того, зачем я так делаю

на одной странице может быть n ангуляр-приложений
в рамках модуля может быть n классов/объектов

свобода выбора, ёпть

всегда ли она нужна?

я наигрался с bluebird, Q. теперь думаю заюзать when.

а я как писал, так и пишу с $q ангуляра Оч. редко jQuery.Deferred.

но у меня одинаковый код, стиль кода и одинаковые либы на сервере и клиенте. это просто супер

это хорошо до поры до времени. Когда задачи становятся сложными, как правило, приходится заниматься чем-то одним (клиент/сервер). Когда еще сложнее, уже происходит деление на подзадачи в рамках [front|back]-end.

а как ты переиспользуешь код? как грузишь третьи зависимости (типа jquery или добавочных плюх angular)?

Переиспользование.
Что касается переиспользования, то в в большинстве случаев стараюсь писать "абстрактные" классы, от кот. можно унаследоваться и дописать частную реализацию.
Например, у меня есть два класса Storage (local) & Cookie с одинаковым API. Т.е. можно заменить одно на другое (при наличии здравого ума) достаточно безболезненно =) Полиморфизм.

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