Погружаться сложно в любой новый инструмент. Оригинальная статья же создает впечатление, что сложно погружаться только в Svelte. Хотя по факту выясняется, что автор просто не хочет погружаться, а хочет на шару, по бырику, стряпать проекты для заказчиков. Отсюда все проблемы со Svelte, отсюда незнание основ Vue и так далее.
Вот вы, полагаю, человек разумный. Наверное прочитали обе статьи. Какие конкретно моменты Svelte остались непонятными после прочтения моего ответа? Или может я как-то супер сложно запаривался чтобы решить их? Остался хоть один конструктивный пункт?
Я написал целую статью для того, чтобы ответить на ваши вопросы. Как видите, этих вопросов просто не существует. Большая часть из них связана с тем, что вы взяли незнакомый для себя сборщик и не удосужились настроить его под нужды своего проекты, либо хотя бы взять более комплексное решение, коих десятки (см. ссылку в статье).
Язык или фреймворк должен быть легким в использовании и обучении, с нормальной работающей и не путающей новичков документацией, не создавать препятствий на ровном месте.
Вы говорите про тот Vue, в котором есть пару-тройку способов навесить event listener на элемент? Или про тот Vue, в котором минимум 4 стиля написания компонентов? По вашему это более понятно новичкам?
Я бы очень хотел увидеть ивенты в Vue или чтобы через год Svelte «повзрослел».
Стоп, вы точно пишете на Vue? У меня конечно закрадывались сомнения по ходу чтения всей вашей статьи, но не до такой же степени. Например, когда вы писали что во Vue якобы можно использовать стейт внутри стилей.
Вы хоть в курсе кто сформулировал подход «props down, events up» или когда вы изучали Vue вам тоже «не хотели прилагать очень большие и долгие усилия и изучать пол года»? Изучили как попало и начали ляпать проекты для заказчиков? Серьезно, изучили бы хоть один инструмент досконально, а не прыгали между ними как кузнечики.
Статья была о том, что Svelte пока еще сыроват.
Нет статья была о том, что у вас горели сроки, а вы взяли незнакомый инструмент и прогнозируемо огребли некоторые проблемы. Большая часть из которые и не проблемы вовсе, а просто непонимание и незнание инструмента и были бы решены за пару минут в чате сообщества.
Svelte был сыроват в 2017 году, когда мы первый раз взяли версию 0.5x для одного из проектов. В 2019 году 3-я версия Svelte вполне зрелая, но было бы странно желать менять фреймворка как перчатки. Если можно, не изучая инструмент, пересесть на него с другого, возникает вопрос, раз они так похожи, то зачем он нужен вообще?
Не все это знают, это факт. Как видите Svelte умудрился оставить валидный синтаксис style атрибута и при этом сделать обновления императивными и точечными.
Во-первых, слишком обще. Во-вторых, наработка практик интеграции никак не связана с работой с DOM. В-третьих, есть не просто практики, а даже специальные инструменты именно для подобных интеграций. Спасибо за ваши предположения, но все же хотелось бы услышать интерпретацию автора.
Шучу, конечно же ничего не ясно. Причем даже не понятно меняется состояние или это просто вспомогательная переменная. В React это решается state, который хоть как-то вносит ясности.
Можно еще уточнить, а что реально дает вам это «знание»? В целом, в Svelte все переменные это стейт. Как и принято в JS, каждая переменная имеет свой скоуп — некоторые имеют скоуп всего компонента, некоторые только функций или иных блочных выражений. Тут как бы ничего нового и неизведанного. Какой смысл вообще выделять что-то в какой-то state?
Синтаксис шаблонов дает место только для одного подписчика: <Button on:click={handleClick}/>, остальные нужно добавлять императивным кодом. Так ли часто это нужно?
Это не так, написали ниже.
Синтаксический сахар, очень сомнительная польза. Можно легко заменить на прокидывание функции с тем же успехом.
Намного меньше действий, пропсы не захламляются лишними вещами. Много плюсов можно придумать, другое дело, если вам не надо, так не используйте просто.
И в целом как-то механизм таких событий не вписывается в идеологию Svelte – минималистичный рантайм. Для реализации событий тянутся createEventDispatcher и bubble методы, хотя можно было бы просто оставить инлайновые вызовы функций без лишних оберток.
Если вы это не используете, вам в рантайм это и не попадает. Поэтому тут никаких противоречий с идеалогией.
Верно, сделано это специально, чтобы управлять этим процессом. Собственно, история такая, что в Ractive, предыдущем фреймворке автора Svelte, события всплывали по-умолчанию и часто это было причиной коллизий. Однако даже прокидывать вручную ивенты значительно проще, чем коллбеки:
<!-- достаточно просто указать дерективу без обработчика -->
<Child on:something />
<!-- и можно сразу ловить ивент от Child на Parent -->
<Parent on:something={doSomething} />
В Svelte можно прокидывать коллбеки через пропсы, но обычно ивенты имеют ряд плюсов:
1) Ивент может иметь N подписчиков, коллбек только одного
2) Ивент может быть легко прокинут через N слоев иерархии, в отличии от коллбека. В Svelte это процесс делается вручную, но сделано это специально, потому что когда ивенты всплывают автоматом, на каком-то уровне иерархии уже сложно понять кто и откуда их прокинул.
3) На ивенте можно применить модификатор once, с коллбеком придется запорачиваться.
4) Так как ивенты в Svelte основаны на CustomEvent, они прекрасно работают с Custom Elements.
Вы не совсем верно поняли. Автор пишет про принципы идеального Application фреймворка, а Svelte — это UI фреймворк. Sapper — это Application фреймворк поверх Svelte.
Мне он интересен как фреймворк который изначально проектировался как universal first.
Я бы так не сказал, по крайней мере я никогда не слышал о такой позиции от автора. Скорее он проектировался как UI фреймворк для создания небольших изолированных компонентов. Собственно именно из этих предпосылок исходит его дизайн и большая часть непоняток со стороны представителей других фреймворков.
Если исходить из того что топ фреймворком не может быть больше трёх интересно кого именно вытеснит svelte
Как мне кажется Большая тройка в принципе не очень верно определена. Vue и React скорее UI фреймворк, а Angular скорее Application фреймворк и его имеет смысл сравнивать скорее с Ember. Вполне логичным кажется 3-ка UI фреймворков: React/Vue/Svelte. Angular/Ember/и кто-то еще ($mol?) ребята из другой оперы.
И? Обычная цена типизации. Все надо описывать явно и не использовать «магию». Собственно Svelte и не заставляет использовать магию. Не нужна типизация пишем так:
$store = 'value';
А если нужна, тогда так:
store.set('value');
Не вижу в этом ничего страшного.
А я вам где-то это предлагал? Или вы сами выдумали и сами же обиделись?
Похоже что да, потому что когда я написал вам, что поддержка TS имеется с помощью препроцессора вы мне ответили:
намазать TS отдельным слоем сборки над всей конструкцией — это нельзя назвать поддержкой.
То есть вам не понравилось, что TS поддерживается лишь опционально и лишь с помощью дополнительных «плагинов». Теперь вы утверждаете, что ничего такого не говорили.
Поэтому в выборе «или-или» проиграет отнюдь не TS.
Могу лишь повторить еще раз, поддержка TS есть, но она опциональная. И по всей видимости, если ее так и не включили по-умолчанию, те кому она нужна в меньшинстве.
Вопрос не в «можно-нельзя», а в «а так уж ли это надо?».
Вот и я о том. А так ли нужен Typescript? Судя по всему нет, потому что я не видел ни одного факта доказывающего, что именно TS сделал приложение лучше/надежнее/поддерживаемее, но зато читал и слышал много историй о том, что это бесполезная штука, с недоказанной пользой, влияющая на скорость разработки.
Вот и возникает вопрос, с чего так много шума вокруг него? И почему все должны срочно его поддерживать и волноваться по этому поводу?
Конечно. Транспилятор TS таковым и является, вам не надо писать собственный.
А мне и не надо. Надо писать препроцессор для компонентов Svelte (точнее он уже написан), потому что они не просто JS, а SFC.
Даже странно, что вы так быстро это для себя открыли.
Если вы согласны с тем, что TS это препроцессинг, тогда в чем проблема его использоваться как препроцессор? Зачем его по-умолчанию включать туда, где он не нужен всем, а только вам например?
В переводе с русского на русский это и означает «да, вы можете пользоваться TS, но требуется проявить некоторую ловкость рук». Когда не будет никакого «но» — это и будет означать поддержку TS.
Это означает только то, что TS штука ограниченная в возможностях. Это TS не поддерживает использование кастомных шаблонизаторов. Как только TS начнет поддерживать HTMLx, никаких проблем с ним в шаблонах не будет.
Опять же, для фанатов и сейчас не так много преград, вы лишь бездумно скачете по верхам.
Я вижу WIP Language Server с открытыми issues в духе «TS не поддерживается» и «Language server молча падает». На моем языке это называется «поддержка IDE начинает появляться».
А причем тут TS? Я про поддержку синтаксиса Svelte. На TS всем плевать.
Вот это говорит мне о том, что таки «TS не поддерживается». То, что можно проявить некоторую ловкость рук, и намазать TS отдельным слоем сборки над всей конструкцией — это нельзя назвать поддержкой.
Это ишак про поддержку из коробки, которая нафиг не нужна. Для таких вещей придуманы препроцессоры. Собственно TS это и есть препроцессинг для JS, поэтому не вижу тут ничего из разряда «ловкость рук». Точно также нужно поставить препроцессоры для PostCSS или SCSS если они необходимы. Так как 100% разработчиков Svelte не нужен TS, значит его не должно быть в Svelte по-умолчанию.
На всякий случай, если вы с первого раза не прочитали: «назвал критичные на мой взгляд недостатки». По каким причинам лично вы считаете это не важным или недостаточно важным — мне совершенно неинтересно.
Кроме фейспалма, у меня ничего для вас нет в этом вопросе.
Нормальная поддержка IDE. TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
При том, что лично я отношу отсутствие поддержки TS к существенным недостаткам. При чём тут хабы и теги?
Потому что это 2 разных языка. Это как сейчас набегут адепты Elm в статью по React и начнут ныть, что React не поддерживает Elm.
Учитывая что вы даже не в курсе про сорс-мапы, кажется глубина вашего погружения была недостаточная, чтобы оценить какая поддержка TS или IDE имеется на данный момент. 8 месяцев назад это очень давно, тогда еще и Svelte 3 то не было.
И опять же, причем тут TS если статья находится в хабе по JS и имеет тег JS. Можно с таким же успехом прийти и про CoffeScript затирать. Любите TS любите дальше, никто вас ни к чему не призывает, но не обязательно пытаться его присунуть везде где он не нужен.
Вот вы, полагаю, человек разумный. Наверное прочитали обе статьи. Какие конкретно моменты Svelte остались непонятными после прочтения моего ответа? Или может я как-то супер сложно запаривался чтобы решить их? Остался хоть один конструктивный пункт?
Я лишь описал одну из возможностей.
Вы говорите про тот Vue, в котором есть пару-тройку способов навесить event listener на элемент? Или про тот Vue, в котором минимум 4 стиля написания компонентов? По вашему это более понятно новичкам?
Стоп, вы точно пишете на Vue? У меня конечно закрадывались сомнения по ходу чтения всей вашей статьи, но не до такой же степени. Например, когда вы писали что во Vue якобы можно использовать стейт внутри стилей.
Вы хоть в курсе кто сформулировал подход «props down, events up» или когда вы изучали Vue вам тоже «не хотели прилагать очень большие и долгие усилия и изучать пол года»? Изучили как попало и начали ляпать проекты для заказчиков? Серьезно, изучили бы хоть один инструмент досконально, а не прыгали между ними как кузнечики.
Нет статья была о том, что у вас горели сроки, а вы взяли незнакомый инструмент и прогнозируемо огребли некоторые проблемы. Большая часть из которые и не проблемы вовсе, а просто непонимание и незнание инструмента и были бы решены за пару минут в чате сообщества.
Svelte был сыроват в 2017 году, когда мы первый раз взяли версию 0.5x для одного из проектов. В 2019 году 3-я версия Svelte вполне зрелая, но было бы странно желать менять фреймворка как перчатки. Если можно, не изучая инструмент, пересесть на него с другого, возникает вопрос, раз они так похожи, то зачем он нужен вообще?
Компилируется в:
Не все это знают, это факт. Как видите Svelte умудрился оставить валидный синтаксис style атрибута и при этом сделать обновления императивными и точечными.
Можно еще уточнить, а что реально дает вам это «знание»? В целом, в Svelte все переменные это стейт. Как и принято в JS, каждая переменная имеет свой скоуп — некоторые имеют скоуп всего компонента, некоторые только функций или иных блочных выражений. Тут как бы ничего нового и неизведанного. Какой смысл вообще выделять что-то в какой-то state?
Это не так, написали ниже.
Намного меньше действий, пропсы не захламляются лишними вещами. Много плюсов можно придумать, другое дело, если вам не надо, так не используйте просто.
Если вы это не используете, вам в рантайм это и не попадает. Поэтому тут никаких противоречий с идеалогией.
Даже стало интересно, что вы имеете ввиду пол «работает с DOM по другому», это как?
1) Ивент может иметь N подписчиков, коллбек только одного
2) Ивент может быть легко прокинут через N слоев иерархии, в отличии от коллбека. В Svelte это процесс делается вручную, но сделано это специально, потому что когда ивенты всплывают автоматом, на каком-то уровне иерархии уже сложно понять кто и откуда их прокинул.
3) На ивенте можно применить модификатор once, с коллбеком придется запорачиваться.
4) Так как ивенты в Svelte основаны на CustomEvent, они прекрасно работают с Custom Elements.
Я бы так не сказал, по крайней мере я никогда не слышал о такой позиции от автора. Скорее он проектировался как UI фреймворк для создания небольших изолированных компонентов. Собственно именно из этих предпосылок исходит его дизайн и большая часть непоняток со стороны представителей других фреймворков.
Как мне кажется Большая тройка в принципе не очень верно определена. Vue и React скорее UI фреймворк, а Angular скорее Application фреймворк и его имеет смысл сравнивать скорее с Ember. Вполне логичным кажется 3-ка UI фреймворков: React/Vue/Svelte. Angular/Ember/и кто-то еще ($mol?) ребята из другой оперы.
И? Обычная цена типизации. Все надо описывать явно и не использовать «магию». Собственно Svelte и не заставляет использовать магию. Не нужна типизация пишем так:
А если нужна, тогда так:
Не вижу в этом ничего страшного.
Похоже что да, потому что когда я написал вам, что поддержка TS имеется с помощью препроцессора вы мне ответили:
То есть вам не понравилось, что TS поддерживается лишь опционально и лишь с помощью дополнительных «плагинов». Теперь вы утверждаете, что ничего такого не говорили.
Могу лишь повторить еще раз, поддержка TS есть, но она опциональная. И по всей видимости, если ее так и не включили по-умолчанию, те кому она нужна в меньшинстве.
Вот и я о том. А так ли нужен Typescript? Судя по всему нет, потому что я не видел ни одного факта доказывающего, что именно TS сделал приложение лучше/надежнее/поддерживаемее, но зато читал и слышал много историй о том, что это бесполезная штука, с недоказанной пользой, влияющая на скорость разработки.
Вот и возникает вопрос, с чего так много шума вокруг него? И почему все должны срочно его поддерживать и волноваться по этому поводу?
А мне и не надо. Надо писать препроцессор для компонентов Svelte (точнее он уже написан), потому что они не просто JS, а SFC.
Если вы согласны с тем, что TS это препроцессинг, тогда в чем проблема его использоваться как препроцессор? Зачем его по-умолчанию включать туда, где он не нужен всем, а только вам например?
Это означает только то, что TS штука ограниченная в возможностях. Это TS не поддерживает использование кастомных шаблонизаторов. Как только TS начнет поддерживать HTMLx, никаких проблем с ним в шаблонах не будет.
Опять же, для фанатов и сейчас не так много преград, вы лишь бездумно скачете по верхам.
А причем тут TS? Я про поддержку синтаксиса Svelte. На TS всем плевать.
Это ишак про поддержку из коробки, которая нафиг не нужна. Для таких вещей придуманы препроцессоры. Собственно TS это и есть препроцессинг для JS, поэтому не вижу тут ничего из разряда «ловкость рук». Точно также нужно поставить препроцессоры для PostCSS или SCSS если они необходимы. Так как 100% разработчиков Svelte не нужен TS, значит его не должно быть в Svelte по-умолчанию.
Кроме фейспалма, у меня ничего для вас нет в этом вопросе.
Нормальная поддержка IDE. TS поддерживается в скриптах, в шаблонах нет, но можно и минимизировать выражения в шаблонах и не использовать автоматические биндинги.
Потому что это 2 разных языка. Это как сейчас набегут адепты Elm в статью по React и начнут ныть, что React не поддерживает Elm.
И опять же, причем тут TS если статья находится в хабе по JS и имеет тег JS. Можно с таким же успехом прийти и про CoffeScript затирать. Любите TS любите дальше, никто вас ни к чему не призывает, но не обязательно пытаться его присунуть везде где он не нужен.