Комментарии 40
Главная проблема данной библиотеки всё ещё в том, что есть устоявшиеся синтаксические основы языков программирования которые позволяют после любого одного языка программирования быстро разбираться в основах любого другого. И никто не будет прикладывать усилия к тому, чтобы понять гениальные идеи авторов библиотеки, скрытые за непонятным и недружелюбным синтаксисом.
Простой синтаксис даёт удобную обработку..., окей, давайте попробуем:
$my_app $mol_page // Что мы здесь обьявляем? $my_app? $mol_page? Что $my_app это $mol_page? а что такое $mol_page?
head / // Вероятно подразумевается что head является вложением $my_app
^ // А без стрелочки никак? Или может быть стрелочка вниз?
<= Filter $mol_string // Некий фильтр из которого не понятно он уже есть или это вложение head
hint @ \Filter tasks or Add one // Самый странный способ писать комментарии. А что если я захочу прокомментировать другую строчку?
value? <=> filter? \ // Мы записываем в вэлью фильтр? Или фильтр в вэлью? Откуда мы их вообще берём?
<= Add $mol_button_major
title @ \Add this task // Всё ещё самый странный способ писать комментарии
enabled <= add_allowed false // Мы записываем в enabled эдд эловд? Или фолз? А откуда мы взяли эдд эловед и почему оно без знака вопроса как фильтр,
click? <=> add? null // Записываем в клик эдд? Или эдд в клик?
body /
<= Task_rows $mol_list // Отправляем строки в боди
rows <= task_rows /$my_task_row // Или строки в строки
<= Task_row* $my_task_row // А это видимо мы отправяем строку в строки в боди? А звёздочка это видимо означает что было сложно до этого места дочитать, согласен
Task <= Task* $my_task
drop? <=> task_drop*? null
$my_task_row $mol_row
Task $my_task
title? => title? // Это можно продолжать безконечно
sub /
<= Title $mol_string
value? <=> title?
<= Drop $mol_button_minor
title @ \Drop
click? <=> drop? null
Вот честно, я ни разу в жизни не ел грибы, но кажется если я их употреблю и сяду программировать - напишу что-то подобное.
Собственно поэтому автор и пытается достучаться до разработчиков, демонстрируя выгоду от перехода на свой синтаксис.
Нужна критическая масса разработчиков, которые на этом пишут чтобы это пошло в массы.
Автор не демонстрирует выгоду, да и критическая масса тут не поможет. Проблема в том что вот допустим я новичок и хочу сделать сайт. Когда я учу $mol я учу только $mol. Когда я учу react я учу ещё и vue и angular и svelte и ещё 100500 разных фреймворков.
Когда вы новичек, то вас такие проблемы вообще не волнуют. Вы просто учитесь писать сайт.
Когда вы учите React, вы учите только React. На Vue, Angular, Svelte приложения строятся совсем по другому. А вот когда вы учите $mol вы учите прежде всего TS, который понадобится вам в любом более-менее серьёзном проекте.
Кроме того, изучение $mol даёт хорошую научную базу и прививает чутьё к лучшим архитектурным практикам, что опять же пригодится далеко за пределами $mol.
А Вы точно писали когда-то код в функциональном стиле? Создается стойкое ощущение, что либо я ничего непонял из того, что Вы называете тестами, или, напротив, Вы совершенно не разобрались в том, чем является функциональное программирование.
Я даже выпив 3 чашки чая, не могу представить где в ФП Вам понадобились тесты. Я даже выпил еще три и поболтал с товарищами упоровшимися в хаскель на уровне его разработки, так вот не поверите - они так же как и я не в курсе.
А вот тот весь список из вашего доклада о причинах необходимости тестов, он пример махровой императивщины. Что не удивительно, потому как для нее тесты и придуманы, чтобы как то прикрыть родовые травмы.
В статье есть ссылка, по которой вы найдёте ответы на все ваши вопросы. Обратите также внимание, что большая часть из них у вас возникла бы с любым синтаксисом.
Постараюсь ответит на вопросы в комментари.
Синтаксис действительно просто и состоит из нескольких знаков, который выполняют всем нам привычные действия. Умещается весь синтаксис +- 1 строку.$это_компонент -комментарий, \строка, * объект его_свойство ^и_перегрузка_свойства, /массив
А дальше уже поинтереснее@ \автоматическа локализация строки, <= <=> => наглядное связывание свойства (реактивность), Task_row* - перебераем массив с компонентами и ? - динамическое свойство
Кто прочитал данный комментарий - поздравляю, вы освоили весь view.tree!
Главное тут скорость и эффективность - 1 символ на 1 любое действие. Не 1 лишниго символа нет в view.tree
Вот тут есть шпаргалка https://mol.hyoo.ru/#!section=docs/=vv2nig_s5zr0f/Docs.View"vv2nig_s5zr0f".Details=Шпаргалка по спецсимволам и площадка, где можно поиграться с view.tree https://mol.hyoo.ru/#!section=view.tree
есть устоявшиеся синтаксические основы языков программирования которые позволяют после любого одного языка программирования быстро разбираться в основах любого другого
Тем не менее вы не можете зная Pascal перейти к работе на JS. Если вы про такие вещи как операторы, переменные и т.п. то во view.tree всё это есть...
И никто не будет прикладывать усилия к тому, чтобы понять гениальные идеи авторов библиотеки
Все мы прикладываем усилия что бы понять новый для нас инструмент. Для того что бы научиться делать хорошие приложения на react как ни крути придётся почитать документацию.
Простой синтаксис даёт удобную обработку..., окей, давайте попробуем
Дело в том что синтаксис простой, а не интуитивный. После внимательного прочтения документации и попытки реализовать какой то базовый компонент вы поймете почему view.tree прост.
Если вам действительно интересно вы можете уделить немного времени документации, а непонятные моменты уточнить в чате тг https://t.me/mam_mol. Лично я был удивлен оперативностью отклика сообщества
Удачи!
Руки мыть люди тоже не сразу приучились
Зачем в хабах ReactJS указывать? Я на этот хаб подписался, чтобы читать статьи о React, а не $mol.
На Хабре почему-то до сих пор нет хаба $mol. Хаба JSX я тоже не нашёл.
Если вы считаете, что на сайте не хватает какого-то хаба, то предложите его через форму обратной связи. В сопроводительном письме укажите не менее 10 ссылок на публикации, которые на данный момент расположены «не там».
Прикольно, но первое что я обнаруживаю зайдя по ссылке на подробности про $mol — это горизонтальная прокрутка и обрезанный интерфейс с текстом.
Наверное, это лучшая демонстрация того, что подобно тому, что не каждый размер браузера подходит для приятной работы с $mol, как и то, что $mol не для всех.
И убедить тех, кто с удовольствием пользуется json перейти на view.json, это как убедить, что у кого-то не правильный размер браузера и он пользуется ПК не правильно.
Хотя, практика показывает, что если что-то действительно решает существующую проблему, то синтаксис уже не важен. Например, понятно какую проблему решает rust — и его "ужасный" синтаксис в итоге игнорируется. Про $mol так не получается сказать, он не решает какую-то глобальную проблему, он просто предлагает делать тоже самое, но немного по другому.
При чем, игнорируются потребности других, например в синтаксисе нет поддержки однострочников. Ну кому-то зайдет, наверное.
Поздравляю, вы нашли баг на сайте. Какое он имеет отношение к теме статьи?
view.tree разделяет декларативную композицию и императивную логику. У этого разделения есть множество приятных бонусов, о которых я рассказывал тут: https://page.hyoo.ru/#!=xl437w_w1mpfo
Один из них - да, сложно наговнокодить, как бы ни хотелось влепить "однострочник" по среди вёрстки.
Это же притча. Вроде всё работает как надо, но одна мелочь руинит всё. Плюс, кажется, это не баг, а сайт так сделан, но не суть.
Про view.tree ведь можно сказать и по другому, по аналогии с минусами для других форматов:
- магические символы
- волшебные отступы
- смесь бинарного и текстового формата
- непроглядная мешанина всего подряд
- путаница с unix \ переносом строки
- хорошо совместим с $mol (это плюс)
А так, технически $mol очень крутой, вот эта система атомов, связей, потоков данных и прочее. Но tree не выглядит так, как его пытаются преподнести. Это скорее шаг назад.
Вот за что мне нравится HTML, так этот за то, что его можно прямо в браузере править. Открываешь панель инструментов по F12 и правь DOM хоть вдоль, хоть поперёк. Более того, все перечисленные форматы, после обработки транспилятором, в браузере будут HTML'ом. Просто потому что. И если будут на странице какие проблемы, то разбираться ты будешь именно с транспилированным HTML'ом. И детранспилировать во всю эту первоначальную экзотику будешь самостоятельно и в голове. Это одна из причин, почему среди всего другого я для себя выбрал vue. Правило наименьшего удивления.
view.tree тоже можно править прямо в браузере. Берёте любое приложение и настраиваете его как хотите. Вот, для примера, дефейс $mol портала. И нет, $mol не формирует HTML, он динамически строит DOM для видимой области.
Мы немножко по-разному понимаем "панель инструментов по F12":
$mol не формирует HTML, он динамически строит DOM для видимой области.
Значит сам браузер трансформирует DOM в HTML в панели инструментов. Просто потому, что HTML - это стандарт для веба. Как и CSS, как и JavaScript. У вас же нет плагина для браузера, чтобы он транслировал DOM обратно в tree, не так ли? Иначе в качестве примера дефейса $mol-портала был бы сделан скриншот панели инструментов, а не дана ссылка на сторонний сайт (studio.hyoo.ru vs. mol.hyoo.ru).
Я вполне допускаю, что tree гораздо удобнее для представления структуры страницы/маршрута/компонента в силу своей компактности, но... YAML до сих пор не вытеснил JSON, а JSON до сих пор не вытеснил XML. Наверное потому, что не только компактность важна при описании структур данных.
Студия ещё молода, не всё умеет, но уже умеет гораздо больше, чем в принципе возможно создать для других фреймворков.
Про YAML/JSON/XML можете почитать тут: https://page.hyoo.ru/#!=8i7ao7_xfyxah
Никаких объективных причин, кроме инертности мышления, использовать их нет.
Студия ещё молода, не всё умеет, но уже умеет гораздо больше, чем в принципе возможно создать для других фреймворков.
"больше, чем в принципе возможно" (y) Как можно относится серьёзно к вашей разработке после таких несерьёзных заявлений? :) Ведь всё, что вы пишете про свой фреймворк, нужно делить на 10 после таких заявлений. Энергии вам, конечно, не занимать, но вот с объективностью - беда-а-а.
Никаких объективных причин, кроме инертности мышления
Тогда у меня для вас хорошая новость, вам осталось преодолеть всего лишь одно препятствие!
Скорее умножать на 10. Я очень сильно скромничаю. Можете сами попробовать реализовать аналог студии для React или для Vue.
Как я уже отметил в комменте выше - объективность не входит в список ваших достоинств. Иначе бы $mol уже давно подвинул и React, и Vue. Но на Хабре вас любят как раз таки за её отсутствие.
Объективно вы ничего такого сделать не сможете, поэтому даже не будете пытаться, вместо этого предпочитая нападки на личность.
Почитал доку здесь https://page.hyoo.ru/#!=vv2nig_s5zr0f , но всё же не могу понять почему для событий используется именно такой синтаксис:
click? <=> remove? null
Вы не могли бы пояснить?
У кнопки есть канал click, в который на пушит события при нажатии. По умолчанию этот канал ничего не делает. При создании кнопки, этот канал поменяется на наш канал remove, чтобы кнопка пушила события к нам. Собственно двусторонняя связь разрешает пушить в канал значения. При одно сторонней - пуши игнорируются. То есть владелец контролирует кто имеет возможность пушить в его каналы.
Привет!
Заходи к нам в чат https://t.me/mam_mol, ответим на все вопросы)
Если у тебя есть идеи для пет проектов, который ты хотел бы сделать, мы поможем его довести до результат на $mol ^_^ за очень короткий срок.
А так ещё приглашаю поучавствать в опен соурсе с нами. В самом моле - различные студии https://studio.hyoo.ru/ и парсеры https://tree.hyoo.ru/
Или со мной - я сейчас по фану делаю аудиопереводчик view.tree -> человеский язык, который отвечал бы на эти вопросы))
Сайт: https://lyumih.github.io/milis/treesay/storybook/-/#!demo=milis_treesay_demo
и его код https://github.com/Lyumih/milis/tree/main/treesay
Мне понравился $mol. В свободное от работы (классический финтех на реакте) делаю на нём пет проекты и стараюсь наладить документацию и взаимодействие с людьми).
Недавно захотел проверить MVP 2 моих спонтанных идей, вот один из них.
1. Проект "Сказка в лесу" - чтобы по QR на фигуре в парке можно было перейти на сайт и получить информацию по герою сказке, а также послушать аудиверсию, посмотреть сказку на ютуб и почитать прям в лесу.
Получилось вот так: https://lyumih.github.io/milis/skazka/-/#!skazka=heroes/heroes=vasilisa и репозиторий с проектом https://github.com/Lyumih/milis/tree/main/skazka из 3 файлов (весь сайт).
41 строка view.tree и 74 строк view.ts - из которых 17 строк - заглушка JSON на тот момент.
Ещё $mol очень интересен как российский опен соурс проект - давно хотел поучавствовать в подобной разработке, но в больших американских react/vuev/angular проектах не нашёл, чтобы улучшить без гемморая. А тут всё понятно - компоненты минимальные и общение всё идёт на русском языке
просто факт - заметил, что у сторонников $mol/view.tree есть некоторые систематические проблемы с орфографией/грамматикой. интересно, это случайность или закономерность?
Почему шаблоны в $mol такие странные?