Комментарии 24
Есть новый фреймворк, его я тебе дам, js я тебе не дам, он уже лежит там под капотом. Сделаешь шаг в сторону, утонешь. Писали его долго, сломаешь ты его быстро.
А откуда такие предположения? JS не запрещён в Mavo. Просто многие вещи могут быть решены без его привлечения.
А утонуть можно абсолютно в любом фреймворке, разве нет? И даже не обязательно в фреймворке, можно и в ванильном JS с таким же успехом «попрощаться с жизнью». :) Как обычно, всё относительно. И очень разнообразно. В этом и прелесть. Зато у каждого есть право выбора. И это очень ценно.
И да, Вы абсолютно правы — сломать можно что угодно. И поверьте, для таких проектов, как Mavo, это гораздо ценнее, чем success stories. Именно ошибки и провалы помогут сделать его лучше. Так что, мы этого не боимся. :)
Спасибо за комментарий и вопрос!
Тот пример кода, который Вы привели, это синтаксис Mavo — так называемый MavoScript. Он является несколько упрощённым подмножеством JavaScript. Упрощение позволяет сделать его более доступным для разработчиков, которые не знакомы (или относительно мало знакомы) с JavaScript (верстальщики, дизайнеры, начинающие веб-разработчики и т. п.).
С помощью атрибута mv-action можно добавлять пользовательские действия в HTML-код, тем самым создавая элементы управления, с помощью которых можно некоторым образом изменять данные (добавлять, удалять, перемещать внутри коллекции и т. п.), с которыми работает приложение. Фактически, пишется код обработчика события onclick для того элемента, к которому добавлен этот атрибут. С помощью mv-action можно последовательно выполнить несколько действий. Для этого нужные действия нужно просто описать в качестве значения этого атрибута, например, через запятую, точку с запятой, пробел или вообще подряд. Mavo чрезвычайно лоялен к тому, как разработчики привыкли писать их код. И «подстраивается» под них, нежели ломает их привычки. :)
Метод set() в этом фрагменте кода set(newTodo, newTodo.trim()) устанавливает (присваивает) свойству (фактически, переменной) newTodo очищенное от лишних пробелов значение этого же самого свойства newTodo. Здесь иллюстрируется то, что внутри кода Mavo можно, при необходимости, использовать имеющиеся в JavaScript методы. Например, в данном случае в Mavo нет функции trim(), поэтому я и обратился за помощью к JavaScript. Этого можно было и не делать. Просто мне не хотелось, чтобы пользователи могли в список дел включать строки, которые состоят из одних пробелов. :)
Далее с помощью встроенной в MavoScript функции if() я просто проверяю, имеет ли смысл добавлять введённую пользователем строку (новое дело в списке дел) в этот самый список дел: если это пустая строка, то нет, не стоит. А вот если после того, как на предыдущем шаге она была очищена от лишних пробелов, она окажется не пустой(newTodo != ''), то её нужно добавить в список дел, то есть добавить в коллекцию todo: add(newTodo, todo). А после этого нужно очистить поле для ввода новых дел, за которое отвечает свойство newTodo, установив в качестве его значения пустую строку: set(newTodo, '').
Остался последний нюанс: функция if() позволяет выполнить только одно действие в зависимости от истинности или ложности проверяемого условия. А нам нужно выполнять сразу несколько действий. В данном случае, два — add(newTodo, todo) и set(newTodo, ''). Чтобы это стало возможным, нужно «объединить» два действия в одно с помощью амперсанда (&). И это, на самом деле, очень логично, ведь в английском языке этот символ заменяет союз «и». И нам ровно это и нужно: нам нужно выполнить первое действие И второе. :)
Надеюсь, мне удалось ответить на Ваш вопрос? Если нужно ещё что-то пояснить, то я готов. Спрашивайте. :)
В результате вы получаете рабочее веб-приложение так, будто вы использовали JavaScript, но на самом деле кода JS там будет ноль. [...] Чтобы Mavo можно было использовать, нужно в голову вашего документа подключить два файла — JavaScript-файл
Кто-то лукавит?
В результате вы получаете рабочее веб-приложение так, будто вы использовали JavaScript, но на самом деле кода JS там будет ноль.Это как бы не совсем «Решение задач веб-разработчика без JavaScript» из заголовка.
…
Чтобы Mavo можно было использовать, нужно в голову вашего документа подключить два файла — JavaScript-файл и таблицу стилей, которые обеспечивают основной функционал Mavo.
Насколько я понял, пугающий пользователей JS скрывается под капот, а пользователям выдают рычажки для доступа к подкапотному функционалу.
Но рычажков не хватает на все случаи жизни, поэтому куски JS остаются в HTML, но в атрибутах.
Профессионалам тоже нелегко — ежедневно выходит огромное количество библиотек, и невозможно уследить за всеми современными трендами в мире веб-разработки.Встречайте новую библиотеку. И новый диалект JS.
Но рычажков не хватает на все случаи жизни, поэтому куски JS остаются в HTML, но в атрибутах.
Вы попали нет в бровь, как говорится, а в глаз. Именно для того, чтобы понять, каких рычажков не хватает, и что нужно добавить в Mavo, чтобы исключить JS, нам и нужна обратная связь от тех, кто пробует поработать с Mavo и пытается использовать его для решения своих задач. И именно с этой целью на каждом витке развития Mavo проводятся user study. Если вдруг захотите принять в чём-нибудь таком участие, дайте, пожалуйста, знать. Ну, а если нет, то это тоже позиция. И мы её уважаем. :)
Кажется, тут переизобрели AngularJS
Это настолько популярное наблюдение при поверхностном взгляде на Mavo, что комментарий на него был добавлен в FAQ на сайте Mavo:
Между Mavo и Angular есть некоторое внешнее сходство, а именно:
оба поддерживаю синтаксис, основанный на HTML;
оба поддерживают выражения.
Однако, Angular никогда не разрабатывался с целью написания приложений полностью на HTML, в отличие от Mavo. Он рассматривает HTML как способ связывания данных с представлениями, но вся остальная логика должно быть написана на JavaScript самим разработчиком. Angular, как более низкоуровневая, но, разумеется, более мощная система, позволяет создавать более широкий набор приложений. Но при этом требует гораздо больше усилий со стороны разработчика и большего времени на его изучение.
У Mavo и Angular совсем разные целевые аудитории. Но никто не говорит о том, что они не могут пересекаться. :)
Мне кажется или товарищи изобрели первый ангуляр? Все эти аттрибуты в HTML и всё такое...
Не просто первый ангуляр, а еще и на 300Кб даже не минифицированного js.
Ну и ToDoApp конечно безумно радует своими дикими выражениями на каком-то птичьем языке в атрибутах. Это, как обычно, прекрасно согласовывается с "вам больше не нужен js" (просто выучите наш новый нескучный обрезанный скриптоязык, а потом пытайтесь на нем что-то сделать).
Just Don't use it.
Давайте просто позволим людям самим попробовать и решить, подходит им это или нет. Вы попробовали (судя, по комментарию, даже подробно изучили), Вам не подошло. И это нормально. Красота мира, в том числи мира фронтенд-разработки, в его многообразии. Нужно просто правильно подбирать инструменты, адекватные решаемой задаче. И уверяю Вас, есть задачи и люди, которым Mavo прекрасно подходит. Если Вы не в их числе, что ж, пусть так оно и будет. :)
Ребята мыслят в правильном направлении, но идут каким-то совершенно неправильным путем. Для решения всех этих задач, вообще-то, изобрели веб-компоненты.
Ребята мыслят в правильном направлении
Я бы не сказал.
Попытки программировать не программируя — они идут примерно с конца 80-х годов прошлого столетия (привет, UML). Это всё всегда упирается в ограничения чисто декларативного подхода, где любой шаг в сторону от имеющихся "строительных элементов" всегда порождает сон разума и чудовищ.
Вот том то и дело, что есть много задач, где настоящее программирование вообще не требуется, но нужна некоторая гибкость решения. Эти задачи традиционно решаются всякими GUI и вполне успешно: от работы с графикой до всяких CMS. Суть этих задач - сугубо композиционная. HTML - это хорошая основа low-code подхода - расширяемая, практически, до бесконечности, где обычный пользователь накидывает готовые блоки а про-разработчик создает нужные ингредиенты.
Вот том то и дело, что есть много задач, где настоящее программирование вообще не требуется, но нужна некоторая гибкость решения.
Есть. Их беда в том, что с течением времени они очень легко могут превратиться в задачи, где "настоящее программирование" внезапно уже нужно. А вы сидите с вендор-локом на каком-то магическом low code решении, и деваться вам с него абсолютно некуда.
Собственно, это центральная причина невзлёта BPMN-решений, при всей серьезности замаха.
HTML — это хорошая основа low-code подхода — расширяемая, практически, до бесконечности, где обычный пользователь накидывает готовые блоки а про-разработчик создает нужные ингредиенты.
"Расширяемые до бесконечности" декларативные решения не взлетают по причине комбинаторного взрыва. Пытаться что-то сварить из 100500 во многом схожих, но таки чуточку разных ингредиентов — это на самом деле куда сложнее "настоящего программирования".
Вы спорите явно не с тем, что я говорю. Я говорю, что система никак не ограничивающая в "настоящем" программировании (какой там вендор-лок, это же веб-платформа, самая свободная среда из существующих) и предоставляющая возможность программирования "ненастоящего" - взлетит. То есть, конечно, уже давно взлетела, сейчас ей предстоит просто перейти на новый уровень удобства для более широкой аудитории.
(какой там вендор-лок, это же веб-платформа, самая свободная среда из существующих)
Несмотря на то, что в вебе действительно технически возможно относительно легко скрещивать ежа с ужом — делать это захочет невероятно малое количество фронтэндеров. Это и будет "вендор-локом" в реалиях веба. Как некоторые люди устроили себе вендор-лок с первым ангуляром — потом тупо не могли найти людей, согласных это тащить (даже в формате "давайте все перепишем") дальше за вменяемые деньги. Как то же самое происходит прямо сейчас с вордпрессом — есть отдельно спецы по WP, но найти человека, согласного "скрестить" WP с чем-то еще серьезным — очень сложно.
В общем, вы напрасно думаете, что веб чем-то принципиально отличается от не-веба. Отличие только количественное — в не-вебе непредусмотренные интеграции стоят как крыло от боинга и даже дороже (на спецов реверс-инжиниринга и всё вот это), а в вебе — как крыло от… кукурузника.
У любого, кто решит втянуться -- море вопросов, ответы потянут на отдельную статью:
Хорошая ли документация? (кажется, как-то не очень)
Большое ли сообщество? (кажется, не очень)
Хороший ли код, архитектура?
Насколько это всё легко расширяется?
Насколько большая и удобная библиотека готовых компонентов? Есть слайдеры, а есть ли слайдеры "от-до"? Есть ли таблицы? Кто пополняет библиотеку, кто апрувит?
Сейчас весь сайт и демо разъезжаются на мобильном. С компонентами тот же подход, desktop first?
Насколько быстро чинятся баги?
Кто, собственно, основной состав разработки и поддержки, какой у них опыт?
Это только навскидку, вопросы, которые стоит понять про любой фреймворк, в какой собираешься вписаться.
Постараюсь ответить на эти вопросы, если Вы, действительно, искренне хотите получить на них ответы, а не просто обозначили в этом комментарии свою позицию. :)
Хорошая ли документация? (кажется, как-то не очень)
Можете, пожалуйста, указать конкретно, ответ на какой вопрос Вы пытались найти в документации, но не нашли его? В этом случае мы сможем её улучшить. Это будет очень полезно для всех.
Да, Вы правы, документация нуждается в доработке, как минимум в том плане, что не все возможности Mavo подробно задокументированы. Но пока нас мало (и здесь Вы тоже правы), мы придерживаемся принципа, что лучше иметь такую документацию, чем не иметь никакой. А на все возникающие вопросы мы с радостью ответим в Gitter, например.
Хороший ли код, архитектура?
А мы ничего не скрываем — код открыт, и Вы можете детально изучить его на GitHub.
Насколько это всё легко расширяется?
Mavo изначально разрабатывается, как чрезвычайно расширяемый инструмент: за счёт плагинов и системы хуков. В любом случае, чтобы получить ответ на этот вопрос, нужно просто попробовать. Разумеется, при наличии желания. :)
Насколько большая и удобная библиотека готовых компонентов? Есть слайдеры, а есть ли слайдеры "от-до"? Есть ли таблицы? Кто пополняет библиотеку, кто апрувит?
Как таковой никакой библиотеки компонентов нет. Те примеры, которые были приведены в статье, нужны для иллюстрации возможностей Mavo. Однако, в силу того, что код Mavo-приложений может быть легко переиспользован либо за счёт простого копи-паста, либо за счёт переопределения хранилища, с которым работает приложение, Вы сможете использовать компоненты, написанные другими авторами. Или разработать свои, которыми с благодарностью и признательностью будут пользоваться и все остальные.
Сейчас весь сайт и демо разъезжаются на мобильном. С компонентами тот же подход, desktop first?
Будет очень здорово, если Вы сможете найти время и возможность завести ишью в соответствующем репозитории. Мы недавно уже кое-что пофиксили. Но могли что-то упустить. Спасибо!
Насколько быстро чинятся баги?
Прекрасный вопрос! И для ответа на него есть приложение, написанное Лией Веру на Mavo. Она даже описала, как его разрабатывала. Если Вам будет любопытно, то вот эта статья.
Кто, собственно, основной состав разработки и поддержки, какой у них опыт?
И это тоже не секрет. Все, кто так или иначе принимает участие в работе над Mavo, здесь и здесь.
console.log() в Mavo?Для этого в Mavo есть встроенная функция log(), которую можно использовать непосредственно в выражениях в HTML-коде. Вот здесь можно посмотреть её описание и пример использования.
Если же нужен более мощный отладочный инструмент, то предлагаю посмотреть в сторону инспектора Mavo. К сожалению, он доступен только в Chromium-based браузерах. Однако, для отладки, думаю, этого должно хватить.
50 цветных оттенков Mavo. Решение задач веб-разработчика без JavaScript