В документации к фреймворку нет фотографии автора, там другое изображение. Фотография автора на его личной странице, у вас тоже может быть там личная страница со своей фотографией или любым другим своим изображением.
И да, на правой панели снизу есть кнопка для включения/отключения фона.
Сам я познакомился с $mol пару лет назад, когда узнал про формат tree, вдохновился им и захотел сделать реализацию на питоне. После чего стал читать разные статьи и смотреть примеры. Чем больше я погружался в фреймворк, тем больше влюблялся в него.
Очень жаль, что почти все вокруг так пренебрежительно относятся к фреймворку и его автору, даже не разобравшись что к чему: «не буду использовать $mol, там непривычный нейминг, странные шаблоны, токсичный автор». Такие люди просто не смотрят дальше своего носа.
Вы меня очень вдохновили, я стал иначе смотреть на разработку и многие вещи по-другому, можно даже сказать, моя жизнь в каком-то смысле поменялась, когда я познакомился с Вами и Вашим творчеством, за что безмерно Вам благодарен.
Вам желаю крепких нервов, большого здоровья и сил продолжать работать над тем, над чем ведется работа. Фреймворку желаю дальнейшего развития, а Красу скорейшего релиза.
Исходя из личного опыта, я все же убежден, что виноват не синтаксис, а нежелание людей пробовать что-то новое и необычное.
Вот смотрите, моя основная специальность - бекенд-разработчик, я не считаю себя фронтендером. Ранее пробовал реакт и свелт для своих проектов, прежде чем познакомился с $mol. Я прочитал разные статьи от Дмитрия Карловского про его фреймворк, после чего вдохновился попробовать.
Основы синтаксиса можно изучить, ну, правда, за один подход. Смотрите:
И... всё. Не понятно как работает тот или иной код view.tree? Идем сюда, вставляем непонятный кусок и смотрим, во что он генерируется.
То есть, что получается? Какой-то бекенд-разработчик смог разобраться в ужасном синтаксисе в чужеродной среде (я сейчас про фронтенд, если что), а сами фронтендеры ну прям не могут, как бы ни старались? Может... а хотя нет, бред какой-то...
Они открывают это, плюются и закрывают
Вот да, тут нет этапа «попробовали разобраться».
простой вопрос - будь это правильно поданное решение люди бы уходили? вероятно нет - они бы как минимум пробовали писать на этом
Много людей не скрывают того, что не пробовали $mol только из-за токсичности автора, что не может меня не забавлять) Это называется «ежики плакали, кололись, но продолжали есть кактус», когда у них есть возможность попробовать что-то крутое, но препятствием стало даже не что-то техническое.
Возможно $mol и правда слаб в маркетинговой части, чтобы суметь его "правильно подать", но это не делает его технически хуже. И view.tree тоже не делает его технически хуже, если фразой "правильно подать" вы имели ввиду именно внешний вид синтаксиса. Вовсе нет, в нем просто нет ничего лишнего, ему не нужны кейворды, делающие его "интуитивно понятным", в нем есть только то, что ему нужно, всё.
Он не читаемый и не поддерживаемый даже на малых проектах.
Вот это уже не правда. У меня свой проект на моле, не путаюсь в исходниках, и я без особых проблем читаю код из репозиториев hyoo. Не понятно, из чего вы сделали такой вывод.
Будь это не так, фреймворк уже давно бы занял хоть какую-то часть рынка, хотя бы в рф
Как раз таки озвученные выше проблемы и не дают ему пробиться наверх:
Кто-то не желает его использовать из-за токсичности автора
Кто-то не желает менять свои подходы
Мне же не составило труда разобраться во всей экосистеме, и даже поделать туда PR (хотя напомню - я бекенд-разработчик). И да, я считаю формат view.tree особенным, и даже... гениальным? Чем больше с ним работаю, тем больше меня не покидает эта мысль.
Не призываю бросить всё и схватиться на $mol. Просто попробуйте разобраться... Не понравится - сделаете свои выводы, возможно предложите какие-то улучшения, и продолжите пользоваться своим.
А что вы хотели услышать? Фреймворк $mol сам по себе это другой подход, зачем переделывать инновационный фреймворк в "очередной"? Любое нестандартное решение в моле аргументируется с технической точки зрения. Технической, а не маркетинговой.
Вы задали вопрос, почему бы не изменить подход в обмен на новых разработчиков. Ну а как насчет того, чтобы другие разработчики немного вышли из той зоны, которая им кажется комфортной, изменили свои подходы, и попробовали настоящий комфорт?
В любом случае, их никто не заставляет. Просто есть возможность узнать, как можно иначе, и попробовать.
Для SQLite нет места в вебе, он нужен для однопользовательских приложений (десктопные программы или мобильные приложения, например), а для многопользовательских нужно брать что-то по-серьезнее, например, PostgreSQL или MySQL/MariaDB.
Вангую аргументы по типу «для примера сойдет», «когда пользователей немного - самое оно», поэтому сразу привожу контраргументы:
1. Для примера не сойдет, поскольку эта статья, судя по всему, рассчитана на новичков, которые будут брать эту СУБД в каждый свой проект, зачем учить людей "бэд прэктисам"? Ничего не стоит показать подключение к более подходящей к этой задаче СУБД. К тому же, зачем учиться на SQLite, когда можно сразу учиться на нормальной клиент-серверной СУБД? Зачем учиться на SQLite, если бекенд-разработчик все равно не будет его использовать на работе? Порог входа не то чтобы прям сильно выше, чтобы выбор пал на SQLite. 2. SQLite конечно будет работать и когда пользователей не мало, но что стоит запустить тот же Постгрес? Я понимаю, если бы это было платно, но нет же, да и с докером (для тех же "учебных целей") это делается одной командой, да даже без докера это делается минут за 5. "В подарок" мы получаем большое количество фич и преимуществ, которые в SQLite недоступны.
Так что нет, это не выглядит "прям идеальным вариантом".
Sqlite, глобалы, "паттерн репозиторий" (лол) на классметодах. Это попытка заменить уже существующий официальный, и также далеко не идеальный, туториал FastAPI из документации? Плохая попытка. Новички прочитают эту статью, научатся неправильным вещам, и будут потом писать также неправильно. Для прошаренных статья также бесполезна, так на кого она рассчитана?
Достаточно только посмотреть на качество написанной для Python библиотеки, и станет ясно, зачем писать свое
В документации к фреймворку нет фотографии автора, там другое изображение. Фотография автора на его личной странице, у вас тоже может быть там личная страница со своей фотографией или любым другим своим изображением.
И да, на правой панели снизу есть кнопка для включения/отключения фона.
Дмитрий, спасибо за прекрасную статью!
Сам я познакомился с $mol пару лет назад, когда узнал про формат tree, вдохновился им и захотел сделать реализацию на питоне. После чего стал читать разные статьи и смотреть примеры. Чем больше я погружался в фреймворк, тем больше влюблялся в него.
Очень жаль, что почти все вокруг так пренебрежительно относятся к фреймворку и его автору, даже не разобравшись что к чему: «не буду использовать $mol, там непривычный нейминг, странные шаблоны, токсичный автор». Такие люди просто не смотрят дальше своего носа.
Вы меня очень вдохновили, я стал иначе смотреть на разработку и многие вещи по-другому, можно даже сказать, моя жизнь в каком-то смысле поменялась, когда я познакомился с Вами и Вашим творчеством, за что безмерно Вам благодарен.
Вам желаю крепких нервов, большого здоровья и сил продолжать работать над тем, над чем ведется работа. Фреймворку желаю дальнейшего развития, а Красу скорейшего релиза.
Не сдавайтесь!)
Исходя из личного опыта, я все же убежден, что виноват не синтаксис, а нежелание людей пробовать что-то новое и необычное.
Вот смотрите, моя основная специальность - бекенд-разработчик, я не считаю себя фронтендером. Ранее пробовал реакт и свелт для своих проектов, прежде чем познакомился с $mol. Я прочитал разные статьи от Дмитрия Карловского про его фреймворк, после чего вдохновился попробовать.
Основы синтаксиса можно изучить, ну, правда, за один подход. Смотрите:
Быстрое введение в синтаксис view.tree
Чуть более подробно про синтаксис view.tree
Еще есть о том, как бы в моле жилось без view.tree, и как он упрощает разработку.
И... всё. Не понятно как работает тот или иной код view.tree? Идем сюда, вставляем непонятный кусок и смотрим, во что он генерируется.
То есть, что получается? Какой-то бекенд-разработчик смог разобраться в ужасном синтаксисе в чужеродной среде (я сейчас про фронтенд, если что), а сами фронтендеры ну прям не могут, как бы ни старались? Может... а хотя нет, бред какой-то...
Вот да, тут нет этапа «попробовали разобраться».
Много людей не скрывают того, что не пробовали $mol только из-за токсичности автора, что не может меня не забавлять) Это называется «ежики плакали, кололись, но продолжали есть кактус», когда у них есть возможность попробовать что-то крутое, но препятствием стало даже не что-то техническое.
Возможно $mol и правда слаб в маркетинговой части, чтобы суметь его "правильно подать", но это не делает его технически хуже. И view.tree тоже не делает его технически хуже, если фразой "правильно подать" вы имели ввиду именно внешний вид синтаксиса. Вовсе нет, в нем просто нет ничего лишнего, ему не нужны кейворды, делающие его "интуитивно понятным", в нем есть только то, что ему нужно, всё.
Вот это уже не правда. У меня свой проект на моле, не путаюсь в исходниках, и я без особых проблем читаю код из репозиториев hyoo. Не понятно, из чего вы сделали такой вывод.
Как раз таки озвученные выше проблемы и не дают ему пробиться наверх:
Кто-то не желает его использовать из-за токсичности автора
Кто-то не желает менять свои подходы
Мне же не составило труда разобраться во всей экосистеме, и даже поделать туда PR (хотя напомню - я бекенд-разработчик). И да, я считаю формат view.tree особенным, и даже... гениальным? Чем больше с ним работаю, тем больше меня не покидает эта мысль.
Не призываю бросить всё и схватиться на $mol. Просто попробуйте разобраться... Не понравится - сделаете свои выводы, возможно предложите какие-то улучшения, и продолжите пользоваться своим.
А что вы хотели услышать? Фреймворк $mol сам по себе это другой подход, зачем переделывать инновационный фреймворк в "очередной"? Любое нестандартное решение в моле аргументируется с технической точки зрения. Технической, а не маркетинговой.
Вы задали вопрос, почему бы не изменить подход в обмен на новых разработчиков. Ну а как насчет того, чтобы другие разработчики немного вышли из той зоны, которая им кажется комфортной, изменили свои подходы, и попробовали настоящий комфорт?
В любом случае, их никто не заставляет. Просто есть возможность узнать, как можно иначе, и попробовать.
Предложите что-то иное сами, если видите конкретные проблемы в синтаксисе. «Ненраица» - не конкретная проблема, «неасилил» - не конкретная проблема.
О том, почему был выбран такой синтаксис, а не другй, есть отдельная статья, кстати.
И да, язык простой, кто-то просто ленится потратить 5 минут на его изучение.
Для SQLite нет места в вебе, он нужен для однопользовательских приложений (десктопные программы или мобильные приложения, например), а для многопользовательских нужно брать что-то по-серьезнее, например, PostgreSQL или MySQL/MariaDB.
Вангую аргументы по типу «для примера сойдет», «когда пользователей немного - самое оно», поэтому сразу привожу контраргументы:
1. Для примера не сойдет, поскольку эта статья, судя по всему, рассчитана на новичков, которые будут брать эту СУБД в каждый свой проект, зачем учить людей "бэд прэктисам"? Ничего не стоит показать подключение к более подходящей к этой задаче СУБД. К тому же, зачем учиться на SQLite, когда можно сразу учиться на нормальной клиент-серверной СУБД? Зачем учиться на SQLite, если бекенд-разработчик все равно не будет его использовать на работе? Порог входа не то чтобы прям сильно выше, чтобы выбор пал на SQLite.
2. SQLite конечно будет работать и когда пользователей не мало, но что стоит запустить тот же Постгрес? Я понимаю, если бы это было платно, но нет же, да и с докером (для тех же "учебных целей") это делается одной командой, да даже без докера это делается минут за 5. "В подарок" мы получаем большое количество фич и преимуществ, которые в SQLite недоступны.
Так что нет, это не выглядит "прям идеальным вариантом".
Статья противопоказана для новичков.
Sqlite, глобалы, "паттерн репозиторий" (лол) на классметодах. Это попытка заменить уже существующий официальный, и также далеко не идеальный, туториал FastAPI из документации? Плохая попытка. Новички прочитают эту статью, научатся неправильным вещам, и будут потом писать также неправильно. Для прошаренных статья также бесполезна, так на кого она рассчитана?