Comments 36
Преимущества:
👨💻 Максимальная оптимизация под использование нативных браузерных средств разработки.
🔮 Простое и быстрое тестирование в изолированных контекстах благодаря ленивой архитектуре.
🔌 Разумные универсальные соглашения вместо развесистых однотипных конфигураций.
🤏 Малые размеры бандлов даже без tree-shaking.
🍇 Микромодульная архитектура без выделенного ядра.
📦 Автоматическое детектирование, скачивание и обновление зависимостей.
🌌 Изоморфный код, запускающийся на: NodeJS, Web browsers, Cordova.
📺 Уникальная автоматическая виртуализация рендеринга для максимальной отзывчивости.
🎨 Богатая библиотека стандартных виджетов и легко интегрируемых приложений.
📚 Простая локализация из коробки с автогенерируемыми человеко-понятными ключами.
🎠 Все виджеты полностью самодостаточные, но при этом полностью управляемые.
🎎 Беспрецедентная кастомизируемость компоновки, поведения и оформления любых виджетов.
🧩 Любой виджет может быть зарегистрирован как Web Component.
Система реактивности $mol_wire:
🚀 Ленивость и реактивность на всех уровнях абстракций, а не только между View и Model.
🎢 Автоматическая оптимизация потоков данных, без ручных подписок/отписок.
⏰ Автоматический контроль времени жизни различных ресурсов.
🔱 Полная поддержка SuspenseAPI на всех уровнях, позволяющая писать синхронный, но неблокирующий код.
🆔 Глобально уникальные, но человеко-понятные идентификаторы всех объектов.
Каскадная стилизация $mol_style:
🤿 Типизация стилей с учётом глубокой иерархии компонент.
🏰 Автоматическая генерация фрактальных BEM-атрибутов.
🤼 Нет борьбы со специфичностью селекторов.
🥇 Первый фреймворк полностью написанный на TS.
🧤 Богатая библиотека утилитарных типов $mol_type.
🎶 Богатая библиотека рантайм валидации, нормализации и типизации данных $mol_data.
Недостатки:
О нём вечно забывают в таких вот подборках.
А локализация только простая? Без подстановки значений и плюрализации?
Агась. Фреймворк предоставляет лишь инфраструктуру для получения строк на разных языках. Вопросы поддержки микроразметки в них отданы на откуп прикладному коду, так как пока не придумано универсального решения для склонений, падежей, числительных и их произвольной комбинации в рамках одного текста. Но все это как правило и не требуется, ибо для пользователя же лучше переформулировать текст так, чтобы вариативности не было и ему не приходилось каждый раз в него вчитываться.
так как пока не придумано универсального решения для склонений, падежей, числительных и их произвольной комбинации в рамках одного текста.
LLM довольно неплохо с этим справляются.
А зачем прям такая универсализация? Для задач локализации в большинстве случаев вполне достаточно подстановки чисел в строку и возможности выбора нужного варианта слова по числу. Условно говоря:
"{count} {count|order|orders} processed"
"{count|Обработан|Обработано|Обработано} {count} {count|заказ|заказа|заказов}"В большинстве случаев никакая плюрализация и не нужна: "обработано задач: 1".
А у вас при 10 типах сущностей и 10 типах действий происходит комбинаторный взрыв.
«Обработано задач: 1» — это унылая канцелярщина. А комбинаторного взрыва в реальных приложениях я не наблюдал. В крайнем случае можно написать «Обработано {counted_items}» и подставлять в неё отформатированную строку типа «5 задач», которая получается по описанному выше принципу.
Ну а я наблюдал до чего доводит эта погоня за плюрализмом - пользователь не может быстро считывать информацию, десяток переводчиков переводят кучу текстов.
Так и в вашем фреймворке возможно порождение множества одинаковых строк, поскольку на каждое вхождение строки создаётся отдельный ключ в файле локали.
Что касается плохих текстов, так запрет на подстановку переменных сам по себе от них не спасёт. С другой стороны, инлайновые строки дадут соблазн использовать конкатенацию, что чаще всего неправильно.
В любом случае, философия «я не буду класть в набор инструментов молоток, потому что он может ударить себя по пальцу, пусть купит себе отдельно» выглядит не очень.
да сколько можно уже а
Пока вы не поумнеете.
Я уважаю вашу продуктивность, честно. Уважаю за вклад в веб-разработку
Но, хоть убейте, я не понимаю - чем $mol может быть удобнее того же React / Vue
В React / Vue синтаксис понятный, человекочитаемый, легаси код легко поддерживать
+ у React / Vue развитое сообщество, в котором разработчики все болячки уже обсосали
Не в обиду. Просто мысли вслух
Работал с nuxt полтора года назад. На тот момент он был довольно глючным и не шибко быстрым. Но вроде для vue нет особо альтернатив.
Мне для SSR понравилась пара Vue + Vike, Nuxt использовала для Vue 2 - неплохо работал, но Nuxt 3 сильно не понравился именно из-за сырого релиза
Связку Vue+Vike считаю лучшей. Сам Vike по сути просто скелет для SSR приложения, он не навязывает тебе свои паттерны. Проектируй приложение как хочешь, просто придерживайся определенных правил.
Хочешь полный SSR? Держи!
Хочешь гибридный SSR? Пожалуйста!
Хочешь SSG? Да не вопрос!
И вот в этом его огромное преимущество, тебя не загоняют в рамки, где если отошёл от канонов - расстрел (привет NextJS). Да это накладывает опр риски, ведь с NextJS нельзя построить неправильную архитектуру, ведь ее уже построили для тебя. Для новичков это плюс, но для сторожил иногда это реальная боль.
Лично у меня в приоритетах Vue + Astro. Это если для SSR. Для фронта хватает чисто Vue, для бэка - ноды. Если же использовать ИИ для программирования, то чем проще и ближе к основам (HTML/CSS/JS) - тем лучше. Там уже и Vue многовато.
Astro же не на SSR, а на SSG ориентирован. Их острова и т.д., нормально себя показывают лишь в SSG формате.
При SSR острова теряют смысл, т.к. рендеришь на сервере и отдаешь на фронт, а там гидрейтишь. В общем стандартная SSR история для которой Astro используется, лишь для того чтобы его использовать
Да, вы правы. Но я не слишком строго отношусь к различию между SSR & SSG, т.к. я больше по PWA/SPA, а SSR/G - это от безысходности :) Поисковики с PWA/SPA плохо в силу принципиальной невозможности хорошо.
Поисковики с PWA/SPA плохо в силу принципиальной невозможности хорошо.
Это неправда
С Гуглом полностью, с Яндексом - частично
Если вы сделаете сайт, типа библиотеки Максима Мошкова, в виде SPA, то - да, поисковики его проиндексируют. Но зачем делать библиотеку в виде SPA? Есть смысл делать в виде SPA фитнес-трекер типа Runkeeper или Endomondo, но зачем его делать индексируемым? Это всё равно, что делать индексируемым банковское приложение.
Я согласен, что вы можете сделать SPA, которое будет успешно проиндексировано Гуглом. Но вот лично я бы не стал этого делать.
А что за интеграция такая с Vercel такая что невозможно на обычном хостинге запустить?
Я что-то пропустил в мире фронтенда видимо
Какие-то вебсокеты с закрытыми протоколами? Что там происхоит вообще?
Fusor - это как низкоуровневый React но проще.
Javascript не ограничивается фронтендом, а указанные в статье библиотеки нацелены лишь на него. Так и написали бы в заголовке, что речь только о фронте.
Привет автор.
Статья конечно интересная и узнавать что-то новое это всегда хорошо.
Вообще хочется сказать какие-то общие вещи которые автор в пылу страсти поделиться знаниямми либо не заметил, либо забыл.
Начну с того что как я и говорил выше учить новое это хорошо и полезно, но опыт многих программистов показывает. Первое что в одиночку программирует небольшое количество человек и то какие-то незначительные малые проекты. Второе, если программировать командой то это как минимум стартап, а как минимум компания не малых размеров. Стартапы я опущу, а вот про компании скажу что у большинства компаний уже имеется наработанный стек технологий которые они используют в данный момент.
По этой причине программисту работающиму на эту помпанию (или тому кто захочет в компании работать) учить то что использует эта компания. Причин для изучения того что использует компания есть несколько. Одна это причина что есть определённый код написанный на определённых фреймах и его нужно поддерживать. Другое это все в компании знают только те фреймворки и технологии которые использует компания (по крайней мере даже если кто-то что-то и знает другте то без разрешения компании ему это в компании использовать не позволят).
Исходя из вышесказанного изучать намного больше и новее чем используется в работе сейчас просто не получиться. Во первых нужно хорошо знать то что уже используешь и второе паралельно новое учить долго так как времени на практику либо нет, либо мало и много знаний в одной голове удержать тоже не получиться (даже если это будут знания по ссылкам из интернета или записи в компьютере так как всегда будешь путаться между тем что используешь и тем что изучаешь).
В конце добавлю своё мнение.
Я считаю что хорошим вариантом постепенно учить чистые языки программирования, в данном случае JavaScript. Это во первых позволит делать те веш=щи которые нужно быстрее и правильнее, ну и фреймфорки могут не понадобиться. Во сторых если изучить основу то в любом случае большинтво фреймворков будет легче изучать если они основаны на JavaScript и сильно от него не отступают (это в случае если нужно изучить что-то новое).
Это база! Абсолютно согласен с вами! Понимание работы на чистом JS добавляет опыта в работе и некой универсальности специалиста.
У меня ситуация обратная: я имея опыт React JS устроился в компанию которая работает на чистом js. И это позволило мне глубже понять как работает js и я в этом нашел кайф в своей работе.
у большинства компаний уже имеется наработанный стек технологий
Вы же это про jQuery сейчас? Согласен, он настолько распространён, что притянуть в проект, что-то отличное от jQuery UI нет абсолютно никаких шансов.
Эх, новые фреймворки это конечно хорошо. Тот же svelte - прикольный. Жаль, что затащить их в продакшн - в принципе не возможно в крупных компаниях.
Svelte поэтому и не популярен уже столько лет. У него совершенно другой синтаксис, отличный от чистого JS и других фреймворков.
Чего не скажешь например о SolidJS, я могу затащить его в продакшн не опасаясь, что с ним никто не разберётся, т.к. любой реакт-разработчик довольно быстро вкатится, ведь принципы очень похожи, по сути только хуки по другому называются. Конечно, там есть более глубокие различия, но это не сильно помешает другому быстро вкатиться
На данный момент, я считаю, самый перспективный это именно SolidJS. Из-за схожего с реактом синтаксиса, своей скорости и при этом довольно небольших размеров. Плюс он опирается на ведущие решения в JS-отрасли, такие как сигналы например. Он не развивающийся, ведь в нем уже есть все, что есть у конкурентов, кроме сторонних библиотек, хотя и тут под каждую задачу ты в любом случае найдешь решение
Не пойму, все таки стоит изучать новый фреймворк если есть React и знаешь его. Наверное неплохо знать несколько, но я все таки думаю лучше уж знать один и досконально. Все его возможности. А знать с десяток, но поверхностно это такое себе....
Когда год назад пришло время выбирать (после многих лет в фронт HTML/CSS/PHP/JS),
то выбор стоял между SvelteKit и Nuxt.js и React.
React отпал по причине отвращения к Facebook, Meta и всему что с ними связано.
Nuxt.js понравился, но когда тестил Nuxt3 столкнулся с проблемой что много документации написано о Nuxt2 и в Nuxt3 уже не работает. И вообще иногда кажется сыроватым.
SvelteKit завоевал своё доверие очень быстро. Все более менее просто и интуитивно. Переход с html/css/js был лёгким. Файловый роутинг похож на Nuxt.
Надеюсь скоро допишу свой первый коммерческий проект используя SvelteKit.
Но судя по тому что у меня получается на данный момент, это очень перспективно по красоте и быстродействию.
И ещё поисковики очень любят SSR и SSG
Remix переехал в React Router 7
JavaScript-фреймворки и библиотеки, на которые стоит обратить внимание в 2025 году