Нет, комментарии как раз для непонятности. Там же абракадабра в них. А если серьёзно, то они здорово помогают в изучении view.tree.
Да, для пониманию view.tree реально все средства хороши. )))
Есть большая разница между «прочитать что написано» и «понять что происходит». В первом коде понять существенно сложнее.
Ты написал субъективное мнение без обоснования. Я выше в комментарии написал точно такое же субъективное мнение, но противоположное. Однако обосновал это хоть как-то.
Для понимания кода компонента знать про МАААМ вообще не обязательно. Даже про работу «хелперов» $mol_mem и $mol_view знать надо не больше, чем «эта штука мемоизирует» и «эта штука — базовый класс».
Ну как это. У нас JS, а не PHP, в котором классы могут браться «из воздуха» благодаря авто-загрузке. В JS то что не импортировано, не существует в скоупе. Поэтому любому JS разработчику сперва нужно будет разобраться откуда взялись магические классы типа $mol_view и что это вообще.
В Svelte сверху файла просто и очевидно импортируются хэлперы с вполне говорящими именами, на которые всегда можно ткнуть и посмотреть их код. Сами хелперы как правило не более чем в 10-ток строк кода.
Поддержка TS есть только внутри script и только с использованием специального препроцессора для компилятора Svelte. В шаблонах поддержки типов нет из-за отсутствия поддержки кастомных DSL в самом TS.
То есть мы устанавливаем препроцессор в настройки компилятора (например можно юзать сразу пакет препроцессоров svelte-preprocess), выставляем тегу script аттрибут type=«typescript» и пишем TS.
Далее, во время сборки, сперва код проходит через компилятор TS, проверяются типы и все такое, потому уже сгенерированный TS-ом JS идет в Svelte.
Однако тут есть пара моментов:
Писать TS приходится с оглядкой на SvelteScript. Многие вещи TS не понимает, некоторые конструкции TS ломают компиляцию Svelte.
Процесс сборки становится в 2 раза дольше (2 компилятора)
Поэтому поддержка TS есть, но она не полная и сбоку.
А комментарии там видимо из-за его понятности? ;-) Если не ерничать, то думаю оба примера вполне себе хорошо читаются. Подходы разные, это да, но уверен что даже начинающий JS разработчик поймет что тут написано.
В пользу кода на Svelte скажу, что если бы ты оставить импорты, то все таки в нем меньше магии, потому что там намного очевиднее что и откуда берется.
Читая аутпут $mol надо сразу понимать откуда взялись все эти $mol_view и т.п. То есть придется сразу почитать про MAAM. Опять же работа с this. Да и за кулисами же есть ядро, которое дергает за все эти «ниточки».
В аутпуте Svelte мы видим сразу все что нужно. Однако повторюсь, оба выхлопа выглядят в целом вполне читаемо и понятно.
Я, в свою очередь, не первый раз замечаю что вы пристально следите за моих блоготворчеством. Это приятно, спасибо! ;-)
«Svelte в любой момент можно скомпилировать в вебкомпоненты», правда «компиляция в веб-компоненты не в приоритете, поэтому ничего удивительного, если у вас там что-то не сложится».
Забавно.
Не уверен, что понимаю что именно забавного вы тут видите. Это обычная логика и констатация фактов. Факты следующие:
Факт 1: Компиляция в веб-компоненты мне может понадобиться в том случае, если они захватят мир. В данный момент до этого далеко, поэтому они не являются приоритетом.
Факт 2:Svelte уже по всем тестам (ссылку давал где-то по треду) имеет прекрасную поддержку веб-компонентов. В случае если веб-компоненты начнут захватывать мир, приоритет их поддержки изменится и можно будет допиливать пожелания типа «хочу, чтобы Shadow DOM был опциональным». Главное, что их поддержка и принципиальная возможность компиляции в них уже существует.
Какой из тезисов вам не понятен или как вы выразились «сужает контекст»?
Мне вот правда интересно, вы намеренно ведете себя так, что вот эта вот статья прямо 100% про вас, или у вас это неосознанно выходит?
Это кстати одна из постоянных тем в дизайне Svelte. Соблюсти баланс между привычным и удобным, и новыми идеями и подходами, невероятно сложно. Если перегнуть палку, то инструмент получится кардинально другой и его будет сложно понять. Если недогнуть, тогда инструмент не будет выделяться чем-то особенным и пройдет мимо. Мне кажется, что Svelte 3 удалось найти некий баланс между двумя этими крайностями и это частично повлияло на то, что он выстрелил.
Кстати довольно верная мысль. Примерно это я и пытался выразить в разделе «Про (НЕ)осознанность».
Действительно, одна из проблем Svelte и понимании его, долгое время заключалась в том, что он слишком похож на существующие решения. Именно поэтому ключевые отличия, которые конечно же имеются, долго оставались незамеченными. И только с выходом Svelte 3 различий стало больше, хотя по сути все равно подходы используются те же.
Иными словами да, Svelte делает многие вещи по-другому, местами удобнее и лаконичнее, но в масштабе это точно также же компонентный фреймворк, как и React или Vue.
Поэтому я и написал в статье, что вовсе не утверждаю что Svelte — это обязательно и бесповоротно фреймворк будущего, но то что он уже на пороге Большой четверки я не сомневаюсь.
Да я тут немного упростил из-за ненадобности. Собственно в тоже же Vue.extend под капотом тот же VDOM и теми же рендер-функции. Все это лишь разные формы записи по-сути.
Ну и конечно не могу согласиться с тем, что Vue делает тоже самое что и Svelte. Скорее уж он делает тоже самое что React. Вся кодогенерация сводится в тому чтобы превратить декларативный шаблон в вызовы функций и подготовить это хозяйство к работе в рантайм.
Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) сами. В Svelte же мы ограничены исключительно декларативным подходом.
А разве у Polymer не была довольно приличная экосистема? До сих пор большая часть существующий готовых веб-компонентов завязана на него или что-то из его окружения. Мне почему-то кажется, что основная проблема Polymer была именно в том, что стандарт веб-компонентов довольно долго не могли стандартизировать, а разработчики Polymer уже понаписали своего добра. При этом мир не стоял на месте и получилось так, что Polymer устаревал до того, как стандарт который он реализовывал принимался комитетами.
Думаю потому что всем чего-то не хватает в JS и его обязательно нужно улучшить.))) Кстати, output у Svelte очень понятный, очевидный и легко читается. Можете сами посмотреть в REPL.
Да собственно прям с первых абзацев — переход на личности:
А вы оригинальную то статью читали? Если не уловили, то там речь шла только о моих статьях, поэтому все набросы, коих там полно, также адресуются мне.
Ставить подобные диагнозы, это уже перебор.
Никто не заставлял автора оригинальной статьи писать ту фразу, которую он написал. Дальше каждый делает выводы. Я сделал вывод, что фраза про «психотерапевта» и «выговариваться мне придётся вам» в скопе с явно нервозным тоном публикации, может говорить о наличии депрессии.
Более того, обратите внимание что за последнее время никаких особых статей про Svelte не выходило. То есть тезис о том, что автора прям так вот до невозможности достали постоянно выходящие статьи также не подтверждается.
Есть стремления вывести Sapper в 1.0 и добавить таки поддержку Typescript. Рич еще в тихую пилит Svelte GL, который в будущем можно будет использовать для 3D графики и интерфейсов к VR.
В самом Svelte сейчас по факту community-stage, когда сообщество уже получило на руки рабочий инструмент и наращивает экосистему вокруг него.
Да, для пониманию view.tree реально все средства хороши. )))
Ты написал субъективное мнение без обоснования. Я выше в комментарии написал точно такое же субъективное мнение, но противоположное. Однако обосновал это хоть как-то.
Ну как это. У нас JS, а не PHP, в котором классы могут браться «из воздуха» благодаря авто-загрузке. В JS то что не импортировано, не существует в скоупе. Поэтому любому JS разработчику сперва нужно будет разобраться откуда взялись магические классы типа $mol_view и что это вообще.
В Svelte сверху файла просто и очевидно импортируются хэлперы с вполне говорящими именами, на которые всегда можно ткнуть и посмотреть их код. Сами хелперы как правило не более чем в 10-ток строк кода.
То есть мы устанавливаем препроцессор в настройки компилятора (например можно юзать сразу пакет препроцессоров svelte-preprocess), выставляем тегу script аттрибут type=«typescript» и пишем TS.
Далее, во время сборки, сперва код проходит через компилятор TS, проверяются типы и все такое, потому уже сгенерированный TS-ом JS идет в Svelte.
Однако тут есть пара моментов:
Поэтому поддержка TS есть, но она не полная и сбоку.
В пользу кода на Svelte скажу, что если бы ты оставить импорты, то все таки в нем меньше магии, потому что там намного очевиднее что и откуда берется.
Читая аутпут $mol надо сразу понимать откуда взялись все эти $mol_view и т.п. То есть придется сразу почитать про MAAM. Опять же работа с this. Да и за кулисами же есть ядро, которое дергает за все эти «ниточки».
В аутпуте Svelte мы видим сразу все что нужно. Однако повторюсь, оба выхлопа выглядят в целом вполне читаемо и понятно.
Не уверен, что понимаю что именно забавного вы тут видите. Это обычная логика и констатация фактов. Факты следующие:
Факт 1: Компиляция в веб-компоненты мне может понадобиться в том случае, если они захватят мир. В данный момент до этого далеко, поэтому они не являются приоритетом.
Факт 2:Svelte уже по всем тестам (ссылку давал где-то по треду) имеет прекрасную поддержку веб-компонентов. В случае если веб-компоненты начнут захватывать мир, приоритет их поддержки изменится и можно будет допиливать пожелания типа «хочу, чтобы Shadow DOM был опциональным». Главное, что их поддержка и принципиальная возможность компиляции в них уже существует.
Какой из тезисов вам не понятен или как вы выразились «сужает контекст»?
Спасибо, ознакомлюсь на досуге.
Действительно, одна из проблем Svelte и понимании его, долгое время заключалась в том, что он слишком похож на существующие решения. Именно поэтому ключевые отличия, которые конечно же имеются, долго оставались незамеченными. И только с выходом Svelte 3 различий стало больше, хотя по сути все равно подходы используются те же.
Иными словами да, Svelte делает многие вещи по-другому, местами удобнее и лаконичнее, но в масштабе это точно также же компонентный фреймворк, как и React или Vue.
Поэтому я и написал в статье, что вовсе не утверждаю что Svelte — это обязательно и бесповоротно фреймворк будущего, но то что он уже на пороге Большой четверки я не сомневаюсь.
Ну и конечно не могу согласиться с тем, что Vue делает тоже самое что и Svelte. Скорее уж он делает тоже самое что React. Вся кодогенерация сводится в тому чтобы превратить декларативный шаблон в вызовы функций и подготовить это хозяйство к работе в рантайм.
Да, это верно.
А вы оригинальную то статью читали? Если не уловили, то там речь шла только о моих статьях, поэтому все набросы, коих там полно, также адресуются мне.
Никто не заставлял автора оригинальной статьи писать ту фразу, которую он написал. Дальше каждый делает выводы. Я сделал вывод, что фраза про «психотерапевта» и «выговариваться мне придётся вам» в скопе с явно нервозным тоном публикации, может говорить о наличии депрессии.
Более того, обратите внимание что за последнее время никаких особых статей про Svelte не выходило. То есть тезис о том, что автора прям так вот до невозможности достали постоянно выходящие статьи также не подтверждается.
В самом Svelte сейчас по факту community-stage, когда сообщество уже получило на руки рабочий инструмент и наращивает экосистему вокруг него.
Надеюсь мне удалось ответить не агрессивно ))))