Комментарии 86
Вполне возможно что svelte ещё не готов для продакшина по упомянутым Вами причинам. Но то что он состоялся это факт. Мне он интересен как фреймворк который изначально проектировался как universal first. См пост https://svelte.dev/blog/sapper-towards-the-ideal-web-app-framework. Поэтому если бы я его использовал то в паре с sapper. Хотя по нему также есть отзывы что он ещё сырой.
Если исходить из того что топ фреймворком не может быть больше трёх интересно кого именно вытеснит svelte
Мне он интересен как фреймворк который изначально проектировался как universal first.
Я бы так не сказал, по крайней мере я никогда не слышал о такой позиции от автора. Скорее он проектировался как UI фреймворк для создания небольших изолированных компонентов. Собственно именно из этих предпосылок исходит его дизайн и большая часть непоняток со стороны представителей других фреймворков.
Если исходить из того что топ фреймворком не может быть больше трёх интересно кого именно вытеснит svelte
Как мне кажется Большая тройка в принципе не очень верно определена. Vue и React скорее UI фреймворк, а Angular скорее Application фреймворк и его имеет смысл сравнивать скорее с Ember. Вполне логичным кажется 3-ка UI фреймворков: React/Vue/Svelte. Angular/Ember/и кто-то еще ($mol?) ребята из другой оперы.
Чтобы одолеть Vue, Svelte нужен спонсор и большое комьюнити.
Если побороть все детские болезни Svelte, лично я бы предпочёл его чем Vue.
У Vue большое комьюнити в Китае.
На сколько я помню авторы Svelte говорили, что Svelte делался для Sapper.
Не встречал такого утверждения.
В статье на которую я дал ссылку выше изложены принципы которых придерживался разработчик svelte. Первый принцип это поддержка ssr. Второй поддержка universal. Именно эти принципы реализует sapper.
Так это пункты идеального по мнению автора фреймворка для Node. Эти принципы были руквовдствующими при создании Sapper и в некоторой степени к этим принципам приближаются Next.js и Nuxt.js. Это практически никак не коррелируют непосредственно с UI фреймоврком Svelte.
Вот, кстати, эта статья в переводе.
В нашу небольшую компанию пришёл заказ на разработку веб-админки для сервиса с бекэндом на Mongodb Stitch. В последние пару лет frontend Мы пишем на React или Vue (в зависимости от размера проекта и нужен ли ReactNative), но наслышав о красотах Svelte мы решили попробовать его, чтобы понять для себя так ли он хорош.
Получается вы решили потренероваться в новом фронт-стеке за счёт заказчика? Интересны подробности, как принималось решение и что в итоге с судьбой проекта. Бюджет освоили, сдали и забыли?)
Как я писал в статье выше, Svelte точно не для «больших» проектов и команд. Для большого у нас есть React.
Хотелось «пощупать» Svelte в продакшене. Так-же мы «щупали» Vue в своё время, он понравился и Мы сейчас успешно используем его там где не нужен Native а только Web-only.
С вот этим моментом непонятно.
Можно создавать свои event в компонентах и избавится от передачи в child коллбэков функции, для коммуникации между child > parent.
В чем особая разница между
<Button on:click={handleClick}/>
и
<Button onClick={handleClick}/>
?
Вопрос остается тем же. В чем практическая польза от создания CustomEvent, по сравнению с обычным вызовом функции?
В документации пишут, что такие события не всплывают, а значит придется их передавать наверх вручную.
<!-- достаточно просто указать дерективу без обработчика -->
<Child on:something />
<!-- и можно сразу ловить ивент от Child на Parent -->
<Parent on:something={doSomething} />
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 скорее способствует хорошему дизайну ваших приложений.
Синтаксис шаблонов дает место только для одного подписчика: <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? Вы пробовали когда-нибудь вводить нового разработчика в существующий Svelte проект? Мы попробовали… Но это лично моё мнение и оно может отличаться от мнения других )
Если не секрет, поделитесь — зачем Вам был нужен Svelte в проекте? Почему Вы выбрали именно его.
Меньший размер bundle во времена 4G…
Покажите мне его в глубине подвального ресторана, в поезде на пути между Питером и Москвой, в окружении тысячи других любителей 4G...
плюсами я считаю значительное сокращение размера бандла и лаконичность кода, простейший компонент на Svelte — 1 строка кода.
мы реализовали в данный момент небольшой виджет, и размер кодовой базы по сравнению с React там значительно меньше.
простейший компонент на Svelte — 1 строка кода.
Формально 0 строк кода — тоже компонент.
Меньший размер bundle во времена 4G
Не надо так! Отъезжаешь немного от Москвы и начинаешь ненавидеть разрабов с такой позицией. Белый экран в ожидании бандла. А если еще не
4g редкость, качественный 4g без потерь связи еще меньше. Особенно когда рассматривается покрытие аудиторией по всему миру.
Проблем с поддержкой никаких нет. Процесс выбора данной технологии у нас на проекте остался за кадром, но наша команда подхватила идею и начали активно ее развивать. Сейчас практически все новые функции пишут с участием svelte. Проект у нас очень старый и там накопилось много legacy кода, на разных стеках технологий. Переделка шагом за шагом функций на svelte занимает немного времени за счет компонентности. Но это же и доступно в реакте и вью. Только получаешь на выходе легковестный пакет, где находится только то что необходимо пользователю в данный момент. Из за этого время до первого рендера экстремально маленькое.
По поводу обучения новых сотрудников: никаких проблем, как тимлиду приходилось мне учить новеньких на проекте не знакомых с данной технологией, никаких проблем с этим нет, 2 часа воркшопа простенького и пару часов на поиграться лично. Пока что особо невероятных проблем не испытываем. Раньше испытывали ннхватку интелисенса, но исправили данный нюанс своим плагином для vs code :)
https://marketplace.visualstudio.com/items?itemName=ardenivanov.svelte-intellisense
В случае с продуктовой разработкой ui kit никак не поможет, т.к. всегда приходят требования по дизайну что проще сделать новый компонент.
Это особенность фреймворков с убитой кастомизацией. В гибких фреймворках нет проблемы взять готовый компонент и кастомизировать его под себя.
Из-за того, что Svelte работает с DOM «по другому»
Даже стало интересно, что вы имеете ввиду пол «работает с DOM по другому», это как?
Не вычисляет изменения Dom через сравнения в рантайме.
Нет наработанных практик по интеграции.
Шучу, конечно же ничего не ясно. Причем даже не понятно меняется состояние или это просто вспомогательная переменная. В React это решается state, который хоть как-то вносит ясности.
Можно еще уточнить, а что реально дает вам это «знание»? В целом, в Svelte все переменные это стейт. Как и принято в JS, каждая переменная имеет свой скоуп — некоторые имеют скоуп всего компонента, некоторые только функций или иных блочных выражений. Тут как бы ничего нового и неизведанного. Какой смысл вообще выделять что-то в какой-то state?
Помню, когда Vue выходил, все тоже самое спрашивали, но без Vue в предложении) Прошло еще три года с момента выхода Vue и вот он обгоняет React по количеству звездочку на github. Вероятно, через три года станет ясно, зачем это все нам и наверное, появится похожая статья про очередной негодный фреймворк, в конце которого, в голосовании, будет пункт: «Зачем мне это, если есть Svelte, Vue, Angular?»
А… нет, в стиле у Вас не получится вставлять переменные. Из этой ситуации Вы можете выкрутится через «ReactWay» и делать динамические стили в как переменные или функции с возвратом стиля.
Vue, к примеру, тоже так не умеет
Пока что не люблю свелте, зашел почитать аргументы против евангелистов — чот слабенькие =(
Почти всё решится сводится к тому что "чет сыровато". Неужели нет серьезных по существу?
React, Vue при скалфолдинге 'Hello World' проекта уже идут с роутером в коробке (или можно его выбрать). Но как и всё в Svelte — это дается не просто.
Берем обычный pagejs, импортим, пишем роутинг и… все. Я вот даже не фронтендер, но как-то осилил за минут так 10.
Ну и относить к боли и слезам отсутствие кучи разных ui китов (из которых нормальных вообще три калеки) — ну я не знаю
Вообще не понимаю о чем говорит автор.
У нас крупная админка написана на Svelte где 90% кода я писал в одиночку.
Никаких uikit не использовали и надобности не было… я взял готовый бутстрап с материал дизайном и просто писал html — все работает. У нас около сотни компонентов.
Спасибо.
О том, что эти 90% кода вы могли бы и не писать, потратив это время на что-то более полезное.
О том, что, например, в экосистеме Реакта вам понадобилось бы только половина написанного вами кода, остальное бы уже было готовое.
Ох уж эти изобретатели велосипедов, лишь бы бизнес-задачи не решать
Неа, перекреститься хочется когда узнаёшь, что предстоит поддержка веб-приложения, основанного на чужом наборе UI. Велосипедный-то контрол можно отладить и починить, а вот любой баг стороннего контрола будет возвращаться снова и снова, обрастая костылями.
Как-то прозрачно для бизнеса перевёл внутренний UI Kit на Material UI, даже грамоту (забавный проект был) получил за то, что "доработал" наконец UI Kit и бизнес перестал слышать на оценках задач "это у нас ещё не реализовано" и почти пропали баги с ним связанные.
О, один из последних багов, которые я чинил во фронте, был как раз связан с несовместимостью библиотеки ng-select с Angular Material UI CDK. Единственное рабочее исправление в итоге потребовало добавить зависимость от CDK. Как думаете, имеет ли смысл предлагать такой патч в апстрим? Мне вот показалось, что нет...
Боль и слёзы в Svelte 3