Pull to refresh

Comments 86

Вполне возможно что svelte ещё не готов для продакшина по упомянутым Вами причинам. Но то что он состоялся это факт. Мне он интересен как фреймворк который изначально проектировался как universal first. См пост https://svelte.dev/blog/sapper-towards-the-ideal-web-app-framework. Поэтому если бы я его использовал то в паре с sapper. Хотя по нему также есть отзывы что он ещё сырой.


Если исходить из того что топ фреймворком не может быть больше трёх интересно кого именно вытеснит svelte

Тогда $mol вам должен быть ещё более интересен ибо:


  • маленькие бандлы
  • исполнение хоть на клиенте, хоть на сервере, хоть ещё где
  • ui-kit в комплекте
Винтаж и Мол в каждой статье про сравнение JS-фреймворков. Это уже классика ;)
UFO just landed and posted this here
То есть, исходя из вашей логики вы рекламируете «шмоль»?
Мне он интересен как фреймворк который изначально проектировался как universal first.

Я бы так не сказал, по крайней мере я никогда не слышал о такой позиции от автора. Скорее он проектировался как UI фреймворк для создания небольших изолированных компонентов. Собственно именно из этих предпосылок исходит его дизайн и большая часть непоняток со стороны представителей других фреймворков.

Если исходить из того что топ фреймворком не может быть больше трёх интересно кого именно вытеснит svelte

Как мне кажется Большая тройка в принципе не очень верно определена. Vue и React скорее UI фреймворк, а Angular скорее Application фреймворк и его имеет смысл сравнивать скорее с Ember. Вполне логичным кажется 3-ка UI фреймворков: React/Vue/Svelte. Angular/Ember/и кто-то еще ($mol?) ребята из другой оперы.
На сколько я помню авторы Svelte говорили, что Svelte делался для Sapper.
Чтобы одолеть Vue, Svelte нужен спонсор и большое комьюнити.
Если побороть все детские болезни Svelte, лично я бы предпочёл его чем Vue.
У Vue большое комьюнити в Китае.
На сколько я помню авторы Svelte говорили, что Svelte делался для Sapper.

Не встречал такого утверждения.

В статье на которую я дал ссылку выше изложены принципы которых придерживался разработчик svelte. Первый принцип это поддержка ssr. Второй поддержка universal. Именно эти принципы реализует sapper.

Так это пункты идеального по мнению автора фреймворка для Node. Эти принципы были руквовдствующими при создании Sapper и в некоторой степени к этим принципам приближаются Next.js и Nuxt.js. Это практически никак не коррелируют непосредственно с UI фреймоврком Svelte.


Вот, кстати, эта статья в переводе.

Вы не совсем верно поняли. Автор пишет про принципы идеального Application фреймворка, а Svelte — это UI фреймворк. Sapper — это Application фреймворк поверх Svelte.
У Svelte отличное комьюнити в России — это плюс. Он реально красив, я как дизайнер говорю. Конечно он слишком молод для продакшена пока, хотя некоторые уже перелезли на него, но мне нравится подход. Я, опять же, как дизайнер дико не люблю jsx. Потому мне Vue залетел много больше чем React, ну и Vue — красивее Angular. Svelte красивее чем Vue, будем посмотреть, но пока он ещё не готов, да
В нашу небольшую компанию пришёл заказ на разработку веб-админки для сервиса с бекэндом на Mongodb Stitch. В последние пару лет frontend Мы пишем на React или Vue (в зависимости от размера проекта и нужен ли ReactNative), но наслышав о красотах Svelte мы решили попробовать его, чтобы понять для себя так ли он хорош.

Получается вы решили потренероваться в новом фронт-стеке за счёт заказчика? Интересны подробности, как принималось решение и что в итоге с судьбой проекта. Бюджет освоили, сдали и забыли?)
А разве малобюджетная заказная разработка не вся такая?
Заказчику обычно глубоко всё равно на чём это будет написано. Ему важно чтобы работало и было сделано в срок. Дело не в бюджете, а в том, что если проект крохотный, не сложный и нужно всего несколько разработчиков Мы можем себе позволить поэкспериментировать, так как сроки рассчитаны с запасом.
Как я писал в статье выше, Svelte точно не для «больших» проектов и команд. Для большого у нас есть React.
Хотелось «пощупать» Svelte в продакшене. Так-же мы «щупали» Vue в своё время, он понравился и Мы сейчас успешно используем его там где не нужен Native а только Web-only.
За статьи про этот ужасный фреймворк и его рекламу надо уже банить.
а можете рассказать поподробнее о том, что не так со Svelte?
Могу. Во-первых, авторы подобных статей уже сделали это за меня своими статьями. Во-вторых, что это еще за Svelte 3? Никому не нужный фреймворк, который вдобавок постоянно переделывается и обновляет номер мажорной версии. В-третьих, фреймворки должны упрощать разработку, а не превращать ее в бег с препятствиями по пересечённой местности.
Пока конкретики ноль

Конкретики стало меньше чем 0...

Сколько пользы от этого фреймворка и этой статьи, столько и у меня конкретики :)

С вот этим моментом непонятно.


Можно создавать свои event в компонентах и избавится от передачи в child коллбэков функции, для коммуникации между child > parent.

В чем особая разница между
<Button on:click={handleClick}/>
и
<Button onClick={handleClick}/>?

Вопрос остается тем же. В чем практическая польза от создания CustomEvent, по сравнению с обычным вызовом функции?

Не нужно обрабатывать на промежуточных уровнях, можно не обрабатывать вовсе

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

Верно, сделано это специально, чтобы управлять этим процессом. Собственно, история такая, что в Ractive, предыдущем фреймворке автора Svelte, события всплывали по-умолчанию и часто это было причиной коллизий. Однако даже прокидывать вручную ивенты значительно проще, чем коллбеки:

<!-- достаточно просто указать дерективу без обработчика -->
<Child on:something />


<!-- и можно сразу ловить ивент от Child на Parent -->
<Parent on:something={doSomething} />
В Svelte можно прокидывать коллбеки через пропсы, но обычно ивенты имеют ряд плюсов:

1) Ивент может иметь N подписчиков, коллбек только одного
2) Ивент может быть легко прокинут через N слоев иерархии, в отличии от коллбека. В Svelte это процесс делается вручную, но сделано это специально, потому что когда ивенты всплывают автоматом, на каком-то уровне иерархии уже сложно понять кто и откуда их прокинул.
3) На ивенте можно применить модификатор once, с коллбеком придется запорачиваться.
4) Так как ивенты в Svelte основаны на CustomEvent, они прекрасно работают с Custom Elements.
Ивент может иметь N подписчиков, коллбек только одного

Синтаксис шаблонов дает место только для одного подписчика: <Button on:click={handleClick}/>, остальные нужно добавлять императивным кодом. Так ли часто это нужно?


Ивент может быть легко прокинут через N слоев иерархии

Синтаксический сахар, очень сомнительная польза. Можно легко заменить на прокидывание функции с тем же успехом.


Так как ивенты в Svelte основаны на CustomEvent, они прекрасно работают с Custom Elements.

Очень гипотетический плюс, для ванильного Svelte-приложения пользы никакой.


И в целом как-то механизм таких событий не вписывается в идеологию Svelte – минималистичный рантайм. Для реализации событий тянутся createEventDispatcher и bubble методы, хотя можно было бы просто оставить инлайновые вызовы функций без лишних оберток.

Синтаксис шаблонов дает место только для одного подписчика: <Button on:click={handleClick}/>

Можно два обработчика навесить, если надо:


 <Button on:click={handleClick1} on:click={handleClick2} />

Можно обработать ивент в текущем компоненте и передать на уровень выше:


 <Button on:click={handleClick1} on:click />

На мой взгляд, это очень противоестественно и неожиданно, что атрибуты работают таким образом, потому что в нативном html работать будет только один. Аналогично с одноименными полями в JS.


Если вам это при работе со Svelte это пока еще не стреляло в ногу, рад за вас, но мне с таким подходом не по пути.

Я, пожалуй, с Вами соглашусь.
На практике 1-й пример мне ни разу не приходилось применять, и я даже кейс затрудняюсь придумать.
2-й же вариант на мой взгляд вполне читаемый, если уже имеется понимание как в Svelte пробрасываются события.

Сейчас еще подумалось – а как это работает со spread props?


То есть получается что <Button {...props} on:click={handleClick} /> и <Button {...props, 'on:click': handleClick} /> это не одно и то же.

Всё верно, "намазываются" только свойства и атрибуты. Т.е. в вашем варианте в компонент будет передано свойство с именем 'on:click', содержащее ссылку на функцию. Никаким образом она не будет относиться к соответствующему обработчику события.


Вот накидал пример, чтобы продемонстрировать это наглядно.

А вот это не очень, я разочарован
А по-вашему как это должно работать? И главное, где вы видели чтобы это работало как-то иначе?
Да, но только в Svelte у нас нет необходимости прокидывать коллбеки вообще. Как правильно все это решается ивентами и описанный вами подход скорее bad practice, так как способствует запутанности кода. Особенно если скрывать эти коллбеки внутри объектов.

В этом смысле, Svelte скорее способствует хорошему дизайну ваших приложений.
В принципе да, я согласен, но после стольких лет с реактом, какие-то привычные вещи не совсем так работают в Svelte как ты думаешь и надо к этому приспосабливаться, но это не проблема конечно) просто например я не знаю заранее понадобиться мне onChange только лишь, или например onBlur тоже, а в Svelte просто надо явно указывать какие ивенты можно пускать наружку
Синтаксис шаблонов дает место только для одного подписчика: <Button on:click={handleClick}/>, остальные нужно добавлять императивным кодом. Так ли часто это нужно?

Это не так, написали ниже.

Синтаксический сахар, очень сомнительная польза. Можно легко заменить на прокидывание функции с тем же успехом.

Намного меньше действий, пропсы не захламляются лишними вещами. Много плюсов можно придумать, другое дело, если вам не надо, так не используйте просто.

И в целом как-то механизм таких событий не вписывается в идеологию Svelte – минималистичный рантайм. Для реализации событий тянутся createEventDispatcher и bubble методы, хотя можно было бы просто оставить инлайновые вызовы функций без лишних оберток.

Если вы это не используете, вам в рантайм это и не попадает. Поэтому тут никаких противоречий с идеалогией.

Нет варианта "до прочтения этого поста собирался скоро, теперь подожду с годик

А вы попробуйте, мне зашло под определенные кейсы.
Не хватает в опросе:
— использовал, понравилось, буду везде использовать
— использовал, понравилось, но для мелких проектов
— использовал, не понравилось
Я юзаю сейчас для небольшого проекта. Тут всё относительно хорошо, писанины меньше. Но для сложных — увольте. Лучше день потерять, потом за 5 минут долететь.

На Реакте тоже вначале было все непросто.
Снобы таинственно вещали что он якобы смешивает html+js а это нарушает какие-то принципы которых они сами не догоняют (т.к. корифеи программирования учили, что плохо смешивать view, model и controller, в то время как наличие js в jsx не делает компонент ни моделью ни контроллером)


Документация по flux, которая ниразу не помогала в понимании что это такое также добавляла сложностей.


Но потом как-то все стало более ясно. В том числе благодаря появлению большого количества статей, новых библиотек (redux, mobx)

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

Вообще все минусы перечисленные в статье высосаны из пальца. Особенно понравился пункт: взяли говвй ui kit не на свелте, и он не заработал. А чего вы хотели?
Да согласен, что сейчас все очень туго с готовыми наборами дизайнов, и тяжело это использовать для быстрого старта нового проекта, в одиночку. В случае с продуктовой разработкой ui kit никак не поможет, т.к. всегда приходят требования по дизайну что проще сделать новый компонент.
Собственно на нашем проекте уже давно используется 2 версия, в планах переход на 3. За все время уже насобиралась внутреняя библиотека компонентов и создание новых страниц — это сказка. Все работает быстро, бандлы получаются мизерными.

В этом и проблема, чтобы запустить что-то на Svelte Вам нужно делать свой UIKit, с учётом, что Svelte как раз подходит для небольших проектов, создание своего UIKit выходит в большие трудозатраты из чего выходит, что в продакшене Svelte просто не нужен. Разбираться с его косяками и делать свой UIKit с нуля — это долго и дорого. И что в качестве выиграша вы получите? Меньший размер bundle во времена 4G… Я лично не понял что за плюшки кроме размера мы получаем.
И как быть с поддержкой проекта написанного на Svelte? Вы пробовали когда-нибудь вводить нового разработчика в существующий Svelte проект? Мы попробовали… Но это лично моё мнение и оно может отличаться от мнения других )

Если не секрет, поделитесь — зачем Вам был нужен Svelte в проекте? Почему Вы выбрали именно его.
Меньший размер bundle во времена 4G…

Покажите мне его в глубине подвального ресторана, в поезде на пути между Питером и Москвой, в окружении тысячи других любителей 4G...

Там и статика не факт что загрузится, какой уж там Svelte

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

плюсами я считаю значительное сокращение размера бандла и лаконичность кода, простейший компонент на Svelte — 1 строка кода.

мы реализовали в данный момент небольшой виджет, и размер кодовой базы по сравнению с React там значительно меньше.
Меньший размер bundle во времена 4G

Не надо так! Отъезжаешь немного от Москвы и начинаешь ненавидеть разрабов с такой позицией. Белый экран в ожидании бандла. А если еще не самый мощный телефон все это интерпретировать…

4g редкость, качественный 4g без потерь связи еще меньше. Особенно когда рассматривается покрытие аудиторией по всему миру.
Проблем с поддержкой никаких нет. Процесс выбора данной технологии у нас на проекте остался за кадром, но наша команда подхватила идею и начали активно ее развивать. Сейчас практически все новые функции пишут с участием svelte. Проект у нас очень старый и там накопилось много legacy кода, на разных стеках технологий. Переделка шагом за шагом функций на svelte занимает немного времени за счет компонентности. Но это же и доступно в реакте и вью. Только получаешь на выходе легковестный пакет, где находится только то что необходимо пользователю в данный момент. Из за этого время до первого рендера экстремально маленькое.
По поводу обучения новых сотрудников: никаких проблем, как тимлиду приходилось мне учить новеньких на проекте не знакомых с данной технологией, никаких проблем с этим нет, 2 часа воркшопа простенького и пару часов на поиграться лично. Пока что особо невероятных проблем не испытываем. Раньше испытывали ннхватку интелисенса, но исправили данный нюанс своим плагином для vs code :)
https://marketplace.visualstudio.com/items?itemName=ardenivanov.svelte-intellisense

В случае с продуктовой разработкой ui kit никак не поможет, т.к. всегда приходят требования по дизайну что проще сделать новый компонент.

Это особенность фреймворков с убитой кастомизацией. В гибких фреймворках нет проблемы взять готовый компонент и кастомизировать его под себя.

Почему нельзя было взять material-components-web и на их основе запилить врапперы на светл? Подсмотреть примеры реализаций можно было на других фремвёрках.
Из-за того, что Svelte работает с DOM «по другому»

Даже стало интересно, что вы имеете ввиду пол «работает с DOM по другому», это как?

Не вычисляет изменения Dom через сравнения в рантайме.

Как это связано с контекстом статьи? И главное как это влияет на интеграцию внешней либы для работы с DOM?

Нет наработанных практик по интеграции.

Во-первых, слишком обще. Во-вторых, наработка практик интеграции никак не связана с работой с DOM. В-третьих, есть не просто практики, а даже специальные инструменты именно для подобных интеграций. Спасибо за ваши предположения, но все же хотелось бы услышать интерпретацию автора.
Как по мне, то Svelte отличный framework. Качественная документация, френдли комьюнити. Пока Svelte молод и, конечно, есть куда расти. Сейчас он хорошо подходит, если не ищешь готовый кит, а есть дизайнеры со своими макетами.
Шучу, конечно же ничего не ясно. Причем даже не понятно меняется состояние или это просто вспомогательная переменная. В React это решается state, который хоть как-то вносит ясности.

Можно еще уточнить, а что реально дает вам это «знание»? В целом, в Svelte все переменные это стейт. Как и принято в JS, каждая переменная имеет свой скоуп — некоторые имеют скоуп всего компонента, некоторые только функций или иных блочных выражений. Тут как бы ничего нового и неизведанного. Какой смысл вообще выделять что-то в какой-то state?
> Зачем мне это, если есть React, Vue, Angular?
Помню, когда Vue выходил, все тоже самое спрашивали, но без Vue в предложении) Прошло еще три года с момента выхода Vue и вот он обгоняет React по количеству звездочку на github. Вероятно, через три года станет ясно, зачем это все нам и наверное, появится похожая статья про очередной негодный фреймворк, в конце которого, в голосовании, будет пункт: «Зачем мне это, если есть Svelte, Vue, Angular?»
Мне нравится идея Svelte, однако пока что он не может предложить мне всего того, что я сейчас использую под React. Подумаю через 1.5 — 2 года, а на данный момент его еще рано использовать в реальных проектах.

А что вы используете в React?

А… нет, в стиле у Вас не получится вставлять переменные. Из этой ситуации Вы можете выкрутится через «ReactWay» и делать динамические стили в как переменные или функции с возвратом стиля.


Vue, к примеру, тоже так не умеет

Пока что не люблю свелте, зашел почитать аргументы против евангелистов — чот слабенькие =(
Почти всё решится сводится к тому что "чет сыровато". Неужели нет серьезных по существу?

React, Vue при скалфолдинге 'Hello World' проекта уже идут с роутером в коробке (или можно его выбрать). Но как и всё в Svelte — это дается не просто.

Берем обычный pagejs, импортим, пишем роутинг и… все. Я вот даже не фронтендер, но как-то осилил за минут так 10.
Ну и относить к боли и слезам отсутствие кучи разных ui китов (из которых нормальных вообще три калеки) — ну я не знаю
Пару месяцев назад начал следить за ним, как всегда самые пытливые говорили просто бомба. А пока что, сыроват и на конкурента Трём китам пока не дотягивает…

Вообще не понимаю о чем говорит автор.
У нас крупная админка написана на Svelte где 90% кода я писал в одиночку.
Никаких uikit не использовали и надобности не было… я взял готовый бутстрап с материал дизайном и просто писал html — все работает. У нас около сотни компонентов.


Спасибо.

О том, что эти 90% кода вы могли бы и не писать, потратив это время на что-то более полезное.

О том, что, например, в экосистеме Реакта вам понадобилось бы только половина написанного вами кода, остальное бы уже было готовое.

Ох уж эти любители всего готового, лишь бы палец о палец лишний раз не ударить…

Ох уж эти изобретатели велосипедов, лишь бы бизнес-задачи не решать

А потом на собеседовании узнаешь, что тебе предстоит поддержка/доработка очередного внутреннего набора UI и перекреститься хочется.

Неа, перекреститься хочется когда узнаёшь, что предстоит поддержка веб-приложения, основанного на чужом наборе UI. Велосипедный-то контрол можно отладить и починить, а вот любой баг стороннего контрола будет возвращаться снова и снова, обрастая костылями.

Есть вариант сообщить о баге в апстрим, а то и фикс сделать, а не только баг-репорт. Не всегда работает, особенно если BC ломает, но несколько раз помогало.

Вот в случае багов / недостаточной функциональности можно и покостылесепедить конкретные контролы, не спорю. Но не набор UI целиком.

Как-то прозрачно для бизнеса перевёл внутренний UI Kit на Material UI, даже грамоту (забавный проект был) получил за то, что "доработал" наконец UI Kit и бизнес перестал слышать на оценках задач "это у нас ещё не реализовано" и почти пропали баги с ним связанные.

О, один из последних багов, которые я чинил во фронте, был как раз связан с несовместимостью библиотеки ng-select с Angular Material UI CDK. Единственное рабочее исправление в итоге потребовало добавить зависимость от CDK. Как думаете, имеет ли смысл предлагать такой патч в апстрим? Мне вот показалось, что нет...

Sign up to leave a comment.

Articles