• Веб-компоненты в реальном проекте
    0
    В названии статьи «веб-компоненты» можно было бы заменить на «кастомные элементы» — в итоге это стало единственным API, которое я использовал в проекте, и самое проработанное из всей технологии.

    Спасибо за статью. Хочу вас обрадовать, вы фактически использовали весь стандарт Web components, кроме Shadow DOM. Тот же HTML Template используется внутри lit-html, который является шаблонизатором LitElement. Так что все ок. )))
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +2
    Хотя это все мелочи, как именно передаются пропсы/инпуты это не важно.
    Для меня важно когда фреймворк предоставляет подобие архитектуры, т.е. является фреймворком. И тут Angular вне конкуренции.

    В этом вы правы, но есть один момент, который упускается из вида, потому что кто-то когда-то решил поставить в один ряд React, Vue и Angular. Хотя по-сути это не верно.

    В данном случае Angular действительно вне конкуренции, просто потому что это фреймворка другого уровня. В отличии от React, Vue и Svelte, которые являеются UI фреймворками, Angular — это полноценный Application фреймворк и его имеет смысл ставить в один ряд с такие фреймворками как Ember и другими.

    Показательным является то, что поверх каждого из UI фреймворков, также есть и Application фреймворк для создания сайтов и не сложных приложений. Для React это Next, для Vue — Nuxt, для Svelte — Sapper. Именно эти Application фреймворки и дают ту саму архитектуру, работу с роутингом, данными и т.п., а не только работу с view-слоем.

  • Svelte, исчезающий фреймворк, который уже не исчезнет
    –1
    Ну конечно же, плагин для TypeScript подразумевает, что вы в него встраиваете другой язык, иначе в чем смысл?
    Однако, можно типизировать html-шаблоны в шаблонных строках.

    Svelte уже HTML-first и, как я писал выше, и мы в очередной раз выяснили, TS не дает средств работы с такими вещами. Шаблонные строки это тот же JS и никто не сомневается что TS дает работать с JS. Другое дело, что загнать любой кастомный DSL внутрь шаблонных строк тоже не получится. Это просто не удобно.

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

    Я вам ничего плохого не писал и конкретно с вами был весьма корректен. Не нужно строить из себя Робина Гуда, пожалуйста. Это вы пришли в мою статью по той теме, которая вам не интересна. Стали отвечать на мои комментарии и давать решения, не соответствующие проблеме.

    Вы можете писать что угодно, но «караван идет». В будет идти дальше.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Да да, я в курсе. Кстати согласен с вашим комментарием выше. Доклад просто про React+Redux и общая конва треда про стейт внутри сторов, а Redux все еще самый популярный для React вроде. Мне самому кажется что проще застрелиться.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Вашу точку зрения я понял уже давно. В целом даже поддерживаю, особенно применительно к React. Речь по большей части про самих авторов React и то какие именно фичи они считают важными.

    Кстати, ваш пример почему-то напомнил вот этот доклад. Доклад отличный, но после того как видишь насколько сложным может быть код на React + Redux для столь простого кейса, удивляешься стойкости ребят, пишущих на React.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    apapacy Собственно о чем я и писал выше. Хуки в данный момент фактически самый react-way для стейта. Видимо авторы React считаю это верным способом, иначе нафиг им выкатывать большое обновление с еще один ненужным state. Хотя можно было бы сразу реализовать встроенный в React стор по всем flux'aми или что у них там сейчас.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Мне наверное надо глубже изучить Language Service Plugin, но по ссылке опять же Javascript-first код, котором появился кастомный синтаксис. А в Svelte у нас HTML-first код с кастомным синтаксисом и кажется в этом одно из основных отличий. Если опять ошибаюсь, можете меня поправить. Глубоко в Language Service Plugin не смотрел.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    –2
    Можно еще заминусовать мой комментарий, но факт остается фактом.

    Было
    image
    Стало


    Не так уж и плохо за пару дней для «непопулярного» фреймворка.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    То что реактовский state практически бесполезен а стор реализован отдельно ровно ни о чем не говорит. Т.к. state практически не используют, его просто де факто нет. А стор есть хотя и не реактовский.

    На самом деле state юзают очень много кто. Да и старых проектах на state еще навалом. Сами такие время от времени разгребаем.

    Проблема со стором которого нет в реакте относится не только к реакту. Это общая боль всех фрондендов.

    В целом то вы все верно пишете, но у меня тогда вопрос. Если это «общая боль» и все такое, то почему Svelte поставляется со встроенным решением для стора (пусть и весьма примитивным, но зато расширяемым), а ребята из React, которые как вы думаете все понимают, вместо того, чтобы в новой версии React поставить встроенный react-way стор, предлагают для управления стейтом вовсе не стор, а хуки, которые пишутся прямо внутри рендер-функции и, несмотря на свое удобство и лаконичность, кажется довольно сильно сказываются на производительности и требуют постоянных оптимизаций (все эти memo-)? И видимо в качестве насмешки, хуки презентует автор наиболее популярного в React решения для сторов.

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

  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +1
    Хм, а вдруг action52champion и есть тот самый «проплаченный SMMщик»? Специалист по черному PR-у просто.)))
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    state внутри компонента отбюросило меня на пару лет в изучении реакта т.к. я не понимал зачем о нужен и его использоване приводило к разным противоречивым решениям.

    Я сразу написал что это так. Что впрочем не отменяет того факта, что многие проекты использовали state именно как модель. Да и Redux далеко не сразу появился. То есть по-сути, авторы React зашипили его именно со state и именно так предполагали использовать. Это потом они сами же схватились за головы и придумали Flux/Redux.

    С хуками я честно говоря еще не разбирался, вообще.

    А я уже успел. И важно здесь именно то, что это опять же результат мыслительной деятельности авторов React. Не сообщества, которое положим понимает что мешать модель и представление вредно, а именно core-team реакта. А значит, по-сути своей это и есть истинный react-way.

    Из новшеств меня больше заинтересовала suspense которое почему-то никак не зарелизится.

    Самое интересное, что suspense точно также реализуется внутри рендер-функции и за счет ее перезапуска на каждый рендер, то есть точно также лезет в представление.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Более того, есть и тикет с подробным описанием, как этого достичь в Svelte.

    Да видел, но кажется там немало подводных камней.

    Перспективы на поддержку Typescript в Svelte очень радужные.

    Буквально час назад они стали еще более радужными, после выступления на Svelte Society Day чувака из MS, который рассказал как они попробовали Svelte на внутреннем хакатоне, как он им очень понравился. И вроде как в MS есть даже планы на нативную поддержку Svelte со стороны Typescript. Но эту информацию еще нужно проверять.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +1
    Вот понимаю что вы говорите, но есть нюансы.

    redux, relay, mobx, effector

    Это не React и даже не часть React, а по сути даже не часть экосистемы React. Redux/Mobx/Efector юзают и со Svelte.

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

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

    Раньше все это хотя бы было размазано по классу, его свойствам и методам. С приходом хуков все засунули в рендер-функцию, а это примерно то, о чем написал Kroid
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Спасибо за высокую оценку публикации. Очень приятно)
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Насколько я вижу это не дает типизацию в шаблонах. Если я не прав, может есть ссылка где с помощью этой фичи реализована поддержка любого шаблонизатора?
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    ctrl+click

    Не знал что это работает с MAAM. Как реализовано?

    Опять ложь.

    В каком смысле ложь? Так работают модули JS или я не прав в этом? Глобалы конечно тоже работают, но глобалы как бы bad practice, поэтому о них говорить смысла нет.
  • Svelte, исчезающий фреймворк, что всё никак не исчезал
    0
    Согласен, с точки зрения SEO мессенджеры так себе. Но они сейчас наверное самый удобный способ связи. Может у вас есть какие-то предложения?
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Нет, комментарии как раз для непонятности. Там же абракадабра в них. А если серьёзно, то они здорово помогают в изучении view.tree.

    Да, для пониманию view.tree реально все средства хороши. )))

    Есть большая разница между «прочитать что написано» и «понять что происходит». В первом коде понять существенно сложнее.

    Ты написал субъективное мнение без обоснования. Я выше в комментарии написал точно такое же субъективное мнение, но противоположное. Однако обосновал это хоть как-то.

    Для понимания кода компонента знать про МАААМ вообще не обязательно. Даже про работу «хелперов» $mol_mem и $mol_view знать надо не больше, чем «эта штука мемоизирует» и «эта штука — базовый класс».

    Ну как это. У нас JS, а не PHP, в котором классы могут браться «из воздуха» благодаря авто-загрузке. В JS то что не импортировано, не существует в скоупе. Поэтому любому JS разработчику сперва нужно будет разобраться откуда взялись магические классы типа $mol_view и что это вообще.

    В Svelte сверху файла просто и очевидно импортируются хэлперы с вполне говорящими именами, на которые всегда можно ткнуть и посмотреть их код. Сами хелперы как правило не более чем в 10-ток строк кода.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Поддержка TS есть только внутри script и только с использованием специального препроцессора для компилятора Svelte. В шаблонах поддержки типов нет из-за отсутствия поддержки кастомных DSL в самом TS.

    То есть мы устанавливаем препроцессор в настройки компилятора (например можно юзать сразу пакет препроцессоров svelte-preprocess), выставляем тегу script аттрибут type=«typescript» и пишем TS.

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

    Однако тут есть пара моментов:

    1. Писать TS приходится с оглядкой на SvelteScript. Многие вещи TS не понимает, некоторые конструкции TS ломают компиляцию Svelte.
    2. Процесс сборки становится в 2 раза дольше (2 компилятора)

    Поэтому поддержка TS есть, но она не полная и сбоку.

  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    А комментарии там видимо из-за его понятности? ;-) Если не ерничать, то думаю оба примера вполне себе хорошо читаются. Подходы разные, это да, но уверен что даже начинающий JS разработчик поймет что тут написано.

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

    Читая аутпут $mol надо сразу понимать откуда взялись все эти $mol_view и т.п. То есть придется сразу почитать про MAAM. Опять же работа с this. Да и за кулисами же есть ядро, которое дергает за все эти «ниточки».

    В аутпуте Svelte мы видим сразу все что нужно. Однако повторюсь, оба выхлопа выглядят в целом вполне читаемо и понятно.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +2
    Это здраво и так часто бывает. Успеха вам в проекте!
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Каюсь, не удержался) Уж такая забавная фраза была в оригинале))
  • Svelte, исчезающий фреймворк, что всё никак не исчезал
    0
    Вы ушли от ответа. Так это был запланированный breaking change в минорной версии или случайный баг?
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +1
    Я, в свою очередь, не первый раз замечаю что вы пристально следите за моих блоготворчеством. Это приятно, спасибо! ;-)

    «Svelte в любой момент можно скомпилировать в вебкомпоненты», правда «компиляция в веб-компоненты не в приоритете, поэтому ничего удивительного, если у вас там что-то не сложится».
    Забавно.

    Не уверен, что понимаю что именно забавного вы тут видите. Это обычная логика и констатация фактов. Факты следующие:

    Факт 1: Компиляция в веб-компоненты мне может понадобиться в том случае, если они захватят мир. В данный момент до этого далеко, поэтому они не являются приоритетом.

    Факт 2:Svelte уже по всем тестам (ссылку давал где-то по треду) имеет прекрасную поддержку веб-компонентов. В случае если веб-компоненты начнут захватывать мир, приоритет их поддержки изменится и можно будет допиливать пожелания типа «хочу, чтобы Shadow DOM был опциональным». Главное, что их поддержка и принципиальная возможность компиляции в них уже существует.

    Какой из тезисов вам не понятен или как вы выразились «сужает контекст»?

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

    Спасибо, ознакомлюсь на досуге.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Это кстати одна из постоянных тем в дизайне Svelte. Соблюсти баланс между привычным и удобным, и новыми идеями и подходами, невероятно сложно. Если перегнуть палку, то инструмент получится кардинально другой и его будет сложно понять. Если недогнуть, тогда инструмент не будет выделяться чем-то особенным и пройдет мимо. Мне кажется, что Svelte 3 удалось найти некий баланс между двумя этими крайностями и это частично повлияло на то, что он выстрелил.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Кстати довольно верная мысль. Примерно это я и пытался выразить в разделе «Про (НЕ)осознанность».

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

    Иными словами да, Svelte делает многие вещи по-другому, местами удобнее и лаконичнее, но в масштабе это точно также же компонентный фреймворк, как и React или Vue.

    Поэтому я и написал в статье, что вовсе не утверждаю что Svelte — это обязательно и бесповоротно фреймворк будущего, но то что он уже на пороге Большой четверки я не сомневаюсь.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Да я тут немного упростил из-за ненадобности. Собственно в тоже же Vue.extend под капотом тот же VDOM и теми же рендер-функции. Все это лишь разные формы записи по-сути.

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

    Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) сами. В Svelte же мы ограничены исключительно декларативным подходом.

    Да, это верно.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +3
    Было бы интересно узнать о каких именно недостатках гибкости идет речь? Спасибо.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    А разве у Polymer не была довольно приличная экосистема? До сих пор большая часть существующий готовых веб-компонентов завязана на него или что-то из его окружения. Мне почему-то кажется, что основная проблема Polymer была именно в том, что стандарт веб-компонентов довольно долго не могли стандартизировать, а разработчики Polymer уже понаписали своего добра. При этом мир не стоял на месте и получилось так, что Polymer устаревал до того, как стандарт который он реализовывал принимался комитетами.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Думаю потому что всем чего-то не хватает в JS и его обязательно нужно улучшить.))) Кстати, output у Svelte очень понятный, очевидный и легко читается. Можете сами посмотреть в REPL.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +2
    Да собственно прям с первых абзацев — переход на личности:

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

    Ставить подобные диагнозы, это уже перебор.

    Никто не заставлял автора оригинальной статьи писать ту фразу, которую он написал. Дальше каждый делает выводы. Я сделал вывод, что фраза про «психотерапевта» и «выговариваться мне придётся вам» в скопе с явно нервозным тоном публикации, может говорить о наличии депрессии.

    Более того, обратите внимание что за последнее время никаких особых статей про Svelte не выходило. То есть тезис о том, что автора прям так вот до невозможности достали постоянно выходящие статьи также не подтверждается.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Конечно, с интеграцией все идеально: custom-elements-everywhere.com
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +1
    Есть там, в разделе про сообщество.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    –3
    Возможно. С другой стороны action52champion также никто за язык не тянул. Наверное…
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Есть стремления вывести Sapper в 1.0 и добавить таки поддержку Typescript. Рич еще в тихую пилит Svelte GL, который в будущем можно будет использовать для 3D графики и интерфейсов к VR.

    В самом Svelte сейчас по факту community-stage, когда сообщество уже получило на руки рабочий инструмент и наращивает экосистему вокруг него.

    Надеюсь мне удалось ответить не агрессивно ))))
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    Из плюсов, воспользовавшись поводом, еще раз рассказать всем про Svelte ;-)
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +1
    этом пункте вы полностью провалились.

    Эх, я очень старался, честно.))) Возможно сыграло то, что все посылы оригинальной статьи были так или иначе направлены на меня. Только в более завуалированной форме. Я предпочитаю открытость и честность.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    0
    При компиляции в Web Components, который состоит из нескольких стандартов, среди которых Custom Elements и Shadow DOM, Svelte пытается использовать максимум возможностей встроенных в браузер. Иными словами компоненты получаются с использованием Shadow DOM для их изоляции. В этом ишаке предлагается, чтобы это поведение можно было настраивать.

    В целом думаю было бы не плохо иметь такую возможность. Однако так как компиляция в веб-компоненты не является приоритетной для Svelte, а переделывать это видимо не просто, думаю это предложение имеет не очень высокий приоритет.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    +2
    Было бы не плохо использовать какие-то конкретные примеры для аргументации. Насколько я помню, большая часть протагонистов просто выдавала свои субъективные мнения за объективную реальность, требуя «правильных» ответов взамен тех, которые им давали.

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

    Странно приходить из React во Vue и с порога требовать, условно говоря, делать `this.setState({ foo: 1 })`, а не `this.foo = 1;`. А если оказывается что setState вовсе не нужен и есть способ лучше, уходить ворча, что все не так, да не эдак.

    В телеграм чат часто приходят с готовым решением задачи, которое нужно срочно натянуть на Svelte, даже если оно натягивается с трудом. Такова природа человека — сперва мы пытается работать так как привыкли. Я и другие ребята в чате, кто активно юзает Svelte, всегда предлагаем говорить о сути задачи и стараемся предложить более подходящее решение. Собственно об этом я написал в разделе «Про (НЕ)осознанность». Если есть возможность перечитать — сделайте это пожалуйста.
  • Svelte, исчезающий фреймворк, который уже не исчезнет
    –10
    Я так понял, статью вы не осилили. Жаль, я так старался для вас. Если кратко — все что вы написали, в той или иной степени, НЕ соответствует действительности и является лишь плодом ваших собственных мироощущений.

    Почему? Все ответы есть в статье.