Matreshka.js заполняет образовавшуюся за последние годы пропасть между джуном и сеньором

Вышла beta второй версии фреймворка Matreshka.js. Релиз выйдет через неделю (плюс пара дней) после последнего патча, отчет начинается с выходом этого поста. Версию можно считать стабильной, а статус beta — чистой формальностю, так как проект достаточно долго и без серьезных изменений пребывал в статусе prealpha/alpha и проверялся в реальных проектах.



» Репозиторий
» Сайт


Позиционирование фреймворка


Вместо наивного "JavaScript фреймворк для всех", Matreshka.js теперь позиционируется, как "Простой фреймворк для джунов". Позвольте мне, вместо дублирования текста с сайта, разместить ссылку на текст, объясняющий этот момент более детально.


Общие изменения


  • Фреймворк был переписан с нуля, с использованием ECMAScript 2015 и некоторых элементов синтаксиса, еще не вошедших в финальную спецификацию.
  • Все примеры так же переписаны на новый JavaScript.
  • Устранены все потенциальные утечки памяти.
  • Добавлена возможность импортировать только необходимые функции и классы. В документации к каждому статичному методу и классу указан и адрес модуля.

const bindNode = require('matreshka/bindnode');
bindNode(object, key, node);

  • Все сопроводительные материалы так же обновились: статьи, роутер, и пр.
  • Документация собирается с помощью Webpack и самописного плагина, который очень быстро генерирует HTML файлы из JSDoc и GFM.


Автоматизация процесса выпуска новых версий


Раньше, для выпуска нового релиза приходилось совершать несколько повторяющихся действий:


  • Изменение в коде, написание тестов
  • Коммит изменений
  • Сборка с помощью Grunt
  • Коммит, сообщающий о сборке
  • Изменение версии в package.json вручную
  • Публикация модуля на NPM
  • Пуш на Github
  • Создание релиза на Github
  • Обновление раздела "что нового" в русскоязычной версии сайта
  • Добавление нового пункта в документацию (если в релиз попадает новая фича)
  • Сборка сайта и деплой на сервер
  • Коммит в репозиторий сайта
  • Сообщение о выпуске новой версии в Twitter, VK, Facebook

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


Благодаря включению в проект semantic-release, использованию Travis CI и другим изменениям (например, удалению русскоязычного changelog), выпуск релизов происходит по очень простой схеме.


  • Изменение в коде, написание тестов
  • Пуш на Github
  • Добавление нового пункта в документацию (если в релиз попадает новая фича)
  • Коммит в репозиторий сайта (если в релиз попадает новая фича)

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


После того, как коммит с префиксом fix или feat попадает на Github, происходит следующее:


  • CI вызывает тесты
  • semantic-release анализирует коммиты и меняет версию в package.json
  • Код компилируется в ES5 для NPM
  • Сборка с помощью Webpack
  • Публикация сборки в бранче gh-pages (т. е. больше нет грязных коммитов, типа "rebuild")
  • Бот сообщает о новом релизе в Twitter
  • Публикация нового релиза на Github

Не удивляйтесь, если увидете несколько патчей, сделанных в один день (надеюсь, что такие случаи будут редки).


В свою очередь, при любом коммите в репозиторий сайта, Travis с помощью PM2 автоматически деплоит сайт на сервер.


Другие реформации


  • Добавлена версия документации на украинском.
  • Название у фреймворка теперь одно: Matreshka.js или, сокращенно — Matreshka (латиницей, с большой буквы).
  • Страницы в VK и Facebook закрыты из-за нерегулярности и шаблонности новостей, типа "вышла новая версия".
  • Все примеры и основные туториалы теперь живут в этом репозитории.
  • Запущена кампания по сбору средств на Patreon. Если ваша компания использует Matreshka.js, финансовая поддержка проекта будет являться гарантией того, что проект будет активно развиваться. Если вы индивидуальный разработчик, то и ваша помощь не менее важна. Надеюсь на вашу поддержку, ведь разработка такого крупного продукта и создание трехъязычной документации стоит сотен часов безвозмездной работы.

Изменения API


Самым крупным изменением стало удаление многих функций, которые были ни к селу, не к городу (например, функция trim).


Почему эти функции вообще существали? Мотивация была простой: они были нужны для внутренних механизмов работы фреймворка и, если эти функции и так есть, почему бы не добавить их в публичное API фреймворка?


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


Начиная со второй версии Matreshka.js включает в себя возможности специфичные для самого фреймворка, но не включает никаких "общих" функций. О конкретных причинах удаления некоторых методов, я писал на форуме.


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


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


(!!!) — ломающие изменения
(!) — ломающие изменения, которые, скорее всего, не повлияют на старые приложения


То, что было удалено


  1. (!!!) Matreshka.delay
  2. (!!!) Matreshka#delay
  3. (!!!) Matreshka.define
  4. (!!!) Matreshka#define
  5. (!!!) Matreshka.defineSetter
  6. (!!!) Matreshka#defineSetter
  7. (!!!) Matreshka.defineGetter
  8. (!!!) Matreshka#defineGetter
  9. (!!!) Matreshka#getAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything
  10. (!!!) Matreshka.trim
  11. (!!!) Matreshka.orderBy
  12. (!!!) Matreshka.noop
  13. (!!!) Matreshka.extend
  14. (!!!) Matreshka.each
  15. (!!!) Matreshka.bound
  16. (!!!) Matreshka#bound
  17. (!!!) Matreshka.$bound
  18. (!!!) Matreshka#$bound
  19. (!!!) Matreshka.boundAll
  20. (!!!) Matreshka#boundAll
  21. (!!!) Matreshka.randomString (теперь живет тут)
  22. (!!!) Matreshka.get
  23. (!!!) Matreshka#get
  24. (!!!) Matreshka.deepFind
  25. (!!!) Matreshka.setProto
  26. (!!!) Matreshka.toArray
  27. (!!!) Matreshka.version
  28. (!!!) Matreshka#sandbox
  29. (!!!) Matreshka#$sandbox
  30. (!!!) Matreshka.Object#toNative
  31. (!!!) Matreshka.Object#toObject
  32. (!!!) Matreshka.Array#toNative
  33. (!!!) Matreshka.Array#toArray
  34. (!!!) Matreshka.binders.file (теперь живет тут)
  35. (!!!) Matreshka.binders.dropFile (теперь живет тут)
  36. (!!!) Matreshka.binders.dragOver (теперь живет тут)
  37. (!!!) Matreshka.Array#each
  38. (!!!) Matreshka.Array#hasOwnProperty
  39. (!!!) Matreshka.Array#useBindingsParser
  40. (!!!) Matreshka.Object#hasOwnProperty
  41. (!!!) window.Class (используйте Matreshka.Class вместо глобальной переменной)
  42. (!!!) window.$b, Matreshka.$b
  43. (!!!) Matreshka.$
  44. (!!!) Библиотека matreshka-magic
  45. (!!!) Matreshka.binders.innerHTML
  46. (!!!) Matreshka.binders.innerText
  47. (!!!) Matreshka.binders.attribute
  48. (!!!) Matreshka.binders.property

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


  1. (!!!) Matreshka#linkProps -> Matreshka#calc
  2. (!!!) Matreshka.to -> Matreshka.toMatreshka
  3. (!!!) Matreshka#setClassFor -> Matreshka#instantiate
  4. Matreshka.Object#jset -> Matreshka.Object#setData (jset не убран)
  5. (!!!) Matreshka#isMK -> Matreshka#isMatreshka
  6. (!!!) Matreshka.Object#isMKObject -> Matreshka.Object#isMatreshkaObject
  7. (!!!) Matreshka.Array#isMKArray -> Matreshka#isMatreshkaArray
  8. (!!!) Matreshka.useAs$ -> Matreshka.useDOMLibrary

Изменения в методах bindNode и unbindNode


  1. (!!!) Синтаксис { key: [node, binder] } больше не поддерживается.
  2. (!!!) Синтаксис "куча аргументов" больше не поддерживается.
  3. Новый синтаксис ([{key, node, binder, event}], commonEventOptions).
  4. Новый синтаксис {key: { node, binder }} and {key: [{ node, binder }]}. (Эврика! Этот синтаксисс позволяет красиво навешать много байндингов одним вызовом bindNode).
  5. (!) События bind, bind:KEY вызываются на каждую привязанную ноду.
  6. (!) unbind, unbind:KEY вызываются на каждую отвязанную ноду.
  7. Флаг useExactBinder.
  8. (!!!) Флаг assignDefaultValue переименован в getValueOnBind.
  9. Флаг setValueOnBind.
  10. (!!!) Флаг debounce удален.
  11. (!) Флаг debounceSetValue.
  12. (!) Флаг debounceGetValue.
  13. Флаг debounceSetValueOnBind.
  14. Флаг debounceGetValueOnBind.
  15. Флаг debounceGetValueDelay.
  16. Флаг debounceSetValueDelay.
  17. (!!!) Флаг exactKey вместо deep.

За подробностями обратитесь к документации bindNode и unbindNode


Изменения в байндерах


  1. Новый метод байндера destroy.
  2. (!!!) Байндер className больше не поддерживает синтаксис с восклицательным знаком. Вместо этого, можно передать false в качестве второго аргумента.
  3. Аргумент bindingOptions для всех методов байндера (например, getValue(bindingOptions) {...}).

За подробностями обратитесь к документации bindNode и binders


Изменения в parseBindings


  1. Метод принимает eventOptions вторым аргументом
  2. {{штуки}} не заменяются элементом span.
  3. (!!!) Первый аргумент обязателен.
  4. Внутри {{ скобок }} можно использовать пробелы.

За подробностями обратитесь к документации parseBindings


Изменения в bindSandbox


  1. Теперь метод отвязывает предыдущую песочницу, прежде, чем привязать новую.

За подробностями обратитесь к документации bindSandbox


Изменения в методе calc (который раньше назывался linkProps)


  1. (!!!) Флаг debounce переименован в debounceCalc.
  2. (!) debounceCalc по умолчанию true.
  3. Флаг debounceCalcOnInit.
  4. Флаг exactKey.
  5. (!!!) Флаг skipLinks переименован в skipCalc для использования в методе set.
  6. (!!!) Синтаксис [inst, key, inst, key] убран.
  7. Новый синтаксис { target: {source, event, handler} } (Эврика! Можно вызывать метод calc один раз на много свойств).
  8. Новый синтаксис [{object, key}].
  9. Флаг debounceCalcDelay.

За подробностями обратитесь к документации calc


Изменения в Matreshka.Array


  1. (!!!) Флаг skipMediator переименован в skipItemMediator.
  2. (!) Метод pull поддерживает только объекты и числа.
  3. from и of теперь наследуются.
  4. (!!!) Объект события addone содержит добавленный объект под свойством addedItem вместо added.
  5. (!!!) Объект события removeone содержит удаленный объект под свойством removedItem вместо removed.
  6. (!) itemRenderer не оборачивается в span, если содержит несколько узлов; вместо этого генерируется исключение.
  7. Свойство useBindingsParser удалено.
  8. (!!!) Парсер байндингов включен по умолчанию.
  9. Метод includes.
  10. Метод find.
  11. Метод findIndex.
  12. Метод fill.
  13. Метод copyWithin.
  14. Метод keys.
  15. Метод values.
  16. Метод entries.

За подробностями обратитесь к документации Matreshka.Array, pull, from, of, itemRenderer, METHOD.


Изменения в Matreshka.Object


  1. Событие set, которое срабатывает при изменении свойств (но не удалении), отвечающих за данные.
  2. Метод jset переименован в setData (по просьбам сообщества, старое название по-прежнему будет присутствовать).
  3. Флаг replaceData для метода setData.
  4. Метод isDataKey.
  5. Метод values.
  6. Метод entries.

За подробностями обратитесь к документации Matreshka.Object, setData, isDataKey, values, entries


Изменения в Matreshka.Class


  1. Статичные методы наследуются.
  2. Свойства с именами типа symbol поддерживаются и в качестве свойств прототипа и в качестве статичных свойств.

За подробностями обратитесь к документации Matreshka.Class


Другие изменения


  1. Статичный метод chain.
  2. (!!!) Геттер и сеттер свойства sandbox генерируют исключение для всех объектов.
  3. (!!!) Геттер и сеттер свойства container генерируют исключение для экземпляров Matreshka.Array.
  4. (!!!) "Список ключей, разделенных пробелами" больше не поддерживается ни одним из методов.
  5. Исправлены некоторые неочевидные баги
  6. Все классы и функции можно импортировать в виде CommonJS модуля (import text from 'matreshka/binders/text')
  7. Понятные ошибки.

Проекты, которые появились благодаря работе над Matreshka.js


  • deploy-to-git — CLI тулза, позволяющая деплоить что-либо (в моём случае, результат сборки) на Git сервер.
  • github-embed — эмбеддинг кода с Github, используется на официальном сайте.
  • webpack-generate-umd-externals — приблуда для Webpack, решающая редкую задачу: создание плагина, поддерживающего UMD для чего-то, так же поддерживающего UMD (в данном случае, Matreshka.js), но с импортом CommonJS зависимостей без импорта всего фреймфорка (сложно, не вдумывайтесь).
  • cz-simple-conventional-changelog — упрощенный cz-conventional-changelog.
  • eslint-plugin-output-todo-comments — плагин для ESLint, который выводит комментарии, с заданным префиксом в виде варнингов или ошибок; используется в Matreshka.js, чтоб TODO комментарии не терялись.
  • babel-plugin-transform-object-spread-inline — транспайлит синтаксис object spread в быстрый цикл for вместо вызова Object.assign.
  • babel-plugin-nofn — транспайлит вызов мета функции в быстрый цикл for.
  • babel-plugin-transform-es2015-modules-simple-commonjs — упрощенный трансформер модулей ECMAScript 2015 в CommonJS для компактности результирующего кода.
  • uniquestring — генератор псевдослучайной строки (замена Matreshka.randomString).
  • makeelement — создание DOM элементов (замена Matreshka.$b.create).

Спасибо за внимание!

Поделиться с друзьями
-->

Комментарии (90)


  1. yury-dymov
    11.10.2016 12:49
    +9

    Глядя на "ломающий" changelog, понимаешь, что ты и раньше без Matreshka.js нормально жил, и дальше хуже не станет.


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


    1. Finom
      11.10.2016 12:51
      +4

      Каждые несколько лет «ломать» можно, иначе накапливается критическая масса недоразумений, которые отталкивают и старых и потенциальных новых пользователей. Это касается любого open source проекта.


    1. faiwer
      11.10.2016 19:30
      +1

      Это ещё скромно. А вот мажорные обновления LoDash-а…


      1. vintage
        11.10.2016 21:34
        +1

        Как раз сегодня ковырялся в этом чуде..


        https://github.com/lodash/lodash/blob/4.16.4-npm/drop.js
        38 строк, 2 зависимости, делает то же, что и array.slice( n )


        https://github.com/lodash/lodash/blob/4.16.4-npm/_Map.js
        7 строк, 2 зависимости, просто возвращает глобальную переменную Map.


        https://github.com/lodash/lodash/blob/4.16.4-npm/isArray.js
        26 строк, странно, что без зависимостей, возвращает Array.isArray.


        1. faiwer
          12.10.2016 06:42
          +1

          o_O. А зачем вы берёте в расчёт jsDoc? Да и что такого неприличного в их инфраструктуре? Никакого криминала не увидел.


          1. vintage
            12.10.2016 10:33

            А почему бы его не брать в расчёт?
            Неприлично лишние действия, лишние модули, лишняя сложность на ровном месте.


            1. faiwer
              12.10.2016 11:09
              -2

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


              1. vintage
                12.10.2016 17:47
                -1

                А при чём тут продакшен?


                Бестолковая справка, не идёт ни в какое сравнение с TypeScript Definitions.


                Что в ней крутого, кроме того, что она переусложнена?


                1. faiwer
                  12.10.2016 17:55

                  В смысле причём тут production? Какой смысл считать строки комментариев в коде, да ещё и судить библиотеку по их количеству? В особенности строки из документации. А документация вполне годная, хотя и не идеальная. Чем же хорош _? Гхм. Мне кажется хватит цирка на сегодня. Ничем не хорош, продолжайте наблюдписать велосипеды в стол и критиковать.


                  1. vintage
                    12.10.2016 21:30

                    Библиотеку я сужу по соотношению числа строк к полезному действию. Документация толком не говорит о типах. Да и какой толк "документировать" нативные функции?


                    1. faiwer
                      13.10.2016 07:06
                      +1

                      Библиотеку я сужу по соотношению числа строк к полезному действию.

                      Ок. Сложно найти более глупое занятие.


                      Да и какой толк "документировать" нативные функции?

                      LoDash wrap-ает ряд нативных функций. Линия партии LoDash-а предполагает, что пользователь по большей части работает именно через underscore (habr съедает этот символ). Скажем в их линтере есть правила по использованию _.map, вместо [].map. Насколько это целесообразно оставим за рамками данного разговора, т.к. такие вопросы лучше задавать автору библиотеки. А документировать собственное API (включая обёрнутое) святая обязанность авторов столь популярной библиотеки. Документация включает в себя примеры и ссылки. Построена очень удобна. Редко натыкаюсь на столь хорошую документацию. Не понимаю ваших претензий. Про типы я вообще не понял. У вас передоз typescript-а? Зачем вы их вообще упоминаете? В целом loDash работает преимущественно с коллекциями, которые могут быть массивами, либо hash-объектами. Может быть появилась поддержка итераторов, не проверял. В последнее время не слежу.


                      В одной из последних мажорных версий было поломано почти всё, ввиду того, что был произведён волевой отказ от утиной типизации. Лихой шаг. Про него я выше и написал. В ченжлогах лодаша нормально между делом прочитать что-то вроде "удалено 80 методов" :)


                      1. vintage
                        13.10.2016 11:11
                        -1

                        Осталось удалить ещё пол библиотеки и документация перестанет быть завалена мусорными методами "врапающими" нативные.


                        JSDoc — статическая типизация для бедных, скрученная из палок и изоленты.


                         * @static
                         * @memberOf _
                         * @category Array
                         * @param {Array} array The array to query.
                         * @param {number} [n=1] The number of elements to drop.
                         * @param- {Object} [guard] Enables use as an iteratee for methods like `_.map`.
                         * @returns {Array} Returns the slice of `array`.

                        module _ {
                            export function dropFirst< Value >( sourceArray : Value[] , countToDrop = 1 ) : Value[] {
                                return sourceArray.slice( countToDrop )
                            }
                        }

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


                        Также мы конкретизировали типы. Возвращается не просто какой-то там массив, а массив из элементов того же типа, что и исходный.


                        1. faiwer
                          13.10.2016 12:06
                          +2

                          Похоже, что всё тщетно и безнадёжно.


                          1. RubaXa
                            13.10.2016 16:02

                            Аминь, брат.


                1. k12th
                  12.10.2016 18:32
                  +2

                  TypeScript Definitions — это только типы, в jsdoc куда больше мета-информации. Можно, например, на ее основе сайт генерить (как оно, собственно, и сделано) — и это гораздо надежнее, чем писать доки отдельно. Кроме того, jsdoc использовался и работал в lodash (и не только) задолго до появления ts/tsd, flow и т.д.


                  1. vintage
                    12.10.2016 21:32
                    -2

                    Я вам открою секрет, но для тайпскрипта тоже можно писать всю эту мета-информацию и тоже генерируются сайты. Только информация о типах более конкретня, отлично понимается средой разработки и валидируется при сборке. А ещё она в 10 раз компактнее.


                    1. k12th
                      12.10.2016 21:53
                      +2

                      Спасибо. Вы напомнили, почему я какое-то время перестал было ходить на хабр.


                      1. vintage
                        12.10.2016 22:29

                        Нам расскажете или секрет?


                    1. faiwer
                      13.10.2016 07:11
                      +1

                      Причём тут типы? Причём тут typescript? Речь идёт о javascript документации. Предположим, что typescript definitions располагает лучшей документацией, нежели обсуждаемая (смотреть лень, ибо вообще нет дела до typescript). Вопрос: зачем вы их сюда приплели? Вам скучно? Или любая документация отличная от указанной рассматривается вами как несуществующая или нецелесообразная?


                      Нам расскажете или секрет?

                      Потому, что люди вроде вас повсеместно разводят какой-то нелепый фарс. Какой-то бред про количество строк, про типы, про избыточную инфраструктуру (вы вообще в курсе, что это за библиотека, где она используется, чтобы судить о её модульности?), про компактность (кому она вообще сдалась, оО).


                      Не хватает здесь разве что D, fibers, $mol и что вы там ещё столь неустанно спамитепиарите


                      1. vintage
                        13.10.2016 11:21
                        +1

                        При том, что на дворе 2016 год, а вы всё пользуетесь устаревшими инструментами — описываете типы через jsdoc (а все эти ваши static, @memberOf, param и @returns — это примитивная типизация), заворачиваете половину стандартной библиотеки в свои обёртки, вместо сигнализирования об ошибке реализуете ветвление логики, лишь бы не падало.


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


                        1. faiwer
                          13.10.2016 12:15
                          +1

                          Лично я к разработке loDash никакого отношения не имею. Я просто использую его в своих проектах. Все ваши нападки на него имеет смысл размещать в github issues, а не здесь. Касательно всего остального ? лично мне ваше мнение не интересно. Соглашусь с k12th .


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

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


                1. staticlab
                  12.10.2016 19:30
                  +1

                  Теперь понятно, почему у $mol до сих пор нет документации.


                  1. vintage
                    12.10.2016 21:25

                    Есть.


  1. 776166
    11.10.2016 12:56
    +21

    Я нихрена не понял, зачем это всё нужно. В описании сплошной маркетинг и светлое будущее. Не понятно даже, это «типа jquery?» или нет. И hellow world! на полтора экрана прокрутки. :)
    Самый простой ферймворк во вселенной. Вам даже не надо ничего писать! Просто добавьте его к сайту, и больше ничего не надо делать! От всё сделает сам!
    А теперь главное!!! В следующей версии его даже не надо добавлять к сайту!!! Никаких API! Никакого программирования! Только вселенная!


    1. Finom
      11.10.2016 12:59
      -5

      > Я нихрена не понял

      За две минуты вряд ли что-то можно понять.

      И нигде не написано о светдом будущем. Это фреймворк для новичков, не более.


      1. AstarothAst
        11.10.2016 13:51
        +14

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

        Реактивный API, позволяющий эффективно решать сложные и запутанные задачи

        Какие задачи? Это главный вопрос — для чего пригоден, а для чего не пригоден Ваш фреймворк. Ответа процитированное не дает.

        Меньше ошибок в коде

        Меньше по сравнению с чем? И почему меньше, за счет чего? За счет богатой библиотеки? Или за счет сокращения количества кода, который приходится писать? Или еще почему-то? Нет ответа.

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

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

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

        Поверим на слово. Но как насчет возможностей? Если цена простоты отсутствие возможностей, то зачем такой фреймворк нужен? А о возможностях мы до сих пор ничего не знаем…

        Одна из самых удобных документаций среди JavaScript библиотек

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


        1. Finom
          11.10.2016 14:05
          -1

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


          Какие задачи? Это главный вопрос — для чего пригоден, а для чего не пригоден Ваш фреймворк. Ответа процитированное не дает.

          Это фреймворк общего назначения для веба. Имеются в виду задачи, которые встречаются при разработке одностраничных веб приложений: работа с DOM элементами и данными. Основная сложность, которая возникает у начинающих программистов — это зависимость одного от другого, другого от третьего и пр.


          Меньше ошибок в коде

          С опытом разработик начинает писать код без ошибок, а Matreshka.js ускоряет этот процесс за счет того, что связывает одно с другим. Один раз задали правило "первое зависит от второго" и забыли. Это звучит очень абстрактно, посмотрите этот ролик. Он немного устарел (linkProps переименован в calc), но, в целом, отвечает на ваш вопрос.


          Эта возможность есть всегда и везде

          Скажем, если вы всё переписываете на Реакт, то придется переписать всё, без исключения. Иначе жизнь превращается в боль (по опыту знаю).


          Вы уверены, что не выдаете желаемое за действительное?

          Это не я сказал. Пользователи фреймворка раз документацию к фреймворку называли "лучшей документацией среди всех фреймворков".


          1. Finom
            11.10.2016 14:11

            Под конец, в спешке, белиберду написал, сорри. Перефразирую: юзеры так считают, не я.


  1. PQR
    11.10.2016 13:44

    Везде ES2015, но для модулей используете require, почему не import?


    1. Finom
      11.10.2016 13:49

      Обновлю документацию, когда в V8 появится поддержка import. Это такой психолигический барьер: импорты еще ни одним движком не поддерживаются.

      В сорсах фреймворка, конечно же, используется import, вместо require.


  1. Finom
    11.10.2016 14:09
    +3

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


  1. Riim
    11.10.2016 14:16

    для больших и бесконечно расширяемых приложений

    Честно говоря, очень сомнительно. Я тут пару месяцев назад, выполняя ишъю, поковырялся немного в вашем фреймворке, много вопросов появилось и главный — это биндинги, которые сделаны таким образом, что при любом изменении вёрстки прийдётся каждый раз перепроверять все биндинги соответствующего вёрстке компонента. Есть какая-то уверенность, что в действительно большом проекте, над которым работают много разработчиков и который динамически дорабатывается, это начнёт настолько жёстко напрягать, что человека предложившего делать проект на матрёшке начнут просто избивать ногами)). Так же не понятно есть ли в матрёшке какая-то компонентная система? И если нет и нет какой-то альтернативы, то опять же непонятно о каких больших проектах вообще можно заикаться?
    На мой взгляд ниша фреймворка — маленькие представительские странички, но и в этой нише тот же angular-light явно выигрывает в удобстве.


    1. Riim
      11.10.2016 14:20

      Кстати, матрёшка в тесте предложенном в ишъю показала почти самый худший результат, хуже только Kefir.js. Во второй версии что-то изменилось?


      1. Finom
        11.10.2016 14:23

        Да, там много всяких улучшений. Например calc и bindNode юзают debounce по умолчанию. Если обновите тест, буду благодарен.


        1. Riim
          11.10.2016 14:31

          Ок, попозже обновлю)


    1. Riim
      11.10.2016 14:28

      Ещё не понятно, что с условными биндингами? Например, в Rionite я могу написать так:


      <template is="rt-if-then" if="users?.length">
          <ul>
              <template is="rt-repeat" for="user of users">
                  <li>{user.name}<li>
              </template>
          </ul>
      </template>

      Реально переписать на матрёшку?


      1. Finom
        11.10.2016 14:31
        -1

        Условных байндингов в шаблонизаторе нету, иначе бы получился "очередной Ангуляр, но лучше". Байндинги должны быть в JavaScript коде (bindNode), за исключением самых простых (parseBinsings).


        1. Riim
          11.10.2016 14:43

          Речь не про то где они, а про возможность создания условных биндингов. В примере выше <template is="rt-repeat" for="user of users"> и {user.name} автоматически сбиндятся как только появится список users с ненулевой длинной (и разбиндятся при надобности). По матрёшке сложилось впечатление, что в такой ситуации прийдётся ручками подписываться на users и в обработчике опять же делать всё ручками. Это уже отстой, плюс в результате всё это будет раскладываться по методам и биндинги будут не в одном месте каждого компонента (так компоненты-то есть?) а размазаны по всему файлу, ищи их потом при изменениях в вёрстке.


          1. Finom
            11.10.2016 14:48
            +1

            Я не работал с библиотекой, о которой вы говорите. Я так порнимаю, что речь идет об автоматическом рендеринге коллекций, верно? Можете пролистать в самый конец этого поста, там типичный пример создания простой коллекции с её рендерингом. Документация к классу Matreshka.Array тут.


            1. Riim
              11.10.2016 14:52

              Нет, вы неправильно понимаете, перечитайте ещё раз. Можно и без коллекции:


              <template is="rt-if-then" if="user">
                  <div class="user-card">
                      <img src="{user.avatar}">
                      <span>{user.name}</span>
                  <div>
              </template>


              1. Finom
                11.10.2016 14:55

                if/else в виде атрибутов — антипаттерн. А так, да, без создания класса, либо экземпляра класса не обойтись.


                1. Riim
                  11.10.2016 15:21
                  -1

                  if/else в виде атрибутов — антипаттерн

                  разработчики стандарта вебкомпонентов смотрят на вас с недоумением)


                  1. Finom
                    11.10.2016 15:26
                    +1

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


                    1. Riim
                      11.10.2016 16:44
                      -1

                      Вебразработка пережила вебкомпоненты? А я то всё думал, что вебкомпоненты — это будущее вебразработки.
                      Можете рассказать почему считаете "if/else в виде атрибутов — антипаттерн"?


                      1. Finom
                        11.10.2016 16:58
                        -1

                        Циклы, условные операторы и прочая логика в HTML — антипаттерн из-за, того, что их сложно дебажить. В JS если что-то упустил (опечатался, не определил переменную), узнаешь моментально.


                        1. Riim
                          11.10.2016 17:35
                          -1

                          Что-то в этом есть, но это скорее проблема реализации. Раньше работал с библиотекой Rivets.js там действительно такое случалось, сейчас при работе с Rionite вроде всё хорошо, но потенциально есть места где возможны такие проблемы. В тоже время не вижу проблем в их устранении, думаю мне будет чем заняться в свободное время)) Спасибо за идею)


    1. Finom
      11.10.2016 14:37
      -1

      У нас с Вами всё время возниакют споры, касающиеся двух методов. Сейчас они работают немного по-другому, гляньте переработанное описание bindNode и calc (ниже описание флагов с объяснениями) и исходный код.


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


      1. Riim
        11.10.2016 14:48
        -1

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


        1. Finom
          11.10.2016 14:51
          +2

          Ну, будем честными, можно вообще на всё забить и использовать React/Redux.


          1. Riim
            11.10.2016 16:53

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


            1. Finom
              11.10.2016 17:05
              -1

              Ух, сложно. Это фреймворк для студий, позволяющий экономить деньги на найме специалистов и фреймворк для разработчиков, позволяющий быстро начать что-то делать, не используя сложные современные решения — это основная задача фреймворка. Зайдите на сайт и прочтите подробности, не буду копипастить.


            1. Finom
              11.10.2016 17:10
              -1

              Зашел на ваш Гитхаб и… я тоже задался вопросом "зачем", просматривая проекты, которые вы сделали. Я ни в коем случае ни хочу сказать, что ваши решения плохи, просто не понимаю, почему вы ходите в каждый пост о Matreshka.js и выясняете со мной отношения. Если мне не интересно, что делаете вы, я не буду вас убеждать в чем-то. А я удостаиваюсь такой чести уже не первый раз.


              1. Riim
                11.10.2016 17:28

                я тоже задался вопросом "зачем"

                какой именно модуль вам интересен?


                почему вы ходите в каждый пост о Matreshka.js

                вы меня с кем-то путаете, посмотрел свои комментарии, это первый ваш пост, в котором я есть))


                1. Finom
                  11.10.2016 17:52
                  -1

                  какой именно модуль вам интересен?

                  Ни какой.


                  вы меня с кем-то путаете, посмотрел свои комментарии, это первый ваш пост, в котором я есть))

                  Значит, магия (на самом деле нет, и я вижу, что вы заново зарегистрировались относительно недавно).


                  1. Riim
                    11.10.2016 18:12
                    +2

                    Ни какой.

                    Ок, перефразирую. В необходимости какого модуля у вас есть сомнения?


                    что вы заново зарегистрировались относительно недавно

                    Смотрите здесь: https://habrahabr.ru/users/riim/


                    Зарегистрирован: 16 мая 2015 в 21:41
                    Приглашен: 02 декабря 2015 в 12:15 по приглашению НЛО

                    Я в принципе на хабре не так давно, около года, регистрировался 1 раз, уж не знаю что и где вы там видите)) Видимо всё же с кем-то путаете меня.
                    Зачем мы это вообще обсуждаем? Это вы так от вопросов о фреймворке ушли?


    1. dolphin4ik
      11.10.2016 15:00

      А вы действительно можете показать настолько огромные приложения которые не возможно будет написать на матрёшке или на ней они будут безумно запутанными?


      1. Riim
        11.10.2016 15:08
        -2

        Сделать можно и на jQuery, вопрос в удобстве поддержки. Могу скинуть в ЛС минимум три крупных проекта (ещё один в разработке) с которыми работал и которые было бы крайне непросто поддерживать будь они сделаны на матрёшке.


        1. dolphin4ik
          11.10.2016 15:10

          Будьте любезны


          1. Riim
            11.10.2016 15:39
            -2

            Отправил. Не все, к сожалению, дожили до сегодняшнего дня))


            1. Riim
              12.10.2016 14:01

              Оценили? Реально считаете возможным сделать что-то подобное на матрёшке?


              1. vintage
                12.10.2016 17:48
                +2

                А чего по личкам прячетесь? Дайте всем оценить :-)


                1. Riim
                  12.10.2016 18:07
                  -1

                  Ну не знаю, вдруг окажется, что я нуб и всё это на матрёшке за пару недель делается)) Позор-то какой будет) Отправил в ЛС.


      1. dolphin4ik
        14.10.2016 15:21

        Отвечу в свою ветвь, чтоб могли посмотреть все пользователи. Вдруг разработчики в яндексе действительно боги, и смогли закодить 10+ кнопочек и переключателей без модных Ангуляра и Реакта


        1. Riim
          14.10.2016 16:37
          -2

          чтоб могли посмотреть все пользователи

          если бы я хотел показать всем, я бы наверно не стал отправлять в ЛС. Это как минимум не красиво с вашей стороны. Не считаете так?


          Вдруг разработчики в яндексе действительно боги, и смогли закодить 10+ кнопочек и переключателей без модных Ангуляра и Реакта

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


          1. shifttstas
            02.02.2017 12:54

            Это же косяк поставшика электричества, да?


            1. Riim
              14.10.2016 17:10
              -1

              Наверное мне решать, какая информация обо мне должна светиться в общественной переписке, и отправил её я лично вам, а не кому-то. Больше я такой ошибки, конечно, не сделаю. А вы, извините, мудак, но это, конечно, субъективно, вы так точно не считаете))


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


  1. sp1ne
    11.10.2016 17:47

    Прочитал все комментарии и всё равно не понял, зачем нужен этот вселенский фреймворк и зачем мне использовать его, вместо того же самого jQuery?


    1. Finom
      11.10.2016 17:57
      -1

      За тем же, зачем вообще используют фреймворки: для разделения логики, уменьшения количества кода и пр. Комментарии действительно ни о чем. Возможно, небольшой туториал частично ответит на ваш вопрос.


    1. k12th
      11.10.2016 18:14

      Реактивность — это удобно, это декларативно, это производительно. Не обязательно, кстати, использовать именно этот вселенский фреймворк, но вообще этот подход действительно удобный.


      Ну и да, никто не запрещает использовать jQuery, если вам самому еще не надоело.


      1. Riim
        11.10.2016 18:23

        bindNode как раз нифига не декларативно, linkProps тормозной, а кроме этого в фреймворке остаётся солянка каких-то утилитных методов на все случаи жизни. Зачем тащить пак таких методов, минимум половина из которых будет не нужна в проекте, когда можно устанавливать только нужное из npm?


  1. hdkr
    11.10.2016 18:01

    По моему для начинающего разработчика ( а именно для него позиционируется Матрёшка, ансколько я понял ) будет полезнее изучить JQuery или Angular на базовом уровне. Они не намного сложнее чем то, что Вы предлагаете. Полезнее тем что JQuery или Angular он хотя бы потом сможет использовать и на других фирмах и вообще вероятность столкнуться с ними гораздо выше чем с Матрёшкой. А практического применения для крупных проектов судя по возможностям фреймворка не особо вижу.
    На мой взгляд чтобы предлагать в массы очередной фреймворк, он должен или иметь какую-то новую идею которой нет у других или решать существующие проблемы быстрее и с написанием наименьшего кол-ва кода или быть крайне удобным и ф-циональным по сравнению с другими. Ничего из перечисленного пока я не наблюдаю в Матрёшке.
    Но это лично моё мнение. Как говорится на каждый товар есть свой покупатель. Желаю Вам успехов в усовершенствовании Матрёшки. Я думаю информации для размышлений Вам накидали достаточно, не воспринимайте её в штыки, просто подумайте над этим и возможно получится сделать Матрёшку еще лучше ;)


    1. Finom
      11.10.2016 18:08
      +3

      Вы писали этот комментарий пять минут, я писал Matreshka.js четыре года. Уж поверьте, за это время я многое обдумал :)


  1. MAXHO
    11.10.2016 18:24

    Без всякой иронии… Вы не могли бы тезисно изложить ++ для изучения новичком вашего фреймворка.
    Если он годен и учит «хорошему» я даже готов начать писать для него уроки.

    У меня проблема выбора начального фрейморка для школьников в кружок.
    Фореймворк должен продемонстрировать основные современные реалии без тяжоловесного кода.


    1. Riim
      11.10.2016 18:35

      Посмотрите на Riot, самое что надо для новичков. Если хочется немного реактивное программирование показать, то можно Vue.js посмотреть, отлично подойдёт. KnockoutJS тоже всё ещё хорош.


      1. PaulMaly
        11.10.2016 19:01

        RactiveJS еще.


    1. Finom
      11.10.2016 19:16
      +1

      • Не нужно прыгать с места в карьер, используя NPM, Webpack и пр (хотя, можно).
      • Можно объявлять двустороннее связывание с помощью селекторов (селекторы умеют юзать все).
      • Нет многословной теоретизации, есть одно правило: делаешь кусочек приложения (например, форму), объяви для этого класс и размести его в отдельном файле (ученикам будет понятно, зачем нужна модульность).
      • Документация настаивает на использовании ECMAScript 2015, который через год-два будут знать абсолютно все (сейчас многие противятся прогрессу)
      • Реактивность (например, поле формы, зависит от свойства А, свойство А от свойства Б, свойство Б от свойства В, свойство В зависит от другого поля формы: при изменении второго поля по цепочке изменятся свойства и первое поле формы). Читайте о методах bindNode и calc. Плюс к этому, можно навешать обработчик события изменения свойства, для того, чтоб запустить кастомный код (например, отправить запрос на сервер). Читайте о методах on, off, trigger

      Самое главное: это чистый JavaScript. Никакого расширения синтаксиса языка разметки.


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


  1. jMas
    11.10.2016 21:57
    +2

    Очень много воды о библиотеке, даже вспомнил как начинал пирить "свой" проект (php).


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


    В примерах я увидел очень много концепций, которых нет в обычном JS (например кастомный синтаксис биндинга к событиям) — все это придется понять, Мне без вкуривания документации трудно интуитивно понять например modify *@modify. Я знаю и работал с vue.js — все то же самое, но во всех отношениях доступней.
    Меньше агрессивного маркетинга и пустых слов — больше исследований, бенчмарков, добавляйте библиотеку сюда чтобы вы сами смогли найти ближайших конкурентов по производительности, а разработчики смогут помереть вашу библиотек и посмотреть на более-менее типовое приложение.


    1. Finom
      11.10.2016 22:19

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


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


      Слова "самый простой", простите, когда вы говорите это — вы сразу попадаете в категорию болтунов

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


      1. jMas
        11.10.2016 22:34
        -1

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

        Это не витрина, где вы выставляете свой фреймверк — это прежде всего бенчмарк и возможность сравнить библиотеку на стандартном шаблоне. Вы можете сделать форк всего репозитория и разместить / обновлять код когда вам удобно. Зато получите в замен Example который знаком каждому более-менее серьезному программисту на JS.


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

        Абсолютно все равно и не информативно. Какое то время назад vue.js продавал себя как самый маленький (сейчас просто с самым низким порогом вхождения) с синтаксисом похожим на ангуляр. Это было действительно крутая реклама. Слоган "самый простой фреймверк" не только не понятный, но еще и вредный.


        1. Finom
          11.10.2016 22:39

          Спасибо, подумаю над этим. У Evan You можно многому научиться, он большой молодец.


          1. vintage
            11.10.2016 23:11

        1. Finom
          11.10.2016 23:06

          Да, я знаю, что сделаю (по крайней мере, в общих чертах). Спасибо за адекватную критику.


  1. Alternator
    12.10.2016 15:55

    В тему к babel-plugin-nofn.
    Хочется упомянуть близкий по задачам плагин — babel-plugin-macros

    Позволяет объявить любую функцию с меткой macro:, и она будет инлайново развернута в месте вызова.


    1. Finom
      12.10.2016 15:55

      Где вы были раньше? :)


  1. arhangelsoft
    12.10.2016 15:56
    -3

    Фреймворк был переписан с нуля, с использованием ECMAScript 2015 и некоторых элементов синтаксиса, еще не вошедших в финальную спецификацию.

    Кто-нибудь, объясните мне, почему вы все просто поехали крышей на этом «новом стандарте» который из коробки толком ещё нигде не поддерживается? Потому что я искренне не понимаю, почему не надо послать автора, код которого является по сути псевдокодом (простой сахар) и сам по себе работать он не будет, и этому сахару нужен целый babel с кучей расширений, чтобы транслировать этот сахар в то, что годами из коробки работало и продолжает это делать по сей день. Зачем вы все так усложняете?


    1. Finom
      12.10.2016 15:58

      Вы удивитесь, но ES2015 поддерживается всеми современными браузерами. С некоторыми оговорками, конечно же (например, файерфокс не умеет так: for(const x of y) {}, прриходится объявлять переменную с помощью let и юзать eslint-disable-line с конфигом airbnb).


      1. arhangelsoft
        12.10.2016 16:02
        -3

        В том-то и проблема, что «всеми современными». Остальная часть земного шара ещё с 18 версии фаирфокса не слезла и как-то не планирует, и «ES2015 поддерживается всеми современными браузерами» ни разу им не аргумент. Про старые версии хрома, сафари под винду (есть и такие гурманы), и IE 7, очевидно же.


        1. Finom
          12.10.2016 16:07
          +2

          Для поддержки старых браузеров юзают Babel :)


          Да и чего вас это так возмущает? Например, когда почти все использовали Кофескрипт, он мне не нравился и я его просто не использовал.


    1. k12th
      12.10.2016 16:10

      Вообще-то из коробки он уже поддерживается во всех evergreen-браузерах более чем на 90%, аналогично в Node.js. Никакой babel с кучей расширений уже, в общем-то, не нужен (за исключением поддержки модулей), если вы остаетесь в рамках ES2015.


  1. yul
    15.10.2016 11:54

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