Давайте по порядку.

Про велосипеды

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

Слой Scope + виды - я переписал раз 10 почти с нуля. И еще несколько раз частично. Причем был такой момент, когда я сказал "ну все, наконец то готово!". А потом достал маленькое требование из бэклога... "ё моё, опять все переделывать". Примерно после 7 раза.

Refresher - 3 раза с нуля
Шаблонизаторы - 3 раза с нуля
Data - 1 раз полностью, и много раз по кусочку
mixin.Observable - 1 раз полностью
Анимация - примерно раза 3...

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

Насчет стиля кода

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

var my_cool_function, my_cool_variable

Но функция из API класса никогда не будет названа my_cool_function, правильно myCoolFunction.

Почему подчеркивание вместо camel: у меня есть серверный PHP движок в разработке, и я взял один стиль чтоб не путаться.

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

if(n)
   a = 5;

В моем коде есть такие штуки, но в одну строку - в основном DEBUG проверки. Если к ним добавить скобки и разнести на 3 - то код становится практически нечитаемым, пробовал.

У меня всегда один var на функцию. Исключение - пример todo_app - им так нравится, и это их правила. Есть хорошая причина использовать один var на функцию - variable hoisting.
http://designpepper.com/blog/drips/v...ction-hoisting
Помогает избежать ошибок.

Приватные методы

Приватный метод - это не тот метод, который используется внутри фреймворка. Приватный метод - это метод, который нельзя вызывать извне. Тут у меня закралось подозрение, что вы, fancy, никогда не программировали на C++...

Если во фреймворке есть код, который используется только внутри фреймворка - то это мусорный код. У меня весь код - для программиста. Все методы в моих классах, даже приватные - можно переопределить (во всем фреймворке есть всего 3 исключения, которые нужно будет пометить как final, когда добавлю поддержку в ClassManager).

Надеюсь, правильно понял.

Насчет MooTools - мне тоже не нравится что он расширяет прототипы глобальных объектов.
Поэтому у меня есть Firestorm. Со временем я буду переписывать MooTools и переносить его функциональность в Firestorm, и там будет все как вы и написали. Когда тесты будут.

Про жесть

this.Text$broadcastInDOM();

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

var element = this._input_container.getDOMElement();

Тут все в полном порядке. "_input_container" - приватная переменная, getDOMElement - публичная функция. Все вместе - часть красивой и гибкой Системы. Что с этим не так?

API у меня - произведение искусства. Но не современного, в котором каждая мусорка это искусство, а старого. Когда люди еще читали книги про рефакторинг, паттерны, и шарили C++.

"пробуй себя в js в Москве"
Думаю, еще успею. И я уже давно не студент.
Кстати, mail.ru и Яндекс - это фактически иностранные фирмы на российском рынке.

А у меня нет PHP движка и мне твой стиль буэээ :) К сожалению, люди приходят в js и не могут понять, что там другой стиль кода и продолжают бомбить в своем.

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

kogarashisan,
Просто в js-сообществе так принято.

+1

Хочешь чтобы начали пользоваться люди, пиши в js стиле, а не в PHP или perl.

Единственное что крутое в твоем проекте, это сам факт, что ты делаешь аналог Angular.
Начни с нормального API, а уж потом можешь говорить что у тебя что-то супер мега классное :)

Мне очень нравится MooTools, но я не пользуюсь им именно из-за 2 ньюасов в API.

Воспринимай посты на форуме как советы от опытных разработчиков, которые хотят тебе помочь :)

Вы услышаны. Я подумаю, что с этим делать.

Главное что в функциональном плане с ним все в порядке.

"единственное"? и не просто "аналог", а лучший аналог.

В далеком прошлом, 2 года использовал C++.
Знал очень многое про него.
Сейчас немогу уже вспомнить элементарные вещи из него.
Это как с иностранным языком, не изучаешь забываешь так как будто и не учил.

Паттерны и шаблоны проектирования изучал очень серьезно.
Скажу дилетантский языком.
Для RIA - достаточно классов, ClassManager по типу виджетов и задач, Observe, Template - вроде все... непомню, чтобы еще какие то особо пригодились.
А еще для данных, простым языком MVC.
Но я пользуюсь свои модифировнным вариантом MVC.
Короче просто модели и все)) и без всей мути с контролемами и view.
Долго описывать как это ))
А так можно и Adapter и proxy еще использовать.
Я не готовился выступать про Design Patterns на конференции :)
Чтобы дать аккадемический ответ, надо дня 3 все повторить.
Паттернов штук 200, только нужны из них максимум 5-7.
Чем проще тем лучше.
Вон C11 Standart в 1500 страниц, даже из профи мало кто читал.

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

flux, russian edition :)

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

Просмотрел несколько книг, никак найти не могу.
Толи в книге Мука по ActionScript видел, то ли в Definite JavaScript Guide 6.

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

Отдельно стоит сказать про использование $ в методах и переменных.
Тоже советую этим пользоваться, в самом крайнем случае.
У меня это используется только в этом месте.
Для классов, для внутреннего именования класса.
Т.е. предположим класс называется, напишу в стиле MooTools, как оно должно быть, а не как сейчас.

Mt.Class('Mt.Panel', {
   extend: Mt.Event/Mt.Observe, либо 'Mt.Event'

Так вот внутри класса у меня идет определение названия класса
$class: 'Mt.Panel'


Теперь еще раз про слишком длинные названия методов.

var element = this._input_container.getDOMElement();

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

var el = this.inputEl;

слишком красиво...

Надо сокращять длинные названия. Не все.
Но уж совсем элементарные вроде
this.getElement()
делаем хотя бы
this.getEl()
Это настолько очевидно и просто, что El - это Element


Еще один момент, уж думайте сами нужно вам или нет :)
Я пользуюсь :)
Ссылка на this.
Сейчас если и пользуются такой ссылкой то через "self'

var self = this;

   self.show();

Я вместо self, использую me.
Не помню уже где первый раз это встретил.
Но это делает код мега красивым и удобным.

var me = this;

   me.show();

Еще один плюс таких ссылок, особенно для ООП библиотек, которые
в методе раз 5 - 20 обращаются к друг методам или свойствам -
сокращение код.

Все способы которые есть для уменьшения код, я использую - делает на ~30% код меньше ...
Т.е. весит проект minified до такой оптимизации 300кб, а после оптимизации 210-250$
Для меня это было критично.

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

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

У них вместо шаблонизации, как то так

.innerHTML = '<div class="class-name">' +
myVar +
....;

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


Про React хочу сказать.
То что они преподносят как прорыв, не факт что таковым является да круто... Но на деле, полный rerender редко когда нужен.
И никто не будет каждые 1-5 секунд делать rerender 5000 + строк для table например.
Не знаю на чем работает facebook, какая js либа, но vk гораздо быстрей за счет клиентского рендеринга и кучи фишек.
У них вообще очень много классно сделано.
Помню у меня была своя fx либа - css3 не решает до сих пор всех моментов, приходится иметь свое решение.
Так вот, у них fx сделано так красиво и просто.
не ожидал такого решения.
Молодцы.

Иногда чувствую себя внештатным сотрудником контакта )))
Я их код вдоль и поперек изучил))
Некоторые моменты исправил бы, но все равно их код классный...
На их внутренней либе можно делать полноценный продукт, который может стать лучше всех современных JS UI фреймворков.

Еще про React
Уж раз про него заговорили

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

React.render(<MarkdownEditor />, mountNode);

render: function() {
    return (
      <div className="MarkdownEditor">
        <h3>Input</h3>
        <textarea
          onChange={this.handleChange}
          ref="textarea"
          defaultValue={this.state.value} />
        <h3>Output</h3>
        <div
          className="content"
          dangerouslySetInnerHTML={{
            __html: converter.makeHtml(this.state.value)
          }}
        />
      </div>
    );
  }

Ладно может так надо было, но идем дальше.
Во что они превращают это

Минус два

render: function() {
    return (
      React.createElement("div", null, 
        React.createElement("h3", null, "TODO"), 
        React.createElement(TodoList, {items: this.state.items}), 
        React.createElement("form", {onSubmit: this.handleSubmit}, 
          React.createElement("input", {onChange: this.onChange, value: this.state.text}), 
          React.createElement("button", null, 'Add #' + (this.state.items.length + 1))
        )
      )
    );
  }

Это ж получается для каждого тега надо вызвать функцию, и думаю не маленькую.
Повторю их заявление, что типа мы берем и просто все перерендерим.
Что это значит?
Это значит что еще надо заново поставить обработчики событий на dom.

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

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

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

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

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

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

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

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

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

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

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

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

не интересовался. предлагаю погрузиться в тему :) но моя приложуха на реакте не тормозит
перерисовываем в VDOM все компоненты, которые требуют перерисовки. требует ли компонент перерисовки - он решает сам - это метод shoudComponentUpdate

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

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

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

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

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

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

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

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

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

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

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

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

Да...

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

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

Их есть у вас? :)

MyClass
   require: [
       Foo,
       Bar
   ]

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

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

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

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

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

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

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

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

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

npm i -S bluebird

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

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

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

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

react - kiss. angular - не kiss.




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


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

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

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

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

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

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

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

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

Почему их нельзя вызывать извне? Потому что тогда нарушается целостность класса,
нарушаются алгоритмы, по которым он работает. Для этого и придумали ключевые слова 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 и прочему это кажись меня не сильно касается, поэтому просто почитаю.

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

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

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

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

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

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 - Ошибки в работе даже с тем примером который на странице.


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

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

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

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

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

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

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

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

да, потому что vendor lock-in - плохо. я пару раз спотыкнулся на этом (не в ангуляре, а ... например, в SaisJS) и возвращаться к монолитным фреймворкам не хочется... я надолго запомню бессонные ночи переписывания)
угумс. под словом "модуль" я имел в виду модуль JS (CommonJS\AMD), а не модуль angular (angular.module). Хотелось автоматической сборки, а соединить декларации DI ангуляра с зависимостями requireJS не получилось, так что писал 2 раза - сначала для requireJs, потом для angular
промисы - это только один пример. но больше не могу припомнить :)
конечно, есть frontend\backend only код

одним я не смогу заниматься, потому что я один программист :Р fullstack dev here
вижу, ты ещё не дозрел :) ну, если что, ты знаешь, где меня искать)

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

Не верю я, что API - жесть. Докажи. Какая практическая задача вызывает сложности?

Что нибудь расширить и добавить - здесь намного проще, чем во фреймворках с "нормальным" API.

Про ошибки.

1 - При первом открытие, 2 секунды видно большим черным шрифтом отображение кода в том месте где потом будет пример.
Может не ошибка, но так быть не должно.
2 - Несколько дней назад, добавлял задачи, потом возникла ошибка.
Не реагировали задачи.
Сейчас искать и выяснять в чем дело нет времени.


У тебя есть какие-нибудь Unit Test-ы?
Такие ошибки очень сложно отловить просто jasmin-ом.
Selenium 2 может помочь.

Вообще сейчас нет нормальной библиотеки для тестов, которая бы симулировала поведение пользователя.
Может вот это тебе пригодится, если у тебя на JQuery работает.
http://www.bryntum.com/products/siesta/
У них есть Light версию, но сделано все так, чтобы покупали.
Так что Light версию надо еще заставить работать, поискать файлы, которые отсутствуют в сборке.

Лично мне пришлось, свою библиотеку для тестов делать...
Не мог сделать симулирование событий пользователя, вроде mousedown, mousemove, mouseup, mousewheel и другие.
Говоря откровенно, Selenium и даже Selenium 2, реально может лишь одно click и все...
Хотя в API много что-написано, в действительности это так.

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

Но тебе придется делать как в Angular, если будешь делать.

SauceLabs может пригодится - но она платная, 12$ месячная подписка.
Но штука супер...

fancy, https://github.com/segmentio/nightmare

Максимум из событий - это click...
Нет инструмента для реальное поведение пользователя с расширеными событиями.

Siesta от брунтум, что-то для этого делает.
Но у них заточка под JQuery, ExtJS, Prototype и что-то еще.
У меня своя библиотека для dom.
Плюс местами они делают не сами события, а запуск обработчиков.

Не подошла Siesta.
Все что есть для этого проверял.
Большинство инструментов используют внутри web driver(Selenium 2)
Т.е. ограничены возможностями Selenium 2.
PantomnJS, тоже особых возможностей не предоставляет.

Потом еще пришлось для полу-автоматического написания тестов делать
record событий.

"шеф, клиент уже созрел" :D

Надо будет попросить тебя показать образец проекта с точки зрения клиента)

Я на ангуляре почти два года пишу. Не скажу, что он ужасен. Есть как плюсы, так и минусы.

"я у мамы программист" (с) максимус :)

проект как проект

для клиента - пофигу, что на ангуляре он, что на реакте, что на чём либо другом - хоть на джейКвери :)

главное - чтобы работало, как говорится.



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

PSS. с появлением Service Worker я задумался о написании shit apps (мелких ненужных приложений) для "набития руки". но я ничего не обещаю.
:D ха, ну ты вспомнил

имел ввиду твою структуру приложения на клиенте))) Образец)

melky, еще пару вопросов:
1. в реакте есть дата биндинг?
2. что насчет валидации форм? В ангуляре очень много из коробки. Это радует.

упс, не догнал)

тут всё прозрачно. иногда даже слишком)

подход сверху: хелпер

подход снизу: биндинг делается через делегата (коллбек):

var model = { value: '' };

var handleChange = function (e) {
    model.value = e.target.value;
};

<input onChange={handleChange} />

не берусь ответить, ибо пока не занимался валидацией, но вроде npm: react-forms.


PS. ты хочешь начать писать на нем или просто интересуешься?

melky, спасибо за ответ, плюсы не ставятся)

Я интересуюсь на предмет попробовать в проекте) На данный момент собираю инфу по кусочкам из разных мест, для объективности =)

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

Очень полезный баг репорт, спасибо! :) (это был сарказм)

Пока ничего нет. В тестах я не спец, еще буду разбираться и выбирать платформу. У меня где-то в закладках есть бесплатный (для opensource) сервис который позволяет прогнать селениум на 200+ браузерах.

Судя по документации современного Селениума - там сейчас есть все мышиные события, включая Drag&Drop, mousedown итп. Если они не работают в IE9 - то с моей стороны правильно будет на него забить и подождать пока исправят.

===

У меня тоже планируется валидация форм "из коробки", придет время - сделаю.

P.S.
Нашел баг у себя в системе обновления видов - в сложных сценариях программа вылетает с ошибкой. Сейчас исправляю.

Доработал сайт: теперь вы уже не видите исходников страниц, когда они загружаются.

Приглашаю зайти и оценить скорость загрузки страниц.

P.S.
Я долго не отписывался, но само собой, все найденные баги давно исправил. Документация закончена! (на английском)

теперь можно вникнуть во фреймворк и оценить его на иерархическом уровне при ближайшем рассмотрении ? :-?

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

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

да ладно. не так то просто представить новый рабочий инструмент :) ещё херачить и херачить.
глаз замылился - сам знаю. предлагаю ещё бахнуть обучающий курс типа Fast Start и мелкую статью "Быстрое ознакомление", и можно писать на Hacker News \ Habrahabr

Ух ты! благодарю за ссылку на Hacker news - до сегодняшнего дня не знал о его существовании.

Для публикации на таком ресурсе мне действительно чего-то не хватает... главная у меня совсем не презентабельная... Да и fast start не помешал бы. Буду дорабатывать.

Тынц по теме http://m.habrahabr.ru/post/250311/