Ну и я записал короткое видео из нашего фрэймворка. Может также обновлять контроллеры, а в месте с ними и события и логику, и шаблоны, и стили (в том числе и less). Согласен, программирование на лету это здорово. Kакая статья, такой и комментарий.
Вы засомневались от здешних комментариев? Да бросте вы, хорошая на самом деле библиотека — маленькая и лаконичная. Со своей задачей, Waterfall / Functions Flow, справляется хорошо. Менее перегруженная чем when.js. Поэтому не бросайте это дело. Добавьте механизм обработки ошибок, возможность остановки «потока», определения контекста всем функциям. Про велосипед не переживайте — всё в этой жизни велосипед. Поверьте, что даже самые известные библиотеки, фрэймоврки начинались как велосипед.
«Каждая библиотечная сущность имеет право на свой репозиторий.» — поэтому не обижайте Chain.js
Можно ли создавать также приложения без участия сервера — скажем, для PhoneGap? Я просто такого у них не видел, всегда требуется backend, или что под «offline» подразумевалось?
Техника шикарная, но в этом варианте вас уже немножко «понесло», так как здесь Constructor1() === Constructor1() — получили мешанину из инициализатора и синглтона.
Смотрите, вы же согласны, что любое приложение нужно разбивать на модули/компоненты. Ну а что бы разработать какой либо компонент/модуль, его же нужно как-то «дебажить». И как обычно делают без TDD? Создают классы, и сразу подключают в приложение и уже вместе с приложением разрабатывают тот самый модуль, изменили код «кирпичика» — перезапустили приложение. Или так уже никто не делает? Если нет — то хорошо, потому что более удобный способ как раз TDD, или что то сравнимое с ним. Дела ещё усугубляется языком — мой основной на данный момент javascript. И здесь без TDD, ещё сложнее — здесь сплошной «контракт» — нет никаких типизаций, интерфейсов, сигнатур функций. Как раз тесты будут всегда держать модули и их связи целостными. Но вернёмся к разработке — мы даже свою библиотеку тестов создали, что бы было проще разрабатывать. Таким образом разрабатывается не приложение, а модули по отдельности, а тесты перенимают роль «мини-приложений» для дебага. И как раз эта особенность «мини-приложений» делает TDD таким привлекательным в разработке.
если вы не можете определиться с конечным Интерфейсом модуля, можно начать с функционала, а там уже и интерфейс модуля отшлифуется, и можно подключать в приложение.
каждый раз, когда обнаружите ошибку в программе, достаточно найти модуль/компонент который ломает приложение, ввести «входные» данные в его тесты и продолжить разработку/ремонт модуля.
Это как дом строить — можно или свезти все детали на стройку и там же создавать кирпичи, отливать плиты и прочее, а можно это все сделать отдельно на разных заводах (читать тестах) и потом привезти уже готовые элементы. И не построить — а собрать дом.
Под cpu статистикой имел ввиду «cpu profiling». Сколько мс выполняется сама функция и её цепочки выше по стеку, как у вас на скриншоте из dev tools.
Думаю, для nodejs будет такая вещица даже более востребована, так как нормального профилирования (не через пень-колоду) так и не нашел. Довольно легко сделать аналог require и подменять оригинал, так что бы все скрипты после загрузки, обзаводились метками и исполнялись. Ну a используя socket.io, данные бы отсылались на локальный сервер и был виден результат в браузере.
Замечательная работа. Почему только, в дереве вызовов показываются лишь события? Или точнее сказать, каждый новый event loop. Имея много асинхронного кода, становится довольно сложно ориентироваться в списке, так как становится много readystate/timeout/otherGenericListener. Собственно, хотелось бы иметь поиск также в списке с событиями, что бы искать нужную функцию.
И почему не «трейсятся» консольные вызовы — myLib.doSmth();, хотя просматривая myLib.doSmth; видно, что все метки проставлены шпионом ).
Есть ли в планах сделать cpu статистику функций? И версию для node.js приложений ($ spy myapp.js)?
Ну и в конце концов, больше подробностей с примерами не помешало бы… )
Если воспользоваться transform-origin вычисления могут быть проще, а если использовать lesshat, то запись будет проще.
Пример для левой верхней ленты —
Поддерживаю, тоже голосую за «второго» — если и я правильно понял автора. «Упаковывать максимум логики» никак нельзя в «стратегии» (плюс не помню, что бы в DRY было такое определение — «упаковывание логики»).
Можно и один обработчик — но лишь со стратегией внутри.
А про «крупные проекты», тоже повеселило — такой код с («упакованной» логикой :)) будет подходить лишь для «integration testing», но никак не для «unit testing», и плюс нарушает «Single responsibility principle». Вообщем — второй молодец…
Ааа. Это просто сообщение — может быть любой текст. Ваш пример отличный ({{age}}). Просто, понимаете, если будет много других параметров — changeEvent, signal listener, геттеры и сеттеры и прочее, то инлайн запись не подойдёт, через тэг тогда нужно будет.
Но простые записи двухсвязных биндингов обязательно сделаю проще. Спасибо за замечание.
— я же как раз и сравниваю этот «запуск» приложения — на сколько быстро angularjs сможет приложение зарендерить и создать биндинги — и не важно где происходит инициализация участка страницы — в domReady или после ответа сервера.
Вам разве не важна скорость отображения вашего приложения, а только насколько быстро «а» изменится на «б» в рантайме? Мне как раз первое важнее — это и тестирую.
Манипуляции — если это две разные модельные сущности в разных участках дома, то нет. Если же это списки то да, но лучше массивы менять через splice, чем 100 раз push — ну или просто сообщить маске, что нужно кешировать изменения — (lock model), а потом пакетом применить — (unlock model).
А можете более подробно сказать, почему тест не корректный — это две идентичные программы — после теста можете вставить тестируемые участки в консоль, и убедитесь, что все биндинги и прочее работает. И маска здесь выступает не только как шаблонизатор…
Поэтому, я исхожу из этого, что вполне корректные тесты — на выходе дают один и тот же результат…
Angular ничем не лучше, а в производительности очень отстаёт, особенно в контексте мобильных девайсов, где у всех webkit. jsperf — одно и тоже приложение. А если вы сравните с бэкбоном, то тоже думаю удивитесь. Кстати, не хотели бы создать такое же маленько todo на бэкбоне?
Понимаете, model.get('attrName') — это ужасный хак. Проперти должны оставаться ими, а не создаваться функции геттеры / сеттеры. Биндинг в маске это всего лишь плагин, который может привязаться к свойствам любой модели model.attrName. Но как уже сказал в статье, можно создать кастомный биндинг провайдер, который будет привязываться к этим функциям и слушать изменения. А такая запись div > '~[:get("username")]' — это не binding, а просто expression.
А ответ на вопрос довольно прост — backbone и не нужен. Нормальных Data Fetch / Routings библиотек тоже пруд пруди. Маску же можно использовать в контексте backbone как шаблонизатор для более плавной миграции от бэкбона к маске в целом. В результате получите более целостное и более быстрое приложение.
«Каждая библиотечная сущность имеет право на свой репозиторий.» — поэтому не обижайте Chain.js
Constructor1() === Constructor1()— получили мешанину из инициализатора и синглтона.Это как дом строить — можно или свезти все детали на стройку и там же создавать кирпичи, отливать плиты и прочее, а можно это все сделать отдельно на разных заводах (читать тестах) и потом привезти уже готовые элементы. И не построить — а собрать дом.
Думаю, для nodejs будет такая вещица даже более востребована, так как нормального профилирования (не через пень-колоду) так и не нашел. Довольно легко сделать аналог require и подменять оригинал, так что бы все скрипты после загрузки, обзаводились метками и исполнялись. Ну a используя socket.io, данные бы отсылались на локальный сервер и был виден результат в браузере.
readystate/timeout/otherGenericListener. Собственно, хотелось бы иметь поиск также в списке с событиями, что бы искать нужную функцию.И почему не «трейсятся» консольные вызовы —
myLib.doSmth();, хотя просматриваяmyLib.doSmth;видно, что все метки проставлены шпионом ).Есть ли в планах сделать cpu статистику функций? И версию для node.js приложений (
$ spy myapp.js)?Ну и в конце концов, больше подробностей с примерами не помешало бы… )
transform-originвычисления могут быть проще, а если использоватьlesshat, то запись будет проще.Пример для левой верхней ленты —
delete к переменным не применим, только к свойствам объекта.
Можно и один обработчик — но лишь со стратегией внутри.
А про «крупные проекты», тоже повеселило — такой код с («упакованной» логикой :)) будет подходить лишь для «integration testing», но никак не для «unit testing», и плюс нарушает «Single responsibility principle». Вообщем — второй молодец…
this == null{{age}}). Просто, понимаете, если будет много других параметров — changeEvent, signal listener, геттеры и сеттеры и прочее, то инлайн запись не подойдёт, через тэг тогда нужно будет.Но простые записи двухсвязных биндингов обязательно сделаю проще. Спасибо за замечание.
Можно записать и так, (с аттр. type опечатка вышла)
Согласен, что запись дуалбиндеров не очень лаконичная, но тэг нужен, так как через него можно указывать много других параметров BindingProvider-a.
Вам разве не важна скорость отображения вашего приложения, а только насколько быстро «а» изменится на «б» в рантайме? Мне как раз первое важнее — это и тестирую.
Манипуляции — если это две разные модельные сущности в разных участках дома, то нет. Если же это списки то да, но лучше массивы менять через
splice, чем 100 раз push — ну или просто сообщить маске, что нужно кешировать изменения — (lock model), а потом пакетом применить — (unlock model).Поэтому, я исхожу из этого, что вполне корректные тесты — на выходе дают один и тот же результат…
model.get('attrName')— это ужасный хак. Проперти должны оставаться ими, а не создаваться функции геттеры / сеттеры. Биндинг в маске это всего лишь плагин, который может привязаться к свойствам любой моделиmodel.attrName. Но как уже сказал в статье, можно создать кастомный биндинг провайдер, который будет привязываться к этим функциям и слушать изменения. А такая записьdiv > '~[:get("username")]'— это не binding, а просто expression.А ответ на вопрос довольно прост — backbone и не нужен. Нормальных Data Fetch / Routings библиотек тоже пруд пруди. Маску же можно использовать в контексте backbone как шаблонизатор для более плавной миграции от бэкбона к маске в целом. В результате получите более целостное и более быстрое приложение.