Pull to refresh

Comments 20

Опять ни слова про $mol, ну да ладно.

Есть такая ментальная модель для написания кода и решения проблем – Make it work, make it right, make it fast.

А есть такая ментальная модель: Make it right and fast, then make next feature in the same way.

Компании хотят большой легкозаменяемый штат. И реакт прекрасно им с этим помогает.

Раян Карниато, создатель инструмента, потратил более 5 лет, пересобирая реактивные примитивы, чтобы добавить слой абстракции поверх ванильного javascript так, как если бы его не было.

JSX как-то совсем не похож на JS.

Все это помогает, например, решить проблему долгой регидрации приложения при серверном рендеринге.

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

Опять ни слова про $mol, ну да ладно.

Про $mol не поднялась рука написать, так как он выглядит слегка зубодробительно. В инфополе кроме текста о том что он решает большое кол-во проблем, ничего не заметно. А когда открываешь quick start, начинает рябить в глазах от обратных стрелок и знака доллара. Я может быть и рад разобраться что и как работает, но, насколько я понял, вы не готовы помогать комьюнити вливаться, не желая тратить на это время.

А есть такая ментальная модель: Make it right and fast, then make next feature in the same way.

Можно еще код сразу без багов писать)

JSX как-то совсем не похож на JS.

На solid, насколько мне известно, можно обычный js использовать, а jsx делает его похожим на реакт, опять же, все привыкли к компонентам реакта.

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

Да, так и живем, история циклична)

В инфополе кроме текста о том что он решает большое кол-во проблем, ничего не заметно.

Это ваш информационный пузырь. Выходите из него, в нём жизни нет. Как минимум стоит подписаться на новости и на видео канал.

А когда открываешь quick start, начинает рябить в глазах от обратных стрелок и знака доллара.

То есть от прямых стрелок и знаков доллара в jQuery у вас не рябит, а тут прям шоустопер? Вы кого такими сентенциями обмануть пытаетесь?

насколько я понял, вы не готовы помогать комьюнити вливаться, не желая тратить на это время.

А это вы откуда взяли?

Можно еще код сразу без багов писать)

Пока вы ёрничаете, среднее приложение на $mol на порядок меньше и быстрее среднего приложения на React при той же функциональности, и имеет на порядок меньше багов. Пруфы.

На solid, насколько мне известно

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

Вот тебе и 5 лет исследований стейт-менеджеров
Вот тебе и 5 лет исследований стейт-менеджеров

Это ваш информационный пузырь. Выходите из него, в нём жизни нет. Как минимум стоит подписаться на новости и на видео канал.

Ну так вы тоже в моем пузыре присутствуете) Вы сделали отличную работу по описанию реактивных систем, но это, к сожалению, последнее что я помню, что вы делали именно для комньюнити.

Вы же хотите привлечь людей на свою сторону, но почему-то концентрируетесь на хейте других инструментов и на тех разработчиках, которые уже определились, на каком инструменте им лучше работать. Но не рассматриваете молодых разработчиков, которые еще не определились и не доносите им пользу $mol, не проводите воркшопы и тд.

p.s. на канал подписался)

То есть от прямых стрелок и знаков доллара в jQuery у вас не рябит, а тут прям шоустопер? Вы кого такими сентенциями обмануть пытаетесь?

А мы обсуждаем инструменты 10ти летней давности?

А это вы откуда взяли?

Был на вашем выступлении. Вы это прямым текстом сказали https://youtu.be/ItqUPTi8JIw?t=2351

Пока вы ёрничаете, среднее приложение на $mol на порядок меньше и быстрее среднего приложения на React при той же функциональности, и имеет на порядок меньше багов. Пруфы.

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

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

А вы смотрите воркшопы конкурентов? Того же Раяна, любой jsx код может быть заменен нативным api.

Вы щупаете слона за хвост, утверждая, что видите его целиком и он похож на гадюку.

На этот канал, кстати, тоже подписывайтесь.

Пока вы ёрничаете, среднее приложение на $mol на порядок меньше и быстрее среднего приложения на React при той же функциональности, и имеет на порядок меньше багов. Пруфы.

Пруфы, которые ведут на Ваши выступления и посты? А есть обзор от независимых экспертов? Очевидно, что автор условного реакта напишет на реакте лучше и быстрее, чем на $mol. Неудивительно, что автор $mol пишет на нем быстрее и лучше, чем на реакте. Может я, конечно, не дочитал

 А есть обзор от независимых экспертов?

Странно задавать эти вопросы афиллированному лицу, не находите? Спрашивайте у этих ваших независимых экспертов, где же эти их независимые сравнения.

Очевидно, что автор условного реакта напишет на реакте лучше и быстрее, чем на $mol.

Ну раз вам всё очевидно, то можно и не проверять, так ведь?

Не, не нахожу. Вы пишете на $mol и постоянно хвалите что он быстрее, выше, сильнее.

Это, конечно, хорошо, но только что то никто на нём не пишет. Хороший проект давно бы уже нашёл свою нишу

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

Исходники открыты, никто вам не мешает развеять свои сомнения.

Фреймворки и прочее создают не для того чтобы копаться в их исходниках, а чтоб быстро взять и стартануть, легко решать проблемы за счет обширного комьюнити, а ваш $mol рокет сайс в котором никто не хочет копаться

Одно другому не мешает. Многие учились писать код на $mol, просто читая его исходники. Это не адская лапша, как у большой тройки.

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

$mol - не рокет саенс, там всё просто до безобразия, не выдумывайте.

Блин, да никому не нужен твой $mol. Соглашусь с автором в том, что нужно поменьше хейта в адрес других или вообще перестать упоминаться под каждой статьей в комментариях. Я считаю вы сами (своим поведением в частности) отталкиваете людей от своей технологии.

Спасибо за статью, интересно!

Я думаю, что в будущем подходы будут различные в зависимости от задач. Так,

  • enterprise - продолжит тяготеть к отдельным слоям и фреймворконезависимости. Т.к. я занимаюсь в основном этой сферой, то давно привык собирать приложения "по кубикам", которые не зависят от фреймворков (сборка, роутинг, хранилища, компоненты с адаптерами для разных рендереров, апи, сайд-эффекты, слои реакций и т.п.) - это обеспечивает максимальную гибкость и предотвращает устаревание. На первых этапах (MVP) как правило используется один из мета-фреймворков, но не надолго.

  • малый бизнес - продолжит пользоваться no-code решениями и готовыми CMS

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

А в целом тренд сейчас идет на расширение нативного HTML API - те же веб-компоненты и воркеры для вычислений (чтобы не блокировать основной тред), пропоузал добавления типов в JS. Они постепенно вытесняют компоненты конкретных фреймворков, а фреймворки добавляют их поддержку. Самая очевидная проблема (SSR), думаю, постепенно решится, и мета-фреймворки следующих поколений будут основаны на них. И, надеюсь, функциональные компоненты наконец уйдут в прошлое, уступив классовым)

Спасибо за комментарий!

Да, с этой точки зрения тоже интересно фантазировать на тему развития.

На счёт тренда согласен, кажется что веб стремится быть нативным насколько это возможно.

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

Сейчас да, сделать на них точечное обновление, ssr и нормальный проброс не только строковых значений - та еще задача. С массивами работать сложно, shadow dom концепт непростой... Проблем масса. Но как прототип для нативных кастомных элементов - пойдет. Мы же о будущем говорим, и я надеюсь что удобство jsx может придти и в стандарты

Я напомню, если вы проспали, текущая реализация веб компонентов уже вторая по счёту.

Да, заинтересовался веб-компонентами только пару месяцев назад, поизучал, уперся в ограничения и дальше дело не пошло. Вероятность, что из них выйдет что-то путное есть, как и вероятность, что они останутся глубоко нишевыми.

Ещё возможный путь - развитие wasm и webgpu в будущем приведёт к тому, что HTML/CSS/JS станут подключаемыми необязательными модулями, а самим браузером будет считаться комплекс "виртуальная машина + 3d движок + сеть". Хоть это в каком-то смысле откат назад, но дающий перспективу серьёзного расширения возможностей веба

Очень интересная статья, спасибо!)

Sign up to leave a comment.

Articles