Комментарии 48
Есть некоторые вопросы с дублированием кода, это правда, но они решаемы и решаются. К тому же не нужно забывать, что это довольно смелая идея и по-сути первая разработка подобного рода. Уверен, что проблемы, которые наблюдаются сейчас будут решены в будущем, код будет только оптимизироваться, а статический анализатор улучшаться. Уже есть много идей насчет 2-й версии (текущая 1.4). Тот же Vue тоже не сразу стал таким крутым, как сейчас, первая версия была не очень.
В любом случае, если развитие обычных фреймверков как правило связано с увеличением кодовой базы, то Svelte должен и будет развиваться в обратную сторону — в сторону оптимазации и уменьшения генерируемого кода. У него просто нет другого выбора)))
Ну и опять же давайте смотреть реальные примеры:
ToDoMVC Svelte (http://svelte-todomvc.surge.sh/) ~ 3Kb
ToDoMVC Vanilla (http://todomvc.com/examples/vanillajs/) ~ 11Kb
ToDoMVC Vue (http://todomvc.com/examples/vue/) ~ 80Kb
ToDoMVC React (http://todomvc.com/examples/react/) ~ 300Kb
Получается что код на Svelte для решения одной и той же задачи весит даже меньше, чем на ванилле. Не говоря уже о других фреймверках. На своем опыте могу сказать, что меня размеры бандла Svelte радуют гараздо больше, чем итоговые бандлы на других фреймверках. И это на реальных проектах.
Не очень понятно — а в чём выигрываем то? Смотрю официальный пример — на 1 строчку html-шаблона сгенерировало 237 строк кода. Какая в итоге разница — тащить фреймворк отдельно, или вот так? Он же всё равно никуда не изчезает.
Оверкост на каждый компонент в данный момент составляет буквально вот такой кусок кода:
function SvelteComponent(options) {
init(this, options);
this._state = assign({}, options.data);
this._fragment = create_main_fragment(this._state, this);
if (options.target) {
this._fragment.c();
this._fragment.m(options.target, options.anchor || null);
}
}
assign(SvelteComponent.prototype, proto);
export default SvelteComponent;
Рич, говорит что у него есть идеи, чтобы минимизировать и этот кусок кода + минимизировать некоторые функции, которы используются.
В официальных примерх компоненты компилируются и отображаются с полном объеме для наглядности. Иными словами, они там скомпилированы с флагом shared: false.
Спасибо, за ваш вопрос. Мне стало самому интересно.
Честно говоря, вот это вот "исчезающий фреймворк" кажется маркетинговой уловкой. *.vue компоненты не компилируются в чистый JS? JSX не компилируется в чистый JS? Ну и понятно, что все эти component.set
все равно требуют каких-то вспомогательных функций и они попадут в бандл.
Однако минималистичное API и небольшой размер в любом случае приятно.
Ну скажем для каких-то небольших приложений, когда в jQuery мараться не охота, то почему бы и нет.
Только а толку от экономии на спичках если полноценное приложение в любом случае натянет ещё шрифтов на пару сотен килобайт, стилей на такие же размеры, и изображений на пару мегабайт.
Отвечу словами Рича из его вводной статьи:
We're shipping too much code to our users. Like a lot of front end developers, I've been in denial about that fact, thinking that it was fine to serve 100kb of JavaScript on page load – just use one less .jpg! – and that what really mattered was performance once your app was already interactive.
But I was wrong. 100kb of .js isn't equivalent to 100kb of .jpg. It's not just the network time that'll kill your app's startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive. On mobile, those milliseconds rack up very quickly.
Возможно вам стоит с ней ознакомиться, чтобы лучше понять Svelte.
Смешивать логику приложения и логику абстракции чтобы единоразово (потом заработает кэш) съэкономить 100мс на загрузке фреймворка — ну такой себе выигрыш.
А где вы увидели смешение? Svelte API вполне себе соответствует самым распространенным подходам в написании компонентов. Примеры есть в статье.
Svelte генерирует полностью ванильный JS. На самом деле вы уже сейчас можете написать какой-то компонент на Svelte, скомпилить его и безшовно внедрить в существующее приложение на Vue. Также как вы, я уверен, не раз внедряли туда D3 или какую-то другую стороннюю JS либу на ваниле.
Ну и понятно, что все эти component.set все равно требуют каких-то вспомогательных функций и они попадут в бандл
Конечно потребуется, совсем без кода не бывает. Отличие в том, что в бандл попадет лишь то что реально используется, а не вся махина фреймверка. Как я писал в статье, это фактически «tree-shaking» из коробки. Сейчас он может работать лучше, или хуже, но в итоге Svelte всегда будет стремиться к оптимизации генерируемого кода. В этом его суть.
написать какой-то компонент на Svelte, скомпилить его и безшовно внедрить в существующее приложение
Хм, а как это будет выглядеть? Я имею ввиду, как мне передать в этот svelte-компонент параметры и получить от него вывод?
Какая, однако, интересная штука! Для меня выглядит как глоток свежего воздуха на фоне жирнющих фреймворков.
Надеюсь, что в итоге авторам удастся добиться компиляции максимально эффективного кода.:)
С другой стороны для больших приложений типа SPA — выигрыш будет мало заметен, к тому же им важнее наличие множества готовых компонентов, которые есть в больших фреймворках.
к тому же им важнее наличие множества готовых компонентов, которые есть в больших фреймворках.
Это дело наживное)) Будет интерес к фреймворку — будут и куча готовых компонентов.
но для отдельных компонентов которые будут встраиваться в разные сайты, которые непонятно на чем написаны и что есть из коробки (CMS), идеально подойдет. Сам буду следить за проектом именно для этих целей. Если делать сайт полностью — то лучше возьму полноценный VUE. По крайней мере пока ощущения такие.
В любом случае, у каждого инструмента должна быть своя ниша. Возможно вы правильно описали нишу Svelte. А может быть он станет чем-то большим. Пока не ясно.
https://stenciljs.com/ попадает в ту же категорию, от разработчиков Ionic.
В чём-то быстрее, в чём-то медленнее.
JSFB — обычная писькомерка, она ничего не скажет об отзывчивости приложения, которое складывается далеко не только из рендеринга.
Ну и да, $mol тоже не бандлит ничего лишнего — только то, что необходимо (todomvc ~10kb). При этом полностью статически типизирован в отличие от большинства JS поделок и сабжа в том числе. То есть на нём можно делать, как маленькие встраиваемые виджеты, так и огромные сложные приложения. Не "выбирая инструмент под задачу", а по мере усложнения задачи не переписывая на более сложный инструмент. Библиотека стандартных легко кастомизируемых виджетов в комплекте. Ну и, конечно, уникальная киллер-фича — ленивый рендеринг, который позволяет быстро показать страницу, даже вывалив на неё кучу данных в условиях ограниченных ресурсов.
Svelte — не более чем DSL, с соответствующими проблемами — среда разработки совершенно не понимает, что вы пишите. Поэтому фреймворк лучше, чем DSL, но только если он микромодульный, а не монолитный.
Ну и да, $mol тоже не бандлит ничего лишнего
Ну то что $mol лучший, это и так понятно. ;) Я вообще считаю, что у $mol только один минус — им никто не пользуется и никто не будет пользоваться. В остальном он великолепен!
Кстати, а вы могли бы добавить в свою «пискомерку» вот эту либу: http://leeoniya.github.io/domvm/demos/TodoMVC/? Буду вам очень признателен.
Не прибиты. Да я уже и убрал их из ToDoMVC, ибо всё-равно переводов кроме английских там не было.
PaulMaly добавлю как будет время. Ну или можете пул-реквест сделать, чтобы это произошло быстрее: https://github.com/eigenmethod/todomvc
Временно выиграть в гонке производительности это поможет, но пока не появится нормальный инструментарий, который для любого фреймворка сможет сгенерить подобный код.
Это выглядит как очередная стадия взросления экосистемы, где пока нет нормальных стандартов, компилятора с нормальным tree shaking и языка с мощными возможностями метапрограммирования.
Почему так на этой производительности все сосредоточились: react и vue далеко не самые быстрые, но пока в большинстве задач их производительности хватает.
Если отбросить оптимизацию, которая часто приводит к увеличению объема кода, чем принципиально такая кодогенерация лучше обычной сборки какого-нибудь todomvc на preact ролапом (кода кстати тоже около 3кб в gz)?
Почему так на этой производительности все сосредоточились: react и vue далеко не самые быстрые, но пока в большинстве задач их производительности хватает.
Ведь я же неспроста «начал издалека»)) В статье четко указана причина, по которой я вообще начал искать альтернативное решение. Все дело в том, что я не считаю (и мой заказчик тоже), что виджет, который будет устанавливаться на сайты клиентов, должен тащить с собой 100Кб фреймверка, при весе самого виджета в несколько Кб. Ну и скорость конечно тоже играет роль.
Касательно производительности, часто работаем со Смарт ТВ (одно из направлений деятельности), так вот там Ractive частенько подтормаживает на бюджетных теликах. Последний проект делали на Svelte результаты порадовали. Учитывая схожешь API, возможно даже перепишем часть приложений на него.
Если отбросить оптимизацию, которая часто приводит к увеличению объема кода, чем принципиально такая кодогенерация лучше обычной сборки какого-нибудь todomvc на preact ролапом (кода кстати тоже около 3кб в gz)?
Принципиально ничем наверное. Хотя 3Кб весит только сам preact, насколько я помню. Плюс код, плюс шаблоны и того больше получится скорее всего. Собственно вот — 6Кб, те больше ровно на вес фреймверка. Такие пироги.)))
А вот кодогенерация создает некоторый избыточный код на каждый компонент. Да, svetle-todomvc 22кб без сжатия и минификации, но код изобилует портянками createElement/appendNode, т.е. низкоуровневой работой с DOM, которая слабо реюзается, на каждый if в шаблоне тоже генерятся приличные портянки функций.
Что будет, если приложение состоит уже из двух и более компонентов, похожих на todomvc?
Есть предел масштаба приложения, где svetle по размеру будет выигрывать, думаю его даже можно высчитать.
Если фреймворк удачный, бизнес код почти не содержит лишнего и не требует кодогенерации.
Если вы прочитали статью, то наверное заметили, что Svelte кроме всего прочего обладает значительно большими возможностями, чем Preact и даже React. Если фреймверк маленького размера это как правило сказывается и на функциональности.
Подход Svelte гарантирует, что каким бы огромным и функциональным не был сам Svelte, вы не будете тащить все это добро к себе в бандл. Только то, что нужно.
но код изобилует портянками createElement/appendNode, т.е. низкоуровневой работой с DOM, которая слабо реюзается, на каждый if в шаблоне тоже генерятся приличные портянки функций.
Вообще, это как бы и называется ванилла JS.))) Вы если бы писали на ванилле, не использовали бы DOM API и т.п.?
Что будет, если приложение состоит уже из двух и более компонентов, похожих на todomvc?
Есть предел масштаба приложения, где svetle по размеру будет выигрывать, думаю его даже можно высчитать.
Писал где-то выше. Любое дублирование кода, можно оптимизировать и вообще говоря это основаная задача Svelte и он будет этим заниматься. Будет улучшаться статический анализ и результирующий код оптимизироваться по-максимому. Обычные же фреймверки со временем только распухают, в то время как Svelte будет только уменьшаться. У него просто нет выхода)))
Там на странице проекта внизу есть приписка
or try out one of the many Vanilla JS plugins.
Я говорил именно об этих "плагинах" :-)
большими возможностями, чем Preact и даже React.Ну да, логичнее с vue сравнивать.
Если фреймверк маленького размера это как правило сказывается и на функциональности.КПД фреймворка зависит от идеи в его основе, тут уж кто как угадает. Мне кажется, если автор смог такой генератор написать, то смог бы и обычный фреймворк не хуже, только tree shaking friendly.
Вообще, это как бы и называется ванилла JS.))) Вы если бы писали на ванилле, не использовали бы DOM API и т.п.?Я бы наделал хелперов над DOM, т.к. он слишком низкоуровневый.
Писал где-то выше. Любое дублирование кода, можно оптимизироватьПосмотрим как у автора получится. Мне это видится более сложной задачей, чем написать нормальный фреймворк. Опосредованно получается, мы не сразу пишем оптимальный код фреймворка, а пишем генератор, который должен давать оптимальный код.
Ну да, логичнее с vue сравнивать.
Ну да, но при этом весь результирующего кода Svelte и Vue в десятки раз меньше.
КПД фреймворка зависит от идеи в его основе, тут уж кто как угадает. Мне кажется, если автор смог такой генератор написать, то смог бы и обычный фреймворк не хуже, только tree shaking friendly.
Предыдущее детище автора — RactiveJS, весьма не плох, по сравнению с остальными, в плане функциональных возможностей. Насчет «tree shaking friendly», что вы имеете ввиду? Как мне кажется эффективный «tree shaking» прежде всего зависит от применения модульности в итоговом коде приложения, а не от фреймворка.
Ну да, но при этом весь результирующего кода Svelte и Vue в десятки раз меньше.Нужно объективно сравнивать степень автоматизации в реальных проектах, в todomvc нет даже обработки ошибок и серверного взаимодействия.
Мне в реальности нужно знать насколько хорошо фреймворк автоматизирует
1. Реактивность, как сделан observable state, автотрекинг зависимостей без on/off/subscribe/observe (mobx, cellx, mol_atom), работа с сервером: крутилка, обработка ошибок, retry
2. Контексты, DI или что-то вроде, что бы не прокидывать все через пропсы
3. Компоненты, как расширить уже имеющийся компонент (принцип open/close), переиспользовать с другой копией стейта
4. Как задать стили компонента и стили компонента в контексте чего-либо, как динамически управлять стилями и темизацией из js
5. Типизация (насколько хорошо используется вывод типов вместо прописывания аннотаций, работает ли в шаблонах/стилях?)
Svetle простая штука для небольших проектов, но тут пока до уровня vue ему далеко.
Хотелось бы конечно видеть полноценный todomvc (вроде такого) и сравнивать, насколько вышеперечисленные фишки просто делаются в коде.
Насчет «tree shaking friendly», что вы имеете ввиду?Проблема отбрасывания лишнего кода техническая и она в природе импортов в js, поэтому приходится особым образом собирать и использовать эти модули. Это и есть friendly =).
Например, сейчас часто модули фреймворка собираются вместе в index.js, что мешает tree shaking-у. Но, в том же lodash, мы же можем так сделать: import _add from 'lodash/fp/add', есть даже плагин, которые такие импорты делает из обычного import _ from 'lodash'.
Мне в реальности нужно знать насколько хорошо фреймворк автоматизирует
Вас так послушать, так только Angular вам подходит. )))) Svelte, Ractive, React и Vue — это все же библиотеки UI, а не полноценные MV* фреймверки.
Svetle простая штука для небольших проектов, но тут пока до уровня vue ему далеко.
А что такого принципиального умеет Vue, что нельзя реализовать на Svelte?
Например, сейчас часто модули фреймворка собираются вместе в index.js, что мешает tree shaking-у. Но, в том же lodash, мы же можем так сделать: import _add from 'lodash/fp/add', есть даже плагин, которые такие импорты делает из обычного import _ from 'lodash'
Не, вы меня не поняли. Я к тому, что даже если либа молодец, все распихала по отдельным подмодулям и все такое (как lodash к примеру), но так как фича tree shaking'a основана на импортах, запороть ее может уже сам разработчик, использующий данный модуль. Например, тупо используя дефолтный конфиг Babel. Все, на этом tree shaking сразу заканчивается.
Магически исчезающий JS фреймворк