Comments 48
UFO just landed and posted this here
Вы же не поверили в заголовок и не ждали какой-то реальной «магии», правда? Совсем без кода конечно не получается)))
Есть некоторые вопросы с дублированием кода, это правда, но они решаемы и решаются. К тому же не нужно забывать, что это довольно смелая идея и по-сути первая разработка подобного рода. Уверен, что проблемы, которые наблюдаются сейчас будут решены в будущем, код будет только оптимизироваться, а статический анализатор улучшаться. Уже есть много идей насчет 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 радуют гараздо больше, чем итоговые бандлы на других фреймверках. И это на реальных проектах.
Есть некоторые вопросы с дублированием кода, это правда, но они решаемы и решаются. К тому же не нужно забывать, что это довольно смелая идея и по-сути первая разработка подобного рода. Уверен, что проблемы, которые наблюдаются сейчас будут решены в будущем, код будет только оптимизироваться, а статический анализатор улучшаться. Уже есть много идей насчет 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 радуют гараздо больше, чем итоговые бандлы на других фреймверках. И это на реальных проектах.
Специально уточнил у Рича ответ на ваш вопрос:
Оверкост на каждый компонент в данный момент составляет буквально вот такой кусок кода:
Рич, говорит что у него есть идеи, чтобы минимизировать и этот кусок кода + минимизировать некоторые функции, которы используются.
В официальных примерх компоненты компилируются и отображаются с полном объеме для наглядности. Иными словами, они там скомпилированы с флагом shared: false.
Спасибо, за ваш вопрос. Мне стало самому интересно.
Не очень понятно — а в чём выигрываем то? Смотрю официальный пример — на 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 и небольшой размер в любом случае приятно.
UFO just landed and posted this here
Ну скажем для каких-то небольших приложений, когда в 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 вполне себе соответствует самым распространенным подходам в написании компонентов. Примеры есть в статье.
Позволю себе не согласиться с вами. Vue-компоненты и JSX все же компилятся не в ванильный JS. Вы не можете скомпилить Vue-компонент и положить его на CDN или внедрить в приложение на React без того, чтобы тащить Vue в зависимостях.
Svelte генерирует полностью ванильный JS. На самом деле вы уже сейчас можете написать какой-то компонент на Svelte, скомпилить его и безшовно внедрить в существующее приложение на Vue. Также как вы, я уверен, не раз внедряли туда D3 или какую-то другую стороннюю JS либу на ваниле.
Конечно потребуется, совсем без кода не бывает. Отличие в том, что в бандл попадет лишь то что реально используется, а не вся махина фреймверка. Как я писал в статье, это фактически «tree-shaking» из коробки. Сейчас он может работать лучше, или хуже, но в итоге Svelte всегда будет стремиться к оптимизации генерируемого кода. В этом его суть.
Svelte генерирует полностью ванильный JS. На самом деле вы уже сейчас можете написать какой-то компонент на Svelte, скомпилить его и безшовно внедрить в существующее приложение на Vue. Также как вы, я уверен, не раз внедряли туда D3 или какую-то другую стороннюю JS либу на ваниле.
Ну и понятно, что все эти component.set все равно требуют каких-то вспомогательных функций и они попадут в бандл
Конечно потребуется, совсем без кода не бывает. Отличие в том, что в бандл попадет лишь то что реально используется, а не вся махина фреймверка. Как я писал в статье, это фактически «tree-shaking» из коробки. Сейчас он может работать лучше, или хуже, но в итоге Svelte всегда будет стремиться к оптимизации генерируемого кода. В этом его суть.
Какая, однако, интересная штука! Для меня выглядит как глоток свежего воздуха на фоне жирнющих фреймворков.
Надеюсь, что в итоге авторам удастся добиться компиляции максимально эффективного кода.:)
Думаю отлично подойдет для создания небольших отдельно встраиваемых компонентов. Например делаем плагин для CMS, тащить большой фреймворк для маленького плагина — жирновато, а на такой шуке самый раз.
С другой стороны для больших приложений типа SPA — выигрыш будет мало заметен, к тому же им важнее наличие множества готовых компонентов, которые есть в больших фреймворках.
С другой стороны для больших приложений типа SPA — выигрыш будет мало заметен, к тому же им важнее наличие множества готовых компонентов, которые есть в больших фреймворках.
к тому же им важнее наличие множества готовых компонентов, которые есть в больших фреймворках.
Это дело наживное)) Будет интерес к фреймворку — будут и куча готовых компонентов.
Несомненно будет. но для SPA обычно требуется много логики, в итоге все равно весь фреймворк нужно будет подключать, выигрыша в конечном бандле либо не будет, а может и еще больше будет весить. Пока что не понятно как он компилирует все. Подозреваю что код будет более избыточный чем получается в фреймворке.
но для отдельных компонентов которые будут встраиваться в разные сайты, которые непонятно на чем написаны и что есть из коробки (CMS), идеально подойдет. Сам буду следить за проектом именно для этих целей. Если делать сайт полностью — то лучше возьму полноценный VUE. По крайней мере пока ощущения такие.
но для отдельных компонентов которые будут встраиваться в разные сайты, которые непонятно на чем написаны и что есть из коробки (CMS), идеально подойдет. Сам буду следить за проектом именно для этих целей. Если делать сайт полностью — то лучше возьму полноценный VUE. По крайней мере пока ощущения такие.
Да, пожалуй, есть в ваших словах смысл. Во всяком случае, пока я сам не пробовал Svelte на большом проекте. Но чуствую что возможностей Ractive будет не хватать.
В любом случае, у каждого инструмента должна быть своя ниша. Возможно вы правильно описали нишу Svelte. А может быть он станет чем-то большим. Пока не ясно.
В любом случае, у каждого инструмента должна быть своя ниша. Возможно вы правильно описали нишу Svelte. А может быть он станет чем-то большим. Пока не ясно.
Как я понял суть, вместо того чтобы хранить в бандле модули с функциями фреймворка, эти функции размазываются по пользовательскому коду за счет включения в него (некая аналогия с inline-подстановками). Выигрыш в несколько десятков килобайт может и есть, но полученный код читать будет значительно менее удобно.
А зачем вам читать получившийся код? Вы когда код углифаете и минифицируете тоже его читаете? Мне кажется все же всегда удобнее работать с исходниками.
https://stenciljs.com/ попадает в ту же категорию, от разработчиков Ionic.
Видел его также, но он пока даже «не показался на поверхности». Его и в JS Frameworks Benchmark последнем нет, хотя там есть такие штуки, о которыя лично я первый раз вообще слышал. Но все равно спасибо что дополнили статью ссылкой, пожалуй помещу ее в конец статьи.
Итересный факт, что судя по вашему бенчмарку Ractive быстрее Vue, однако JS Frameworks Benchmark говорит об обратном. Есть идеи?
В чём-то быстрее, в чём-то медленнее.
JSFB — обычная писькомерка, она ничего не скажет об отзывчивости приложения, которое складывается далеко не только из рендеринга.
Ну и да, $mol тоже не бандлит ничего лишнего — только то, что необходимо (todomvc ~10kb). При этом полностью статически типизирован в отличие от большинства JS поделок и сабжа в том числе. То есть на нём можно делать, как маленькие встраиваемые виджеты, так и огромные сложные приложения. Не "выбирая инструмент под задачу", а по мере усложнения задачи не переписывая на более сложный инструмент. Библиотека стандартных легко кастомизируемых виджетов в комплекте. Ну и, конечно, уникальная киллер-фича — ленивый рендеринг, который позволяет быстро показать страницу, даже вывалив на неё кучу данных в условиях ограниченных ресурсов.
Svelte — не более чем DSL, с соответствующими проблемами — среда разработки совершенно не понимает, что вы пишите. Поэтому фреймворк лучше, чем DSL, но только если он микромодульный, а не монолитный.
Ну и да, $mol тоже не бандлит ничего лишнего
Ну то что $mol лучший, это и так понятно. ;) Я вообще считаю, что у $mol только один минус — им никто не пользуется и никто не будет пользоваться. В остальном он великолепен!
Кстати, а вы могли бы добавить в свою «пискомерку» вот эту либу: http://leeoniya.github.io/domvm/demos/TodoMVC/? Буду вам очень признателен.
Локализации бандлит же, т.к. они прибиты гвоздями к mol_view
Не прибиты. Да я уже и убрал их из ToDoMVC, ибо всё-равно переводов кроме английских там не было.
PaulMaly добавлю как будет время. Ну или можете пул-реквест сделать, чтобы это произошло быстрее: https://github.com/eigenmethod/todomvc
Странная все-таки тенденция. Вместо оптимизации на уровне языка и компилятора, каждый фреймворк обзаводится собственным компилятором, который работает только для подмножества идиом этого фреймворка.
Временно выиграть в гонке производительности это поможет, но пока не появится нормальный инструментарий, который для любого фреймворка сможет сгенерить подобный код.
Это выглядит как очередная стадия взросления экосистемы, где пока нет нормальных стандартов, компилятора с нормальным tree shaking и языка с мощными возможностями метапрограммирования.
Почему так на этой производительности все сосредоточились: react и vue далеко не самые быстрые, но пока в большинстве задач их производительности хватает.
Если отбросить оптимизацию, которая часто приводит к увеличению объема кода, чем принципиально такая кодогенерация лучше обычной сборки какого-нибудь todomvc на preact ролапом (кода кстати тоже около 3кб в gz)?
Временно выиграть в гонке производительности это поможет, но пока не появится нормальный инструментарий, который для любого фреймворка сможет сгенерить подобный код.
Это выглядит как очередная стадия взросления экосистемы, где пока нет нормальных стандартов, компилятора с нормальным tree shaking и языка с мощными возможностями метапрограммирования.
Почему так на этой производительности все сосредоточились: react и vue далеко не самые быстрые, но пока в большинстве задач их производительности хватает.
Если отбросить оптимизацию, которая часто приводит к увеличению объема кода, чем принципиально такая кодогенерация лучше обычной сборки какого-нибудь todomvc на preact ролапом (кода кстати тоже около 3кб в gz)?
В целом могу с вами согласиться, но имеем то что имеем.
Ведь я же неспроста «начал издалека»)) В статье четко указана причина, по которой я вообще начал искать альтернативное решение. Все дело в том, что я не считаю (и мой заказчик тоже), что виджет, который будет устанавливаться на сайты клиентов, должен тащить с собой 100Кб фреймверка, при весе самого виджета в несколько Кб. Ну и скорость конечно тоже играет роль.
Касательно производительности, часто работаем со Смарт ТВ (одно из направлений деятельности), так вот там Ractive частенько подтормаживает на бюджетных теликах. Последний проект делали на Svelte результаты порадовали. Учитывая схожешь API, возможно даже перепишем часть приложений на него.
Принципиально ничем наверное. Хотя 3Кб весит только сам preact, насколько я помню. Плюс код, плюс шаблоны и того больше получится скорее всего. Собственно вот — 6Кб, те больше ровно на вес фреймверка. Такие пироги.)))
Почему так на этой производительности все сосредоточились: react и vue далеко не самые быстрые, но пока в большинстве задач их производительности хватает.
Ведь я же неспроста «начал издалека»)) В статье четко указана причина, по которой я вообще начал искать альтернативное решение. Все дело в том, что я не считаю (и мой заказчик тоже), что виджет, который будет устанавливаться на сайты клиентов, должен тащить с собой 100Кб фреймверка, при весе самого виджета в несколько Кб. Ну и скорость конечно тоже играет роль.
Касательно производительности, часто работаем со Смарт ТВ (одно из направлений деятельности), так вот там Ractive частенько подтормаживает на бюджетных теликах. Последний проект делали на Svelte результаты порадовали. Учитывая схожешь API, возможно даже перепишем часть приложений на него.
Если отбросить оптимизацию, которая часто приводит к увеличению объема кода, чем принципиально такая кодогенерация лучше обычной сборки какого-нибудь todomvc на preact ролапом (кода кстати тоже около 3кб в gz)?
Принципиально ничем наверное. Хотя 3Кб весит только сам preact, насколько я помню. Плюс код, плюс шаблоны и того больше получится скорее всего. Собственно вот — 6Кб, те больше ровно на вес фреймверка. Такие пироги.)))
Да, согласен preact побольше на данном примере, но размер фреймворка постоянен, его суть в общем переиспользуемом каркасе. Если фреймворк удачный, бизнес код почти не содержит лишнего и не требует кодогенерации.
А вот кодогенерация создает некоторый избыточный код на каждый компонент. Да, svetle-todomvc 22кб без сжатия и минификации, но код изобилует портянками createElement/appendNode, т.е. низкоуровневой работой с DOM, которая слабо реюзается, на каждый if в шаблоне тоже генерятся приличные портянки функций.
Что будет, если приложение состоит уже из двух и более компонентов, похожих на todomvc?
Есть предел масштаба приложения, где svetle по размеру будет выигрывать, думаю его даже можно высчитать.
А вот кодогенерация создает некоторый избыточный код на каждый компонент. Да, 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 будет только уменьшаться. У него просто нет выхода)))
К ванилле JS есть множество плагинов, использование которых может сократить объем кода (обычно увеличивает, да — но если подойти с умом то может и сократить).
Ванилла JS не имеет системы плагинов))) Вы наверное про либы на ванилле, но в итоге вы просто соберете «фреймворк-солянку» )))
Там на странице проекта внизу есть приписка
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 сразу заканчивается.
UFO just landed and posted this here
Как уже писал выше, готов согласиться с первой частью. И все же серверный код и клиентский код это разные вещи. Не думаю что гонка за соотношением «размер приложения — размер бандла» когда-нибудь закончится. Во всяком случае, пока у нас существуют сеть и связанные с передачей по сети проблемы. Так как и никогда не закончится гонка «сложность приложения — скорость работы», потому как на сервере у вас полностью подконтрольное окружение, а разнообразие клиентов всех мастей, только растет с годами. Скоро будем на картошке JS запускать.
Чем меня смущают компилирующие фреймворки для js, так это тем что они существенно усложняют отладку кода, хотя есть конечно Sourse Mapping. Не подскажите как тут с этим обстоят дела?
Sign up to leave a comment.
Магически исчезающий JS фреймворк