Фреймворки без фреймворка: почему мы не подумали об этом раньше?

Вы не можете писать серьезные приложения на ванильном JavaScript. Но компилятор может сделать это за вас.

Этот новый фреймворк работает в рантайме? Фи. Спасибо, мне не надо. - фронтендеры 2018 года

Мы отправляем слишком много кода нашим пользователям. Как и многие разработчики фронтендеры, я отрицал этот факт, думая, что ничего страшного в лишних 100 КБ JavaScript нет и при загрузке страницы можно просто убрать один .jpg файлик- ведь в реальности, когда ваше приложение уже стало интерактивным, гораздо большее значение имеет производительность.

Но я ошибался. 100 КБ .js не то же самое, что 100 КБ .jpg. Это не только время загрузки из сети, которое убивает производительность первого запуска вашего приложения, но и время, потраченное на анализ и оценку вашего скрипта, в течение которого браузер перестаёт отвечать на запросы. На мобильных устройствах эти миллисекунды копятся ещё быстрее.

Если вы не уверены в существовании такой проблемы, почитайте Twitter Алекса Рассела. Алекс не приобрёл друзей в сообществе фреймворков, но он прав. Но предложенный Polymer, в качестве альтернативы Angular, React и Ember ещё не завоевал популярность в мире фронтенда и, конечно,не из-за отсутствия маркетинга.

Возможно, нам нужно полностью переосмыслить всё это.

Какую именно проблему решают фреймворки?

Общепринятое мнение состоит в том, что фреймворки облегчают управление сложностью вашего кода: фреймворк абстрагирует все скучные детали реализации с помощью таких методов, как, например, нахождение различий в виртуальном DOM. Но это не совсем так. В лучшем случае фреймворки перемещают сложные штуки из кода, который вы должны были бы написать, в код, который вы не писали.

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

Таким образом, что, если бы фреймворк на самом деле не работал в браузере? Что если бы вместо этого он преобразовывал ваше приложение в чистый ванильный JavaScript, точно так же, как Babel конвертирует ES2016 + в ES5? Вам не нужно тащить здоровенный рантайм, и ваше приложение будет работать очень быстро, потому что между вашим приложением и браузером не будет слоёв абстракции.

Представляем Svelte

Svelte — это новый фреймворк, который делает именно это. Вы пишете свои компоненты, используя HTML, CSS и JavaScript (плюс несколько дополнительных фишек, которые вы можете изучить менее чем за 5 минут), и в процессе сборки Svelte компилирует их в крошечные автономные модули JavaScript. Статически анализируя шаблон компонента, мы можем быть уверены, что браузер будет выполнять необходимый минимум всей работы.

Реализация TodoMVC на Svelte весит 3,6 КБ в сжатом виде. Для сравнения, React + ReactDOM без кода приложения весит около 45 КБ в сжатом виде. Для разбора React браузеру требуется примерно в 10 раз больше времени, чем для Svelte, чтобы только запустить интерактивный TodoMVC.

И когда ваше приложение уже запущено и запущено, в соответствии с js-framework-benchmark Svelte работает быстро, чёрт возьми. Это быстрее, чем React. Это быстрее, чем Vue. Это быстрее, чем Angular, или Ember, или Ractive, или Preact, или Riot, или Mithril. В настоящее время он конкурирует с Inferno, который, вероятно, является самым быстрым фреймворком в мире, потому что Доминик Ганнауэй — волшебник. (Svelte медленнее удаляет элементы, но мы над этим работаем.)

По сути он такой же быстрый, как ванильный JS, что имеет смысл, потому что это и есть ванильный JS, который вам не нужно было писать.

Но это не самое главное

Конечно, производительность очень важна. Но что действительно впечатляет в этом подходе, так это то, что мы наконец-то можем решить некоторые из самых сложных проблем в веб-разработке.

Проблемы с совместимостью. Хотите сделать npm install cool-calendar-widget и использовать его в своём приложении? Ранее вы могли сделать это только в том случае, если виджет был разработан под уже используемый вами фреймворк — если cool-calendar-widget был сделан в React и вы используете Angular, то, конечно, ничего не получится. Но если автор виджета использовал Svelte, приложения, которые его используют, могут быть созданы с использованием любой технологии, которая вам нравится.

Или разделение кода. Это отличная идея (загрузить только тот код, который необходим для конкретной страницы), но есть проблема — даже если вы изначально посылаете только один компонент React вместо сотни, вам всё равно придётся посылать сам React. С Svelte разделение кода может быть намного более эффективным, потому что структура встроена в компонент, а сам компонент получается крошечный.

И, наконец, кое-что, с чем я боролся как разработчик ПО с открытым исходным кодом: ваши пользователи всегда хотят, чтобы нужные им функции были в приоритете, и им всё равно, что это будет пустой балласт для других людей, которым эти функции не нужны. Автор фреймворка всегда должен сбалансировать долгосрочную работоспособность проекта с желанием удовлетворить потребности своих пользователей. Это невероятно сложно, потому что трудно предвидеть последствия постепенного раздувания фреймворка, и требуются серьёзные социальные навыки, чтобы сказать людям (которые, возможно, с энтузиазмом проповедовали ваш инструмент до этого момента), что интересующая их функциональность мягко говоря никому не нужна. Но с таким подходом, как в Svelte, любые функции могут быть добавлены абсолютно свободно, без ущерба для людей, которые их не используют, потому что код, реализующий эти функции, просто не генерируется компилятором, если он не требуется.

И это только начало

Svelte ещё очень молод. Ещё предстоит проделать большую работу — создание интеграций для сборщиков, добавление рендеринга на стороне сервера, горячая перезагрузка, переходы, дополнительная документация и примеры, стартовые наборы и так далее.

Но вы уже можете создавать крутые компоненты с его помощью, поэтому мы начали сразу со стабильной версии 1.0.0. Прочитайте руководство, попробуйте поиграть в REPL или перейдите на GitHub, чтобы помочь начать новую эру разработки UI.