private framework что это
Framework — это что? Простым языком о том, что такое фрейморк
Написали статью для новичков, чтобы рассказать, что это такое и какие виды framework-ов бывают.
Framework — это что?
Из этой статьи о framework вы узнаете:
Framework это что?
Фреймворк — это структура, на базе которой можно создать конечный продукт. Это проще, чем писать весь код с нуля.
Проведем аналогию с домом. Если вы хотите его построить, то можно закупить материалы и делать все самостоятельно, набивая шишки. А можно скачать в интернете готовый план постройки. Конечно, вы все еще можете набить шишки, когда будете клеить обои и выбирать мебель. Но, по крайней мере, фундамент, стены, крыша и канализационная система точно будут в порядке. Потому что то, как их строить, прописано в плане постройки.
Framework — это тот самый план постройки продукта для разработчиков.
Разница между CMS, фреймворками и написание кода с нуля
Разбираем на примере фронтенд-разработки. Предположим, вам нужно создать сайт. Есть 3 подхода, которые можно использовать: написать код с нуля, использовать framework или использовать CMS.
Что такое framework?
Framework — это набор шаблонов, заготовок. Каркас будущего проекта, на который разработчик может нанизывать дополнительные функции и фишки, которые нужны проекту.
Framework используют, потому что это удобно. Создавать проект проще, потому что у него уже есть структура. Разработчику остается пройтись по всем блокам кода, сопоставить их с техническим задание и сделать вывод, что и куда нужно добавить.
Плюсы использования framework
Минусы использования фреймворков
Популярные фронтенд фреймворки это
React.js — это framework на JavaScript. Его создал Facebook 7 лет назад, в 2013 году. Framework React.js обычно применяют чтобы проектировать интерфейсы, которыми будет пользоваться конечный клиент.
Хотите быстро и легко понять, как работает framework React.js? Запишитесь на консультацию к ментору!
Angular — framework для веб-разработчиков, который разработали в компании Google. Этот фреймворк обычно используют для создания динамических приложений. Он удобный благодаря открытому исходному коду и большому количеству внутренних возможностей.
Vue.js — framework, который разработал и выпустил в 2014 году сотрудник Google Эван Ю. У него также исходный открытый код и 89% разработчиков, который использует его, довольны.
JQuery — один из самых ранних framework. Он появился в далеком 2006 году. Этот framework неплохо подходит для создания небольших проектов, в которых не используется большое количество дополнительных элементов JavaScipt.
Антон Волков, CTO в Solvery:
React.js проще, быстрее и гибче конкурентов, потому что из коробки в нем меньше функционала. Это один из самых популярных фреймворков по фронтенду. Также популярен Angular. Он не такой гибкий, как React, и тяжелее его. Но в нем из коробки зашито больше функций, поэтому на Angular быстрее сделать готовый продукт. Соответственно, если вы не хотите думать о структуре и архитектуре проекта, то логичнее использовать Angular. К тому же, у него есть официальные подробные и качественный гайдлайны. А если важна гибкость, скорость загрузки и возможность вносить максимум изменений — выбирайте React.
Новичкам логичнее начинать с Angular, чтобы допускать меньше глупых ошибок. Но в целом ничего не мешает идти наоборот. Главное не гнаться за популярными молодми технологиями. Часто в новых фреймворках обещают кучу плюшек. Но часто они менее гибкие, чем их классические «товарищи». Чем больше всего загружено во фреймворк из коробки, тем больше шанс, что продукт в каком-то смысле станет заложником технологии.
Популярные бэкэнд framework
Laravel — один из самых популярных бэкенд framework для языка программирования PHP. Его выпустил американский разработчик Тэйлор Отвел в 2011 году. Framework регулярно обновляется. У него открытый исходный код. И много удобных инструментов для решения стандартизированных задач.
Хотите быстро и легко понять, как работает framework Laravel? Запишитесь на консультацию к ментору-специалисту, который объяснит вам все детали работы framework!
Flask — молодой framework от австрийского разработчика Армина Ронахера. Flask часто относят к категории микрофреймворков. Это значит, что в нем присутствуют только самые базовые конструкции.
Express.js — самый популярный framework для разработки Node.js приложений. Его используют в создании программ для смартфонов и веб-сайтов.
Популярные мобильные framework
Flutter — самый популярный мобильный framework для Android от создателя самого Android — компании Google.
Станьте специалистом по Flutter и напишите свое первое приложение для Android с помощью ментора!
Ionic — один из самых популярных Android framework с открытым исходным кодом. Его структура похожа на структуру фронтенд framework-ов. Ionic может работать совместно с Angular и React.
AFNetworking или Alamofire — фреймворки Objective-C и Swift, соответственно. Они помогают упростить работу мобильных приложений на IOS с сетью.
Популярные Python фреймворки
Django — этот framework был выпущен в далеком 2005 году. Он заточен под быструю и эффективную разработку. Очень практичный фреймворк.
Pyramid — фреймворк Pyramid представили в 2010 году.
Исчезающие фреймворки
Почему мы используем фреймворки? Angular, React и Vue помогают нам строить сложные веб-приложения: структурировать код, управлять состоянием и разрабатывать сложные интерфейсы. За последнее десятилетие фреймворки стали стандартом. Дорогим стандартом. С тех пор как фреймворки вошли в обиход, JS сильно раздуло. Страниц весом несколько мегабайт становится больше, и существенная часть этого объема — фреймворк сам по себе. Кажется, это немного, но для пользователя критично — на телефоне или слабом интернете страница может даже не загрузиться. Это проблема.
Кроме лишнего веса у классических фреймворков много других минусов и они подходят не для всех проектов. Эти проблемы решены в «исчезающих фреймворках». Что это за новый тренд, почему это не «еще один JS-фреймворк», а хорошая идея и как таинственные фреймворки могут улучшить наши приложения, расскажет Павел Малышев.
О спикере: Павел Малышев (PaulMaly) — fullstack со стажем больше 10 лет. Работает в компании Mustlab, которая занимается аутсорсингом веб, Smart TV и мобильных устройств, а также IoT. Евангелист фреймворка Svelte JS в России, ведет Telegram-группу на эту тему.
Чего не должно быть в докладе
Когда я обдумывал этот рассказ, решил, что он должен быть нестандартным. Поэтому я выписал то, чего здесь быть не должно. Не будет акцента на конкретный фреймворк, сравнения с другими фреймворками – они всем надоели, и, конечно, мне не хочется быть Капитаном Очевидность. Всего этого не должно было быть в моем рассказе, но, к сожалению, будет…
Когда вы прочитали название, наверное, подумали, что появился еще один фреймворк, а их и так целый зоопарк.
Мне кажется, если появляется новый фреймворк, значит, старые не удовлетворяют какие-то наши потребности. Возможно, сами потребности меняются со временем, и именно поэтому нам нужны новые решения — более эффективные и интересные. Поэтому прошу вас подойти к изложенному с этой точки зрения непредвзято и посмотреть на исчезающие фреймворки, как на новый инструмент, который, возможно, поможет в вашей работе.
Для начала разберемся, кто есть кто.
Кто есть кто
Я взял большую тройку и Svelte. Интересно то, что каждый инструмент характеризует себя по-разному. Angular позиционирует себя, как фреймворк на все случаи жизни, «все в коробке». React мимикрирует под библиотеку: «Я такой маленький, как библиотека», но вместе со всей инфраструктурой это тоже полноценный фреймворк. Vue — якобы прогрессивный фреймворк. Вы можете переходить на него с jQuery последовательно перенося код, начиная чуть ли не с обычного тэга script без сборщиков. Svelte — магически исчезающий фреймворк. WAT?
Давайте разбираться, о чем это я вообще.
Почему фреймворки стали исчезать?
Мы отправляем слишком много кода нашим пользователям.
Наши клиенты становятся более мобильными, но технологии интернета не везде хороши — даже 3G есть не везде, не говоря про LTE. Нам надо сокращать размер кода.
На эту тему есть интересное исследование от 2017 года, которое показывает, что если в ваше приложении много JS, то вы можете поставить лишь 130 Kb, чтобы пользователь был доволен. Если JS мало, то до 170Kb. Такая разница обусловлена тем, что в исследовании учитывалось, что JS отличается от других видов ресурсов, его надо распарсить, интерпретировать и прочее.
В исследовании 130 Kb — это не только JS, а вообще все, включая CSS, HTML, конечно, без картинок. При этом один Angular весит 143 Kb, а мы еще даже не написали ни одной строчки кода. Посмотрим, что нам предлагают текущие решения.
Производительность
В принципе, любой классический фреймворк — это абстракция над платформой, которая позволяет нам писать на более удобных уровнях. Это плохо тем, что любая абстракция несет некоторые издержки, в том числе, и по производительности.
Мы несем дополнительные издержки из-за лишних абстракций между нашим кодом и браузером.
Фишка исчезающих фреймворков в том, что они убирают лишние абстракции и вычисления из рантайма браузера, производя анализ и расчеты в момент компиляции. Исчезают они именно поэтому. Об этом поговорим подробнее чуть ниже.
Совместимость
Решения, которые написаны для классического фреймворка, нельзя применить где угодно.
Они работают только в рамках этого фреймворка. Например, вы делаете 2-3 проекта на своем любимом React, написали для него кучу классных решений, а потом решили переехать на Angular. Эти решения вам больше не нужны, их можно выкинуть. Хотя основная идея — соответствие компонентов, классические фреймворки лишают нас возможности переиспользования кода.
Фишка исчезающих фреймворков в том, что у них нет никаких абстракций, и в этом случае нет никакого фреймворка в рантайме. Ваш код — это абсолютно ванильный JS, который можно унести куда угодно — в любой проект даже на другом фреймворке. Например, можно взять код на исчезающем фреймворке и перенести его на React.
Code splitting & tree shaking
Старые технологии мешают применять новые технологии.
Большинство фреймворков создавались когда эти технологии не так были развиты. Мы имеем достаточно монолитное ядро, и любой компонент, даже минимальный кусочек вашего кода завязан на весь фреймворк. Соответственно, эффективно делать code splitting и даже tree shaking не получается.
Сейчас все фреймворки развиваются в сторону большей модульности, чтобы «трястись» лучше. В исчезающих фреймворках это решено из коробки, потому что они сделаны так, что в бандл добавляется только тот код, который вам нужен изначально, и он решает исключительно вашу задачу. Это очень конкретный кейс — как будто вы ровно для своей задачи написали код руками и засунули его в бандл, только это за вас делает фреймворк.
Feature cost
Любой фреймворк имеет цену новой фичи.
Сообщество требует разных новых фич и каждый участник — что-то свое, а любая фича имеет свою цену. В исчезающих фреймворках эта проблема решена на уровне концепции, потому что любая фича, которую вы не используете, никогда не попадет к вам в бандл.
Итак, главный вопрос: могут ли исчезающие фреймворки, и конкретно Svelte, решить все эти проблемы? Давайте разбираться.
Бе з с рантайма
Рантайм — достаточно эфемерная тема. Не совсем понятно, что это такое, и разные люди понимают это по-разному. В данном контексте я буду говорить о рантайме с точки зрения двух аспектов: окружения, в котором выполняется код и непосредственно исполнения кода.
Runtime как окружение
Разберемся на примере. Если код написан на Vanilla, то единственный рантайм, который нужен — это DOM. Если код написан на React, то нужен другой рантайм: DOM, React и React DOM.
Любой, самый маленький компонент вашего кода в React будет зависеть от того, в каком окружении работает ваш фреймворк, то есть от рантайма.
Runtime как исполнение кода
Второй момент — рантайм с точки зрения исполнения кода во время работы. Рассмотрим базовый на сегодня кейс рантайма для фронтенда — виртуальный DOM — большой кусок рантайма, например, в React-приложениях, — на простом примере:
В этом куске HTML есть динамическая переменная. С точки зрения виртуального DOM код работает так.
Виртуальный DOM — это абсолютный overhead, потому что всегда будет быстрее так: как только произошли изменения, сразу сделали изменения в DOM.
Вопрос: как понять, что изменилось и что нужно изменить? Виртуальный DOM решает вопрос того, что изменилось, а не скорости этих изменений. Скорость достигается за счет того, что мы максимально хорошо знаем, что изменилось, и можем эффективно манипулировать с DOM.
Скомпилируй это
Чтобы решить этот вопрос, исчезающие фреймворки просто определяют изменения на этапе компиляции: вы написали код, во время компиляции исчезающий фреймворк строит все зависимости, вычисляет, какие манипуляции в DOM нужны. Фактически все, что делает виртуальный DOM в рантайме, исчезающий фреймворк делает в билд-тайме: генерирует прямые манипуляции с DOM, которые просто вызываются во время рантайма. В результате получается схема: когда мы делаем изменения, сразу же идет манипуляция в DOM.
You can’t write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.
Rich Harris, создатель Svelte
Расскажу, как я познакомился со Svelte. У нас был интересный проект — виджет для вставки на неограниченное количество сайтов, при этом мы не знаем, какие это сайты, на каких устройствах пользователь будет их открывать. Виджет должен быть очень маленьким по размеру и очень быстрым по скорости. Естественно, когда мы взялись за эту задачу, сразу поняли, что делать на React или даже на Vue не вариант, потому что получается достаточно много лишних накладных расходов.
Мы практически склонились написать на Vanilla, но это сложно и не всегда удобно поддерживать. Но нам повезло — мы наткнулись на Svelte. Основная идея этого фреймворка приведена в цитате: вы не можете написать серьезное приложение на Vanilla, потому что очень быстро упретесь в стену сложности — команде будет сложно работать, нет общих подходов, а компилятор может сделать это за вас.
Как это работает
Исходный код — это framework-based code — код, который зависит от фреймворка. Все как обычно: есть некая документация, вы пишите код, как будто бы вы используете любой другой фреймворк, в котором есть какие-то API, принципы и подходы. Все как обычно.
Во время сборки этот код компилируется. В итоге в бандле лежит ванильный JS, причем, как я уже говорил, туда попадает ровно тот код, который необходим для исполнения конкретно вашего приложения. Если вы через две минуты допишите туда еще какую-то новую функцию или используете новую фичу из фреймворка, Svelte ее туда добавит, и она также попадет в бандл. В противном случае этого не произойдет.
Рассмотрим этапы поподробнее. Первый шаг — component. Рассмотрим тот же компонент.
На втором шаге — AST — код продуцируется в абстрактное синтаксическое дерево.
Третий шаг — DOM API. На основе дерева производится непосредственно генерация кода, который необходим для работы этого компонента. Код очень простой, никаких сложных рантаймов и абстракций здесь нет в принципе.
В конце статьи укажите в опросе, нравится ли вам идея AOT-компиляции фреймворка Svelte? В прошлый раз большинство высказалось положительно.
Теперь давайте посмотрим, что такое Svelte.
Svelte
Английское слово svelte или svelt, означает «стройный, гибкий». Svelte JS такой и есть!
Я утверждаю, что это не «Yet another JS framework», потому что это build-time UI framework. Обычные фреймворки работают в рантайме, а Svelte существует только до того, как мы его скомпилировали.
Это compile-time static analyzer, или статический анализатор кода, который во время компиляции проходит по коду, статически его анализирует и на основе этого генерирует соответствующий итоговый бандл.
Это ahead-of-time compiler — AOT-компилятор, который это все делает.
Создатель фреймворка Rich Harris, которого вы можете знать по таким инструментам, как Rollup, Ractive, Buble — аналога Babel — крутой чувак. На мой взгляд, тот же самый Rollup до сих пор остается лучшей реализацией tree-shaking. В нем он появился гораздо раньше, чем в Webpack, и до сих пор работает лучше. Harris изначально делал фреймворк Svelte с учетом tree-shaking, code splitting и других современных подходов.
Svelte — это средство, писать vanilla JS без необходимости писать на vanilla JS.
Давайте посмотрим на этот фреймворк изнутри.
Однофайловый компонент
Svelte — однофайловый компонент. Если вы работали с Vue, он вам будет очень напоминать этот фреймворк, но это неспроста. Синтаксис, который преимущественно используется в Vue, позаимствован из фреймворка Ractive, который тоже сделал Harris еще в 2012 году. Этот фреймворк, к сожалению, не стал популярным, мне кажется, потому что вышел в 1.0 слишком поздно. Они так замутили с версиями, что Ractive 6 лет был в минорных версиях.
Многие интерфейсы Vue оттуда позаимствовал, а Svelte — продолжатель Ractive. Поэтому вам будет казаться, что все похоже, но однофайловые компоненты появились в Ractive в 2013 году. Они выглядят чуть-чуть по-другому, но в целом — похоже. Любой компонент, который вы будете писать на Svelte, будет выглядеть примерно так.
Сверху некий HTML-шаблон — обычный HTML без каких-то исключений. Единственное, что на него сверху наворочен некий язык шаблонов, который называется HTMLx. Про него я расскажу подробней позже.
Дальше идет скрипт, в котором мы пишем поведение нашего компонента. Как его писать, описано в гайде. Там можно импортировать, делать разные функции и методы — все как во Vue.
Можно использовать scoped style, чтобы получить из коробки изолированные стили компонентов. Это работает так: в main-компиляции генерируется хэш, в итоге получается как бы эмуляция Shadow DOM.
Ни одна из секций не обязательна, поэтому компонент может состоять только из одного HTML.
Синтаксис HTMLx
Как и в любом HTML, в скобках записываются данные.
Так записываются условные операторы.
Перечисления и циклы:
Можно использовать директивы для отлавливания событий, для двойного биндинга данных.
В HTMLx очень мало директив — всего 4-5 видов, а кастомных директив, как в Angular, вообще нет.
Можно любые динамические данные засовывать в любые атрибуты, с этим проблем нет.
Изолированные стили и удаление неиспользованных
Если вы используете изолированные стили, то кроме того, что они изолируются, неиспользуемые стили еще вырезаются автоматически.
Композиция компонентов
Здесь все как обычно: импортируем файл, регистрируем его в компонентах, используем как тэг.
Дополнительные возможности Svelte
Первые две возможности: SSR & Hydration — серверный рендеринг и гидрация, и built-in state management — встроенное глобальное управление состоянием на основе собственного решения, так называемы store.
У store есть интересная особенность, которую я больше нигде не видел, — он распространяется глобально на одну иерархию компонентов. Если у вас, например, есть Root-компонент, он используется во всей этой иерархии. Если у вас появился другой store где-то внутри этой иерархии, то на всю нижнюю иерархию распространяется уже этот store.
Это удобно когда вы хотите сделать большой сложный компонент со множеством подкомпонентов, и дальше его использовать в разных проектах, в одних из которых есть Redux, а в других нет. Если вы используете обычные store с Redux, то вы должны убедиться, что в проекте, куда вы его добавляете, есть Redux. Здесь это не нужно делать — Svelte реализует свой собственный store для этой подиерархии. Его можно легко переносить даже в те проекты, где глобального store нет вообще. Вы занесли, а Svelte внутри себя уже все делает.
Custom elements поддерживаются из коробки. Есть специальный сайт на котором тестируется поддержка фреймворками стандарта Web Components. Согласно тестам Svelte имеет 100% поддержку кастомных элементов. Это работает так: указывается имя тэга, в компиляторе ставится флажок «customElement: true», и генерируется готовый к использованию кастомный элемент, который поддерживает все существующие возможности Svelte.
Sapper — Svelte app maker. Это аналог Next.js и Nuxt.js для Vue. В принципе все то же самое: изоморфность, поддержка code-splitting, prefetching и offline из коробки и другие фичи. По-моему, недавно даже часть идей роутинга вошла из Sapper в Next.js.
Но не один Svelte этим занимается. Мы за добросовестную конкуренцию!
Кто еще?
Stencil — это фреймворк от разработчиков Ionic. Они также работают над компилируемым фреймворком, но с большим уклоном именно на веб-компоненты и кастомные элементы. Svelte отличается от него, тем что его компоненты, как правило, принято компилировать в обычные JS классы и нет уклона в веб-компоненты.
Glimmer — думаю, все знают этот проект. Он здесь приведен только потому, что он тоже компилируется: у него свой байткод, своя виртуальная машина, очевидно дающая дополнительные оптимизации для итогового кода.
Marko от eBay. Подробно не изучал, но они тоже компилируют, не уверен, что настолько глубоко, как Svelte. Правда я и не разбирался подробно и могу ошибаться.
Angular. Здесь есть AOT-компилятор, и он хорошо промоутится, но это просто заранее перекомпилирование строковых шаблонов в уже готовый разобранный вид. Насколько я понимаю, полной AoT-компиляции там нет пока.
Hello movies
Я написал небольшое приложение — список фильмов с фильтрами на основе TMDb API. В нем есть категории: popular, top rated, upcoming. Можно походить по страничкам, выбрать страну, применить для нее фильтры, поменять язык. Это примитивное приложение занимает всего 6,4 Kb.
В общей сложности HELLO MOVIES — это всего 172 строчки кода вместе с HTML, из них 36 строчек JS-кода вместе со всякими кавычками. Это весь код который я написал лично. Естественно, все это компилируется в гораздо больший объем, но для меня, как для разработчика, это неважно.
Еще немного показателей. «TodoList MVC» на Svelte занимает 3,6 Kb — зависит от того, кто как пишет, но даже на Vanilla он занимает 11 Kb, а на Vue и React и того больше — по 80 и 300 Kb, соответственно. Проект «RealWorld», клон Medium, с регистрацией, аккаунтами, лайками, шэрами, френдами — 40 Kb, на React и Angular по 211 и 575 Kb. Клон «HackerNews» на Svelte — 30 Kb, на React и Vue — в несколько раз больше.
Бенчмарки
Все мы любим похоливарить на тему бенчмарков. Я использовал известный бенчмарк Krausest. Вы, наверное, думаете, что я сейчас покажу результаты, где Svelte просто всех рвет в клочья, а Inferno просто плачет в сторонке. Но этого не будет.
Я взял сравнение Svelte с большой тройкой — Angular, React и Vue в последних версиях. В итоге выделил две первых позиции относительно Vanilla. Причем здесь цифры не так важны, как основная идея, которая заключается в том, что Svelte очень сбалансирован.
Svelte стремится быть сбалансированным — он хорош по всем показателям в любых бенчмарках. По некоторым параметрам Svelte даже обгоняет Vanilla, по некоторым занимает первое, а где-то его обгоняет Vue и Angular. При этом во всех тестах Angular и Vue потребляют много памяти, а Svelte — нет. Он не стремится быть самым лучшым вообще везде, хотя он сопоставимо быстрый, потребляет мало памяти и имеет быстрый запуск. Основная суть — баланс.
Пока Svelte пока мало кто использует — это достаточно новый инструмент. Давайте посмотрим, где же он применяется.
Чик-чик — и в продакшн!
Автор Svelte работает в New York Times. Это достаточно большой продакшн. Конечно, не весь сайт сделан на Svelte, думаю, это большой legacy-проект с CMS, где все сделано прежде всего для редакторов. Многие интерактивные спецпроекты и виджеты, которые они помещают на странице, сделаны на этом фреймворке.
Например, интерактивный виджет-опрос по теме «Игры престолов» — с анимашками, с Drag&Drop. Этот виджет реализован как раз на Svelte, и таких примеров много.
Японская облачная платформа для игр Soft-Gear с достаточно сложной админкой, у которой я видел скриншоты, на Svelte. Я это знаю, потому что ее разработчик сидит у нас в Телеграм-чатике и мы с ним общаемся.
Интерфейс сервиса мультикастинга airca.st полностью сделан на Svelte. Редактор сервиса сторителлинга Dabble полностью на Svelte. Забавный сервис поиска электро-велосипедов поблизости i-want-to-ride-an-electric-citi с прикольными картами и анимашками тоже использует Svelte.
В заключение еще один наш кейс. Наверное, все знают RuTube. Сейчас мы сделали им обновление для Smart TV для платформ Tizen, в том числе Samsung. Их новое приложение для Tizen для Smart TV будет написано тоже на Svelte. Оно уже сейчас готовится к публикации, будет выглядеть примерно так.
Итого плюсы
Итоговый код standalone vanilla JavaScript без зависимостей. Он решает только те проблемы, которые вы решаете в своих компонентах, никакого overhead нет.
Небольшой размер и высокая производительность. В Svelte нет никаких абстракций между кодом и DOM. Здесь вообще минимум абстракций.
Низкий порог входа. Все говорят, что очень просто обучиться Vue, но изучить Svelte еще проще. У него простой гайд, отличный REPL, причем все ссылки с гайда идут на готовый пример, который можно потыкать и изменять.
Мощь статического анализа и компиляции из коробки. Хотя я считаю, что там работы еще много — и компилятор не идеален, и статический анализатор используется далеко не на полную катушку. Но это все зашито на уровне концепции, поэтому будет развиваться.
Code-splitting & tree-shaking. Опять же на уровне концепции решены проблемы с code-splitting и tree-shaking. Все компоненты и любую иерархию компоненты можно собрать отдельно. Это будут отдельные независимые модули, которые можно сочетать в любой последовательности и получать разные пакеты.
Micro-frontends ready. Это очень хорошо для микро-фронтендов. У нас даже есть небольшой опыт, когда на каждой странице, которая отдавалась с сервера с помощью обычного PHP, находилось полностью независимое Svelte-приложение. притом, что общая кодовая база была единая. Мы просто набирали из разных компонентов, для каждой страницы собирали отдельно и получали абсолютно независимые приложения. Даже внутри этих приложений можно независимо проводить code-splitting и tree-shaking.
Итого минусы
Svelte довольно молод, мало готовых решений. Первые релизы были в конце 2016 года. Но уже есть вторая версия и даже идут обсуждения третьей.
Непроверенный подход. В принципе, подход с перекомпиляцией всего и вся еще не до конца опробован в крупных проектах. Но мы уже года полтора его используем в продакшене. Конечно, есть проблемы, но не больше, чем в других фреймворках, которые мы использовали до этого, в том же самом Vue.
Нет поддержки корпораций. Если React поддерживает Facebook, Angular — Google, Vue кто только не поддерживает, то здесь проект держится на Rich Harris и команде майнтейнеров, которые вместе с ним работают и я рад быть частью этой команды.
Всего через неделю на Frontend Conf в рамках РИТ++ Павел Малышев пойдет дальше и расскажет, что делать, если хочется больше ванилы. И еще 33 отличных доклада по фронтенду будет на фестивале. Читайте здесь подробнее о темах и концепции и успевайте присоединиться к большой компании профессионалов на РИТ++ 27 и 28 мая.