Pull to refresh

Comments 85

Вы забыли про одну ложку дегтя — в отличие от svelte jsx позволяет не выбрасывать типизацию и все три фрейворка могут использовать все удобства статической типизации легко подключив typescript или flow. А вот как подключить typescript или flow к svelte чтобы мне также как и во всех этих трех фреймворках редактор подсветил что я опечатался в шаблоне?


<div>{user.profile.emal}</div>

Поэтому хватить хейтить jsx — люди придумали хранить шаблоны внутри js не потому что им так красивше а чтобы получить возможность статически протипизировать выражения и обращения к данным на отсутствие опачаток и заодно получить удобный автокомплит. Например запись условий через вот эти &&, ||, ?:


<div>
 {user.profile && 
    <div>{user.profile.email}</div>
 }
</div>

про которые многие хейтеры jsx говорят как захламлением любимого им xml синтаксиса (где мол форматирование получше) придуманы не для красоты а для того чтобы typescript или flow смог проверить сужение nullable типа и валидность обращения после проверки и тоже самое касается вывода списка записывая через .map чтобы можно было проверить что элемент массива будет нужного типа вместе с проверкой всех возможных опечаток или удобным автокомплитом.


<div>
 {task.comments.map(comment => 
  <div>{comment.author.name}: {comment.text}</div>
 }
</div>

Как получить все эти удобства статической типизации со svelte?

это был ответ на эту цитату
В отличие от JSX, который, как под копирку, применяется во всех 3-х фреймворках из оригинального сравнения, и по сути расширяет javascript код html-подобным синтаксисом, Svelte использует более привычные возможности — внедрение js и css кода в html с помощью тегов

А где вы, собсно, хейт увидели?

это была отсылка к обсуждению синтаксиса svelte и jsx в предыдущих статьях
Как получить все эти удобства статической типизации со svelte?

jsx это не js. подсветка синтаксиса, автокомплит, проверка типов и т.п. для jsx не задаром. это заслуга инструментария, специально написанного для данного формата.

для svelte есть плагин к vscode с поддержкой автокомплита и typescript (они реализовали language server).

но вообще да, отсутствие качественных инструментов — основная проблема для большинства dsl, которая часто заставляет разработчиков отказываться от них и переходить на mainstream языки.
для svelte есть плагин к vscode с поддержкой автокомплита и typescript (они реализовали language server).

Попробовал этот плагин — подсветка синтаксиса есть но ни автокомплита ни проверки на ошибки внутри выражения (<h1>Hello {user.profile.emal}!</h1>) нет, но возможно это у меня что-то не завелось, у вас работает проверка выражений и автокомплит?


jsx это не js. подсветка синтаксиса, автокомплит, проверка типов и т.п. для jsx не задаром. это заслуга инструментария, специально написанного для данного формата.

Да, но jsx уже стал стандартом и у него нет никакого кастомного языка — достаточно распарсить js-выражение внутри скобок и передать статическому анализатору джаваскрипта.
А вот написание typescript-плагина кастомного языка описания шаблонов может быть не простым делом — недостаточно просто распарсить js выражение — нужно объяснить ему откуда берутся новые переменные как например "todo" "i" в этом шаблоне


<div>
 {#each todos as todo, i}
    <div>{i}: {todo.text}<div>
 {/each}
</div>

и также подсказать что нужно сузить определение для nullable типа user.profile в этом случае


 {#if user.profile}
    <div>{user.profile.emal}</div>
 {/if}

и в общем случае нужно учитывать все особенности кастомного синтаксиса и это при условии что плагины для тайпскрипта не ограничены в функциональности в том что они могут проверять. Плюс неясно насколько это будет замедлять работу — одно дело проверять js где все достаточно хорошо оптимизировано включая инкрементальную проверку при редактировании и совсем другое дело — при каждом вводе символа вызывать хуки для плагина который будет проверять все заново.
Но это тайпскрипт — для него еще можно написать плагин а для flow такой возможности нет и теряем всю аудиторию пользователей flow среди потенциальных пользователей svelte.

Краткий ответ на ваш комментарий из 2-х пунктов:
  1. JSX — тот же DSL
  2. Svelte — такой же статический анализатор как и Flow/TS и он уже знает все о своем DSL.
В последнем ангуляре же как-то сделали проверку вычислений в html.
Все это лишь вопрос инструментов. Но работа маркетинга на лицо, поэтому последователи JSX свято верят, что это не просто еще один шаблонизатор))
Вы забыли про одну ложку дегтя — в отличие от svelte jsx позволяет не выбрасывать типизацию и все три фрейворка могут использовать все удобства статической типизации легко подключив typescript или flow.

Раскажите, пожалуйста, чем типизация одного DSL отличается от типизации другого? Или вы из тех, которые «JSX — это просто JS» ?? ))))) Намекаю, вам тут ниже писали про инструменты.

А вот как подключить typescript или flow к svelte чтобы мне также как и во всех этих трех фреймворках редактор подсветил что я опечатался в шаблоне?

Typescript и Flow — это прежде всего статические анализаторы кода, Svelte — это тоже статический анализатор кода + компилятор из SFC в ванилу. Так зачем нам 2 статических анализатора?

В итоге, все DSL конструкции превращаются в обычный JS (не строковые шаблоны же, ей Богу), поэтому бравада с JSX вообще не понятна.

Далее, вы и многие тут, так говорите про опечатки, будто это самая частая и большая проблема разработки. По моему опыту баги связанные с опечатками фиксятся в момент девелопмента и даже не доходят до тестов. Да и вообще, в чем проблема с опечатками? Если вы опечатались вы увидите undefined, пойдете в компонент, где он произшел и поправите свою ошибку. Если же вам сложно понятно где это происходит, то, возможно, у вас есть более серьезная проблема в архитектуре, а не в том, что вы плохо печатаете.

Про типизацию мы обсуждаем одно и то же в комментариях к каждой статье. По моему опыту build-time типизация практически бесполезна, большинство проблем возникает в глубоком рантайме, где у вас никаких flow/typescript уже нет. Проблему с проверкой входящий данных вполне решаются ассерты.

Давайте просто остановимся на 3-х вещах:
  1. Svelte — это Javascript (ES6+) и он создан для тех, кто любит JS таким, какой он есть. Когда в JS будут встроенная статическая типизация, например, опциональная, она будет и там.
  2. Svelte — сам по себе статический анализатор кода, поэтому если его создателю и/или сообществу покажется, что статическая типизация нужна здесь и сейчас, ее можно будет реализовать максимально удобно для Svelte, без TS/Flow и других доп. примочек сбоку.
  3. Уже сейчас есть предпроцессоры, которые до компиляции позволяют делать с кодом все что вашей душе угодно. Если автор и сообщество не будут нуждаться в типизации вы сами можете заморочится с ней для себя.


Typescript и Flow — это прежде всего статические анализаторы кода, Svelte — это тоже статический анализатор кода + компилятор из SFC в ванилу. Так зачем нам 2 статических анализатора?

Typescript и Flow — это еще и языки, которые понимает IDE. У Swelte есть плагины для всех IDE?


Svelte — сам по себе статический анализатор кода, поэтому если его создателю и/или сообществу покажется, что статическая типизация нужна здесь и сейчас, ее можно будет реализовать максимально удобно для Svelte, без TS/Flow и других доп. примочек сбоку.

И каким таким образом Svelte может понять типы переданных на вход параметров без TS/Flow? Ответ: никаким, потому что в чистом JS нет никаких статических типов.


По моему опыту build-time типизация практически бесполезна, большинство проблем возникает в глубоком рантайме, где у вас никаких flow/typescript уже нет.

А по моему опыту большинство проблем можно решить именно в build-time.

А по моему опыту большинство проблем можно решить именно в build-time.

После python как то не согласен с вами… сила статической типизации сильно приувеличенна. Даже в Си скорее попадёшь на что то другое. Вот в Java без этого трудно но там они сами создали проблему а потом её решают. (алгоритмы не при помощи ООП, а через ООП)

UFO just landed and posted this here

Я правильно понимаю что вы считаете Haskell образцом в этом смысле?

UFO just landed and posted this here

И всё же, вы можете нормально написать что вы думаете на этот счёт?
Почему Си не подходит для суждений о статической типизации и какой язык по вашему мнению подходит?

UFO just landed and posted this here
По-моему, вполне очевидно, что судить о всём спектре возможных систем типов по этому — так себе идея.

Как бы да, но всё же сильная и слабая типизация это немного отдельная тема. И мы тут по сути обсуждаем только статическую типизацию т.е. время связывания переменной.
ЗЫ а так к примеру в питоне сильная типизация но динамическая. :)

UFO just landed and posted this here
Typescript и Flow — это еще и языки, которые понимает IDE.

Возможно, зато их понимают не все программисты. Еще раз, Svelte — это о ES6 и его возможностях, а значение статической типизации сильно преувеличено.

У Swelte есть плагины для всех IDE?

Не знаю, у меня IDE поддерживает и Javascript, и CSS, и HTML, а что еще что-то надо? Если понадобиться, то плагин написать это не проблема. И уж точно это не проблема Svelte, а лишь инструментария, который, конечно же, пока не такой богатый как у более популярных фреймворках.

И каким таким образом Svelte может понять типы переданных на вход параметров без TS/Flow? Ответ: никаким, потому что в чистом JS нет никаких статических типов.

В чем проблема для Svelte добавить свои описательные средства для JS и на их основе понимать типы? Говорю же, статический анализатор уже встроен, а на его основе можно сделать что угодно. Другое дело, что сейчас этого нет, потому что нет особого запроса от сообщества.

А по моему опыту большинство проблем можно решить именно в build-time.

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

Еще раз, Svelte — это о ES6 и его возможностях, а значение статической типизации сильно преувеличено.

Пока что я наблюдаю недооцененность статической типизации.


В чем проблема для Svelte добавить свои описательные средства для JS и на их основе понимать типы?

Ключевое слово — "свои". В этом и проблема: программисту их нужно будет отдельно поддерживать.

Пока что я наблюдаю недооцененность статической типизации.

Интересно, а какой у вас бекграунд, что вы так сильно чуствуете необходимость в статической типизации на клиенте? У меня C/C++ около 5 лет и честно говоря проблем с типами в JS практически не ощущаю, хотя первое время было конечно не привычно. Конечно для больших проектов, пожалуй, смысл есть, но для средних и малых, отнюдь.

Ключевое слово — «свои». В этом и проблема: программисту их нужно будет отдельно поддерживать.

Какому программисту? Можете немного раскрыть мысль, чтобы я был уверен, что вас правильно понял?
UFO just landed and posted this here
Ваше право конечно. Знаю многих людей, которые пришли также из строго-типизированных языков и хотят типы в JS, знаю тех, кто пришел и не хочет. Знаю даже таких, которые никогда с такими типами не писали и JS — это чуть ли не первый их язык, но тоже хотят типы.

Возможно именно из-за того, что первые заходят в статьи по JS и начинают на полном серьезе требовать наличие TS во всех JS инструментах, будто бы это статья про TS или TS — это уже де-факто стандарт JS. Но все это не так.

TS — не стандарт, стандарт это ES и в нем типов нет, сорри. Если лично вам это не устраивает, ок, я вас не виню. Я вообще считаю что переходящим со строго-типизированных языков, да еще с классическим ООП, лучше всего подойдет Angular 2+ для фронтенда. Очень хороший инструмент для любителей всего этого, пользуйтесь. Там вам и TS, и классы и кучу тулзов из коробки.

Не понимаю зачем только заходить в комменты к JS статья и писать там о тех вещах, которые нужны прям скажем не всем (реверанс не в вашу конкретно сторону)?
Вот только отсутствие статической типизации как раз и переводит Svelte в категорию «подходит не всем». Почему вы отказываетесь это признать?
А вы знаете интсрумент который подходит всем? Серьезно? ))) Я не знаю, так что с интересом узнаю от вас!

Разве кто-то в статье или комментариях говорил, что Svelte подходит всем? Я так сказать не могу, потому что я не все, и потому что не занимаюсь всеми проектами. С уверенностью могу сказать ли то, что Svelte хорошо подходит для маленьких и средних веб-проектов, веб-виджетов, stand-alone UI компонентов, а также html5 мобильных приложений и даже Smart TV приложений. Это то, что лично я на нем разрабатывал.

Мое личное имхо, в таких проектах он очень хорош. Возможно даже лучше, чем React и Vue, хотя утверждать этого не буду, потому что у оных также есть свои плюсы.
Чтобы не быть голословным, могли бы вы скопировать точную цитату, пожалуйста? Комметрий на который вы дали ссылку, слишком большой, чтобы понять ваши намеки.

И я все еще жду от вас фреймворк, который подходит всем. Может и мне подойдет.

В том комментарии вы начали спорить вот с этой цитатой:


Вы забыли про одну ложку дегтя — в отличие от svelte jsx позволяет не выбрасывать типизацию и все три фрейворка могут использовать все удобства статической типизации легко подключив typescript или flow.

Так все-таки, есть у Svelte эта ложка дегтя (минус) или нет?


Если есть, то я не понимаю почему вы вообще начали этот спор. Если у него минусов нет — значит, по вашему мнению, Svelte подходит всем.

Во-первых, это не значит, что я считаю, что Svelte подходит для всех. Я этого никогда не писал и не утверждаю сейчас.

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

Поэтому да, я не согласен конкретно с этим минусом, но это не значит что я утверждаю, что он подходит всем.

Например, если бы вы написали, что к минусам Svelte можно отнести является отсутствие возможности шарить код между компонентами, путем наследования или миксинов, то я бы с вами согласился. И хотя я понимаю, почему так сделано и не раз слышал доводы автора, мне все равно иногда хочется пропатчить конструктор или отнаследоваться от общего класса. Ситуацию частично спасает глубоко интегрированный в иерархию компонентов Svetle Store, через который можно делать подобные вещи.

Если у него минусов нет — значит, по вашему мнению, Svelte подходит всем.

Вы бинес-логику также пишете? Тогда понимаю почему вам нужен TS. В данном случае, языком кода это выглядело бы так:

if ( ! singleCon) {
    return 'no cons';
}


Только если я не согласен с одним описанным недостатоком, это вовсе не означает, что я считаю что их нет совсем.

И кстати, так и не узнал от вас фреймворк, который подходит всем.

Мне статическая типизация не подходит к примеру. :)

И что? Суть в том, что если Svelte не поддерживает статическую типизацию — его нельзя полноценно использовать в проекте где статическая типизация используется.

А если Svelte поддерживает статическую типизацию — его можно использовать где угодно. Или тут кто-то подумал что я предлагаю статическую типизацию сделать обязательной?
UFO just landed and posted this here

Мне кажется, что вы только что приравняли динамическую типизацию к ХХивП. Наверное ничего не надо говорить ему в ответ, чтобы кормить тролля :)

К слову о том почему вредны или неподходят TDD и MVC есть много статей, не нужно верить всегда маркетологам от ИТ.

UFO just landed and posted this here
Какому программисту? Можете немного раскрыть мысль, чтобы я был уверен, что вас правильно понял?

Какому-нибудь. Ведь гипотетические "свои описательные средства" Swelte кто-то должен сначала использовать чтобы описать входные для Swelte данные, не само же по себе описание возьмется?

А что TS никто не описывал? Или Flow? Они что всегда были? Никто их не учил? В рождения вы их знали? В React что нет PropTypes? В Vue нет собственного синтаксиса типов для пропсов? Это никто не придумал и не поддерживает?

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

Зачем ему сбоку лепить еще один статический анализатор, чтобы получить что? Опять же, если прям очень надо, то можно написать свой предпроцессор для Svelte и там прикрутить хоть TS, хоть Flow. Не уверен, может это уже и сделано, но я не видел. Если нет, значит видимо в сообществе Svelte пока это никому не надо. Это плохо? Имхо, нет.

Далее, никто вам не мешает использовать TS в импортируемых в Svelte компоненты модулях и там держать всю бизнес-логику. Это даже архитектурно будет более правильно.

А что TS никто не описывал? Или Flow? Они что всегда были?

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


пять же, если прям очень надо, то можно написать свой предпроцессор для Svelte и там прикрутить хоть TS, хоть Flow.

Да без проблем. На самом деле, можно поступить даже проще: взять тот код который генерирует Svelte и с минимальными модификациями отдать на вход компилятору TS. Но это никак не приблизит к появлению контекстных подсказок в IDE.


Далее, никто вам не мешает использовать TS в импортируемых в Svelte компоненты модулях и там держать всю бизнес-логику. Это даже архитектурно будет более правильно.

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

Кстати о бакграунде. Каждый раз когда кто-то говорит что статическая типизация не нужна, а опечатки легко исправляются — я вспоминаю один и тот же проект.

Проект на Sharepoint. Билд+деплой — 5 минут. 5 минут на исправление каждой опечатки…
Я больше года работал над легаси-проектом на плюсах, которому было лет 10, а в багтрекере было несколько тысяч ошибок, а кол-во строк кода я даже не пытался оценивать.

Так вот там все примитивные ошибки давно были исправлены, остались только edge-cases и ошибки глубокого рантайма, которые мы и отлавливали. Поэтому когда кто-то пишет мне про проблемы с опечатками, ничего кроме улыбки у меня это не вызывает.)))
Так вот там все примитивные ошибки давно были исправлены, остались только edge-cases и ошибки глубокого рантайма, которые мы и отлавливали.

На этапе сопровождения — да, так и есть. Но у нас-то была активная разработка...

А что от активность разработки как-то снижает кол-во сложных сценариев и ошибок в рантайме и увеличивает кол-во опечаток?

Не знаю почему вы так много опечатываетесь, но мои компоненты Svelte, как правило, содержат до 50 строк кода вместе с шаблонами, а значит легко просматриваются. Также очень легко тестируются, так как не смотря на SFC на выходе это обычный JS конструктор.

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


И да, если все компоненты по 50 строк кода — это, в реалиях того проекта, лишь означает что компоненты появляются пачками по 20 штук. Что же до легкости тестирования — удачи в условиях пяти минутной задержки перед запуском :-)

UFO just landed and posted this here
Еще раз, Svelte — это о ES6 и его возможностях, а значение статической типизации сильно преувеличено

1) Typescript/Flow — это тоже по сути ES6
2) Значение статической типизации в самодокументируемом коде, подсказках в иде, и в том что у вас не будет ситуаций типа
> «Если вы опечатались вы увидите undefined, пойдете в компонент, где он произшел и поправите свою ошибку. „
Вы сразу видите проблему когда еще даже не допечатали “корявую» строку

В чем проблема для Svelte добавить свои описательные средства для JS и на их основе понимать типы? Говорю же, статический анализатор уже встроен, а на его основе можно сделать что угодно

У нас и так уже есть два основных «статических анализатора», и то проблема — какой выбрать. Нафига нам еще один??

1) Typescript/Flow — это тоже по сути ES6

TS код — это валидный код ES? Нет, тогда об чем речь?

Вы сразу видите проблему когда еще даже не допечатали “корявую» строку

Ок, а без нее, я увижу ее сразу как HMR перезагрузит мне страницу. Не уверен, что готов перевести всю свою команду на другой язык, чтобы на 3 секунды раньше замечать опечатки))

У нас и так уже есть два основных «статических анализатора», и то проблема — какой выбрать. Нафига нам еще один??

Потому что в Svelte он уже итак есть, так как является основой подхода, который Svelte использует. Там этот анализатор используется для многих других вещей, в том числе для генерации кода, его оптимизации и т.п. Svelte никак не является аналогом TS/Flow и решает совершенно другие задачи, но раз он решает эти задачи с помощью ± такого же статического анализатора, то я не понимаю зачем сбоку крутить еще один.

Как мне кажется, если сообщество Svelte придет к тому, что нужна статическая типизация, она будет реализована прямо внутри компилятора, без сторонних примочек, будет поддерживать DSL и вообще глубоко и удобно интегрироваться со Svelte. И это будет круто, потому что, на вкус и цвет, но для мне TS органично смотрится только в Angular 2+, а не в React и Vue, например. В React мне нравится как выглядит подход FP, а в Vue по большей части SFC.

Хм, а в чем "подход FP" конфликтует с TS?

DSL это достаточно широкое понятие, чтобы его распространить и на JXS, но пользы в этом немного. Как бы там ни было, JSX — не шаблон.


Разница тут в том, что, не смотря на расширение синтаксиса, JSX семантически равнозначен JavaScript. Он имеет достаточно простую рекурсивную структуру (элемент: имя, атрибуты и вложенные элементы), которая консистентно и однозначно соответствует выражениям JavaScript. Результат JSX-выражения идентичен результату JavaScript-выражения. Это значит, что на JSX распространяются все правила языка-хоста: JSX-выражение можно вычислить заранее, можно сохранить, можно передать как параметр или вернуть из функции, можно заменить равносильным JavaScript-выраженим как полностью, так и частично.
Конечно, поддержку расширения синтаксиса нужно ещё добавить в инструменты, но это совсем не то же самое, что добавить поддержку языка со своей собственной семантикой — они вообще скорее всего будут несовместимы.


Семантику шаблона, раз он компилируется в JavaScript, можно свести к семантике JavaScript. Однако это не то же самое что иметь равносильную семантику. Приведение семантики не является явным, что не позволяет судить о шаблоне в терминах языка-хоста. На шаблон не распространяются языковые средства JavaScript. Можно спорить о нужности этих средств, но факта оно не меняет.


Вопрос нужности/достаточности статической типизации в JavaScript неоднозначен, однако отрицать её преимущества смысла нет. В конце концов это хотя бы просто инлайн-документация, которая проверяется компилятором, и которую понимают IDE.


Также у статической типизации есть побочный эффект. Статически типизируемый интерфейс — это явный интерфейс, с явным контрактом.


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


Кстати говоря, "проблема опечаток" это в своей сути всё та же проблема явных, верифицируемых интерфейсов.


Насчёт того, что Svelte сам по себе статический анализатор. От статического анализатора требуется покрытие значимых сценариев использования и совместимость с экосистемой. Скажем, TypeScript может это обеспечить, насколько это возможно. От Svelte для этого потребуется по крайней мере сопоставимое количество работы, если допустить что это практически реализуемо. Svelte может ограничиться верификацией специфических для себя частей на манер PropTypes, но это только небольшая часть, и остаётся ещё проблема анализа внешнего к фреймворку кода.

Совершенно не понимаю такое отношение к этому посту, я его перечитал 5 раз и не понял где бы автор сказал что то не то. Последный абзац вряд ли мог вызвать такую реакцию т.к. там просто описано текущее состояние вещей.
Вполне возможно кого то задело что то про JSX но вроде это и впрям DSL хоть и близкий к JS. Svelte то же к слову использует JS как есть внутри своих выражений кроме тех что начинаются на #.
Возможно кто то не согласен с мыслью что статическая типизация не настолько необходима? Это увы боюсь дело личного опыта и веры, в моём случае после более чем 10 лет с Python и JS проблем с опечатками не было, а если что то было то элементарно исправлялось и опять же тесты. (а вы пишете тесты?) Мне кажется, даже если вы не согласны с этой идеей то вы всё же должны признать что такая точка зрения есть.
Короче у Svelte (который написан на TS) всё отлично если вы не преверженец статической типизации.

Люди которые думают что статическая типизация — это про опечатки — не врубаются в статическую типизацию.
Для избегания опечаток в JavaScript'e есть «use strict»
Тесты мы все пишем (в мечтах), но дело не в этом, дело в уверенности в своем коде уже на этапе написания, в том что не надо держать все в голове. И еще в том что иде гораздо лучше «понимает» код и не надо так часто лезть в гугл.
Люди которые думают что статическая типизация — это про опечатки — не врубаются в статическую типизацию.

Я надеюсь вы не про меня? т.к. я прекрасно понимаю что это такое и с чем едят. Опечатки это то что тут постоянно упоминали в первую очередь говоря о статической типизации.


Про IDE это хорошо… но лично я по большей части использовал просто редакторы типо Kate,Sublime,VS Code и хватало, даже для С++.

Visual Studio Code is a lightweight but powerful source code editor

авторы другого мнения. ИМХО это редактор с плагинами которые делают систему близкой но всё же не IDE в хорошем смысле

И что же такое «IDE в хорошем смысле»? А написать они на заборе могут всё, что угодно.
Есть идея создать бота для телеграмма, который будет писать что то вроде «React не фреймворк», «Vue — это самый лучший фреймворк», «Svelte — отличный инструмент для создания компонентов практически любых веб-приложений.» и т.д. Учитывая, что и дня не проходит без парочки front-end разработчиков которые бы спорили «какой фреймворк лучше», данный бот будет вроде как грушей для битья. Захотел поспорить на эту тему, пошёл в телеграмм, поколотил его своими «доводами».
Классная идея! Как напишете, дайте ссылку, добавим в наш канал))
Не знаю кого так обидело мое желание добавить бота в чат, но вообще я лишь хотел поддержать шутку. И в шутку бы реально добавил такого бота в чат. Почему нет?
В отличие от JSX, который, как под копирку, применяется во всех 3-х фреймворках из оригинального сравнения

То что в примере для Вью — так обычно никто не делает, у вас будет такой же single file component как в Svelte, и никакого метода render.

ПС
Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.
Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.

Почему? И с каким названием было бы проще?

Почему?

Нe понятно как его правильно произносить, нe «слетает с языка» и вообще «нестандартное» слово для англоговорящих.

И с каким названием было бы проще?

Vue :D шутка
Я не маркетолог, но что-то подсказывает что название должно быть коротким, легко произносимым, и еще желательно звучать «круто» :)
Произносить «свелт» — несложно, вроде бы. Один слог, в отличие от «ре-акт», «ан-гу-ляр» :)
А, например, что Vue нужно читать как «вью» — не всем было понятно.
Произносить «свелт» — несложно, вроде бы

Для того чтобы англосаксам было «несложно» должно быть как минимум «swelt», но уж никак не «svelte»
А, например, что Vue нужно читать как «вью» — не всем было понятно.

Уж точно понятнее чем как читать «Svelte»
Для того чтобы англосаксам было «несложно» должно быть как минимум «swelt», но уж никак не «svelte»

почему? Слово же английское.

Не знаю, не слышал, значит не существует? ))))

svelte — стройный, изящный, гибкий


Уж точно понятнее чем как читать «Svelte»

Мне вот интересно, как несуществующее в словаре слово (vue), похожее по звучанию на существующее слово (view), может быть понятнее чем существующее в словаре и известное слово (svelte)? Понимаю что это субъективное мнение, но все же?

И кстати, Vue раньше читали, как «вуе», а не как «вью». Где-то даже был пост где один из евангелистов, может даже сам Эван, писал как правильно читать.
То что в примере для Вью — так обычно никто не делает, у вас будет такой же single file component как в Svelte, и никакого метода render.


Именно поэтому там есть словосочетание «из оригинального сравнения». Заметил, что многие тут апеллируют к несоответствию примеров их собственным предпочтениям. Господа, какое это имеет отношение к данной статье? Я же не могу менять примеры из оригинальной. Сам пишу на Vue и хорошо представляю, как можно написать, но если вы не согласны с примерами, что ж, быть может вам тоже написать ответную статью? Это будет как минимум интересно.

Вкусовщина конечно, но мне кажется с таким названием фрэймворку будет особенно трудно взлететь.

Сложно сказать, что вы имеете ввиду, но в целом да, слово не избитое. Думаю у автора — Рича Харриса, есть некоторая любовь к названием подтекстом. Его предыдущий фреймворк RactiveJS содержит отсылку к книге Neal Stephenson'а «The Diamond Age: Or, A Young Lady's Illustrated Primer», а именно сокращение от «interactive». Это конечно прикольно, но созвучность названия с, например, Reactive, вызывает путаницу до сих пор.

Правда Vue имеет примерно тот же изъян, потому как читается и слышится как View. Один React не имеет такой проблемы, хотя не у всех есть миллионы баксов, чтобы выкупить себе права на имя.
Именно поэтому там есть словосочетание «из оригинального сравнения».

Оно может и так, но вывод следует все-равно в стиле «видите везде нужен jsx, а в Svetle только html» хотя во Вью по факту вам тоже нe нужен jsx.
Писать статью только для того чтобы показать очевидный факт корявости примеров из оригинального сравнения — может в какой-то степени и интересно, но на мой взгляд — не самая благодарная задача.

Правда Vue имеет примерно тот же изъян, потому как читается и слышится как View

Мне кажется это by design :)
Оно может и так, но вывод следует все-равно в стиле «видите везде нужен jsx, а в Svetle только html» хотя во Вью по факту вам тоже нe нужен jsx.

Я нигде не писал что он нужен, перечитайте еще раз. Там написано, что JSX используется в примерах из оригинальной статьи для всех 3-х фреймворков. Далее идет реверанс в сторону JSX и того что это расширение JS с помощью HTML-like, а Svelte наоборот идет от HTML и расширяет его JS, что в общем-то уже в него заложено.

По поводу Vue, сорри, но там вообще похватали отовсюду. Там и шаблоны, и SFC, и JSX с render-функциями, и angular-like классы c декораторами. И что? Каждый пишет как хочет.

Писать статью только для того чтобы показать очевидный факт корявости примеров из оригинального сравнения — может в какой-то степени и интересно, но на мой взгляд — не самая благодарная задача.

Я ни слова не сказал про примеры из оригинальной статьи. Добавил сюда, потому что это удобнее для читателей. Типа сравнение все же. Не мое дело критиковать то, как эти примеры написаны. Статью писал не для этого, а чтобы расширить кругозор читателей примерами на Svelte, о чем написано в преамбуле.

Мне кажется это by design :)

Старнный ход. Многие до сих пор гуглят View, если в усной речи сказать «мы используем вью в своих проектах». Каждый раз, когда такое произношу и не уверен, что человек знаком с ним, приходится обращать внимание на написание.

По поводу Vue, сорри, но там вообще похватали отовсюду. Там и шаблоны, и SFC, и JSX с render-функциями, и angular-like классы c декораторами. И что? Каждый пишет как хочет.

Да нифига, по своему опыту, во всех проектах пишут в стиле в котором vue-cli задает изначальную структуру (т.е. почти у всех single file components и все такое)

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

Ну, судя по количеству комментариев на этот счет — возможно вы все-таки не совсем правы? Все понимают что «я не я и собака не моя», но все же для корректного сравнения нужны корректные примеры.

Старнный ход. Многие до сих пор гуглят View, если в усной речи сказать «мы используем вью в своих проектах». Каждый раз, когда такое произношу и не уверен, что человек знаком с ним, приходится обращать внимание на написание.

Ну да, такой вот ход. Со Svelte у вас будет такая же история, только когда объясните как оно пишется — все-равно будет не понятно как оно читается.
Да нифига, по своему опыту, во всех проектах пишут в стиле в котором vue-cli задает изначальную структуру (т.е. почти у всех single file components и все такое)

У всех или нет, не знаю. Мне тоже SFC в Vue нравится, хотя, мы на нем начали писать еще тогда, когда такого формата не было. Поэтому большая часть проекто на конструкторах.

Я любом случае, у меня нет задачи править чужие примеры.

Ну, судя по количеству комментариев на этот счет — возможно вы все-таки не совсем правы? Все понимают что «я не я и собака не моя», но все же для корректного сравнения нужны корректные примеры.

Это ответная статья, на другую статью, которая кстати даже перевод, а автор вообще англоговорящий. И при этом вы требуете от меня менять примеры

Опять же, чтобы говорить, что «так обычно не делают» надо иметь какую-то статистику. У меня ее нет. Примеры рабочие и «не правильные» они только для вашего эстетического восприятия. Поэтому я вполне могу предположить, что для автора статьи — это наиболее правильная реализация. Я же в свою очередь к статье никакого отношения не имею, поэтому и менять ничего не должен.

Со Svelte у вас будет такая же история, только когда объясните как оно пишется — все-равно будет не понятно как оно читается.

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

Про Vue примеры некорректные, для столь простого кода никто не будет писать рендер-функции. Образец идиоматического кода для первого примера тут, про второй вам уже сказали, шаблон был бы такой:
<template>
  <div>
     <button @click="getData">Get posts</button>
     <div v-for="post in posts" :key="post.id">
       <h2>{post.title}</h2>
       <p>{post.body}</p>
     </div>
   </div>
</template>

<style scoped>
h2 { color: #3AC1EF; }
</style>


И для третьего примера шаблон такой:
<li :class="{done : done}" @click="toggle(id)">{{value}}</li>

И в svelte у вас пропсы вообще не описаны — непонятно, должно ли описание быть, и как должна IDE подсказки делать при использовании компонента.

А вообще интересно, расскажите, как там с отладкой дело обстоит? Дев тулы? Стейт менеджмент? Роутинг?
Про Vue примеры некорректные,

Я то что могу сделать? Выше про это уже отвечал. Примеры не мои и менять я их не могу.

И в svelte у вас пропсы вообще не описаны — непонятно, должно ли описание быть, и как должна IDE подсказки делать при использовании компонента.

Так как в Svelte нет патчинга геттеров/сеттеров, как в Vue, реактивные данные могут создаваться без первоначально описания в любой момент времени. Однако согласен с тем, что хорошая практика иметь некое описание данных компонента и значения по-умолчанию. Делается это примерно также как в Vue, хотя может наборот, в Vue как в Svelte (мы же все знаем, что изначально Vue — это клон Ractive, а Svelte — это сводный брат Ractive по папиной линии?):

export default {
  data() {
    return { count: 0 }
  }
};

Но повторяю, это не является обязательным. Рабочие примеры я привел.

Пропустил последний вопрос.

А вообще интересно, расскажите, как там с отладкой дело обстоит? Дев тулы? Стейт менеджмент? Роутинг?

Что конкретно по поводу отладки вас интересует? Хром devtools есть, sourcemap есть.

Для стейт-менеджмента есть встроенный стейт компонентов, а также супер простая и удобная реализация глобального стейта — Store с иерархическим наследованием стора в рамках одной иерархии, идущая вместе со Svelte. Он сильно отличается от Redux/Vuex в сторону упрощения и призван прежде всего шарить стейт между компонентами и удобно им пользоваться. Нужен Redux — используйте, многие так делают. Можно даже использовать Redux Dev Tools со Svelte Store с помощью svelte-dev-store, но сам я не пользуюсь.

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

1. Возможность использования переменных без объявления приводит к тому, что ни статическая, ни даже динамическая типизация нам не помощник. А для подстраховки придётся писать больше тестов вида «а не опечатался ли я в таком-то выражении».

2. Одна строчка ровно до тех пор, пока внутри не используется какой-либо иной компонент, и тогда появляется скрипт с портянкой импортов и реэкспортов.

3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.

4. Ну и возможность писать произвольный яваскрипт в шаблоне — скорее вредная возможность, чем полезная. Вот как, например, эти шаблоны тестировать?
1. Возможность использования переменных без объявления приводит к тому, что ни статическая, ни даже динамическая типизация нам не помощник. А для подстраховки придётся писать больше тестов вида «а не опечатался ли я в таком-то выражении».

И вы туда же, со своими опечатками))) Будто это самая частая причина ошибок. Не знаю как у вас, но у меня проблемы с типами значительно чаще в рантайме происходят, особенно с внешними данными, чем из-за опечаток.

Если вам нужно объявить переменные и их значения по-умолчанию, вы также можете это сделать:
export default {
  data() {
    return { count: 0 }
  }
};


Опять же, вы же понимаете, что в Svelte физически не может быть необъявленных переменных? Могут быть лишь объявленные переменные без первоначального значения, т.е. undefined.

2. Одна строчка ровно до тех пор, пока внутри не используется какой-либо иной компонент, и тогда появляется скрипт с портянкой импортов и реэкспортов.

А что за цель такая — писать компонент в одну строчку? Вы к этому стремитесь?

Не знаю в чем портянка, но ES6 модули, которые используются в Svelte — это как бы стандарт уже, так что все вопросы к комитетам. Однако есть даже шорткат для этого:

<script>
  // базовый вариант с ES6 импортом
  import Nested from './Nested.html';

  export default {
    components: {
      Nested,
      NestedShort: './NestedShort.html' // укороченный вариант
    }
  };
</script>


3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.

Хорошо хоть в $mol таких проблем нет, да? Жаль никто об этом не знает…

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

Опять же, если боитесь этого, всегда можно отказаться от 2way биндингов и использовать «props down, events up», благо в Svelte — это очень удобно. Отключить 2way можно даже на уровне компилятора: bind: false.

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


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

Кстати, по поводу тестов, давно идут разговоры о том, чтобы тесты были интегрированы прямо в компоненты. Если это будет сделано, то будет просто бомба! Self-tested components! ))))))

3. Та же беда, что и в Ангуляре — компонент сначала меняет своё состояние, а потом через биндинги оно начинает подниматься. То есть временно приложение находится в неконсистентном состоянии, что приводит к различным багам.

TypeScript c версии 2.7 получил новый флаг компиляции compilerOptions.strictPropertyInitialization, который ужесточает strict режим. Что-то вроде strictNullChecks, но для полей класса.

Если его включить, и объявлять свойсва Angular компонентов которые не инициализируются до этапа завершения инстанциации класса (отработка конструктора) как someProp?:someType, то неконсистентей станет меньше, но кода придется писать несколько больше (не важно с биндингом или нет, но чаще такое нужно при биндингах конечно).

Если же хочется сохранить прежнее / «классическое» Angular поведение, то прижется явно выставить свойство как someProp!:someType, префикс `!` приехал вместе с флагом strictPropertyInitialization.

Я вот в целом заметил, что к сожалению очень большая часть проектов которые я смотрел на гитхабе использующих TypeScript не используют стрикт режимы (ни группирующий, ни отдельные), или даже явно их отключают. В то время как даже вызов tsc --init генерирутет конфиг c флагом strict установленным в true.
При чем тут strictPropertyInitialization? Оно относится только к конструкторам, а тут речь идет о двунаправленном потоке данных.
Напрмер притом что поля с @input биндингом инииализированы только после выполнение ngoninit, а до вызова они undefined, и вот установка strictPropertyInitialization делается такое поведение более явным. Ну и в целом флаг форсирует более предсказуемый код.

Но да, я не сразу заметил что речь идет об прокидвании стостояния через "@output" наверх. Если не нравится использовать подход описанный в официальной доке ангуляра (дерево компонентов которые «общаются» только через "@input/@output"), то почему не использовать глобальный стор (redux / ngrx), в этом случае необходимость использования "@output" будет минимальна.
Согласен, давненько не смотрел видимо))
Объясните мне про Svelte. «Магически исчезающий фреймворк».

Раз он «исчезает», стало быть, он встраивает в код какие-то инлайновые хелперы, которые будут делать его работу. Как babel без плагина transform-runtime.

Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?

А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?

Я вот никак этого не пойму. Выглядит как полный пшик.
Кто пробовал, поделитесь впечатлениями, пожалуйста.
Объясните мне про Svelte. «Магически исчезающий фреймворк».

В конце статьи есть ссылки на другие статьи по Svelte. Также можете почитать перевод статьи «Исчезающие фреймворки» где подробно описано в чем суть.

Раз он их встраивает, то вопрос: как скоро размер этого встраиваемого кода превысит исходный размер фреймворка? Очевидно же, что на крупном проекте это рано или поздно случится. Это происходит скорее рано, или скорее поздно?

В теории да, но это скорее всего произойдет на крупном приложении. Как правило такие приложения уже требуют code-splitting, которые работает лучше со Svelte, чем с классическими фреймворками, так как там даже самый маленький кусочек кода зависит от всего фреймворка. Так что предполагаю, что даже на крупных проектах такой подход будет давать определенные преимущества.

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

Не знаю, насколько для вас это репрезентативно, но могу дать ссылку на «A Real-World Comparison of Front-End Frameworks with Benchmarks.» — это бенчмарки, в том числе по размеру, после реализации проекта RealWorld на нескольких фреймворках. Как видите, Svelte вполне себе хорош.

А если он не инлайном вставляет, а генерирует какой-нибудь модуль с реюзабельным инструментарием, то какой же он, к чёрту, «исчезающий»?

Исчезающий он потому, что во-первых, нет никакого рантайма, который вам надо тянуть, — ваши компоненты stand-alone. Во-вторых, благодаря статическому анализу и генерации кода, в ваш бандл попадает только те хелперы, которые реально используются. Ничего лишнего, только код вашего приложения, а не все что нужно всем юзерам фреймворка. Из-за этого «feature cost» очень низкий.

При этом Svelte сам оптимизирует влючение хелперов в бандл, то есть если какие-то фичи используются в нескольких компонентах, они не будут загружены дважды.


Sign up to leave a comment.

Articles