Комментарии 241
Вообще, по ощущениями от Svelte у многих дико бомбит — мне кажется меньше, чем при появлении Vue например.
Слишком агрессивный пиар, даже для хабра «слишком». Бомбит-то людей от этого, со svelte как с инструментом — всё нормально. Ну сырой, ну молодой еще, ничего сверхъестественного.
А можно пример, в чем именно агрессивный?
Здесь на хабре — например, неоднократно декларировалась (сейчас я уж не скажу, в статьях или только в комментах, но в комментах точно) точка зрения вида «если вам что-то не нравится (например, длительный игнор встроенной поддержки тайпскрипта) — то дело в вас, а svelte развивается идеологически правильно».
Короче, когда пишешь, что именно тебе не нравится, а в ответ неизменно получаешь «ну это проблема на вашей стороне, а на нашей всё прекрасно» — это очень такой себе стиль пиара.
Я пишу статьи не для того, чтобы давать людям субъективно правильные на их взгляд ответы, а чтобы рассказать об инструменте и своем опыте с ним.
Странно приходить из React во Vue и с порога требовать, условно говоря, делать `this.setState({ foo: 1 })`, а не `this.foo = 1;`. А если оказывается что setState вовсе не нужен и есть способ лучше, уходить ворча, что все не так, да не эдак.
В телеграм чат часто приходят с готовым решением задачи, которое нужно срочно натянуть на Svelte, даже если оно натягивается с трудом. Такова природа человека — сперва мы пытается работать так как привыкли. Я и другие ребята в чате, кто активно юзает Svelte, всегда предлагаем говорить о сути задачи и стараемся предложить более подходящее решение. Собственно об этом я написал в разделе «Про (НЕ)осознанность». Если есть возможность перечитать — сделайте это пожалуйста.
Хотя если он вам так нужен, тогда о каком Vue может идти речь? Поддержка TS там ± такая же как в Svelte.
TypeScript — это не синтаксический сахар для корпораций, это автоматизация работы/тестирования, статический анализ, вместе с Реактом шел Flow, а затем и полноценная поддержка TS.
Писать на чистом JavaScript в 2020 — это откат назад, в прошлое, где нужно проверять типы руками и писать тесты там, где TS покрывает этот код автоматически, синтаксисом.
Та же проблема с Angular и шаблонами в нем, с учетом директив, пайпов и всего того, что можно засунуть в шаблон — это нереальная боль. С другой стороны во всем остальном, Angular полностью поддерживает TS.
Последняя версия Vue достаточно хорошо поддерживает типизацию из коробки, но до Реакта далеко.
Конечно, есть инструменты для статического анализа и шаблонов ангуляра и Svelte, но говорить в 2020 году, что статическая типизация во Frontend только для корпораций — это провокация или глупость.
Да нет, поддержка TS в Ангуляре далеко не полная. Вот что я с ходу помню:
Всевозможные View/Content Child/Query никак не проверяются на корректность. Можно написать какую-нибудь ерунду вроде
@ContentChild(Foo) foo: Barи она успешно скомпилируется, хотя казалось бы ошибку заметить несложно. Плюс сюда же накладываются нетипизируемые щаблоны, из-за которых при выборе по id может попасться объект вообще любого типа — счастливой отладки, блин.
Они же не дружат со строгим режимом и проверками на null.
При динамической загрузке модулей под видом NgModule в рантайме может оказаться NgModuleFactory.
ну не знаю… я люблю JS или Python больше чем TS, дело вкуса, стиля разработки и области.
А можно пример, в чем именно агрессивный? Например данная статья написана довольно спокойно.
Да собственно прям с первых абзацев — переход на личности:
Немотря на то, что автор оригинальной статьи, уважаемый action52champion, явно находится в депрессивном состоянии,
Ставить подобные диагнозы, это уже перебор.
Да собственно прям с первых абзацев — переход на личности:
А вы оригинальную то статью читали? Если не уловили, то там речь шла только о моих статьях, поэтому все набросы, коих там полно, также адресуются мне.
Ставить подобные диагнозы, это уже перебор.
Никто не заставлял автора оригинальной статьи писать ту фразу, которую он написал. Дальше каждый делает выводы. Я сделал вывод, что фраза про «психотерапевта» и «выговариваться мне придётся вам» в скопе с явно нервозным тоном публикации, может говорить о наличии депрессии.
Более того, обратите внимание что за последнее время никаких особых статей про Svelte не выходило. То есть тезис о том, что автора прям так вот до невозможности достали постоянно выходящие статьи также не подтверждается.
автор оригинальной статьи, уважаемый action52champion, явно находится в депрессивном состоянии, вероятно вызванном самоизоляцией и мировым кризисомНа мой взгляд, Хабр не площадка для персональных нападок и всякой соловьёвщины, такое на заборе-то противно читать.
Вообще, по ощущениями от Svelte у многих дико бомбит — мне кажется меньше, чем при появлении Vue например
Парадокс Блаба в действии, я считаю. Люди привыкли жить в уютном теплом мирке любимой технологии и яростно сопротивляются подсознательным мыслям «А вдруг действительно окажется лучше и все перейдут на него, а я останусь не удел… Надо переучиваться? Но я боюсь переучиваться. Нет! Нет! И еще раз нет! Я не настолько хорош, чтоб освоить новый фреймворк/язык».
Svelte другой, а люди боятся нового по своей природе, вот и все.
Может не настолько, но времени, инвестированного в изучение реакт/ангулар/вью/… жалко
Svelte другой, а люди боятся нового по своей природе, вот и все.
Меня более смущает не то что он другой, а то что он такой же.
Например другой подход — это скажем нативные веб-компоненты или Polymer в качестве адаптера для браузеров не поддерживающих веб-компоненты.
Все эти "разности" большой тройки+svelte быстро исчезают если абстрагироваться от мелких деталей.
Особенно весело выглядят в разных статьях примеры кода на Angular/React/Vue/Svelte (выбрать один из вариантов по своему усмотрению) после которых победоносно дается другой пример кода с эпиграфом: "А теперь зацените как это можно написать на Svelte/Vue/React/Angular" — и приводится фрагмент кода в стиле найдите N > 0 отличей.
Сейчас реактивность в моде (и не зря, хорошая штука) — разница только в реализации) Но под капотом у svelte все же по другому, и к этому надо привыкать.
А когда показываешь что-то совершенно другое, все плачутся, что всё слишком не похоже на то, к чему они привыкли.
Действительно, одна из проблем Svelte и понимании его, долгое время заключалась в том, что он слишком похож на существующие решения. Именно поэтому ключевые отличия, которые конечно же имеются, долго оставались незамеченными. И только с выходом Svelte 3 различий стало больше, хотя по сути все равно подходы используются те же.
Иными словами да, Svelte делает многие вещи по-другому, местами удобнее и лаконичнее, но в масштабе это точно также же компонентный фреймворк, как и React или Vue.
Поэтому я и написал в статье, что вовсе не утверждаю что Svelte — это обязательно и бесповоротно фреймворк будущего, но то что он уже на пороге Большой четверки я не сомневаюсь.
Другой смол, а не это)
Спасибо этим срачам, я нашёл время и посмотрел на svelte подробнее. 32000 звёзд на гитхабе внушают уважение и снимают вопросы о популярности.
В Svelte заложен механизм трекинга зависимостей в момент компиляции, который в разы упрощает механизмы change detection и применения изменений в рантайме.
Где прочитать как это работает внутри? В туторале я видел сомнительные штуки вроде obj = obj, чтобы запустить этот самый change detection.
Что будет, если я в цикле начну менять свойства объекта, запуская change detection. Я рискую 1000 раз запустить рендер или же рендер запустится после цикла и будет только одна отрисовка? Опять же — как это работает?
Смущает этап компиляции, не сломает ли он мой код? Хочется знать как конкретно оно работает.
Вот: svelte.dev/repl/d69576cba0944f0daabca709ff928b11?version=3.21.0
P.S. это заняло у меня аж целых 2 минуты от силы, это гораздо меньше, чем время, затраченное вами на написание этого комментария.
Где прочитать как это работает внутри?
Вот тут и вот тут. Там нет ничего более сверхъестественного, кроме заворачивания ваших деклараций в то, что предоставляет svelte/store. И да, у этого есть конечно же есть caveats, типа необходимости объявлять что-то только на верхнем уровне модуля, чтоб это было завернуто в стор.
Смущает этап компиляции, не сломает ли он мой код? Хочется знать как конкретно оно работает.
Читайте исходники, сейчас, увы, это самый действенный способ понять, где именно что-то идёт не так. Сообщения об ошибках самой svelte — варьируются по полезности, а уж если что-то не так в svelte, то и вовсе бесполезны для вас, как юзера.
EDIT: Пардон, не «исходники», а результат компиляции, конечно же. Этого скорее всего достаточно будет для понимания множества проблем.
svelte/store никак не связан с механизмом реактивности Svelte. Это минималистическая реализация сторов аля Observable, работает в рантайме, т.е. спокойно можно использовать отдельно от Svelte, в своих проектах.
Это минималистическая реализация сторов аля Observable, работает в рантайме, т.е. спокойно можно использовать отдельно от Svelte, в своих проектах.
В сравнении с той же MobX — это тачка vs 18-wheeler, всё ж таки. Синтаксического сахара никакого, наглядности в коде тоже особо не создаётся. Ну да, имплементация атома — но их таких десятки.
В вашем сравнении, я бы сказал, что это скорее колесо от 18-wheeler. Минимальный кирпичик, легко кастомизируемый под совершенно разные задачи. Реализаций сторов миллион, и Svelte совсем не обязывает использовать коробочный вариант, можно и MobX использовать. Для коробочного варианта фреймворк предлагает "сахар" в своих компонентах в виде автоподписок, но этот же "сахар" будет работать со всем observable-подобным(т.е. любой объект с методом subscribe), например популярный RxJS.
PaulMaly, спасибо за статью. Получилось почти что неплохо. Но лично для меня
интересной и главное НЕ злой, представив все как некое подобие интервью автора оригинальной статьи со мной
в этом пункте вы полностью провалились. Ни разу не видел хорошего интервью, где интервьюируемый переходит на личности и оскорбления интервьюера. Как минимум поскольку последний чаще всего заведомо хуже разбирается в теме.
Если выкинуть все эти переходы на личности и эмоции с вашей стороны, то статья отличная
Я не защищаю оригинальную статью.
На мой взгляд, каждый должен отвечать за себя, и в данном случае автору данной статьи, стоило сохранять бОльшую нейтральность, а не опускаться на уровень другого автора.
Представьте, какой-нибудь студент будет брать интервью у Uncle Bob'a, а тот будет ему отвечать, что тот вообще не рабирается в программировании и архитектуре, и должен сперва что-то сделать достойное, чем вообще разговаривать
Но каждый, конечно, должен отвечать за себя.
(удалено, дубликат)
этом пункте вы полностью провалились.
Эх, я очень старался, честно.))) Возможно сыграло то, что все посылы оригинальной статьи были так или иначе направлены на меня. Только в более завуалированной форме. Я предпочитаю открытость и честность.
Мне кажется, если бы вы оставили статью на ночь, переспать, и перечитали со свежей головой, то половину негатива бы выкинули.
Меня зовут Павел Малышев, я автор всех тех замечательных статей, которые так «переполняют» тебя
Например, последнюю сноску можно выкинуть, от этого статья ничего не потеряет, а вы выиграете +1 к уважению
Чем меньше эмоций, тем солиднее и полезнее выглядит статья, имхо.
Но все равно спасибо, я узнал пару интересных технических вещей для себя.
Возможно евангелисты Svelte проплачены психотерапевтам, а код тут совсем не при чем. В следующих статьях будут прямые номера?
В самом Svelte сейчас по факту community-stage, когда сообщество уже получило на руки рабочий инструмент и наращивает экосистему вокруг него.
Надеюсь мне удалось ответить не агрессивно ))))
Правильно ли я понимаю, что TS можно и сейчас использовать в svelte-компонентах, нельзя только в реактивность через метку $?
Ну тогда некорректно говорить, что ts не поддерживается — скорее поддерживается, кроме пары фич. А что через препроцессоры — так вроде альтернатив то нет. Браузеры в ts не умеют, вроде даже Deno транспилирует перед выполнением.
То есть мы устанавливаем препроцессор в настройки компилятора (например можно юзать сразу пакет препроцессоров svelte-preprocess), выставляем тегу script аттрибут type=«typescript» и пишем TS.
Далее, во время сборки, сперва код проходит через компилятор TS, проверяются типы и все такое, потому уже сгенерированный TS-ом JS идет в Svelte.
Однако тут есть пара моментов:
- Писать TS приходится с оглядкой на SvelteScript. Многие вещи TS не понимает, некоторые конструкции TS ломают компиляцию Svelte.
- Процесс сборки становится в 2 раза дольше (2 компилятора)
Поэтому поддержка TS есть, но она не полная и сбоку.
Однако, можно типизировать html-шаблоны в шаблонных строках.
И да, как я уже написал выше, это не просто какая-то блажь, основная боль в таких фреймворках — это вручную искать соответствие между шаблоном и кодом.
И встроить в TypeScript шаблонные строки можно и достаточно несложно. А вот наоборот как подтягивать в кастомный html все структуры и интерфейсы для сопоставления типов из языка программирования, с нынешними инструментами — это большой вопрос.
Но конечно, смысла говорить об этом с людьми, которые считают других психически больными, а сами вручную на чистом JS бегают ищут ошибки типов и думают, что автоматизация — это удел корпораций, нет, с такими людьми спорить бесполезно.
Ну конечно же, плагин для TypeScript подразумевает, что вы в него встраиваете другой язык, иначе в чем смысл?
Однако, можно типизировать html-шаблоны в шаблонных строках.
Svelte уже HTML-first и, как я писал выше, и мы в очередной раз выяснили, TS не дает средств работы с такими вещами. Шаблонные строки это тот же JS и никто не сомневается что TS дает работать с JS. Другое дело, что загнать любой кастомный DSL внутрь шаблонных строк тоже не получится. Это просто не удобно.
Но конечно, смысла говорить об этом с людьми, которые считают других психически больными, а сами вручную на чистом JS бегают ищут ошибки типов и думают, что автоматизация — это удел корпораций, нет, с такими людьми спорить бесполезно.
Я вам ничего плохого не писал и конкретно с вами был весьма корректен. Не нужно строить из себя Робина Гуда, пожалуйста. Это вы пришли в мою статью по той теме, которая вам не интересна. Стали отвечать на мои комментарии и давать решения, не соответствующие проблеме.
Вы можете писать что угодно, но «караван идет». В будет идти дальше.
Это вы пришли в мою статью по той теме, которая вам не интересна.
Да, все уже поняли, вы видите всех насквозь. И про меня все знаете. И даже куда мне ходить и что мне интересно.
Стали отвечать на мои комментарии и давать решения, не соответствующие проблеме.
Я даю комментарии, отвечающие проблеме, если вы их не понимаете — перечитайте еще раз.
Svelte уже HTML-first и, как я писал выше, и мы в очередной раз выяснили, TS не дает средств работы с такими вещами.
Для вас не дает. Только вы зачем-то зашли в мой комментарий и даете ответ на мой комментарий, который написан не для вас (как я уже сказал, с вами спорить бесполезно). Он написан для людей, которым важна эффективность, а не религиозные высказывания про корпорации, html-first или психику других людей.
HTML — это строка, строки можно типизировать с помощью плагинов в TypeScript, пример я скинул.
То, что Svelte не поддерживает полноценно из коробки TypeScript и делает неудобным работу с HTML — это проблема Svelte, можете называть ее html-first, если так хочется.
Давайте я лучше расскажу в чём проблема. HTML, как и любой DSL, конечно, можно засунуть в строку, но тут есть проблемы, которые MS всё никак не торопится решать в TS:
Чтобы показывать подсказки в этой строке нужно иметь информацию о доступных в контексте её написания типах.
Нет возможности предоставлять тайпскрипту типы, декларируемые в такой строке. Для компилятора это всего лишь строка, не более.
Соответственно, компилятор не протайпчекает стык между TS и DSL.
И конечно на выходе он выдаст в рантайм строку, которую ещё надо будет распарсить и транспилировать в рантайме.
Вот пример с lit-html.
Обратите внимание, шаблонные строки — это не просто строки: «Шаблонными литералами называются строковые литералы, допускающие использование выражений внутри.».
Вот эти самые выражения уже типизированы из коробки. Если этого недостаточно, вы можете добавить какую-то функциональность с помощью плагина.
1. Эта информация есть, либо через выражения, либо через плагин.
2. --=--
3. --=--
4. HTML-файл шаблона — это тоже просто строка, это причем тут вообще, это дело фреймворка уже, что он хочет строки использовать. А если вы просто, как красиво в реакте реализовали JSX — то абсолютно с вами согласен.
И да, думать о том, как новый супер язык будет интегрирован с реальным кодом нужно до, а не после.
Когда вы пишете всякие ${} вы фактически выходите из строки обратно в JS. Код вида:
foo`xxx${bar}yyy`фактически является синтаксическим сахаром для:
foo( 'xxx', bar , 'yyy' )Внутри строки же всё автодополнение ограничивается некоторыми захардкоженными вариантами и не включает то, что вы пишете в коде.
Вы не поверите, я и изначально думал и сейчас ищу способы отказаться от DSL в пользу чего-то, что можно нормально интегрировать в TS. Пока как-то не выходит.
Более того, есть и тикет с подробным описанием, как этого достичь в Svelte. Перспективы на поддержку Typescript в Svelte очень радужные.
Более того, есть и тикет с подробным описанием, как этого достичь в Svelte.
Да видел, но кажется там немало подводных камней.
Перспективы на поддержку Typescript в Svelte очень радужные.
Буквально час назад они стали еще более радужными, после выступления на Svelte Society Day чувака из MS, который рассказал как они попробовали Svelte на внутреннем хакатоне, как он им очень понравился. И вроде как в MS есть даже планы на нативную поддержку Svelte со стороны Typescript. Но эту информацию еще нужно проверять.
Как мне кажется, дело здесь совсем не в Svelte, а в остальных популярных фреймворках, на которые все регулярно пеняют, что они медленные и сложные. Svelte здесь приходится ко столу, как "молодой и перспективный", вот его регулярно и припоминают.
Когда Svelte перейдет через пик завышенных ожиданий, и на нем тоже будет написано немало легаси-кода, появится новый фреймворк, и внимание перейдет на него.
Хотя всё дело обычно в нашем собственном коде, а не зависимостях.
— Количество вакансий на Svelte околонулевое
— Слабый результат в плане захвата рынка — VueJS достиг за 3 года большего чем Svelte за тот же промежуток времени.
— Агрессивное сообщество, считающее себя белым и пушистым
— Не в меру агрессивный пиар для столь непримечательного фреймворка — например посчитайте число статей на хабре по какому-нибудь Infernojs и по Svelte.
— Складывается впечатление, что фреймворк ставит во главу угла идеологию, а не решение практических проблем, что пытается решить проблемы, которые в принципе не решаемы в рамках веб-платформы.
— Фреймворк противопоставляется большой тройке, хотя ни по коммьюнити, ни по экосистеме не готов к этому.
— Есть проблемы интеграции Svelte с нативными веб-компонентами, причем это тянется аж с 18 года.
— Мажорные версии Svelte несовместимы между собой, при этом заявляется, что фреймворк готов для использования в продакшене.
Искренне желаю успеха Svelte, но лишь за счет победы в честной конкуренции с другими открытыми решениями, без использования SMM. А то дурной пример заразителен.
— Мажорные версии Svelte несовместимы между собой, при этом заявляется, что фреймворк готов для использования в продакшене.
Эм, на то они и мажорные. По вашему, как завезли хуки в React или composition api в Vue3 — сразу вон с продакшена эти нестабильные фреймворки/библиотеки?
Эмм, это же вроде немного разные категории. И Vue и React позволяют смешивать старое и новое API в одном приложении, позволяя переехать постепенно. А можно ли Svelte2 компоненты подключить в Svelte3 без переписывания?
Через адаптер разве что. Но соглашусь пример не очень контекстный вышел, хотел сказать, что ничто не вечно и подходы работавшие много лет(приносящие деньги, позволившие стать популярными за 3 года и прочее по тексту) тоже переосмысливаются и заменяются. Svelte3 смог радикально поменять свою парадигму за счет немногочисленности его использования до v3. Изначально предполагалось написать тулинг для конвертации компонентов, но никто не просил и забылось. Если доживем до предпосылок необходимости v4, то такой фокус провернуть уже не получится.
А можно ли Svelte2 компоненты подключить в Svelte3 без переписывания?
Да, достаточно сделать один из них веб-компонентом.
Сильная сторона Svelte — в интеграции с чем угодно, было бы очень странно если бы при этом его было нельзя интегрировать сам с собой.
Да, достаточно сделать один из них веб-компонентом.
Таким образом можно интегрировать любой фреймворк с любым другим. Но при этом компоненты теряют важные возможности, вроде доступа к общему глобальному стору. Поэтому за полноценную интеграцию это не считается.
Почему? Все ответы есть в статье.
В целом думаю было бы не плохо иметь такую возможность. Однако так как компиляция в веб-компоненты не является приоритетной для Svelte, а переделывать это видимо не просто, думаю это предложение имеет не очень высокий приоритет.
— Есть проблемы интеграции Svelte с нативными веб-компонентами, причем это тянется аж с 18 года.
Ну это же скорее не проблема интеграции, а отсутствие фичи.
Однако так как компиляция в веб-компоненты не является приоритетной для Svelte, а переделывать это видимо не просто, думаю это предложение имеет не очень высокий приоритет.
Я уже не в первый раз замечаю, что вы то ли намеренно, то ли неосознанно отвечаете на каждый выпад в адрес svelte с максимально возможным сужением контекста. То есть, вот скажем, в этой ветке комментариев вы пишете «веб-компоненты — это не приоритетно, поэтому ничего удивительного, что чего-то не сделано», в то время как в соседней теме вы комментируете мой выбор вебкомпонентов, и пишите:
Не взяли и не взяли. Дело ваше, проблем нет. Если вы умеете оценить свои потребности и риски, это отлично. У меня другой опыт, мы наоборот не взяли LitElement вот по каким причинам: 1) веб-компоненты не везде, полифилы работают коряво; 2) LitElement в сравнении со Svelte намного более громоздкий; 3) Svelte в любой момент можно скомпилировать в web components, на случай если они захавают мир (очень сомневаюсь).
«Svelte в любой момент можно скомпилировать в вебкомпоненты», правда «компиляция в веб-компоненты не в приоритете, поэтому ничего удивительного, если у вас там что-то не сложится».
Забавно.
Мне вот правда интересно, вы намеренно ведете себя так, что вот эта вот статья прямо 100% про вас, или у вас это неосознанно выходит?
«Svelte в любой момент можно скомпилировать в вебкомпоненты», правда «компиляция в веб-компоненты не в приоритете, поэтому ничего удивительного, если у вас там что-то не сложится».
Забавно.
Не уверен, что понимаю что именно забавного вы тут видите. Это обычная логика и констатация фактов. Факты следующие:
Факт 1: Компиляция в веб-компоненты мне может понадобиться в том случае, если они захватят мир. В данный момент до этого далеко, поэтому они не являются приоритетом.
Факт 2:Svelte уже по всем тестам (ссылку давал где-то по треду) имеет прекрасную поддержку веб-компонентов. В случае если веб-компоненты начнут захватывать мир, приоритет их поддержки изменится и можно будет допиливать пожелания типа «хочу, чтобы Shadow DOM был опциональным». Главное, что их поддержка и принципиальная возможность компиляции в них уже существует.
Какой из тезисов вам не понятен или как вы выразились «сужает контекст»?
Мне вот правда интересно, вы намеренно ведете себя так, что вот эта вот статья прямо 100% про вас, или у вас это неосознанно выходит?
Спасибо, ознакомлюсь на досуге.
— Не в меру агрессивный пиар для столь непримечательного фреймворка — например посчитайте число статей на хабре по какому-нибудь Infernojs и по Svelte.
Господа, не смейте писать статьи по интересующим вас темам больше нормы! За нормой, пожалуйста, в очередь к action52champion!
action52champion, вы как себе это представляете? Люди пишут на интересующую их тему и вроде имеют на это право, согласно правилам Хабра. Если у какой-то темы много статей, значит есть неравнодушные люди, значит есть комьюнити.
— Количество вакансий на Svelte околонулевое
Без учёта вакансий где исполнителю дают право выбирать фреймворк на его усмотрение — это ничего не значит. Моим клиентам, например, совершенно всё равно, хоть на BF — главное результат в рамках заданных временных и иных параметров.
— Агрессивное сообщество, считающее себя белым и пушистым
В любом большом сообществе есть агрессивные элементы, считающие себя белыми и пушистыми.
— Слабый результат в плане захвата рынка — VueJS достиг за 3 года большего чем Svelte за тот же промежуток времени.
— Фреймворк противопоставляется большой тройке, хотя ни по коммьюнити, ни по экосистеме не готов к этому.
Вспомните историю Линукса — ни рынка, ни большой коммьюнити, да и конкуренция ого-го — и так очень много лет. А потом как понеслось… Конечно, может не совсем корректно сравнивать операционку и фреймворк, но всё же — пока ещё рано подбивать итоги.
В общем, неубедительно — мы не знаем как будет через несколько лет, и есть как минимум несколько десятков тысяч человек (если судить по Github) вряд-ли с вами согласятся, а в то что большинство из них агрессивны — верится с трудом.
В чем секрет? Нет, мы не используем костыли по приколачиванию typescript внутрь .svelte файлов. У нас просто не смешивается логика и UI. Мы пишем логику в .ts файлах, где она отлично типизируется, а в .svelte файлах у нас только декларативное описание компонента.
Сам svelte написан на typescript и очень хорошо типизирован, получше многого, что встречается на npm. Даже импортируя что-то из svelte/internal (там очень уж удобные абстракции для прямого взаимодействия с DOM, например в тех же экшенах) мы получаем отлично типизированные функции. Если сравнивать типизацию svelte с типизацией vue (проще выбросить и написать свою, ибо не знает даже о половине тех вещей, что есть в Vue) или react (неплохо, но много недочетов. Например почему SyntheticEvent будучи дженериком от EventTarget'а требует тайпгварда для event.target, чтоб воспользоваться методами, которые там гарантировано есть?)
Ну и немного о javascript и его надмножествах:
typescript является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания типов;
jsx является надмножеством javascript, это как javascript но с дополнительным синтаксисом для описания xml шаблонов;
svelte является надмножеством javascript и html, это как javascript и html но с дополнительным синтаксисом для описания реактивности и манипуляций с DOM.
Ни один из них, не является надмножеством другого… хотя нет, есть tsx, который является надмножеством typescript. И сообщество react должно быть благодарно тому, что у Microsoft так много работы с xml, а jsx оказался очень удобным для его построения, настолько, что они добавили его в свой язык. Не случись этого, в jsx до сих пор не было бы typescript.
Однофайловым компонентам vue и svelte повезло меньше, что впрочем не мешает использовать typescript за их пределами. Вы же не тянете логику внутрь компонента, где по идее должен быть только UI?
Куда тянуть логику UI? Банальный цикл/map по коллекции? Или в нём типищация не нужна?
А с TS упал бы во время компиляции. В целом это более предпочтительно, т. к. тесты пишут не все или пишут, но все кейсы не покрыты. Да и в рантайме можно долго ждать, что звезды сложились так, что баг воспроизведётся и пользователь создаст баг-репорт, по которому можно будет баг локализовать и исправить.
Хотя бы на уровне структур из примитивных типов много где пишут. А тесты как-то обычно особо не ревьювят как раз, если TDD не введено. так, CI прошло, покрытие не упало — апрув.
Которые не сваливаются при первом неудобном случае в tsignore, as any, as unknown as Some, disable eslint rule и пр… Скажем тот же параметризм высшего порядка это тема слишком сложная для большинства разработчиков (увы).
Я бы не сказал, что прямо слишком сложная. Скорее совпадение нескольких факторов:
- нет особой мотивации изучать
- нет материалов, дающих такую мотивацию
- нет удобных средств отладки типов в целом
По последнему пункту много нареканий вообще при работе с типами (которые type). У нас вот практически полный отказ от type в пользу interface исключительно по причине невнятных сообщение об ошибках. И вполне по этой причине вместо сложного типа могут на код-ревью вынудить использовать any.
Когда дело доходит до хитрых случаев то вообще часто непонятно, что и как делать. Вот всякий раз когда я сталкиваюсь с d.ts файлами у меня что-нибудь идёт не так :( Собираю все виды ошибок из самых глубин преисподнейtypescript компилятора.
Или скажем когда есть хитрая комбинация high-order-functions с генериками, и часто high-order-rank polymorphism-ом, то там очень часто всё куда-то как-то разъезжается и умирает (молча превращает всё в any). Я даже стал писать тесты на типы, настолько хрупкая эта инфраструктура порой.
Ну и непонятно как это всё вменяемо дебажить. Одна из наиболее используемых мною штук в vscode это ctrl+shift+p + Typescript: Restart Typescript Server.
когда есть хитрая комбинация high-order-functions с генериками, и часто high-order-rank polymorphism-ом
Keep It Simple и будет No Problemos. Более одного HOF'a это уже перебор. Всегда удивлялся тому, как народ сам всё усложняет на пустом месте, а потом волосы на голове рвет, потом плюют на все это и увольняются оставляя свое чудо наследие другим.
Приведёте пример такого невнятного сообщения? Может подскажу как сделать его внятным.
Например почему SyntheticEvent будучи дженериком от EventTarget'а требует тайпгварда для event.target, чтоб воспользоваться методами, которые там гарантировано есть?
Потому что в таких случаях вам нужен не event.target, а event.currentTarget. event.target — это тот элемент, на котором возникло событие, и он может быть где-то в глубине DOM, если событие не было обработано на нём самом, а всплыло выше. А event.currentTarget — это тот самый элемент, на котором установлен обработчик.
Следующий митап должен был быть в Питере в апреле-мае, но пандемия внесла свои коррективы в наши планы.
Зарубежные коллеги завтра (26.04.2020) организуют очень обширный онлайн-митап — https://sveltesociety.dev/. Спикеры со всего мира, включая создателя фреймворка.
У компиляции есть одно не очень приятное свойство — ты в итоге отлаживать будешь не то, что написал. Если в babel, ts это отличается от написанного, но не прям очень-очень, то в svelte на выходе получается сильно измененный код. И иногда это может стать болью. Хотя есть расширения для браузера, позволяющие отлаживать со Svelte-компонентами. И все комьюнити-дривен кстати))))
И поддержка Sourcemap имеется
С одной стороны, нативный мир живёт с этим уже десятки лет, и ничего. Агрессивная оптимизация может изменить ассемблерный выхлоп до неузнаваемости, при этом выкинув 9/10-х исходной логики за ненадобностью. С другой стороны, я иногда смотрю на результаты всяких там DI или Service Locator и понимаю, что отлаживать это практически невозможно из-за адового количества подкапотной магии. Так что я до сих пор не совсем понимаю, почему во фронтэнде не прижился подход с JS-as-assembly.
Это не так. Простейший пример порождает:
function create_fragment(ctx) {
let input;
let t0;
let p;
let t1;
let t2_value = (/*name*/ ctx[0] || "stranger") + "";
let t2;
let t3;
let dispose;
return {
c() {
input = element("input");
t0 = space();
p = element("p");
t1 = text("Hello ");
t2 = text(t2_value);
t3 = text("!");
attr(input, "placeholder", "enter your name");
},
m(target, anchor, remount) {
insert(target, input, anchor);
set_input_value(input, /*name*/ ctx[0]);
insert(target, t0, anchor);
insert(target, p, anchor);
append(p, t1);
append(p, t2);
append(p, t3);
if (remount) dispose();
dispose = listen(input, "input", /*input_input_handler*/ ctx[1]);
},
p(ctx, [dirty]) {
if (dirty & /*name*/ 1 && input.value !== /*name*/ ctx[0]) {
set_input_value(input, /*name*/ ctx[0]);
}
if (dirty & /*name*/ 1 && t2_value !== (t2_value = (/*name*/ ctx[0] || "stranger") + "")) set_data(t2, t2_value);
},
i: noop,
o: noop,
d(detaching) {
if (detaching) detach(input);
if (detaching) detach(t0);
if (detaching) detach(p);
dispose();
}
};
}
function instance($$self, $$props, $$invalidate) {
let name = "";
function input_input_handler() {
name = this.value;
$$invalidate(0, name);
}
return [name, input_input_handler];
}
class App extends SvelteComponent {
constructor(options) {
super();
init(this, options, instance, create_fragment, safe_not_equal, {});
}
}Для сравнения, как выглядит похожий пример в действительно понятном, очевидном и легко читаемом виде:
"use strict";
var $;
(function ($) {
class $my_app extends $mol_view {
/**
* ```
* sub /$mol_view
* <= Input
* <= Output
* ```
**/
sub() {
return [this.Input(), this.Output()];
}
/**
* ```
* Input $mol_string
* value?val <=> name?val
* placeholder \enter your name
* ```
**/
Input() {
return ((obj) => {
obj.value = (val) => this.name(val);
obj.placeholder = () => "enter your name";
return obj;
})(new this.$.$mol_string());
}
/**
* ```
* name?val \stranger
* ```
**/
name(val, force) {
return (val !== void 0) ? val : "stranger";
}
/**
* ```
* Output $mol_view sub /string <= name
* ```
**/
Output() {
return ((obj) => {
obj.sub = () => [this.name()];
return obj;
})(new this.$.$mol_view());
}
}
__decorate([
$mol_mem
], $my_app.prototype, "Input", null);
__decorate([
$mol_mem
], $my_app.prototype, "name", null);
__decorate([
$mol_mem
], $my_app.prototype, "Output", null);
$.$my_app = $my_app;
})($ || ($ = {}));В пользу кода на Svelte скажу, что если бы ты оставить импорты, то все таки в нем меньше магии, потому что там намного очевиднее что и откуда берется.
Читая аутпут $mol надо сразу понимать откуда взялись все эти $mol_view и т.п. То есть придется сразу почитать про MAAM. Опять же работа с this. Да и за кулисами же есть ядро, которое дергает за все эти «ниточки».
В аутпуте Svelte мы видим сразу все что нужно. Однако повторюсь, оба выхлопа выглядят в целом вполне читаемо и понятно.
Нет, комментарии как раз для непонятности. Там же абракадабра в них. А если серьёзно, то они здорово помогают в изучении view.tree.
Есть большая разница между "прочитать что написано" и "понять что происходит". В первом коде понять существенно сложнее.
Для понимания кода компонента знать про МАААМ вообще не обязательно. Даже про работу "хелперов" $mol_mem и $mol_view знать надо не больше, чем "эта штука мемоизирует" и "эта штука — базовый класс".
Нет, комментарии как раз для непонятности. Там же абракадабра в них. А если серьёзно, то они здорово помогают в изучении view.tree.
Да, для пониманию view.tree реально все средства хороши. )))
Есть большая разница между «прочитать что написано» и «понять что происходит». В первом коде понять существенно сложнее.
Ты написал субъективное мнение без обоснования. Я выше в комментарии написал точно такое же субъективное мнение, но противоположное. Однако обосновал это хоть как-то.
Для понимания кода компонента знать про МАААМ вообще не обязательно. Даже про работу «хелперов» $mol_mem и $mol_view знать надо не больше, чем «эта штука мемоизирует» и «эта штука — базовый класс».
Ну как это. У нас JS, а не PHP, в котором классы могут браться «из воздуха» благодаря авто-загрузке. В JS то что не импортировано, не существует в скоупе. Поэтому любому JS разработчику сперва нужно будет разобраться откуда взялись магические классы типа $mol_view и что это вообще.
В Svelte сверху файла просто и очевидно импортируются хэлперы с вполне говорящими именами, на которые всегда можно ткнуть и посмотреть их код. Сами хелперы как правило не более чем в 10-ток строк кода.
сперва нужно будет разобраться откуда взялись магические классы типа $mol_view и что это вообще.
- Не нужно.
- ctrl+click
- Импорты тут погоды не делают.
В JS то что не импортировано, не существует в скоупе.
Опять ложь. Собственно, это одна из основных претензий людей к вашему пиару — использование дешёвых полемических приёмов. Называете чёрное белым и думаете, что читатели схавают. Новички может и схавают. У всех остальных это вызывает лишь отвращение.
ctrl+click
Не знал что это работает с MAAM. Как реализовано?
Опять ложь.
В каком смысле ложь? Так работают модули JS или я не прав в этом? Глобалы конечно тоже работают, но глобалы как бы bad practice, поэтому о них говорить смысла нет.
Через глобальные переменные и реализовано. Вполне себе good practice: https://github.com/eigenmethod/mol/issues/285
почему во фронтэнде не прижился подход с JS-as-assemblyПотому что js вполне себе человекопонятный язык. Вы спокойно можете его читать, править и даже просто писать на нем. И Вам не нужно для этого objdump или подобных утилит.
Согласитесь, никто ведь не пишет в wasm файлы напрямую, то же касается elf и exe.
Хотя признаюсь, я в свое время писал руками числодробилку на asm.js, но asm.js тоже вполне человекопонятный, да и вызвано это было скорее тем, что emscripten в то время для абсолютно аналогичной функции на C генерил в 3 раза больше кода asm.js, чем я написал руками.
На днях пробовал svelte. Прикольный ничего не скажешь. Ничего не скажешь.
Я думаю судьба у него поболее чем у Polymer, который я так охотно изучил сразу после его анонса на гугл ио, что он и закончился на том же месте :))
Главное это экосистема, пока она не дорастет до реактовской или хотя бы vue — спорить рано.
Не могу не поправить фактическую ошибку в тексте:
И этот подход сильно отличается даже от Vue, в котором SFC не более чем более удобный способ записи Vue.extend.
SFC во Vue это просто способ группировки файлов, вместо трёх отдельных файлов для шаблона, скрипта и стилей вы имеете один файл. На картинке представлены этапы от декларативного кода до скомпилированного императивного. Всё это есть во Vue, на верхнем уровне вы оперируете декларативными шаблонами которые потом компилируются в императивные рендер-функции. Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) сами. В Svelte же мы ограничены исключительно декларативным подходом.
Ну и конечно не могу согласиться с тем, что Vue делает тоже самое что и Svelte. Скорее уж он делает тоже самое что React. Вся кодогенерация сводится в тому чтобы превратить декларативный шаблон в вызовы функций и подготовить это хозяйство к работе в рантайм.
Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) сами. В Svelte же мы ограничены исключительно декларативным подходом.
Да, это верно.
Удобство Vue в том что в каждый из этих этапов мы можем проникнуть и написать скомпилированный код (рендер-функцию) самиДа, можно написать код который генерирует дерево VirtualDOM, но при этом оно все равно будет иметь этап обработки в рантайме, прежде чем попадет в реальный DOM.
В Svelte же мы ограничены исключительно декларативным подходом.В Svelte императивный подход заключается в манипулировании нативным DOM с помощью небольших функций-хелперов из модуля svelte/internal
Никто не мешает сделать руками так:
import {
SvelteComponent, init, noop, not_equal,
create_component, mount_component, destroy_component,
insert, detach, element, text
} from 'svelte/internal';
class Component1 extends SvelteComponent {
constructor(opts) {
super();
let div, prop;
init(this, opts, ($$self, $$props, $$invalidate) => {
$$self.$set = $$updatedProps => {
('prop' in $$updatedProps) && $$invalidate(0, $$updatedProps.prop);
};
return [$$props.prop];
}, ctx => ({
c() {
prop = ctx[0];
div = element('div');
div.textContent = `Hello ${prop}!`;
},
m(target, anchor) {
insert(target, div, anchor);
},
p(ctx, [updates]) {
if(updates & 1 && prop !== ctx[0]) {
prop = ctx[0];
div.textContent = `Hello ${prop}!`;
}
},
i: noop,
o: noop,
d(detaching) {
detaching && detach(div);
}
}), not_equal, {});
}
}
class App extends SvelteComponent {
constructor(opts) {
super();
const comp = new Component1({props: {
prop: 'world'
}});
init(this, opts, null, ctx => ({
c() {
create_component(comp.$$.fragment);
},
m(target, anchor) {
mount_component(comp, target, anchor);
},
p: noop,
i: noop,
o: noop,
d(detaching) {
destroy_component(comp, detaching);
}
}), not_equal, {});
}
}
document.addEventListener('DOMContentLoaded', () => new App({
target: document.body
}));
Да не спорю, это совсем не
render(h) {
return h('div', 'Hello world!');
}
Просто это Вам попросту не нужно, все что обычно в vue решается самописной render функцией, в svelte гораздо проще сделать с помощью use:action
Но пиарят его полные мудаки и невежды
В каком месте? Во всей этой истории ответок «мудаки и невежды» как раз те, кто выступает против svelte.
Я вообще тут со стороны (бэкэнд моя стихия) пришел почитать, чего в JS творится, в котором я вообще не работаю и знать ничего не знаю, но до чего удивительно все это читать. Приходят люди, которые ничего не понимают ни в новой технологии, ни даже в той, которую сами постоянно используют, пишут технически безграмотный поток сознания, а в ответ получают просто аргументированные статьи как сабж. Но почему-то «мудаки и невежды» оказались последние. Как?!
Для интереса посмотрел доклад о 3 версии svelte — да это же очевидно. Нахера весь этот оверхед виртуальный домов? Это же полный абсурд. Фреймворк делает то, что обязан делать. Задает парадигму, освобождает разработчика от рутины, а за кулисами оптимизирует это максимально. Одних бенчмарков достаточно, чтобы понять — у svelte, или по крайней мере его подхода, светлое будущее гарантировано.
Когда впервые прочитал о svelte, подумал: наконец-то! Очень заманчиво, надеюсь завтра попробовать на практике.
Что касается личного опыта, после попыток написать что-то сложнее примеров из документации я плевался. Чувствуется недостаток гибкости после React. Идеологически мне не подходит. Но уверен, что Svelte сможет найти свою нишу.
Svelte, как и Vue — это просто развлечения их создателей, форма искусства, оторванная от практики. Как искусство они очень хороши, их изучать — одно удовольствие.
React и Angular — реальные инновации, они полезны экономически. Это просто совсем другой уровень. Комьюнити и коммерческие проекты — очень разные. И авторы комьюнити фреймворков принципиально не могут посмотреть на крупные коммерческие базы кода, их просто туда никто не пустит смотреть. Если их, конечно, не наймут в одну из таких компаний. Гвидо ван Россум сделал питон, потом его наняли в Google и он смог наблюдать, как его язык используется на практике и сделал python3, который стал конфликтовать с 2.7.
Можете сколько угодно писать, что Svelte «такой же, и даже лучше», но в действительности, единственная причина его появление — автору было скучно. Завтра он найдет себе другое занятие и кончится весь Svelte.
React и Angular — реальные инновации, они полезны экономически.
Svelte, как и Vue — это просто развлечения их создателей, форма искусства, оторванная от практики.
А мужики-то не знали, оказывается, что vue оторван от практики.
Монструозный ангуляр и реакторская мешанина — вот она, ваша инновация.
Я вам по секрету скажу, что проекты на 1С приносят ещё больше денег. При всех его недостатках, он позволяет сделать за час больше, чем на Реакте вы будете бойлерплейтить неделю.
Они создают проблем больше, чем решают.
Сотни разработчиков в фейсбуке и столько же в гугле дураки и не понимают ничего.
Вы делаете очень показательную ошибку: вы считаете, что люди в фейсбуке и гугле будут своими фреймворками главным образом создавать пользу для вас. В то время, как создают пользу они главным образом для себя.
Сможете ли вы отхватить ваш кусок добавочной пользы, или отхватите проблем больше чем пользы, или, хотя бы — просто больше проблем, чем вы изначально надеялись — вопрос очень открытый, если вы не гугл и не фейсбук.
ЗЫ: Но, разумеется, дев-коммьюнити svelte тоже решает проблемы дев-коммьюнити svelte, а не ваши. Другое дело, что к ним присоединиться куда как возможнее, чем к гуглу или фейсбуку.
Не знаю насчёт svelte и google, но мой первый же PR в фейсбуковский продукт был принят. С замечаниями, исправлениями, но принят.
А как еще-то, по-вашему, ценность опенсорса создаётся? Циничный корпоративный взгляд на опенсорс — это «они нам протестируют, пофиксят, и может быть даже разовьют софт, а мы будем стоять во главе процесса, и рулить, куда нам надо».
Это, конечно, не отменяет пользы для других людей, это не zero sum game, в конце концов. Я к тому, что конечно же PR будут принимать, если они укладываются в намеченную линию развития.
«они нам протестируют, пофиксят, и может быть даже разовьют софт, а мы будем стоять во главе процесса, и рулить, куда нам надо»
Раньше с таким лозунгом в некрупных компаниях продавали руководству выкладывание своих наработок в опенсорс, но практика показала, что если вы не гугл, ваша работа просто не будет никому интересна.
Раньше с таким лозунгом в некрупных компаниях продавали руководству выкладывание своих наработок в опенсорс, но практика показала, что если вы не гугл, ваша работа просто не будет никому интересна.
Вы всерьез что-ли думаете, что кроме творчества пера гугла в опенсорсе ничего интересного корпоративного нет? Лул.
Как раз таки море опенсорса — это вот проекты относительно некрупных компаний. Реакт нет, а вот MobX уже да.
Очень интересная мысль на самом деле. Создатель MobX устроился в фейсбук. Про его предыдущую компанию ничего не слышно, особой репутации как место с интересными инновациями она не заработала
Вы правы, сотни мух не могут ошибаться.
React и Angular — реальные инновации, они полезны экономическиИзвините, а в чем инновации в React?
Писать js прямо в шаблоне? — Было до него, шаблонизатор ejs, хоть и строковый, но позволял писать в шаблоне любой js, даже обычные циклы и if'ы
Компонентный подход? — Ну в принципе он давно известен в разработке UI, и даже в вебе он уже был в angular.js, в Elm, а может и еще где
Хм, может VirtualDOM? — Ан нет, Elm был как минимум на год раньше с этой идеей. И с идеей, что компонент — это просто функция, которая возвращает вьюшку. Притом это все было весьма достойно для универской курсовой, коей являлся Elm, но уж никак не для либы агресивно впариваемой большой корпорацией.
Что-то еще? А ничего больше в самом реакт и нет собственно. Просто распиаренный шаблонизатор с поддержкой компонентов и работающий на таком костыле как VirtualDOM.
Вы про искусство. Я же профессионально работаю фронтенд-разработчиком. Каждый день по 8 часов в день последние несколько лет. В работе реально помогает. Я и на ejs писал и на ангуляре первом — это все не то. Перечислять отличия бессмысленно, потому что все то же самое можно было сделать и раньше. Просто не удобно. Больше кода, больше ошибок, сложнее отлаживать, больше всяких нюансов неочевидных.
Можете считать React в мире фронта iPhone в мире смартфонов — инновация в объединение уже существующих технологий таким образом, что рынок "взорван". Если, что я далеко не фанат Apple, но отдаю им должное.
Конечно боятся. Вот сколько я ни пиарил $mol — не было ни одной негативной статьи (если не считать тот разгромный комментарий под последней статьёй, преисполненный боли и негодования от… неиспользования $mol). Всё потому, что можно без опаски просто игнорировать его существование и продолжать пилить подпорки к Реакту, тратя итерацию на то, что можно было бы сделать за день.
К вопросу о популярности svelte, первый раз увидел упоминания о нем здесь, на хабре. Так как решил его использовать для петпроджекта, то добавился в чат телеграма, чтобы задавать всякие нубские вопросы (так как я не фронтендер). Тогда чат насчитывал около 150 пользователей, а сейчас уже 1.5к юзеров, т.е. интерес есть.
В плане поддержки сообщества, топик-стартер и прочие участники чата всегда в этом чатике помогали с непонятными мне моментами по фреймворку и подключению внешних компонентов в него. Так что, если уж ТС — пиарщик на зарплате, то хорошо ему должны платить за постоянную помощь участникам коммьюнити и написание всяких демонстрационных заготовок кода, по наиболее частым вопросам.
В общем, хейта в сторону фреймворка не понимаю. Если он такой плохо, то зачем вы пытаетесь всех догнать и непременно об этом рассказать? Ну, это я к автору оригинальной статьи обращаюсь)
Но фронт, это какая-то чертовщина. Возможно, потому что его изначально проектировали не под то, во что он превратился сейчас. Возможно, из-за огромного количества разработчиков. Но что за напасть такая. Вначале я писал на jQuery. Потом перешел на angular.js — он предлагал слишком много вкусных фич, чтобы остаться в стороне. Сообщество создало под него огромную кучу плагинов и компонентов на любой вкус. Один лишь был недостаток — медленный рендер. Потом вдруг ангуляр превращается в тыкву, а нам предлагают вторую версию, настоящий энтерпрайз, в плохом смысле этого слова. Среди аналогов есть лишь реакт, который могли придумать только пхпшники — это ж надо было додуматься идти по пути смешивания кода и представления! Вдобавок этот ваш jsx еще и далеко не всеми редакторами поддерживался в плане подсветки синтаксиса. Но вот пришел vue, алилуйя! То, что действительно надо, он вобрал лучшее и из реакта и из первого ангуляра. Перешел на него несколько лет назад и до сих под не нарадуюсь. Сейчас к тому же под него экосистема есть — куча готовых компонентов, шикарные вещи вроде генератора статистических сайтов и многое другое. И тут такой приходит svelte, мол подвиньтесь, ребят. Я его еще не изучал, даже поверхностно, но понимаю, что если он действительно настолько хорош, как о нем говорят, то нужно будет не просто этот фреймворк изучить — какие проблемы пару вечеров потратить, но заново всю инфраструктуру изобретать. Ах да, это я еще не говорю про кофе-скрипт — покойся с миром, дружище!
И это ведь ни разу не предел. Браузеры будут и дальше внедрять новые штуки, жаваскрипт будет и дальше развиваться. Повторюсь, просто потому что во фронте как бы не больше разработчиков, чем во всех остальных сферах, вместе взятых. И это значит, что каждые 5 — 10 лет будет появляться новый фреймворк, с новыми принципами построения приложений, и надо будет делать заново абсолютно всё.
Когда пишешь какую-то либу на беке — это инвестиция. Один раз написал, потом просто поддерживай и обновляй под изменившиеся реалии. Когда делаешь то же самое для фронта — ты заранее знаешь, что твоя новая либа улетит в мусорку через пару лет.
А насчет руби, переход с него как раз вполне начался, когда многим надоела медлительность рельс и руби. Тоже самое с питоном на бэке. Но это тектонический сдвиг, такие вещи не происходят каждый день. И то, просто так не получится взять и отказаться от монолита на рельсах. Вижу, что люди по-кусочкам отщипывают куски системы в сервисы на других технологиях.
Но фронт, это какая-то чертовщина.
Сомнительное заявление. Я десять с лишним лет назад писал на JS, пять лет назад писал на JS, год назад писал на JS, и сейчас всё еще пишу на JS. Ну, на TS, конечно, но это одно и то же.
Ни разу не видел смысла «писать на фреймворке», и до сих пор не вижу. Хотя, разумеется, пользуюсь ими. Тем не менее, использование жквери, реакта, ангуляра, вью, и так далее — не означает, что нужно прям писать на жквери, реакте, ангуляре, вью, и так далее. Более того, этого достаточно легко не делать. Кроме как с ангуляром — но и там есть пути не слишком-то зацикливаться на нём самом.
Пишу либы на ваниле плюс плагины, никуда ничего не улетает. Последнее время оцениваю фронтенд с точки зрения удобства интеграции с ванилой, у свелт с этим все нормально. С бэком конечно проще всего, согласен.
Среди аналогов есть лишь реакт, который могли придумать только пхпшники — это ж надо было додуматься идти по пути смешивания кода и представления
Поставил минус за это предложение. Такое может написать только человек с катастрофическим незнанием матчасти. Представление – это тоже код. Что плохого в смешивании кода и кода?
Но замечу, что есть код декларативный, а есть императивный. К примеру, считается хорошим тоном не смешивать строки на sql с инструкциями на %select_your_language%. Точно так же любой вменяемый фронтендер посоветует заменить
<div style="background-color: red;"></div><div class="bg-primary"></div>.bg-primary {
background-color: red;
}Так почему же позволено смешивать html и javascript? Потому что так делает Фейсбук? Они, конечно, молодцы, но не на столько, чтобы воспринимать любую их идею на веру без должного обдумывания.
А если это для вас не аргумент, то подумайте вот о чем. В большинстве компаний существует разделение прав. Зачастую верстальщик и фронтендер — это разные роли и разная квалификация. В чистом html верстальщик разберется без проблем; html с вкраплениями инструкций вроде
<span>{{user.name}}</span>К примеру, считается хорошим тоном не смешивать строки на sql с инструкциями на %select_your_language%.
Все правильно, считается. Потому что SQL и языки программирования исполняются в разных контекстах, поэтому нужно разделение чтобы избежать конфузов. Аналогично не стоит смешивать JS (который исполняется в браузере) и PHP (который исполняется на сервере). А вот JS/HTML/CSS все вместе предназначены для браузера, поэтому в их смешивании противоречий нет.
Точно так же любой вменяемый фронтендер посоветует заменить [инлайновые стили на отдельный CSS]
Здесь причина в переиспользуемости (чтобы стили определялись в одном месте, а не на каждом повторяющемся элементе). По возможности, во фреймворках (Svelte, Vue.js, lit-element и др.) стили компонентов определяются в том же файле, что и JS/HTML, потому что удобнее видеть все в одном месте.
Так почему же позволено смешивать html и javascript? Потому что так делает Фейсбук?
Реакту уже 6 лет и его используют много где. Время показало, что такой подход имеет право на жизнь.
Зачастую верстальщик и фронтендер — это разные роли и разная квалификация.
Да, такое разделение есть. Однако это не означает, что верстальщики не пишут Javascript. Скорее наоборот – для написания более-менее сложных анимаций и взаимодействия с пользователем им нужен Javascript.
И здесь объединение html+js дает пользу – верстальщики могут оформить независимую библиотеку UI-блоков с внятным API, а фронтендщики уже натянут на это дело бизнес-логику.
Чистые/тупые react компоненты — тот же html с вкраплениями js. Хорошо, пускай js с вкраплениями html. Но, в мире PHP верстальщики уже пару десятков лет пишут шаблоны на PHP с вкраплениями HTML. И нормально, не без проблем, но нормально. Да и с другими языками много где подобное наблюдается.
Не любой. В некоторых фреймворках вёрстка жёстко отделена от логики. В некоторых нет ни html, ни js.
В некоторых фреймворках вёрстка жёстко отделена от логики
В каких? Везде есть псевдокод, типа v-model, *ngFor, который есть видоизмененный js.
JSX делает тоже самое, хотя конечно подход с валидным html мне лично симпатичнее.
В некоторых нет ни html, ни js.
Ага, зато есть очередной бегемот, который надо осваивать.
Хотя это все мелочи, как именно передаются пропсы/инпуты это не важно.
Для меня важно когда фреймворк предоставляет подобие архитектуры, т.е. является фреймворком. И тут Angular вне конкуренции. Vue тоже стремится, но там слишком много магии.
В каких?
$mol, например.
который надо осваивать
Какой ужас, инструментом надо учиться пользоваться.
Для меня важно когда фреймворк предоставляет подобие архитектуры, т.е. является фреймворком. И тут Angular вне конкуренции.
У него отвратительная архитектура так-то.
Vue тоже стремится, но там слишком много магии.
А где мало магии?
Хотя это все мелочи, как именно передаются пропсы/инпуты это не важно.
Для меня важно когда фреймворк предоставляет подобие архитектуры, т.е. является фреймворком. И тут Angular вне конкуренции.
В этом вы правы, но есть один момент, который упускается из вида, потому что кто-то когда-то решил поставить в один ряд React, Vue и Angular. Хотя по-сути это не верно.
В данном случае Angular действительно вне конкуренции, просто потому что это фреймворка другого уровня. В отличии от React, Vue и Svelte, которые являеются UI фреймворками, Angular — это полноценный Application фреймворк и его имеет смысл ставить в один ряд с такие фреймворками как Ember и другими.
Показательным является то, что поверх каждого из UI фреймворков, также есть и Application фреймворк для создания сайтов и не сложных приложений. Для React это Next, для Vue — Nuxt, для Svelte — Sapper. Именно эти Application фреймворки и дают ту саму архитектуру, работу с роутингом, данными и т.п., а не только работу с view-слоем.
не стоит смешивать структуру страницы и её внешний вид
Так то оно да, но… вы именно это и сделали:
<div class="bg-primary"></div>
.bg-primary { background-color: red; }Просто теперь вместо inline-стилей у вас стиль зашит в class-name :-) Слово "bg-primary" никак не отражает "структуру страницы"
ваше замечание было бы более верным, если бы я назвал класс «bg-red».
ну ведь вы его так и назвали :) следите за руками:
<div class="bg-primary"/>
<div style="background-color: var(--primary-color)"/>- В случае классов, вам придётся переименовать класс
bg-primaryвbg-gradient,bg-image, а затем поправить стили. - В случае atom-css, только стили.
- В случае структурного именования только стили, потому что роль не поменялась, а в классе отражается только роль.
С primary проблем нет. Проблема в bg, которая предполагает задание исключительно фона. У вас либо вёрстка диктует какие стили можно менять. Либо вёрстка начинает врать, утверждая bg, а на деле получая изменённый border-radius.
Чтобы легче было увидеть разницу, давайте не div рассмотрим, а button. У нее может быть класс btn-primary, т.е. кнопка основного действия. И под этим классом могут быть десятки css свойств — цвета, шрифты, отступы и тд.
Среди аналогов есть лишь реакт, который могли придумать только пхпшники — это ж надо было додуматься идти по пути смешивания кода и представления!
Я эту аргументацию встречал и вызывала она у меня легкую досаду. Вроде бы все правильно человек говорит: вот в одном файле и разметка и js. Но где-то тут есть доля недопонимания.
Смешать тэги и js, и смешать модель, представление и контроллер — это далеко не одно и то же. В react за модель отвечает стор — redux, relay, mobx, effector, за контроллер отвечает роутер, а все что есть в jsx — это вид. Да там дополнительно присутствуют еще обработчики разных кликов или других событий — но это не контроллер и не модель. Если конечно сознательно не поместить год модели или котроллера в jsx что технически возможно но так никто не будет делать.
redux, relay, mobx, effector
Это не React и даже не часть React, а по сути даже не часть экосистемы React. Redux/Mobx/Efector юзают и со Svelte.
С другой стороны в реакт есть свой стейт-менеджмент. Изначально setState, с недавнего времени хуки. Последние вообще в последнее время являются чуть ли не самым рекомендованным средством, а ведь они пишутся прямо в рендер-функции и дергаются при каждом ререндере.
Исходя из этого, делаем вывод, что разработчики, использующие React, в целом умны и понимают все то, о чем вы написали. Многие действительно держат представление отдельно от модели и все такое. Однако, сам по себе React никак этому не способствует, а наоборот выкатывает все больше способов менеджерить модель прямо внутри представения.
Раньше все это хотя бы было размазано по классу, его свойствам и методам. С приходом хуков все засунули в рендер-функцию, а это примерно то, о чем написал Kroid
То что стор это не часть react с точки зрения так сказать физической — не меняет того факта что js в реакт не является моделью. state внутри компонента отбюросило меня на пару лет в изучении реакта т.к. я не понимал зачем о нужен и его использоване приводило к разным противоречивым решениям. Но сегодня мы в той точке в которой находимся. У нас есть сторы для реакта. С хуками я честно говоря еще не разбирался, вообще. Из новшеств меня больше заинтересовала suspense которое почему-то никак не зарелизится.
state внутри компонента отбюросило меня на пару лет в изучении реакта т.к. я не понимал зачем о нужен и его использоване приводило к разным противоречивым решениям.
Я сразу написал что это так. Что впрочем не отменяет того факта, что многие проекты использовали state именно как модель. Да и Redux далеко не сразу появился. То есть по-сути, авторы React зашипили его именно со state и именно так предполагали использовать. Это потом они сами же схватились за головы и придумали Flux/Redux.
С хуками я честно говоря еще не разбирался, вообще.
А я уже успел. И важно здесь именно то, что это опять же результат мыслительной деятельности авторов React. Не сообщества, которое положим понимает что мешать модель и представление вредно, а именно core-team реакта. А значит, по-сути своей это и есть истинный react-way.
Из новшеств меня больше заинтересовала suspense которое почему-то никак не зарелизится.
Самое интересное, что suspense точно также реализуется внутри рендер-функции и за счет ее перезапуска на каждый рендер, то есть точно также лезет в представление.
Проблема со стором которого нет в реакте относится не только к реакту. Это общая боль всех фрондендов. И наличие из коробки однонаправленный связности как в рекомендовано в реакте или двухсторонней связности как в других продуктах не решает проблему стора, модели собственно. То что реактовский state практически бесполезен а стор реализован отдельно ровно ни о чем не говорит. Т.к. state практически не используют, его просто де факто нет. А стор есть хотя и не реактовский.
Реактовский идея с односторонним потоком данных мне сейчас ближе. Хотя когда то я восхищался backbone binding который был построен как раз на двухстороннем связывание и работал кстати очень нестабильно.
Вцелом, я практически не выделяются ни один из фреймворков т.к. все они очень схожи.
То что реактовский state практически бесполезен а стор реализован отдельно ровно ни о чем не говорит. Т.к. state практически не используют, его просто де факто нет. А стор есть хотя и не реактовский.
На самом деле state юзают очень много кто. Да и старых проектах на state еще навалом. Сами такие время от времени разгребаем.
Проблема со стором которого нет в реакте относится не только к реакту. Это общая боль всех фрондендов.
В целом то вы все верно пишете, но у меня тогда вопрос. Если это «общая боль» и все такое, то почему Svelte поставляется со встроенным решением для стора (пусть и весьма примитивным, но зато расширяемым), а ребята из React, которые как вы думаете все понимают, вместо того, чтобы в новой версии React поставить встроенный react-way стор, предлагают для управления стейтом вовсе не стор, а хуки, которые пишутся прямо внутри рендер-функции и, несмотря на свое удобство и лаконичность, кажется довольно сильно сказываются на производительности и требуют постоянных оптимизаций (все эти memo-)? И видимо в качестве насмешки, хуки презентует автор наиболее популярного в React решения для сторов.
Я понимаю, что вы не инсайдер, но давайте попробуем хотя бы предположить почему так происходит.
Наконец бегло прочитал за хуки. Название не самое подходящее. По сути то же state только для stateless компонентов. Собственно этим из появление наверное и объясняется что разработчики хотят state в stateless компонентах.
Кажется будет еще одна мало востребованная фича.
Кажется будет еще одна мало востребованная фича
Наоборот. Class-компоненты полуофициально deprecated. По сути писать в новом коде их сейчас — закапывать проект на старте. А в функциональных компонентах в вашем распоряжении только хуки. Так что вы либо пишете с хуками, либо не используете state вообще, либо пишете legacy.
Я имел в виду что все используют stateless компоненты но не могут использовать с ними state (который и не нужен). Вследствие чего появились хуки, которые хуки (а не stateless компоненты) также мало будут востребованы как и state.
который и не нужен
мало будут востребованы как и state
WAT? В смысле не нужен? В смысле мало востребованы? Ради интереса проверил в текущем проекте у нас 94 useState и 1316 use[A-Z]\w+\(. Как не нужен?
Видимо я вошел в реакт когда stateless было самым что ни на есть react way. И на этом и остановился, и внутренне с этим согласен. Я опять же воспринимаю state не как модель а как некоторое дополнение к view. Поясню что я имею в виду. Например классическая задача — профайл нужно поменять скажем email. Перед тем как окончательно изменить модель, в смысле стор, email валдируется на сервере. Естественно до валидации на сервере в сторе новый email менять не кажется хорошей идеей. Годе же хранить новое значение в этом случае? Проанализируем варианты: добавить в стор новое поле условно скажем newEmail — не очень. Брать значение прямо из input — в приниципе получше, но слишком близко к браузеру. И вот тут если связать input с переменной state — мне такой вариант больше нравится. Но ведь согласитесь это это почти то же самое что взять из input. Поэтому state в этом случае не является моделью. Это по функции своей — view. Это вот основной кейс где мне кажется оправданным как использование state так и хуков.
В случае использования store (скажем redux или useReducer уровнем выше):
- значение email и других полей формы храним в store
- данные о dirty, validation, touched и пр. и пр. в state
- всякие флаги loading, error, анимации и пр. тоже в state
- всё что только можно нигде не храним а высчитываем
В случае неиспользования store всё тоже самое, но ещё и значения формы (email, login, whatever) тоже храним в state (но в другом state).
А вообще мне кажется redux надо запретить в первые годы использования React, чтобы он не травмировал представление о React и SPA в целом :D
Люди начинают мыслить очень узко и не видеть всей картинки. Всё пихать в стор, плодить мульёны файлов, а потом героически со всем эти сражаться, когда минорные фичи задевают 250 файлов в разных частях приложения. Зато dump components, lol
-данные о dirty, validation, touched и пр. и пр. в state
…
А вообще мне кажется redux надо запретить в первые годы использования React, чтобы он не травмировал представление о React и SPA в целом :D
Люди начинают мыслить очень узко и не видеть всей картинки. Всё пихать в стор, плодить мульёны файлов, а потом героически со всем эти сражаться, когда минорные фичи задевают 250 файлов в разных частях приложения.
А мне кажется совсем наоборот — это до тех пор пока связанность фич в проекте небольшая и не будет увеличиваться то можно позволить изолировать стейт в отдельных компонентах и не выносить в глобальный стор.
Но если появится какая-нибудь задачка, например — в совсем другой части приложения, на другой странице нужно при доступе к чему-то проверить что юзер заполнил форму и показать надпись, мол "друг, дополни эти поля которые ты начал заполнять и исправь такие-то поля которые невалидны" то всё, приехали — вам придется теперь выносить состояние полей — dirty, validation, touched которое раньше хранилось внутри одного компонента в общий стор потому что теперь эта информация нужна в совсем другой ui-ирерахии компонентов и соотвественно вместе с вынесением потребуется переписывать весь код работы с этим состоянием.
А вот если бы статусы полей формы изначально хранились в сторе то вам бы не пришлось бы переписывать уже существующие компоненты и фичи
А заказчику или продакт-менеджеру ведь не объяснишь что мол какая-то новая фича требует каких-то там непонятных архитектурных изменений — заказчик обычно думает о фичах в контексте того что можно делать любые проверки или отображать любую информацию в любой части приложения.
И я еще не видел ни одного проекта (который развивается и постоянно требует добавления новых фич) в котором бы решение изолировать какое-то состояние не приводило бы к проблемам — я вижу явную тенденцию что в любом развивающемся продукте количество фич и связность между ними будет только увеличиваться а значит решение изначально хранить любое состояние приложения в глобальном сторе более чем оправдано
Не согласен. Использование очень многих стейтов никогда не вылезет больше одного места, поэтому поднимать их или делать глобальными смысла нет, только усиливает когнитивную нагрузку на того, кто пытается разобраться, а что система в принципе делает, а не почему валидация не срабатывает на граничных значениях.
Вот что важно, при таком подходе — механизм локального и глобального стейта должен быть один (я не помню redux просто не рекомендует делать несколько сторов или технически не позволяет?). Тогда перенос стейта вверх при возникновении необходимости будет простой задачей, как и ожидает бизнес. Ну либо рука должна быть набита на перенос с setState/useState на глобальный стор, чуть ли не ежедневно такие задачи решать надо. На ваших проектах какое условие выполнялось?
При этом будет какая-никакая инкапсуляция. Как минимум разработчик может легко оценить что не могут задеть планируемые им изменения. А с глобальным стором это отдельное исследование надо проводить, и, не дай бог, TypeScript на проекте не используется, а ещё хуже, используется неправильно.
Описанная вами проблема наблюдается лишь во фреймворках, не умеющих в двустороннее связывание. Так что честный ответ менеджеру выглядел бы так: мы выбрали кривой фреймворк, который требует либо сразу много бойлерплейтить и писать непереносимый код, либо как сейчас, делать это, когда нужно, казалось бы, простое изменение.
Вот: codesandbox.io/s/nostalgic-hofstadter-ogbkw
Это не двустороннее связывание, а инъекция зависимостей. Пока вы стор не заинъектите, компонент не заработает. И наоборот, там где создали стор, там его уже не привязать ко внешнему стейту.
То, что без двустороннего связывания вам пришлось вкорячивать костыли с передачей обёртки вокруг значения, чтобы обмануть Реакт. Вы не замечали, что Реакт вам тут только палки в колёса вставляет, и ничем не помогает?
Смотрите, я переписал ваш код на $mol с двусторонним связыванием:
$my_input $mol_view
dom_name \input
attr * placeholder <= hint \
field * value <= value?val \
event * change?ev <=> change?ev null
class $my_input extends $.$my_input {
change( ev : Event ) {
this.value( event.target.value )
}
}
$my_select $mol_input
dom_name \select
options *
\
<= empty @ \No options
Option!id $mol_view
dom_name \option
attr * value <= option_key!id \
sub / <= option_title!id \
class $my_select extends $.$my_select {
sub() {
return Object.keys( this.options() ).map( key => this.Option( key ) )
}
option_key( key : string ) {
return key
}
option_title( key : string ) {
return this.options()[ key ]
}
}
$my_header $mol_view dom_name \h1
$my_app $mol_view
sub /
<= Title $mol_header sub / <= title @ \Hello CodeSandbox
<= Name_first $my_input
value?val <=> name_first?val \
hint @ \First name
<= Name_last $my_input
value?val <=> name_last?val \
hint @ \Last name
<= Gender $my_select
value?val <=> gender?val \male
options *
male @ \Male
female @ \Female
<= Output $mol_view sub / <= output \
class $my_app extends $.$my_app {
output() {
return JSON.stringify({
name_first: this.name_first(),
name_last: this.name_last(),
gender: this.gender(),
}, null, 2)}
}
}Кода получилось меньше. Сам по себе он проще. Добавилась поддержка локализации и кастомизации.
Вот представьте теперь, что вам надо снаружи этой формы иметь информацию о выбранном поле, чтобы, например, рисовать няшную шапку приложения для девочек.
В моём коде даже не придётся ничего менять для этого. Просто пишу внешний компонент и связываю его с нужными полями внутреннего:
$my_portal $mol_page
attr * my_portal_theme <= theme
body /
<= Sign_up $my_app
gender => themeПричём тут используется даже не двустороннее связывание, а правостороннее. То есть само значение по прежнему хранится в форме, а не переносится наверх. А на верху просто создаётся делегат, через который доступно нужное поле формы.
Согласен. Двухстороннее связывание решает эту проблему (если правильно его спроектировать и запретить локальное состояние и оставить только это самое связывание и динамическое добавление полей) но на текущий момент у реакта, jsx или даже js есть фундаментальные ограничения которые не позволяют использовать эту фичу удобно и в полную силу (предполагаю поэтому и нужны шаблоны $mol потому что в жс описывать такие связи получится неудобно или нетипизируемо)
Вообще-то "двухстороннее связывание" вообще очень редкий зверь и похоже нигде кроме $mol его нет.
С первого взгляда даже может показаться что двухстороннее связывание это просто способ избежать болерплейта передачи вложенному компоненту вместе с переменной заодно и коллбека на ее изменение. Но если представить что мы во вложенном компоненте объявляем состояние только в том объекте который нам передал родительский компонент (а он в свою очередь храниться в свойстве объекта который был передан еще выше и т.д по цепочке) то в итоге получится что с одной стороны у нас как бы есть концепция "локального состояния" — любой компонент на любой глубине ui-дерева может объявить переменную состояния без необходимости декларировать где-то в другом месте (в родительском компоненте или например с глобальном сторе) а с другой стороны все это состояние на самом деле хранится в дереве единственного root-объекта и к состоянию любого глубокого компонента можно добраться извне или с любого компонента в любой другой части ui-иерархии
Да не, в TS связи замечательно описываются:
class Input {
@ $mol_mem
value( next = '' ) { return next }
}
class Form {
@ $mol_mem
name( next = '' ) { return next }
@ $mol_mem
Name() {
const input = new Input
input.value = next => this.name( next )
return input
}
}view.tree нужен в большей степени для описания плоского класса в виде дерева компонент.
Вот только ваше input.value = next => this.name( next ) — это такая же "борьба с фреймворком", как и использование { value: null }, в котором вы обвиняете сторонников React.
Будь у вас name не просто методом, а объектом первого класса — вы бы могли написать простое присваивание input.value = this.name. А вы не можете.
Как раз таки наоборот. Тут фреймворк помогает организовывать связывание максимально простым удобным и эффективным способом. Связывать поля в JS далеко не так лаконично и производительно:
class Input {
value = ''
}
class Form {
name = 'Jin'
@ $mol_bind_having({ value : 'name' })
Name = new Input
}Я пробовал, не зашло.
Но если появится какая-нибудь задачка, например — в совсем другой части приложения, на другой странице нужно при доступе к чему-то проверить что юзер заполнил форму и показать надпись
Если бы да кабы. Появится — отрефакторим и вынесем нужные вещи повыше. Поймите, redux это как глобальная переменная. Это сильный antipattern, который однако, как и любой, антипаттерн может быть когда-нибудь в каких-нибудь ситуациях полезным. Но выносить всё подряд в глобальные переменные, чтобы потом связать те вещи, связав которые в обычных приложениях, люди подвергаются порке на code review…
И я еще не видел ни одного проекта (который развивается и постоянно требует добавления новых фич) в котором бы решение изолировать какое-то состояние не приводило бы к проблемам
Собственно изоляция одних вещей от других. Т.е. разделение ответственности это одна из самых главных мантр любого проекта больше 10 строк. Этому просто нужно учиться.
Если перед вами встала новая задача, которая решается не тривиально, и вы вместо того, чтобы обдумать почему старая версия data-flow не решает новые проблемы, просто сделали всё глобальным и связали как удобно будет, то у меня для вас плохие новости. Вы сами копаете себе могилу и загоняете в technical debt.
а значит решение изначально хранить любое состояние приложения в глобальном сторе более чем оправдано
Храните всё в глобальных переменных тогда уж. Вдруг понадобится.
Ужас. Нет, серьёзно. Зря вы взялись за redux. Он вас откинул в средневековье.
Если совсем коротко. В программировании есть 2 большие проблемы (на самом деле больше):
coupling: coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are;[1] the strength of the relationships between modules. Чем меньше модули друг на друга завязаны, тем проще код, тем дешевле он в поддержке, тем проще его тестировать, тем меньше багов, тем проще вносить новые фичи. Особенно плохо когда 1 модуль завязан на мелкие нюансы другого.
coherence: it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. Чем меньше задач решает отдельно взятый сегмент кода, тем лучше. Он должен делать только 1 задачу, но делать её хорошо.
Вот если придерживаться этих двух критериев, то глобальные переменные это зло. У вас разные сегменты кода начинают базироваться друг на друге, да ещё и на кишках друг друга, а не на некоем публичном API. Высокая связанность, многоцелевые компоненты. И всё это в пару кликов клавиатуры. Воткнул connect — фича работает, все довольны? Хах, как бы не так. Вы только что воткнули себе нож в спину.
Чем меньше модули друг на друга завязаны, тем
проще код, тем дешевле он в поддержке, тем проще его тестировать, тем меньше багов, тем проще вносить новые фичи.
Одно не следует из другого. Например, часто в погоне за "развязыванием" люди пишут Enterprise FizzBuzz, который нифига не проще, не дешевле, требует много времени на тестирование, а внедрение новых фич осложняется сотней лишних промежуточных абстракций.
Чем меньше задач решает отдельно взятый сегмент кода, тем лучше. Он должен делать только 1 задачу, но делать её хорошо.
Лучше для кого? Пользоваться таким кодом существенно менее удобно, работает он медленнее, а понятие "задача" вообще не имеет чётких границ.
Вы не находите, что есть некоторая разница между Enterprise FizzBuzz и простым локальным состоянием?
nin-jin ну сие есть не догмы, а идеал к которому нужно смтремиться. Одно как раз следует из другого. Меньше связей, меньше мест где-то "что-то устроено" хитро, где связаны вещи неочевидно, где одно влияет на другое, непредсказуемым образом. Очевидно что без связей совсем ничего не получиться. Но плодить эти связи бездумно левой пяткой это безумие. Каждый раз столкнувшись с тем, что мне тут чего-то не хватает, а оно далеко лежит, вместо того чтобы напрямую туда дотянуться и взять как есть, надо хорошо подумать, а как решить этот вопрос правильно, чтобы уже завтра не проклинать себя в том, что теперь наш код это чёртово месиво в котором и пикнуть нельзя без непонятных сайдэффектов.
nin-jin, come on, я понимаю что ты маргинал и всё такое, но как можно спорить с low coupling high cohesion?
глобальные переменные это зло
Ну да, конечно… Если не умеешь, не берись.
Не надо тут навязывать свое мнение о зле и добре, если вы не умеете готовить глобальный стейт или глобальные переменные, то это сугубо ваши проблемы и недостатки, а не тех, кто умеет и пользуется преимуществами.
если вы не умеете готовить глобальный стейт или глобальные переменные
Сможешь доказать, что я не умею готовить глобальный стейт и глобальные переменные?
Сможешь доказать, что я не умею готовить глобальный стейт и глобальные переменные?
Если глобальный стейт вызывает у вас негативные эмоции и то, что это «нож себе в спину», значит не умеете.
значит не умеете
Хорошо, на том и порешим.
Если лично для вас это зло, то причем тут остальные то? Остальные извлекают из этого максимальную выгоду.
В неумелых руках и спички зло.
Глобальный стейт это инструмент. Известный anti-pattern, который, как я уже писал выше, бывает удобным. Я не то, чтобы против anti-pattern-в. Я сам использую redux. Насколько он "зло", а насколько "добро" вопрос дискуссионный. Выше обсуждается, что делать всё подряд, включая любые кишки, глобальным, чтобы в этому можно было подцепиться из любой точки приложения — это зло. Это очень грубое срезание углов, которое обязательно аукнется в проектах, которые не write-only.
В неумелых руках и спички зло
Давай ты прекратишь писать про то, какие все вокруг идиоты, а ты один очень опытный и всё понимающий? Прямо тошно читать твои кислотные комментарии из статьи в статью. Вот буквально везде — вижу ник MaZaAa, уже знаю, что сейчас будет попытка самоутвердиться вида: "Я весь из себя опытный такой опытный погромист и понимаю что X это Y, и только нубы пишут Z". Из раза в раз. Даже nin-jin пишет скромнее (а у него ведь опыта и понимания куда поболее твоего будет).
Давай ты прекратишь писать про то, какие все вокруг идиоты, а ты один очень опытный и всё понимающий?
Правда, вот прям так и говорил и говорю? Что все вокруг идиоты? Интересно.
Это мне говорит тот, кто пишет такое?
Вот если придерживаться этих двух критериев, то глобальные переменные это зло. У вас разные сегменты кода начинают базироваться друг на друге, да ещё и на кишках друг друга, а не на некоем публичном API. Высокая связанность, многоцелевые компоненты. И всё это в пару кликов клавиатуры. Воткнул connect — фича работает, все довольны? Хах, как бы не так. Вы только что воткнули себе нож в спину.
Далее
Вот буквально везде — вижу ник MaZaAa, уже знаю, что сейчас будет попытка самоутвердиться
Вам не кажется, что это вы сейчас пытаетесь самоутвердиться за мой счет?
Негативные эмоции и, тем более, образные выражения никак не свидетельствуют о неумении. У меня негативные эмоции всегда вызывают ситуации, когда я вынужден выбирать меньшее зло.
Кстати, ваш пример почему-то напомнил вот этот доклад. Доклад отличный, но после того как видишь насколько сложным может быть код на React + Redux для столь простого кейса, удивляешься стойкости ребят, пишущих на React.
React !== Redux и даже !== Flux
Мне кажется все success story c Redux так или иначе завязаны с полным его переосмыслением и изменением до неузнаваемости. К примеру у меня так. Мне очень нравится концепция immutability + predictability + one way driven dataflow. Мне не нравятся лишь многие частности которые ассоциируются именно с redux-way, которые по сути весьма опциональны. Тот же pub/sub, или string-actions. Когда начинаешь всё это дело переделывать под свои нужды получается интересно. Но это уже, наверное, не redux.
В redux-way изначально заложили архитектуру под чуть ли не проект уровня babel или webpack. И все побежали его везде ставить. Очень часто зря. Самое стрёмное когда некоторые интересные идеи оттуда (вроде dump components) доводят просто до состояния безумия (вроде полного отказа от state). Какого-то фанатизма. Ни к чему хорошему это не приводит.
Это просто потрясающий ответ. Именно так и нужно бороться с мракобесием. Проблема современного мира заключается в том что у каждого сегодня есть доступ в интернет и острое желание что-то написать, но мозг и компетентность к сожалению есть далеко не у каждого. Со стороны Хабра мне кажется нужно уже вводить какие-то предварительные тесты тем кто пишет статьи, чтобы проверить на сколько они вообще в праве что-то писать по выбранной теме. Возможно тогда мы сможем получить более адекватное представление о технологиях, а не больные высеры некоторых неадекватов у которых весеннее обострение в разгаре
А еще нет нормального репозитория UI компонентов, например как vuetify, element-ui итп…
А еще есть куча готовый админок на базе этих UI компонентов.
А еще есть даже генераторы админок на базе этих UI компонентов.
Так что идеи и подход Svelte действительно интересны, но блин да, инфраструктура решает.
Svelte может себе такое позволить, так как если Вы это не используете, этого не будет в бандле
Насчет роутера, почему то в React никого не смущает, что людям нравятся разные роутеры с разной архитектурой. Vue тут скорее исключение, что есть 1 вариант и костыли вокруг него, чтоб эмулировать другие подходы к роутеру.
Загляните сюда, здесь лишь малая толика отборного, из всего того, что есть:
github.com/TheComputerM/awesome-svelte
Svelte, исчезающий фреймворк, который уже не исчезнет