LiquidLava MVC Framework
 

Здравствуйте!

Когда-то я уже представлял свой фреймворк на этом форуме. Не совсем удачно, так как в то время он был еще сыроват, и не было документации. С тех пор документация была написана, исправлено много багов, и добавлены новые фичи.

lava-framework.com

Что это?

MVC фреймворк, по возможностям сравнимый с такими гигантами как Angular и Ember (не клон!).

Чем этот фреймворк отличается от остальных?

Прозрачной архитектурой. Это значит, что в любой момент времени вы понимаете, что вы делаете, и что при этом происходит.

Подробнее об этом:
Я встретил непонимание некоторых людей - в чем преимущество прозрачной архитектуры?
Вопрос настолько элементарный, что тогда я не нашелся, что ответить.
Фактически, вы спрашиваете: какая разница, понимаете ли вы что делаете, или нет?
Понимаете ли вы, что при этом происходит, как это работает, или нет?
Если для вас нет разницы - то и продукт не для вас, проходите мимо.

Сравнивая себя с аналогами, приведу такой пример. На хабре есть несколько статей с примерно такими заголовками:

1. "Знаете ли вы как работает if в Angular?"
2. "А вы точно знаете, как работает ng-if?"
3. "То, чего вы не знали о работе ng-if"...

А если ваша программа не работает как надо, то процесс поиска багов в таких фреймворках получается долгий и мучительный. Пример такого бага я описал здесь, кто хочет - посмотрите.

В Lava такого нет. Здесь вы знаете, как работает If. И если в вашей программе что-то работает не так, как вам хотелось бы - то вы знаете место в коде, где искать причину.

Еще немного о фреймворке

С современными фреймворками ситуация такая: часто бывает проще написать что-то на JQuery, чем использовать фреймворк. А если вам нужно изменить какой-то виджет, который идет с этим фреймворком - то проще написать новый. На Хабре есть статья, в которой это хорошо описывается: "Такое ощущение, что каждый разработчик, что использует один из этих модных фреймворков борется с ними и мы тратим кучу времени отлаживая проблемы или перекапывая StackOverflow в поисках решений элементарных (казалось бы) задач"

LiquidLava создавался для решения вот этой самой проблемы. Элементарные задачи здесь решаются элементарно, здесь нет "фабрик контроллеров", есть только яваскриптовые классы и конфиги для них. Если вам нужна кнопка на странице - то здесь вам не придется делать ее через роутер! (*) Вы можете плавно переходить от небольших виджетов к сложным приложениям, при этом сохраняя целостность архитектуры (здесь каждый виджет - это часть фреймворка, а не сам по себе). И еще: мои анимации не моргают! (**)

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

Статус

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

Ну и...

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

P.S. Меня просили учебники на русском, но я один такое не потяну, простите.
Сейчас я рассчитываю, что Lava начнет набирать популярность и кто-то создаст сайт с русскими учебниками и сообществом.

(*) и (**) - привет двум известным фреймворкам.

UPD
Кому понравился фреймворк - буду благодарен за звезду на GitHub.

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

Не хочу тебя расстраивать, но этого скорее всего не будет.

Мне самому очень хотелось бы их иметь, на них есть планы, но скорее всего до них еще далеко. Просто сама разработка очень трудозатратна.

Вы случайно не Павел Глоба? Вы не расстроили, честно. Просто я оптимист, поэтому охотно вам верю. Но все же... по моему вы немного меня недооценили.

амбициозно.

но вот пример кода TodoAPP на главной меня отпугнул)

Синтаксис очень непривычный, согласен.
В других фреймворках ты думаешь "ой как все красиво!", а потом пугаешься.
А тут сперва пугаешься, а потом "ой как все красиво!" :)

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

пару вопросов:
чё те влом было русскую версию документации подготовить, раз так пропагандируешь свою поделку?
чё те без mootools никак не обойтись было?

По уровню и объему работы это не "поделка". Простите, но вы не правы.

Русская документация на этапе альфы - это слишком трудозатратно, так как ее потом нужно еще и поддерживать. По моим соображениям, большинство программистов должно знать английский. Если на этом форуме меня завалят просьбами о переводе - то скорее всего, придется.

Низкоуровневый фреймворк нужен, без него никак. Из низкоуровневых фреймворков - MooTools единственный из актуальных на сегодня с более-менее реюзабельным исходником (попробуйте разобраться с исходником, скажем, JQuery - внутри там настоящая мусорка и сборник плохих практик). Для работы над Lava мне приходится очень хорошо разбираться в его исходнике. Вообщем, остальные не прошли по требованиям.

Сам по себе MooTools - это хороший фреймворк, основанный на хороших практиках программирования (классы, типизация...), и движок селекторов у него ничем не уступает Sizzle. Так что, я сделал правильный выбор.

В будущем я откажусь от MT: весь его функционал перейдет в мой собственный низкоуровневый фреймворк Firestorm, который идет вместе с Lava, но это будет еще не скоро.

http://www.lava-framework.com/www/do...#tab=tutorials

может сразу альфа версии ОС начнём для бесперебойной работы корпорации юзать, а ;)
на каждой из этих 12 маленьких английских страничек всего по 10 маленьких английских строчек английского описания на английском, остальное - код
другими словами, тебе просто влом, к тому же не факт, что ты всё правильно перевёл :D
знание английского языка тут не причём, просто ты таким образом говоришь: "ребята, не юзайте мою поделку, она - для буржуев и я их больше уважаю"


до светлого будущего ещё дожить надо, так что не теряй время и займись переводом своего английского на русский :victory:

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

И ты опять ошибаешься. И насчет "для буржуев уважаю" и насчет "влом".

у тебя навязчивые идеи, похоже инициированные даже не тобой, очнись, окстись, открой сомкнуты негой взоры

Народ, да что вы накинулись на автора то, он молодец, трудится, а труд нужно уважать. Если вам не интересна поделка, то просто пройдите мимо и всё.

считай это медными трубами, в которых тс упорно застревает :)

опа, ни х-я :D

Парень делает реально крутую штуку...
Уважуха.
Ему бы найти фирму где это требуется.
Может в mail.ru

Angular не самое лучшее решение.
Но синтаксис все равно придется менять.
Скажу так синтаксис не продакшен...
И дело не в том что сделал плохо.
Синтаксис это вообще особая тема.
Под час очень сложная.

Мне было бы очень интересно почитать его пост на хабре, с какими проблемами он столкнулся, что нашел интересного, как решал, что он знает про Angular внутри.

Я смотрел Angular внутри - мне не понравилось, мозг выносит.
Использую исходники проектов как учебники по javascript :)

Благодарю за отзыв. Прошу прощения, что сперва плохо о тебе подумал.

Я изучал исходники Angular и Ember недели 2 подряд, и потом к ним несколько раз возвращался. Мне это нужно было чтоб собрать требования для Лавы. Меня от этих исходников просто тошнило - это даже не фрактал дефектов, а как бы сказать... целый "улей". Поэтому в issues на гите тыщи багов - такой код не может быть надежным.

Если речь про синтаксис шаблонов - то я понимаю, что очень непривычно, но все таки это синтаксис для создания конфигов. У Microsoft WinJS есть что-то похожее - там объекты пишутся в атрибутах. Мой вариант мне видится более удобным, так что пока буду склонять людей на свою сторону.

Насчет "пойти к дяде из mail.ru" - для дяди это была бы лафа, которую он не заслужил. Вот если станет мой фреймворк популярным - тогда и продам его, но за намного большую цену чем мог бы отдать сейчас. Если не станет - не продам, но даром никто ничего не получит. Если кому и продамся - то либо Google либо Microsoft - на меньшее я не согласен.

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

Мне есть что рассказать, но сперва надо заслужить признание. Будет признание - обязательно опубликуюсь.

Я до сих пор жду пока меня включат в TodoMVC. У них нет возражений, просто процесс все еще тянется. А пока вот сделал небольшой тест производительности: мои классы такие же быстрые, как если бы вы писали их руками. Ну или почти такие же:
http://jsperf.com/liquidlava-class-system-performance/3

Кому нравится фреймворк - поставьте звезду на GitHub, буду очень благодарен. Мне нужно 80 звезд чтобы попасть на javascripting.com.

Постараюсь объяснить несколько моментов, надеюсь будет понятно))
Походу получился сумбур :(

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

Когда начал делать свое, понял что у меня получается по сравнению с уже существующими в разы хуже
1 - куча ошибок, не возможно на этом работать
2 - синтаксис ....
3 - никому не нужно
4 - денег на этом не сделаешь

И в итоге понимаешь, в других библиотеках сделано плохо не потому что люди не умеют программировать, а потому что это очень сложно сделать так, чтобы продукт был классным.

5-7 раз начинал с нуля...

Чем больше стараешься - понимать как работают другие библиотеки изнутри.

Еще один момент, исходники проектов, того же JQuery, Angular и прочих помогают лучше понять JS.
Но если тебе проект нравится, то начинаешь в этом стиле писать код.
Стиль кода, тоже очень важная штука.
Не помню как называется, вроде guideline code style.
За многие годы пришел к определенному стилю кода.
Каждый разработчик приходит к определенному стилю.
Но есть стиль разработчика, а есть классический стиль кода.
Постараюсь объяснить.
Это как Венгерская нотация.

Приведу самые элементарные примеры.
Про camelCase уж писать не буду))
Твой стиль - это perl.
Не будут люди пользоваться продуктом если там
my_cool_function для js.

Еще пример

//Bad
if(n)
   a = 5;

//Good
if(n){
  a = 5;
}

К сожалению в таком стиле до сих пор программируют.
Нельзя.
Ошибок дает кучу.
Случайно добавил лишнюю строку - 2 дня ищешь ошибку.
А еще снижает читабельность.

Во многих вакансия написано:
Умение понимать чужой код.
Умение писать структурированный код.

Потому что хороший код, повышаешь кпд разработки, особенно командной.

Еще пример

//Bad
var a = 5;
var b = 7;
var c = 10;

У тебя в такой стиле все примеры.

Далее использование спец символов.
Давай вспомним для чего используется символ _ перед названиями переменных/свойств.
Для того чтобы сказать, что это свойство или метод private.
Надеюсь не перепутал...
Короче пользоваться исключительно внутри фреймворка, библиотеки.
Не используют в API названия с _, есть такая договоренность.
А вообще я бы советовал стараться никогда не пользоваться _
сразу снижает читабельность кода.
лично я пользуюсь _ только в самом крайнем случае.

Идем дальше.
У тебя пишется Extends
С твоих слов ты взял это из MooTools
Почему так сделали MooTools - потому что слово extends зарезервировано.
В данном случае лучше просто extend.

MooTools классная штука.
Но это не означает, что они все делают правильно.
Они многое делают так, что никто не будет пользоваться им.
Например: глобальные переменные, добавление в глобальные прототипы функций.

Вот если бы они Class, сделали не глобальным
А хотя бы Mt.Class
И не делали

Array.implement('limitTop', function(top){
    for (var i = 0, l = this.length; i < l; i++){
        if (this[i] > top) this[i] = top;
    }
    return this;
});

[1, 2, 3, 4, 5, 6].limitTop(4); // returns [1, 2, 3, 4, 4, 4]

А сделали вот так

Mt.Array.limitTop([1, 2, 3, 4, 5, 6], 4);

То даже я задумался про MooTools в реальных проектах.

Теперь про названия свойств
Это что за жесть...

this.Text$broadcastInDOM();
var element = this._input_container.getDOMElement();

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

Очень многие библиотеки имеют плохой API.
Но у тебя API пока, ну сам понимаешь...
Работа над API - не простая штука.
Но API должно быть красивым.


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

Но унывать тут не надо, если нужны деньги, то просто иди на работу
пробуй себя в js в Москве.
Или же может в будущем как Дмитрий Сошников будешь работать в FaceBook :)

Понимание как писать JS SDK, библиотеки востребовано.

Думаю это единственная Российская фирма, которой может быть интересен твой продукт.
И то не факт.

Сама идея сделать свой Angular - в этом нет ничего такого.
При необходимости mail может дать задание своим спецам разработать Российский аналог
JQuery, Angular.
Тем более что там работают программисты, у которых есть свои аналоги для них...
Например Octane, еще 5 лета назад сделал js-core
А теперь в mail.ru

а уж про monolithed... который ушел с форума(кстати тоже в mail.ru сейчас) можно много сказать.
Парень мега спец.

Ну, как минимум ещё есть Яндекс :)

Да, Яндекс есть :)
Но мне кажется, возможно ошибаюсь(поправьте если не так), яндекс уже не развивается.
Сейчас если хороший спец по js ищет работу то пойдет в mail.ru

А в яндексе прямым текстом говорят, у нас тут платят мало(мне лично так сказали)

мне ситуация с yandex напоминает ситуацию с rambler
В свое время все говорили, rambler супер проект, прорывной.
А потом с него все ушли.
У yandex сейчас тоже самое.
Если бы не yandex пробки, то я про него вообще забыл, что он есть.

Кто сказал? В Яндексе over9000 отделов, так что развитие кипит :)

Половина моего отдела, когда я работал в Яндексе, была из Меила, но и обратное также справедливо.

В Мэиле в среднем чуть выше ЗП (совсем чуть-чуть), но в Яндексе халявное питание и свободный рабочий график.

С технической точки зрения они равны. А вообще компании есть, просто не все на слуху.

Мало - понятие относительное, если сравнивать ЗП Java разрабов, с JS, то мы вообще нищеброды :)

Я заметил, что ты склонен возводить своё мнение в абсолют, как единственное верное, но жизнь разнообразнее.

Рамблер по прежнему зарабатывает over9000 денег, Яндекс по прежнему самый популярный поисковый ресурс в странах СНГ, а mail по прежнему портит годные игрушки донатом :)

:(

// надо так?

var  a = 5,
     b = 7,
     c = 10;

// можно еще так
var    a = 5
     , b = 7
     , c = 10

какая разница, как декларировать, если в идеальной функции очень мало деклараций*?

* если их много - скорее всего, функция разрослась, делает не совсем то, для чего писалась и её нужно отрефакторить

Впринципе можно писать как хочешь :)
Three.js крут и там var-ом одним за одним навалом.
А для коммерческого ПО, над которым работает команды,
правил в 3 декларации нет, есть другое правило - писать понятный код.

За 12 лет проганья понял одно: архитектура и стиль в в определённых рамках может быть любым и нужно уметь побороть в себе неприязнь к иному. Самое главное - это следование установленным правилам и их наличие.

тоже это понял.

но ещё важнее - чтобы твои личные правила написания кода совпадали с правилом написания других людей.

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

я в верном направлении думаю?

Да, однако нет одного самого хорошего паттерна, а есть N действительно хороших стайлгайдов. Для своих проектов я использую стайлгайды от гугла (правд с некоторыми правками, например, я юзаю табы, а не пробелы), т.к. они хорошо описаны и очевидны.

Когда фирме надоедает, что одному нравится так другому иначе, появляется что-то вроде такого :)

https://github.com/airbnb/javascript
Кстати там несколько var-ов

Мой стиль немного отличается взял из очень большого проекта на js.
над которым работает 100+ разработчиков вот уже 7 лет.

Спорить не хочется :)
Но мне мне хочется "ноги поотрывать" за стиль ниже,
который так любит очень известный http://www.tjholowaychuk.com/

var  a = 5
     ,b = 7
     ,c = 10

Такой стиль помогает не добавить лишнею запятую.
Но какой ценой.
деланием из кода - г***
не могу сдержаться )))
Лучше закончу на эту тему...

yandex codestyle
:D

Привет, Octane :)
Как жизнь, как работа в mail.ru ?
Слышал ты в армию успел сходить.

Во во :)
То что у yandex в этом примере плохо для меня хорошо, но мой стиль все равно другой)))
Где-то встречал сайт для генерации стиля кода компании.
Если найду скину.

Просмотрел стиль Яндекс, нормально.
Не совсем согласен, но пойдет :)

Octane, как по мне - оба варианта нормальные, но всё таки, имхо, правильнее юзать итераторы, forEach, map, reduce и т.д.

Кстати, часто замечаю, что люди юзают в основном forEach, причём зачастую гораздо лучше было бы использовать reduce или map, но люди почему то их боятся :)

Octane, :lol: лебедь, рак и щука

это ведь уже выход за пределы императивности? ФеПешка

array compherension :) ES7

Да какая разница - это удобно и наглядно.

Вот пример - заглушка для console API и один простой reduce.

var console = [
	'log',
	'debug',
	'info',
	'warn',
	'error',
	'assert',

	'dir',
	'dirxml',
	'trace',

	'group',
	'groupCollapsed',
	'groupEnd',

	'time',
	'timeEnd',
	'profile',
	'profileEnd',
	'count'

].reduce((obj, el) => (obj[el] = () => {}) && obj, {});

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

Привет)
Да круто все, в mail.ru работы много, без дела ни дня не проведешь, но атмосфера и условия отличные, работается с удовольствием. Да, отслужил, ну как отслужил… напрограммировал в штабе на сержанта запаса :D

я тоже раньше писал

var a = 5,
    b = 7,
    c = 10;

пока мне не досталось 1,5MB незнакомого кода без 'use strict', который правило несколько человек, в некоторых модулях было куча:

var module1 = require('…'),
    module2 = require('…'),
    module3 = require('…')*!*;*/!*
    module4 = require('…'),
    module5 = require('…');

кто-то в спешке добавлял модули и забыл поставить запятую, без 'use strict' все работает и найти такую штуку очень трудно, когда у тебя 100+ модулей в проекте, о которых ты мало что знаешь :)
К пользователю код попадает после UglifyJS, который сам все переменные в один var объединяет, поэтому экономить на varax смысла нет, я сейчас больше склоняюсь к варианту:

var a = 5;
var b = 7;
var c = 10;

но вот рекомендацию «Переменные объявляются как можно ближе к месту использования» принять никак не могу, считаю без let это вредным советом

fancy,
Нет, развивается.

Нет, не обязательно.

Нет.

kobezzza,
Я разочаровался в тебе(

:D

+1 :)
Практически все объявляю вверху.

Как раз пользуюсь 'use strict'

не делаю много var по куче причин.
Когда работаешь с ООП библиотекой обычная функция в 5-10 объявлений переменных. Приходится так делать из-за ссылки на используемые модули(подъобъекты класса, не знаю как нормально назвать :) ), а ссылаться на модули приходится чтобы код после минификации весил меньше.
И получается, что из-за 'use strict' ошибок нет, а даже если бы и не использовал strict mode, то приоритет сделать проект меньшим по размеру.
Еще одна причина, почему не много var - когда в обычной функции по 5-10 var, замучаешься их писать.

Все вот надеюсь, что для console.log сделают возможным log, а то замучился... этот console писать :)
(чтобы понять, представьте за года надо 50 000+ раз его надо написать)
Возможно утрировал что 50 000, хотя...