Какие существенные минусы у свелте?

Пишите так, если хотите позвать Александра

1. В некоторых кейсах(вероятнее всего ынтырпрайзных) больше бандл https://github.com/halfnelson/svelte-it-will-scale 2. Многим не нравится отсутствие возможности передачи классов(вместе с стилями прописанными в родителе) компонентам. Плюс :global не каждому по душе. 3. Еще не 100% стабильная реактивность. В редких кейсах дичь творит. 4. Нету svelte:element, хотя уже давно в роадмапе. 5. Мало готовых компонентов, относительно реакта и прочих. 6. Почти нет работы на площадках, хотя на фриланс успешно внедряю =) 7. Плагины добавляют поддержку в третью очередь после реакта.

Спасибо большое!

если еще не смотрел мой доклад про то как работает свелт под капотом, рекомендую: https://t.me/sveltejs_public/186

о, то что нужно! Спасибо большое

Видел сравнение свелта с преактом. На большом проекте у свелта бандл выходил немножко больше. Впрочем, это довольно сомнительный минус

Да это пофиг, вес фреймворка на большом проекте играет малую роль по сравнении с весом всего приложения

Ну свелт же не идёт на фронт, только бандл идёт

Кстати, вот оно https://medium.com/@chrisdaviesgeek/tiny-js-frameworks-preact-and-svelte-d2388e2f8994

А что тут значит второй пункт? Не совсем понятен

// Parent.svelte <Child class="margin-right" /> <style> .margin-right { margin-right: 20px } </style> // Child.svelte <div class="margin-right">Margin there</div> Грубо говоря так

По идее, его можно передать как обычный пропс?

Но без стилей написанных в родителе

тогда плюсы свелта в большом проекте становятся вообще незначительными =)

А сравнение цпу и оперативной памяти?

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

Писал веб интерфейсы для планшетов(амазоновские киндлы) и свелт отлично себя показал, а вью пожирнее был бы уверен и с ним было бы больше мороки.

подравляю тебя, ты ничего не сравнивал и сделал выводы так держать =)

У меня простой хорошо написанный лендинг на вью сжирает столько же, сколько интерфейс с полнотекстовым поиском по 15мб json файлу. Достаточно четкое сравнение?

интересно что такое фронт, если не бандл, и что вообще имеется в виду

ну и разве это проблема?) В реакте если нет норм мидла совсем беспорядок в проекте (особенно после хуков). Ну и глобальные редакс. На больших проектах либо нужны прямые руки либо ангуляр)

2016 это не серьёзно...

Тогда ещё и терсера не было и преакт был другим кстати

добавлю, что ещё: - нет нормального эвент-форвардинга (например, on:*), - компонент и элемент различаются настолько сильно, что часто приходится придумывать workaround'ы, делать самоповторы в коде и тп (например, давно могли сделать экшены для компонентов, это возможно, но их нет); - нет единого стандарта разработки компонентов, поэтому мы сталкиваемся с таким дерьмом как свелтстрап и другие компоненты, которые вообще не форвардят события или форвардят не те, которые нужны; - нет нормальной человеческой обработки ошибок, часто когда что-то свалится, не понимаешь, где искать и в чём дело, а главное - не можешь предсказать; - нет таких вещей как ErrorBoundary, поэтому если у тебя вдруг что-то свалится в компонентах, у тебя упадёт вообще всё СПА-приложение; - свелт часто не понимает, где у него компонент, где элемент, хотя это следствие проблем выше (например, ты забыл импортировать <Option> и используешь как компонент в разметке, свелт 1) не отругается на отсутствующий импорт; 2) не использует это как элемент, что корректно; 3) выдаст такую ошибку, по которой ты не поймёшь, что ругается именно на отсутствующий импорт ); - сторы определяются только на верхнем уровне, нельзя стор прокинуть через слот и там же использовать (let:store —> $store); - своенравные и упёртые мейнтейнеры - иногда это хорошо, но чаще это дичь, потому что делают сферических коней в вакууме без привязки к жизни (см. Issues на гитхабе); - ещё оч много проблем. Несмотря на это свелт уже (или пока ещё) хорош. Я делаю на нём энтерпрайз уже несколько месяцев, иногда это кровь и боль, притом которой легко можно было избежать малыми стараниями разрабов свелт.

Спасибо большое!

да, экшны для компонентов было бы круто, непонятно только на какой элемент их вешать внутри компонента если их несколько, на все? какой сейчас на эту тему воркараунд? пропсом передавать?

Зачем их вешать на элементы? У компонента есть лайфсайкл

ну типа экшены это как рефы в реакте, почти 1 в 1. Наверно надо в экшен не ссылку на дом элемент передавать а что-то другое если оно висит на компоненте=)

ну как-то акшны над дом нодой работают же

Нет, экшны вообще не рефы

а что? =)

Лол, ты серьезно?

реф колбэк почти один в один

а какой твой юскейс по экшенам на компонентах?

не помню уже. Что-то нужно было запускать по апдейту и дестрою вроде

да, единственное отличие от рефколбэка в реакте что есть возможность автовызова на апдейт. А так что там что тут дом ноду\инстанс получаешь =)

это скорее побочная фича экшна, а не основная. Ссылку ты через this получить можешь

А что вы хотите делать с экшеном на компоненте вообще? У вас есть юзкейс или это всё умозрительная фича? Экшены замысливались как reusable способ делать логику над дом-узлами. Условные примеры: установить CSS-переменные, фокуснуть элемент, повесить бинд на шорткат и пр. Их можно самому и без use директивы сделать за 10 строк, это чисто сахарная фича.

так и есть, только тебе придется это делать в onMount и onUpdate и проверять что дочерний компонент уже замаунтился, потому что он может маунтиться по условию

Да. Поэтому и спасибо им, что сделали этот сахар. Он хороший и полезный :)

Он может быть полезным и для компонента. В целом если уже есть bind:this то экшен можно собрать руками из этого и onMount, afterUpdate, onDestroy

Так что именно-то хочется делать? Кросс-компонентная коммуникация, типа вызова функции на детях?

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

Ну вот. Тут просто и возникает такая проблема, что скорее всего введение экшенов (которые, еще раз, дают императивный и реактивный доступ к ДОМу по своей изначальной затее) для компонентов не сэкономит никакого кода, и всё это можно решать едва ли не меньшими запарами имея существующие инструменты. Подскролл решается пропсами и биндами. Императивный скролл — биндом на export let функцию, и вся реактивщина останется у вас в родительском компоненте, а не во внешнем экшене. Ну и по понятным причинам оно не даст вам реюзабельности, потому что все компоненты разные. Так что хз.

ну дом элемнты тоже в каком то смысле все разные, но реализуют некоторые общие интерфейсы типа эвент таргета =) С утверждением что они не сэкономят кода я скорее не согласен

Ага, чего не скажешь о компонентах как раз.

ну компоненты ты сам пишешь, а с типизацией соответствие интерфейса легко проверять и ловить ошибки

гыг, оказвается что есть более упоротые люди чем я)))))

не только на ТВ, еще носимая электроника и вообще IoT. Вообще когда читаешь такое от разработчиков, сразу понятно почему браузеры с каждым годом выжирают все больше оперативы.

Мое мнение таково - есть те кто пишет код, а есть те кто делает продукт. Это вообще разные майндсеты разработчиков

если я правильно понял, это еще называется разработчик/инженер vs коддер

экшены для компонентов не имеют смысла. экшн - это life-cycle для DOM элемента. у компонентов уже есть свой life-cycle.

нет, рефы есть отдельно с помощью bind:this. смысл экшенов в том, что их можно вынести в переиспользуемый юнит

Это бесспорно, только вот у меня есть враппер для инпута, со своими шахматами и балеринами, инпут стоит в форме (их несколько), хочу фокуснуть первый, мои действия?

пропс передать?